Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

My presentation at DDD 2010. Now this information is mostly obsolete, and published here to preserve the history.

Published in: Technology
  • Be the first to comment

  • Be the first to like this


  1. 1. “Pulsar”Ideas and plans 1
  2. 2. Overview• Next generation of JS library.• Uses RequireJS as a loader.• Implemented as a package.• Targets different environments. 2
  3. 3. Why separate loader?• Outsourcing all loading and dependency-tracking tasks. • Supports different platforms.• Outsourcing “DOM ready”.• Interoperability with other libraries. 3
  4. 4. Supported environments • Browser • Desktop • Mobile • Web workers • Strict mode • SSJS 4
  5. 5. Simple frontdefine([“pulsar”], function(dojo){ // use here as before}); 5
  6. 6. Layered structure• JS-specific and platform-neutral modules • Idiomatic support: EDP, FP, AOP, OOP... • Helpers: strings, dates, json...• Browser-specific modules • DOM, CSS, events, XHR... 6
  7. 7. Layered structure• Platform-specific modules and scripts • Legacy browser augmentation • SSJS-specific extensions • Mobile-specific support 7
  8. 8. Package structure• Pulsar package is implemented as a relevant CommonJS asynchronous package.• “Main” module imports modules and mixes their APIs together presenting unified namespace.• Different environments use different “main” modules and/or builds. 8
  9. 9. Supporting browser• Browser • JS-specific and platform-neutral modules • DOM, CSS, events, XHR...• Web workers • JS-specific and platform-neutral • XHR 9
  10. 10. Lessons of EmbedJS• Building custom application- and platform-specific bases should be easy.• Finer-grained modules.• Simplified modules (example: query). • Trading features for size/speed. 10
  11. 11. Pulsar foundations• Start with Dojo 1.x base. • Users are familiar with it. • Many parts are “good” and proven.• Replace “bad” parts, add missing pieces. • Dojo Core, DojoX, plugd, EmbedJS, blade + custom code if needed. 11
  12. 12. DOM plan• Replace attr() with prop(). • Clear docs, less code.• Split getters and setters (prop, style...). • Less code, faster functions.• Unify NodeList methods with node functions. • Less code, less docs. 12
  13. 13. DOM events• Remove connect(). • Overloaded for AOP and DOM events. • Leads to inconsistent awkward code: dojo.connect(dojo.byId(“id”), ...);• Add on(): dojo.on(“id”, “onclick”, ...);• Split off AOP. 13
  14. 14. DOM events• Support for event delegation.• No IE6, IE7, IE8? in the base. • Legacy: should be handled separately.• Variant: no disconnect. • on() returns an object with destroy() method, which handles disconnects. • The same style is used consistently. 14
  15. 15. DOM geometry• The biggest mess we have in the base. • A lot of code. • Still buggy in some cases. • A lot of semi-public functions.• We need to decide what to keep. • Feedback from Dijit team? 15
  16. 16. DOM geometry• Possible plan of actions: • Keep position() in the base. • Move marginBox() and contentBox() to the core. • It means: they should be included explicitly by user. 16
  17. 17. XHR plan• Keep objectToQuery() and queryToObject() separately. • They can be used by SSJS.• Keep all form processing separately. • Cannot be used by web workers.• Keep XHR (the I/O part) as a module. • For browsers and web workers. 17
  18. 18. Query plan• What is the problem with query? • A lot of code. • Support issues. • Speed considerations. • Compatibility. 18
  19. 19. Query plan• Alternatives: • Use Acme. • Use Sizzle. • Allow to use both? • Use cssQuery. • Use querySelectorAll. 19
  20. 20. Query plan• Alternatives: • Use simplified query like EmbedJS and move the full-blown version to the core. • Cons: confusion? appearing less feature-rich?• Allow all options for a custom base. 20
  21. 21. Query plan• If we allow options there, we should stop using query in the base itself. 21
  22. 22. Query-related notes• From my experience majority of code works with a single node: • DOM construction. • For several nodes templating is a better solution. • Node updates/manipulations.• We have unnecessary overhead. 22
  23. 23. Query-related notes• It would be nice to return the first matched element and stop searching. • In this case a single node should be returned rather than a NodeList.• In any case single node functions are important. • Less overhead (proven practically). 23
  24. 24. Language helpers• OOP • Should we move declare() out of the base? • It is lighter in Pulsar because the legacy support was removed. • If yes, do we need any light version? • Variant: delegate() + C3MRO 24
  25. 25. Globals• Theoretically CommonJS modules can be evaluated in the sandbox. • No globals. All references are explicit. • What to do about dojo.config? 25
  26. 26. Legacy support• Dojo 1.x is still the main focus of efforts. • We cannot afford another 0.4/0.9 split.• Dojo 2.0 will use the “soft start”: • The base first. • Some other modules are migrated or developed. 26
  27. 27. Legacy support• All SSJS platforms are assumed to be legacy-free (double-check!).• Only browsers need to be augmented. • We can handle browsers in two ways: • Conditional loading of modules (?). • User should include additional script(s), if needed. 27
  28. 28. Legacy support• Possible solution: • Use Dean Edwards libraries: Base2, IE7, cssQuery. • Base2 can update prototypes for Array, Date, String to make them more conformant. • Base2 can augment browser objects, but it requires some code from us. 28
  29. 29. Legacy support• Why augment prototypes instead of wrapper functions? • By using wrappers we penalize all browsers. Augmentation is free. • No need to augment every object: faster, and automatic.• We do not augment Object. 29
  30. 30. Legacy support• We cannot augment DOM objects. • Updating all objects on the fly can be taxing and impractical. • Back to wrapper functions?• IE7 library “updates” IE6-8 to match IE9 HTML-wise and CSS-wise. • No direct effect on DOM. 30
  31. 31. Legacy support• We may need to subset Base2 or provide our own solutions. • Base2 and IE7 are MIT licensed, cssQuery is LGPL.• Augmenting DOM is not enough.• We need to migrate from browser sniffing to feature detection. 31
  32. 32. Legacy support• Feature detection: • I waited for dojo-fd to be finished, yet it is dormant for several months. • Ultimately I used the trunk. • has.js is done by Dojo contributors. • Should we integrate it somehow? • Pulsar’s browser.js is a sniffer. 32
  33. 33. Legacy support• Possible solution: • Reserve a global namespace, which can be populated by a legacy shim. • Normal base modules check that namespace to route their functions properly. 33
  34. 34. Dojo Base 1.x/2.0 plan • Produce 1.6 as usual (end of 2010). • 1.7 base should coordinate with 2.0 base. • Backports, deprecating old stuff. • 2.0 produces a compatibility module for 1.7 base to ease the migration. • 1.8 finalizes base changes. 34
  35. 35. Marketing 2.0• Guides how to migrate from 1.x and other major libraries to 2.0. • Possible compatibility layers for other major libraries to ease the transition.• Common market of JS modules.• Porting important modules from 1.x to 2.0 including charting and grid. 35
  36. 36. Technical plan• Everything in the base should be: • Documented. • Unit tested. • Benchmarked. • Size tested.• Users should know benefits and tradeoffs exactly. 36
  37. 37. Technical plan• All tests/demos should be hosted with optimized builds so we are not embarrassed by unrelated deficiencies.• We have to select tools: • Builder/optimizer - RequireJS? • Inline docs - JSDoc? Dojo doc format? • Test harness - DOH? 37
  38. 38. General considerations• JS is at the strange place now. • SSJS is red hot, yet driven by refugees from other languages. • I don’t know a single SSJS project that can partition a load between server and client. • James Burke and Kris Zyp are working on it with CommonJS. 38
  39. 39. General considerations• JS the language is not used at 100%. • E.g., JS is capable of Code Generation (CG), yet almost nobody uses it. • CG is a norm for LISP languages. • Crockford: JS is “Lisp in Cs Clothing”. Yet... nothing... • Yes, it works in strict mode too. 39
  40. 40. General considerations• We need to explore hidden corners of JS and HTML5 to see if we can use them for the betterment of software development.• We need to explore synergy between client and server on all levels. • Intelligent serving? • Smart pre-processing? 40
  41. 41. That’s all, folks! 41