EmbedJS 0.2 and AMD 4

During JSConf.eu, we released EmbedJS 0.2. That release was mainly about a fundamental architectural change: the move to the AMD pattern for our features. Let me explain why we decided to do this, why we think this is a big step forward and what this means for the user.


AMD stands for “Asynchronous Module Definition”. So, what are modules? I’ll quote the definition from the CommonJS Module specification, as it describes it very well:

This specification addresses how modules should be written in order to be interoperable among a class of module systems that can be both client and server side, secure or insecure, implemented today or supported by future systems with syntax extensions. These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API.

So, modules are isolated parts of code that live in their own scope and are kind of self-contained. Well, that is pretty much how we see the individual Features in EmbedJS – we made our feature implementations as small as possible and reduced dependencies as much as possible. Many of EmbedJS’ features are also browser-independent, so why not make it possible to use some of the tools in a non-browser environment?

(If you want to learn more on modules and why we need them, I recommend @briancavalier‘s presentation on modules.)

Features in EmbedJS

So far, I didn’t really explain what I mean with “Features”, so let me do another quote, this time from the Project Page:

EmbedJS uses the concept of features: Functionalities are split up into features, as fine-grained as possible, and each feature might have multiple implementations.

Our Features are kinda small and contain only few methods, sometimes even just one. The asyc-promise feature, for example, will get you Promises, and the transport-jsonp feature will get you a method for pull in data via jsonp – and that’s it.  If multiple methods are contained within one feature, this is because they are too closely related to each other to split them up, like the html-class feature, which contains the addClass, removeClass, toggleClass and hasClass methods.

AMD vs CommonJS Modules 1.1

Now that we knew modules were the way to go, there was another, quite important question to solve: There are two common patterns for modules, so which one do we want to apply? One pattern is described in the above mentioned CommonJS Wiki, the other pattern is described in the AMD wiki.

Well, there have been some blog posts lately that compare the pros and cons of each of them, so I don’t want to repeat all of this – but I’m hiving a similar tendency towards AMD. Besides this, there was another big reason to go with AMD: Remember, EmbedJS is based on the Dojo Toolkit, and it’s a Dojo Foundation Project – and we hope that the efforts that went into making EmbedJS might flow back into the Dojo Toolkit one day. And as the Dojo Toolkit uses the AMD approach, the decision was quickly made to do so as well.

Implications for EmbedJS

There are several huge benefits for EmbedJS in using the AMD approach. The most noteworthy surely is the ease-of-use for developers. In your code, when you find you want an EmbedJS method, you look up the feature name that provides this method, add it to the require statement and there you go. Man, easy.

A second important thing is that EmbedJS now plays really nice with AMD based projects. In fact, you could see EmbedJS now as a collection of small useful modules, that can be easily integrated – and also easily extended.

The third major benefit is that we can now get rid of all the custom tools we built around EmbedJS – you can load features with any AMD loader (though we use and recommend RequireJS) and build it with any AMD optimizer/builder (we recommend r.js).

Let’s have an extra word on


It was always possible with EmbedJS to create a custom build that would contain only the features you wanted/needed in your project. But, you had to use our build tool that we created. And learning & using Yet-Another-Build-Tool™ is always… well, let’s just say it would be cool to avoid it (and, not to forget, so is maintaining it). We did a lot to improve that, we created a GUI that allowed you to just “click together” the features you wanted, and we worked on a dynamic loader that would ease development. But still, the situation was far from ideal, and people just ended up going for our ready-made “kitchensink” builds that contained all of the features.

Now, we still provide those ready-made builds that contain only the implementations for a given platform (and are stripped of require/define calls), but I really hope that using the AMD approach and using an AMD optimizer to deploy will become the more adopted style.

Q: Cross-target? A: The Feature Plugin

One goal of EmbedJS is to allow for easy cross-device development. We got rid of run-time branching but instead went for an approach that held the different implementations for a given feature in separate files, so that one only has to deploy the actually needed code to a given device – and not all the alternate implementations, that sit useless in the device’s memory and never get used. We needed to achieve that with “in-house” means provided by the AMD approach. Lucky us, there’s the concept of loader-plugins, and so I created a feature-plugin for AMD loaders. The idea is simple yet effective: You create an implementation map that maps a feature name to an implementation, and if there are multiple implementations, you supply tests that tells the plugin which feature to use.

