Mantri Presentation One


Published on

Javascript Dependency System

Presentation One

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mantri Presentation One

  1. 1. What is Mantri?✓ Manages Web Applications Dependencies✓ Leaves no footprint on production✓ Offers a complete workflow✓ IE6+ #mantrijs
  2. 2. What Dependencies?● Multiple Javascript Files● Each file can depend on other files● Order of loading● Order of evaluation● Order of concatenating and building #mantrijs
  3. 3. Why Manage?● Automatic dependency resolution● Enables large scale applications● Collaboration between large teams● Code scalability● Better readability #mantrijs
  4. 4. Mantri Development Cycle #mantrijs
  5. 5. Page Load BreakoutMantri RuntimeStarts Parsing mantriConf Synchronous XHR .json document.write Vendor (<script>...); Libs Synchronous XHR deps.js document.write (<script>...); Your Application Mantri Runtime Finishes Parsing #mantrijs
  6. 6. 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
  7. 7. Web Development with Mantri
  8. 8. The Natural Way #mantrijs
  9. 9. 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
  10. 10. Dependency Tree #mantrijs
  11. 11. Mantri Uses Namespacesgoog.provide(app.views.frontpage);// equals tovar app = app || {};app.views = app.views || {};app.views.frontpage = app.views.frontpage || {};// === app; #mantrijs
  12. 12. 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
  13. 13. Required FilesmantriConf.json deps.js● Declare third-party libs ● Auto generated● Dependency Config ● Command line● Build Config ● Each time a declaration changes #mantrijs
  14. 14. Building Your Application$ mantri build✓ Grunt Task #mantrijs
  15. 15. Workflow Concepts
  16. 16. Application Wrapping"outputWrapper": "(function(){<%=output%>})();"● IIFEs are cool● "Hides" all previously global variables● Explicit exposing #mantrijs
  17. 17. Module DefinitionsCommonJS 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● Doesnt support existing definitions (yet?)● Not a module loader #mantrijs
  18. 18. 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;})); #mantrijs
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. Namespaces vs ModulesTokens● requires build goog.provide(app.views.main);● large scale ready goog.require(app.views.frontpage); /* win */● calculates once per buildFilenames● no build requirement define(viewMain, [app/views/frontpage],● cant move files or folders function (viewFrontpage) { /* .. */ }); easily● calculates on each page load #mantrijs
  23. 23. Recap, Mantri Features
  24. 24. Mantri Specifications● Synchronous, app loads before DomContentLoaded● No footprint on production● Simple provide and require statements● Available on NPM #mantrijs
  25. 25. Mantri Specifications● Wraps around Google Closure Tools● Uses Grunt Task Manager● Abstracts the complexity away● Low entry barrier that scales seamlessly #mantrijs
  26. 26. Thank You!