Difference between revisions of "JS Framework Specification"

Jump to: navigation, search
m (Grunt)
(YUI loader)
Line 57: Line 57:
 
==== YUI loader ====
 
==== YUI loader ====
 
implements modules, sandboxing namespaces, dependency resolution, combo loading, build tools (minification, linting), classes, inheritance, small set of supported widgets, events
 
implements modules, sandboxing namespaces, dependency resolution, combo loading, build tools (minification, linting), classes, inheritance, small set of supported widgets, events
 +
 
pros: we already include the library
 
pros: we already include the library
 +
 
cons: does not look to external devs like we have shifted from yui, requires YUI syntax to load modules (e.g. after the page has loaded)
 
cons: does not look to external devs like we have shifted from yui, requires YUI syntax to load modules (e.g. after the page has loaded)
note: it has ways to load ES6 modules (after transpiling them)
+
 
 +
note: it has ways to load ES6 modules (after transpiling them http://yuilibrary.com/yui/docs/yui/es6-modules.html)
  
 
==== RequireJS ====
 
==== RequireJS ====

Revision as of 08:40, 27 November 2014

JS Framework Specification
Project state Planning
Tracker issue MDL-48392
Discussion [ https://moodle.org/mod/forum/discuss.php?d=268190 ]
Assignee Damyon Wiese


Background

Moodle has used YUI as it's javascript framework (since 2006). We have built in support for using their combo loaders, javascript build chain, module support, debugging and many other nice features. We use YUI to provide a standard API between different browser features and for the many nice things that are built in like dialogs, ajax requests, events, classes and inheritance.

Earlier this year (2014) Yahoo announced:

we have made the difficult decision to immediately stop all new development on YUI in order to focus our efforts on this new technology landscape. This means that, going forward, new YUI releases will likely be few and far between, and will only contain targeted fixes that are absolutely critical to Yahoo properties.

This started a (very constructive) forum discussion on the future of JS in Moodle (https://moodle.org/mod/forum/discuss.php?d=268190).

And following that discussion we made a policy decision (https://tracker.moodle.org/browse/MDL-47036) to create a "first prototype/example as described by Dan above with JQuery, RequireJS and grunt".

This document is meant to clearly document the features / characteristics of this prototype/example and compare it to our existing YUI integration. It should discuss how the 2 solutions can co-exist during a transition period.

Summary of forum discussion

The forum discussion has had many contributors and is full of valuable comments. Please read it: https://moodle.org/mod/forum/discuss.php?d=268190.

Here is a much shorter summary of most of the things that were discussed:

Summary of options for JS library

No framework

pros: less overhead on each page (maybe)

cons: we need to re-implement the cross browser support (drag and drop, events, ajax ...), we are supposed to be building an LMS and tools for teachers, not JS libraries

JQuery

pros: Most popular choice, lots of developers with experience, lots of other libraries rely on jquery, well supported, long life time, "60.4% of web sites use jQuery", fast, many corporate supporters, clearly the most voted for option in the discussion, backing from deque (accessibility), not too different to YUI

cons: Is it too much?, quality of plugins,

Use a set of polyfills and use ES6 syntax for everything

pros: nice "elegant" solution cons: testing requirements go up greatly, we will probably end up rolling our own JS frame work piece by piece, plugins devs would all include jquery anyway (bootstrap).

Angular

pros: trendy, clean MVC design

cons: requires backend rewrite

Ember

cons: requires backend rewrite


Attributes we want in a JS framework

long term support cycles, standardize things that are not standard across browsers (dom manipulation, positioning, ajax, events, drag and drop?, 2d drawing?, transitions, accessible widgets?), sandboxing, dependency loading, able to (easily) load third party modules, performance

Summary of options for loading modules

YUI loader

implements modules, sandboxing namespaces, dependency resolution, combo loading, build tools (minification, linting), classes, inheritance, small set of supported widgets, events

pros: we already include the library

cons: does not look to external devs like we have shifted from yui, requires YUI syntax to load modules (e.g. after the page has loaded)

note: it has ways to load ES6 modules (after transpiling them http://yuilibrary.com/yui/docs/yui/es6-modules.html)

RequireJS

implements: modules, dependency resolution, build tools (minification, linting) (requires node.js) cons: ES6 is a newer standard combining RequireJS and CommonJS syntax

ECMAScript 6 modules

implements: modules, sandboxing, dependency resolution

pros: best forward looking option (standards based)

cons: new standard - no browser support yet - but there is a polyfill (https://github.com/ModuleLoader/es6-module-loader)

Summary of options for build tools

What is a build tool - think minification, linting, module packaging, generate documentation.

Shifter

pros: We use it now

cons: doesn't support ES6 modules except to convert them to YUI modules

Use a PHP library (not minify - maybe jshrink)

pros: Php library - we can automate the minification and tie it to purge caches, don't have to check JS has been compiled, don't have to include build products in git

cons: minify is old and deprecated need to replace it with something better, linting would need a separate tool (maybe part of code checker or cibot)

Grunt

pros: used by a lot of developers, can do more (unit tests), compile less, could run shifter too - so would be a combined process covering old/new

cons: another build tool for new developers to support (barriers)