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

1. “Pulsar”
Ideas and plans
1

2. Overview
• Next generation of JS library.
• Uses RequireJS as a loader.
• Implemented as a package.
• Targets different environments.
2

3. Why separate loader?
• Outsourcing all loading and
dependency-tracking tasks.
• Supports different platforms.
• Outsourcing “DOM ready”.
• Interoperability with other libraries.
3

4. Supported environments
• Browser
• Desktop
• Mobile
• Web workers
• Strict mode
• SSJS
4

5. Simple front
define([“pulsar”], function(dojo){
// use here dojo.xxx as before
});
5

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. Layered structure
• Platform-specific modules and scripts
• Legacy browser augmentation
• SSJS-specific extensions
• Mobile-specific support
7

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. Supporting browser
• Browser
• JS-specific and platform-neutral
modules
• DOM, CSS, events, XHR...
• Web workers
• JS-specific and platform-neutral
• XHR
9

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. 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. 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. 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. 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. 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. 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. 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. Query plan
• What is the problem with query?
• A lot of code.
• Support issues.
• Speed considerations.
• Compatibility.
18

19. Query plan
• Alternatives:
• Use Acme.
• Use Sizzle.
• Allow to use both?
• Use cssQuery.
• Use querySelectorAll.
19

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. Query plan
• If we allow options there, we should
stop using query in the base itself.
21

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. 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. 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. Globals
• Theoretically CommonJS modules can
be evaluated in the sandbox.
• No globals. All references are explicit.
• What to do about dojo.config?
25

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Technical plan
• Everything in the base should be:
• Documented.
• Unit tested.
• Benchmarked.
• Size tested.
• Users should know benefits and
tradeoffs exactly.
36

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. 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. 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 C's
Clothing”. Yet... nothing...
• Yes, it works in strict mode too.
39

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. That’s all, folks!
41