This discusses the benefits of using AMD in Elgg.
We made some strides in 1.8 with the introduction of the “
have quickly realized the approach we were taking was not scalable.
The size of JS on the web is growing quickly, and JS in Elgg is growing too. We want Elgg to be able to offer a solution that makes JS development as productive and maintainable as possible going forward.
The reasons to choose AMD are plenteous and well-documented. Let’s highlight just a few of the most relevant reasons as they relate to Elgg specifically.
1. Simplified dependency management
AMD modules load asynchronously and execute as soon as their dependencies are available, so this eliminates the need to specify “priority” and “location” when registering JS libs in Elgg. Also, you don’t need to worry about explicitly loading a module’s dependencies in PHP. The AMD loader (RequireJS in this case) takes care of all that hassle for you. It’s also possible have text dependencies with the RequireJS text plugin, so client-side templating should be a breeze.
2. AMD works in all browsers. Today.
3. You do not need a build step to develop in AMD.
We like the edit-refresh cycle of web development. We wanted to make sure everyone developing in
Elgg could continue experiencing that joy. Synchronous module formats like Closure or CommonJS just
weren’t an option for us. But even though AMD doesn’t require a build step, it is still very
build-friendly. Because of the
define() wrapper, it’s possible to concatenate multiple modules
into a single file and ship them all at once in a production environment. 1
This is not currently supported by Elgg core, but we’ll be looking into it since reducing round-trips is critical for a good first-view experience, especially on mobile devices.