goog.provide('app'); goog.require('app.model.User'); goog.require('app.view.main'); var user = new app.model.User(); goog.provide('app.view.main'); goog.require('app.view.front); goog.require('app.view.about); goog.require('app.view.login); #mantrijs mantrijs.com
Browser • Uses exports and module. exports keywords AMD Asynchronous Module Definition • Extended browser support • Uses function factories • Encapsulates each file in an anon function [[ harmony:modules ]] ES6 • Spec is not out yet • Doesn't support existing definitions (yet?) • Not a module loader #mantrijs mantrijs.com
=== 'object') { module.exports = factory(); } else if (typeof define === 'function' && define.amd) { define(factory); } else { root.returnExports = factory(); } }(this, function(){return app;})); UMD module definitions can work anywhere, be it in the client, on the server or anywhere else. ...or how you can expose your library as a CommonJS or AMD module. https://github.com/umdjs/umd/ #mantrijs mantrijs.com
for testing • Increases visibility and maintainability • Scales smoothly • Modern build flows decouple development from production Using Namespaces mantrijs.com #mantrijs mantrijs.com
server. Nor it will ever be. • Module Definitions are not Module Loaders. • Debugging requires inspector with break points. • Stubbing for Testing is really hard. • Nasty problems, lengthy troubleshooting. • Overhead. ~+7.5% minified, ~+5.5% gzip #mantrijs mantrijs.com
conflicts Use a wrapping IIFE • Exposes internal methods Use a wrapping IIFE • Modules are the future Use a wrapping IIFE, UMD • Modules are cool Why not Namespaces? mantrijs.com #mantrijs mantrijs.com
Tokens • requires build • large scale ready • calculates once per build Filenames • no build requirement • can't move files or folders easily • calculates on each page load define('viewMain, ['app/views/frontpage'], function (viewFrontpage) { /* .. */ });