When you’re ready to deploy, you have two choices: I f you really don’t know on what target your code is going to end up, you can use the dynamic implementation map containing the tests for the optimizer, and you’ll get a build that contains all of the available implementations. Then, during runtime, the feature plugin will run the tests and load the specific implementation. But, if you do know what target your code will run on, you provide a specific implementation map that doesn’t contain tests but directly maps to the according implementations, and you will only have those in your built file.


AMD is exactly what we needed to make EmbedJS more what we want it to be – an easy to use JavaScript toolbox that is especially handy for cross-target scenarios such as cross-platform mobile development. So, please don’t hesitate and check it out on Github, read the project page and check out the examples!


Resources / Further Reading

  • Oliver Siemoneit

    Hallo Herr Arps,

    vielen Dank für die interessanten Blog-Posts auf uxebu.com. Die Beiträge sind immer sehr hilfreich für mich. Ich hoffe auch, dass die Dojo-Konferenz gut war — die Tagung hätte mich auch sehr interessiert…

    Meine Frage(n) an Sie:

    Wie hängt EmbedJS nun genau mit dojox.mobile zusammen? Was ist für die Zukunft geplant? Irgendwie verstehe ich den Zweck von EmbedJS noch nicht ganz — leider.

    EmbedJS ist zwar schön klein und modular, aber um eine App zu machen brauche ich doch mehr wie ein paar DOM-Manipulationsfunktionen und JSONP-Unterstützung? Dafür braucht man doch auch Widgets/ GUI-Elemente (dojox.mobile.ScrollableView, dojox.mobile.Opener…) und entsprechende, die nativen Elemente imitierende Stylesheets? Eben das, was dojox.mobile jetzt schon hat.

    Oder soll EmbedJS gerade die Lücke füllen, die zwischen Smartphone-Apps und intelligenten, programmierbaren Kühlschränken besteht?

    Über einige Aufklärung würde ich mich sehr freuen, denn gerne würde ich EmbedJS mit in mein Programmier-Repetoire aufnehmen.

    Herzlichen Dank und Ihnen alles Gute. Schön, dass eine deutsche Firma gibt, die so profunde Arbeit im Dojo-Umfeld leistet.

    Keep up the good work!

    Beste Grüße aus Stuttgart
    Oliver Siemoneit

  • http://excellenteasy.com David Pfahler

    Sounds like an incredible leap forward. Congrats on that!

    I’d love to see some detailed explanations / tutorials on how to actually use it, just as Oliver said. But of course, it is already unbelievably valueable. Going to take a deeper look into EmbedJS for my next projects for sure!

  • Jens Arps

    @Oliver Siemoneit:

    Thank you for your comment! Please allow me to answer in English. Your first question was how EmbedJS relates to dojox.mobile, and the short answer: it doesn’t – but let me explain this.

    Many of the existing JavaScript frameworks and toolkits that target mobile development offer ready-made UI components and widgets that mimic native UI controls both in looks and behavior. But what we experienced during our projects is that most of the applications we built (I’m almost sure even all of them) never used any UI components that looked or behaved like standard native controls. Consider a reader application for digital magazines, for example: There are quite a lot of UI components there. You have a store in which you can see magazines on a shelf with a description next to them. Inside of a magazine, you have a bottom area with some buttons that slides in when you tap on that area. You have a flipview that displays thumbnails of pages and displays story titles and descriptions and that you can slide around. You have loads of interactive elements that are animated in fancy ways. And so on…

    But, none of these resemble any “standard” native UI control in any way – and that’s where EmbedJS drops in. We needed a toolkit that offered us helper methods and syntactic sugar that aided us in rapid development of those custom UI components. But every existing framework out there came with the load of widgets we would never actually use – and this is why we created EmbedJS, and this is what it aims at. It takes a different approach than dojox.mobile – it’s goal is to be a lightweight, optimized toolkit that provides you the basic tools you need to build an application from scratch – no matter if it’s a phone, a tablet or a tv – or a fridge :)

    @David Pfahler:

    Thanks! Yeah, I’m working on a tutorial to show EmbedJS in action and to go more into detail on why and how to use it :)

  • http://www.analyte.com Mario Zito

    A tutorial will be greatly welcomed.
    I come from jQuery and also feel it’s just too big and overloaded with crossbrowser stuff.
    But no sure about how to use EmbedJS instead.
    Will the Dojo tutorials be a good starting point ?
    Congrats. EmbedJS seems the way to go !