Tips for developers: When Javascript meets modularization...

Javascript belongs to those programming languages which easily divides people between those who love it or hate it, especially when like me you have a strong background in Java. Some differences in the general philosophy of the language are sometimes not trivial to grasp. But imagining today a web world without javascript is a pie in the sky :-)

Javascript belongs to those programming languages which easily divides people between those who love it or hate it, especially when like me you have a strong background in Java. Some differences in the general philosophy of the language are sometimes not trivial to grasp. But imagining today a web world without javascript is a pie in the sky :-)

There would be a lot of things to discuss around this subject but today I want to talk about an important concept : modularization. There are no built in namespace and/or encapsulation concepts in Javascript available today in our browsers and this could have important consequences at Runtime. This is very annoying when you have to deal with lots of different script files written by different people, and this is more and more true nowadays where projects combine homemade scripts including Javascript frameworks (JQuery, Prototype, Dojo,...).

Of course, Javascript programmers quickly noticed this issue and proposed several workarounds and design patterns to deal with it : one of those is known as Module pattern (you can find a description of it at http://briancray.com/posts/javascript-module-pattern). Some frameworks also provide their own ways to reduce conflicts with other frameworks (especially when using the "$" alias) but it seems clear many people are unhappy with the current situation.

Another problem concerns dependencies and versions.  For instance the well known JQuery UI toolkit is based on JQuery core framework and therefore you need to load the second one in order to use the first one. Moreover, before using a cool third party JQuery widget, you have to make sure it will fit well with the version of JQuery used on your project. You may argue those problems are not currently solved perfectly in Java world either since there are specifications such as Jigsaw which aim to deal with it in Java 8 9. However Java is a static language which significantly reduces those issues at compile time and thanks to Maven POM definitions, we can also solve most of the possible issues at runtime.

Several initiatives have emerged in the Javascript world to solve those encapsulation and dependency issues. The clear winner today, on the client Javascript side, is the Asynchronous Module Definition format which has been adopted by Jquery, MooTools, Dojo and others... which basically works through 2 functions define and require. Then you will be able to lazily load dependencies via a script loader such as requirejs or curl.js. You can find more information on this well written article on http://addyosmani.com/writing-modular-js/.

Those issues explain why module concept should appear in the next ECMAscript version, known as Harmony, why is expected for next year. It is also important to note that the Javascript alternative from Google, known as Dart, includes some form of modularization.

Digital news!

Are you as digitally addicted as we are? We can supply you with a regular dose of digital news. Simply sign-up, or click to Follow us online.

About the author

Josselin Lebret
Josselin Lebret

Java EE and Web Developer since 2002
Working at BI since August 2008