Mantri is a tool that manages dependencies for web applications. It resolves dependencies between JavaScript files, concatenates and builds the application into a single file without requiring statements. This leaves no footprint in production. Mantri offers a complete workflow from dependency management to building the application. It enables large scale applications by teams through automatic dependency resolution and scalable code organization.

2. What is Mantri?
✓ Manages Web Application's Dependencies
✓ Leaves no footprint on production
✓ Offers a complete workflow
✓ IE6+
#mantrijs
mantrijs.com

3. What Dependencies?
● Multiple Javascript Files
● Each file can depend on other files
● Order of loading
● Order of evaluation
● Order of concatenating and building
#mantrijs
mantrijs.com

4. Why Manage?
● Automatic dependency resolution
● Enables large scale applications
● Collaboration between large teams
● Code scalability
● Better readability
#mantrijs
mantrijs.com

5. Mantri Development Cycle
#mantrijs
mantrijs.com

6. Page Load Breakout
Mantri Runtime
Starts Parsing
mantriConf
Synchronous XHR
.json
document.write Vendor
('<script>...'); Libs
Synchronous XHR deps.js
document.write
('<script>...'); Your
Application
Mantri Runtime Finishes
Parsing
#mantrijs
mantrijs.com

7. Mantri 50k feet View
$ mantri deps
Resolves Deps ✓
Concats app to one file ✓
Strips require statements ✓
Compiles app ✓
Optionally wraps app ✓
Minifies third-party ✓
Concatenates all ✓
$ mantri
build #mantrijs
mantrijs.com

8. Web Development with Mantri

9. The Natural Way
#mantrijs
mantrijs.com

10. Mantri Declarations
goog.provide('app');
goog.require('app.model.User');
goog.require('app.view.main');
var user = new app.model.User();
goog.provide('app.model.User'); goog.provide('app.view.main');
goog.require('app.helpers'); goog.require('app.view.front);
goog.require('app.view.about);
app.model.User = function() { goog.require('app.view.login);
// ...
#mantrijs
mantrijs.com

11. Dependency Tree
#mantrijs
mantrijs.com

12. Mantri Uses Namespaces
goog.provide('app.views.frontpage');
// equals to
var app = app || {};
app.views = app.views || {};
app.views.frontpage = app.views.frontpage || {};
// and...
window.app === app;
#mantrijs
mantrijs.com

13. The HTML Document
<script src="js/libs/mantri.web.js"></script>
<script data-require="app" ...
<script data-config="/mantriConf.json" ...
<script data-deps="/deps.js" ...
#mantrijs
mantrijs.com

14. Required Files
mantriConf.json deps.js
● Declare third-party libs ● Auto generated
● Dependency Config ● Command line
● Build Config ● Each time a declaration
changes
#mantrijs
mantrijs.com

15. Building Your Application
$ mantri build
✓ Grunt Task
#mantrijs
mantrijs.com

16. Workflow Concepts

17. Application Wrapping
"outputWrapper": "(function(){<%=output%>})();"
● IIFEs are cool
● "Hides" all previously global variables
● Explicit exposing
#mantrijs
mantrijs.com

18. Module Definitions
CommonJS AMD Asynchronous Module Definition
● Used in node.js ● Extended browser support
● Supported in Browser ● Uses function factories
● Uses exports and module. ● Encapsulates each file in an
exports keywords anon function
[[ harmony:modules ]] ES6
● Spec is not out yet
● Doesn't support existing
definitions (yet?)
● Not a module loader
#mantrijs
mantrijs.com

19. Universal Module Definitions
...or how you can expose your library as a CommonJS or AMD module.
UMD module definitions can work anywhere, be it in the client, on the
server or anywhere else.
(function (root, factory) {
if (typeof exports === 'object') {
module.exports = factory();
} else if (typeof define === 'function' && define.amd) {
define(factory);
} else {
root.returnExports = factory();
}
}(this, function(){return app;}));
https://github.com/umdjs/umd/
#mantrijs
mantrijs.com

20. Using Namespaces
● Debugging from console
● Dead easy stubbing and mocking for testing
● Increases visibility and maintainability
● Scales smoothly
● Modern build flows decouple development from
production
#mantrijs
mantrijs.com

21. So Why Not Modules?
● The Web is not the 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

22. Why not Namespaces?
● Can become verbose app.ui.combo.EventType Use an alias
● Namespace conflicts Use a wrapping IIFE
● Exposes internal methods Use a wrapping IIFE
● Modules are the future Use a wrapping IIFE, UMD
● Modules are cool
#mantrijs
mantrijs.com

23. Namespaces vs Modules
Tokens
● requires build goog.provide('app.views.main'');
● large scale ready goog.require('app.views.frontpage');
/* win */
● calculates once per build
Filenames
● no build requirement define('viewMain, ['app/views/frontpage'],
● can't move files or folders function (viewFrontpage) { /* .. */ });
easily
● calculates on each page
load
#mantrijs
mantrijs.com

24. Recap, Mantri Features

25. Mantri Specifications
● Synchronous, app loads before DomContentLoaded
● No footprint on production
● Simple provide and require statements
● Available on NPM
#mantrijs
mantrijs.com

26. Mantri Specifications
● Wraps around Google Closure Tools
● Uses Grunt Task Manager
● Abstracts the complexity away
● Low entry barrier that scales seamlessly
#mantrijs
mantrijs.com

27. Thank You!
http://mantrijs.com
#mantrijs
@thanpolas
http://thanpol.as