Forging Titanium Episode 1: CommonJS Modules

Two photographs of colored pencils and a paint brush combined to form a new object.

Editor’s note: This and future episodes of Forging Titanium will be available here.

The CommonJS Module specification is an emerging standard for creating self-contained JavaScript modules which do not pollute the global scope.  Titanium Mobile provides an implementation developers can use today to leverage these features in their own applications.  In the first episode of Forging Titanium, we will learn how to use CommonJS modules in mobile applications to provide our own secure, reusable JavaScript libraries.


  1. Kevin,
    It would be great to see some more specific guidance on what to put into a Common JSmodule versus what would be left for another JSmodule. For example I have seen approaches with regard to UserInterface.JS and Database.JS. But what point would break it out further based on performance reasons? Any rule of thumbs here?

    Thanks again for keeping the information and training !

  2. I’m building out our main training application (TiBountyHunter) using the Module spec rather than Ti.include – I’m hoping folks will find that useful. Looking to get it done before Codestrong in September!

  3. @Jeff more on the way, we know we need to give more best practices guidance to you guys out in the trenches.

  4. I’m in the habit of developing OOP. prototype JS apps and compiling down with closure compiler ADVANCED_OPTIMIZATIONS. Is this polluting the global scope?

  5. In my experience that’s only on android side of Ti, require loads the module every time it is called, almost vanishing the chance to use it if you end end up with n copies of a module but really want only one of it, shared among all the other modules that require it.
    What would be very useful would be to have goog.provide and goog.require (or dojo.provide and .require) which do exactly that.

  6. How “secure” is secure? for example could it be used to safely distribute JS modules to third parties? – Looking at the file create when the module is compiled it seems that it uses exactly the same format at the JS within an app? ( inline and base64’d – at least for iPhone).

    Are Appcelerator looking at any way of encrypting the inline JS code rather than just using base64?

    BTW. very timely article as I am looking at converting a lot of my project specific JS into modules so it can be shared across projects.

  7. Are you supposed to be able to set breakpoints and debug code within your CommonJS modules? (It’s not working for me with 1.7.2 and latest stable Ti Studio.)

  8. Ditto the question above – can’t seem to get any breakpoints activating when employing the commonJS approach.

    Any answers on this would be extremely appreciated…

  9. Kevin,
    Any updates on the Ti Bounty? Also I have spent quite a bit of time really practicing what was preached during CodeStrong regarding use of commonJS, however it has become really challenging debugging as whenever you set breakpoints inside of the require files that use commonJS and export the debugger does not honor any breakpoints.


  10. Well, I spent all day learning about CommonJS and Cross-Platform Interface Guidelines and seemed to be a very nice project configuration to have both in consideration. But the fact of not beeing able to set breakpoints while debugging on a “required” file has demotivated me :

    • @NoOne we’re working on the tooling aspect of require right now. In the long run it’s going to be the preferred mechanism.

  11. Ya, I’ve been working with 1.8 since 17 October. Already adapted my whole project to commonjs, c-pig and jolly 🙂

    • @Richard not totally, but along with the next Studio release I will be releasing a new sample app using this method (and a few others we’ve been pioneering in pro services).

Comments are closed.