D.A.Alderson 23/01/2015
DOC for future considerations informed by very lengthy thread in Gen Dev forum Moodle.org
**NOTE** I have not included plain JS/links with Element lib: reasons....appeared un-established by itself (in terms of Moodle), but useful as a blend with one ort’other in table: e.g. one poster stated: I think plain JS for core, critical parts of Moodle, and jQuery for less critical parts of core and as the officially supported framework available for plugins. It therefore might be an idea to have discussion about the minutiae for plain JS in a new forum in the future. In sum, it remains unsubstantiated across the 166 posts in general.
**2ndNOTE** Ditto for small –specialist/third party libs like Rangy (Hope I got that right!)
Outcomes from Dev meeting 20 Jan: With all these libraries in place you can create a JS module simply by creating a modulename.js file in the "amd" folder for your plugin.
DOM Manipulation/cross browser normalization: JQuery
Accessible widget library: JQuery UI but we need to wrap it to make it work with our theme system and improve the accessibility
Javascript Module format: AMD
Javascript Loader: RequireJS
Javascript build tools: 2 options - "None" or "Grunt" - we need to decide this.(Table 2.)
Table 1.
JS Lib / Pros / Cons / Implications / Transition to JQuery / *Successful Atto migration
*Popularity
*Evolving pointer/touch events models
*wontbreak backward compatibilty.
*A JS library with more extensive UI support
*Minimal modifications that won't create a separate version from the rest of the world
*Enabling a modular framework that will allow calling any needed component without special requirements.
*can coexist with YUI, as it already does today, and does not require reworking our class/id names. A gradual transition is possible.
* It does not have a single large corpsponsor, it is a more organic community. This is effectively what hurt us with YUI -- folks flocked to it because of Yahoo, but that also limited its community-driven development.
* It covers a lot of web browser compat; that is a very large surface we do not have to contend to. / * Technical arguments
*Longevity / *an established culture...out there...for development and ease of transition in Moodle
*Comprehensive Mobile support? So plus Embed??
*Atto could migrate to JQuery fairly easily if it has to.
*Plugin ecosystem
*theme development
*UI work
* Poss support for new devs to be innovative with something they already know
*To continue to have a robust system for plugins, and to enable ease for contribution.
*could try to integrate GPL code like an editor pluginthoat uses JQ.
*modular framework
* Consistency
*web developers know it
* there are millions of plugins, examples, tutorials etc
* it has been around a long time, so it has a huge user base
* it has backing from deque (accessibility)
* it has many big name corporate backers (resilient funding sources)
* it is not so different to YUI
* it works
AngularJS / *Angular can tie in with jQuery for UI/DOM manipulation support.
*from 2.x.x release with ES6 integration
*might be useful for all the backend JS
*Separation of presentation, data and logic
*templates that contain html with handlebar style fields inside.
*establish relationships between elements without
having to actually code any js.
*Data models map to handlebar fields in templates
*If your data is an array its easy to loop through using an each function.
*Routing
*two-way data binding
*possproper MVC design framework / *slow
*likely to die (1.3.x)
*Moodle has its own ways to separate data, presentation and logic (e.g. renderers) which work in PHP on theserver-side, and have nothing to do with JavaScript.
*JS in Moodle-thus, could mean a complete re-write
*Angular is designed with node.js and no-sql-databases like MongoDB in mind so this would require quite a bit of dual-logic (client-server) if Angular is not embraced completely.
*With angularjs it inefficiently re-runs ALL functions per element change
*Long term commitment to achieve full migration
EmberJS / *positive sounds about string templates
*Emberjs enables you to bind functions to data relationships which means that when you update one element on the page (e.g. a form field) then anything that is dependent on that field via a function gets updated.
*A full Single page application (SPA) should use Ember.js as it imposes convention (which Moodle desperately needs). Building an SPA will also bring the core developers that much closer to building Apps, as you can use Cordova and such to bundle SPA's into Apps. / *Handlebars only let you bind toproperties...
*means a lot of refactoring
*migration would be complicated
*it would take too long to initially load the libraries required, no matter how fast the site actually runs.
Backbone / *Used by wordpress / *Difficult to use
ReactJS. / *JS-Framework from Facebook / *Not so difficult
*Fast
vanilla JS / *Poss 3rd party components and libraries can be bolted on in a modular fashion, whether using jQuery or other bits and pieces, it would mean good for everyone.
*Core = modular
*allow for entry level front enders to get their hands dirty quickly, but also offer a deeper level of code organisation and pattern usage that can be learned with time. / * in writing own JS this can be time consuming-to draw upon own code- when jQuery can do that instead
*poss browser issue (IE)
requirejs / [Dawn’s addition taken from the link opposite by Finnish chap: Esa-MattiSuuronen]
- Always bundling. No running into build problems later on.
- Can use cool things from node.js.
- Simpler syntax:module.exports = ...FTW!
- npm at your disposal.
- Sharing modules with node.js is no brainer
- Source maps for CoffeeScript. Thou RequireJS will probably get thosesoontoo.
- The plugin API is awesome.
Ecmascript / See VanillaJS
Node.js / [Dawn’s addition] /
Table 2. Javascript build tools: 2 options - "None" or "Grunt"
None / *You edit the JS files directly, and they are minified, concatenated and cached the first time they are requested. If in developer mode or after upgrades the cache will be invalidated.*We already have a less compiler in php that is used by the more theme. / *Unless you can also move recess & shifter to a "None" model of operation, we don't gain much
*not having to deal with a build tool for JS (other than Shifter for YUI modules, which should presumably only be legacy code) - but if the minification/concatenation is too slow, even though the products are cached, it may be worth the extra pain of using Grunt to avoid performance issues when the cache is empty.
*I think it’s a completely false economy to talk about a 'None' option while we still have a CSS build tool.
*Tricky with the more theme and theme designer mode enabled. / *No linting step and we still need "shifter" for yui modules and "recess" for less.
*There is less to learn for new developers
* No build products stored ingit
* I don't like polluting the root moodle folder with dev tools
* We have mdk for dev tools already (behat, phpunit)
*
Grunt / *We can unify all our build tools so you just run grunt and it will compile less, run shifter, or minify AMD modules as required
*I have been using Grunt for theme development a lot. It automates these steps:
- start grunt in my terminal and have it watch my /less folder
- have it create rtl-css / css cleaning and lots of css specific node modules
- clear the moodle theme cache
- signal the LiveReloadplugin in my browser to reload the open Moodle page.
- save changes and all other actions are automated.
*Downsides are more files in the moodle root folder (Gruntfile.js, packages.json), a need to install node_modules locally in each moodle root folder, need to remember to run grunt after modifying JS, need to remember to commit the built files, lots of conflicts in the built files / *the single top-level gruntfile will process every plugin the same way. While there will be exeptional circumstances whenere one plugin will need a completely custom build step, we should try to make that as rare as possible.
*adding more clutter to Moodle with its node_modules folder but using the right .gitignoreconfig only the developer will see this folder.
*Grunt provides watch options too and could offer the same linting and watch options for AMD modules and more.
*If we have Grunt then in could consider using it for some other 'build' actions - namely as a way to let a developer run all the CiBoT checks on their local machine.
*Other things mentioned where running behat/phpunit with grunt (but we already have mdk for that).
* Need to ensure if Grunt was treated astheMoodle build tool, rather than the "MoodleJavascript build tool", so we don't end up with other parts of Moodle using other tools that effectively do the same thing.
*It's already pretty much essential for creating new themes based on bootstrapbase, so there's some crossover there.
*I don't see that it's a big burden for new developers to learn, particularly given that they probably wouldn't be writing their own gruntfile. Even if they were, it's a pretty low entry level - you can install Node and Grunt in about 5 minutes and learn how to write a gruntfile in about 10 (assuming you're already familiar with Javascript).
*Also, even if we use Grunt, we could implement one part of the None model. Namely, we could get Moodle (in developer debug mode) to do the dependency checking. So, if you change a JS or Less file, and forget to re-run grunt, it could print a developer debug warning telling you what is out-of-date, with a nice link to the docs to explain to you what to do about this.
..
1