This document summarizes Eugene Lazutkin's talk on programmer's tools and how Dojo supports different programming paradigms in JavaScript. The talk discusses code structuring techniques like modules, object-oriented programming, mixins, and how Dojo implements these patterns through features like dojo.declare and dojo.require. It also mentions asynchronous programming tools in Dojo and other topics not covered in the talk like widgets and graphics.

1. Dojo for Programmers
Finest tools for programmers by programmers.

2. About me
• I am Eugene Lazutkin (read: la-ZOOT-kin).
• Started to work with JavaScript since ~1998.
• Worked with Dojo Toolkit since 2005.
• Dojo Committer responsible for core
improvements, DnD, graphics, and charting.
2

3. This talk is about...
• Programmer's tools of trade.
• Different programming paradigms...
• ...in JavaScript
• ...and how Dojo supports them.
• Why do we need them.
3

4. This talk is not about...
• Widgets, maps, charts, grids.
• Browsers, DOM, CSS.
• HTTP, XML, JSON.
4

5. JS before ~2005
• Progressive enhancements:
• Project code base is small.
• General complexity is low.
• No need to structure the code.
5

6. JS now
• Web applications are on the rise:
• 100s kbytes of minified code.
• Asynchronous exchange of data with servers.
• Teams of developers.
• Reusable components.
• Modularity.
6

7. Code structure
• Tried and true techniques:
• Modules
• OOP
• AOP
• EDP
• FP
7

8. Modules
• Separation of concerns.
• Well-defined API improves maintainability.
• For reusable components: a distribution unit.
• Browsers: a loading unit.
• Usually roughly corresponds to <script>.
8

9. Modules in Dojo I
• One module - one file.
• Can load other modules.
• Just two functions are visible:
• dojo.provide() - declare a name of the
module.
• dojo.require() - request other module.
9

10. Modules in Dojo II
• There is no restriction on content of a module.
Anything goes.
• Usually module defines discoverable names by
attaching them to well-known global names.
• Dojo defines "dojo" as a global namespace.
• General convention is to define your own
namespaces.
10

11. Modules in Dojo III
• Module names all follow a simple convention:
• "dojox.gfx.svg" => "dojox/gfx/svg.js".
• Top name can be mapped.
• The default mapping:
• "myapp.foo" => "dojo/../myapp/foo.js"
• Custom mapping can be defined too.
11

12. Modules in Dojo IV
• Your custom modules are first class citizens.
• The default mapping takes care of a common
case when your subdirectory is a peer of "dojo":
• /dojo
• /myapp
• Custom mapping takes care of specific
requirements of your deployment.
12

13. Example
dojo.provide("dojox.charting.Theme");
dojo.require("dojox.color");
dojo.require("dojox.color.Palette");
dojo.require("dojox.lang.utils");
dojo.require("dojox.gfx.gradutils");
dojo.declare("dojox.charting.Theme", null, {
// summary:
// A Theme is a pre-defined object, primarily JSON-based,
// style a chart.
13

14. Why?
• We don't need to track dependencies manually.
• No need to include dependencies manually.
• We can use the same modules in different
environments.
• Dojo is used with Rhino, Spidermonkey,
Node.js...
• We can automatically optimize our application.
14

15. Dojo tools I
• In browser Dojo comes with two loaders:
• Simple synchronous XHR-based loader for
debugging.
• Cross-domain asynchronous loader for
CDNs.
15

16. Dojo tools II
• Dojo Builder is used to prep an app for
deployment.
• Collecting all required modules in one or
more layer files.
• Minification of layers.
• Collecting and minifying CSS files.
• Inlining external resources (e.g., HTML
snippets) in JS.
16

17. OOP
• Proven technique to tame the complexity.
• Modularity on a different level.
• Objects are chunks of state with a well-defined
compact API.
• Possibility to reuse common behaviors using
inheritance.
17

18. OOP in JS
• Everything is an object.
• Prototypal inheritance.
• Constructors.
• Dynamic nature:
• Duck typing - satisfying APIs dynamically.
18

19. OOP in Dojo
• Dojo doesn't try to make JS the language
"better".
• Dojo doesn't go against the grain.
• Dojo provides helpers for existing patterns.
19

20. OOP the JS way
• Constructor + delegation:
var MyCtor = function () {
// construct an object
this.name = “circle”;
};
MyCtor.prototype = {
// delegate all undefined properties to this object
radius: 1,
area: function() { return Math.PI * this.radius * this.radius; }
};
20

21. Delegation I
• Common idiom:
function Temp () {} // does nothing
dojo.delegate = function (obj, props) {
Temp.prototype = obj;
var t = new Temp();
Temp.prototype = null;
if (props) {
dojo.mixin(t, props);
}
return t;
};
21

22. Delegation II
• dojo.delegate() is one of the oldest functions
in Dojo.
• This pattern is so common that it was
enshrined in JS5 as Object.create().
• Still as you can see the constructor function is
unused.
22

23. Modern OOP techniques
• Problems with classic OOP:
• Single inheritance is no good at code reuse.
• A fish, a duck, a hippo, and a submarine
can swim. Does it mean they have a
common ancestor?
• Modern approaches: mixins, traits, aspects,
delegates.
23

24. Mixins I
• Assemble objects from independent "bricks",
which encapsulate a state and a functionality.
• Each mixin is like a mini-object, yet it doesn't
make sense on its own.
• It can be composed of other mixins.
• It is (re)used in different objects => all
dependencies should be anonymous.
24

25. Mixins II
• It can reuse and update existing object
variables and methods.
• It can have its own state and methods.
• It can be composed of other mixins.
• It participates in a lifecycle.
25

26. Object's lifecycle
• Constructing an object.
• Destructing an object.
• Required if object uses external resources.
• Application-specific events:
• Dijit defines events before and after building
DOM for a widget.
26

27. Interaction with mixin I
• Mixin can use host object's variables and
methods.
• The simplest way is to use a convention.
• Mixin knows names it uses.
• Object provides proper semantic units
using those names.
27

28. Interaction with mixin II
• Mixin can refer to object's methods
anonymously.
• There is a way to specify how certain
methods are called:
• Automatically before/after its host's
method.
• Replacing a host's method and using some
means (a super call) to call host.
28

29. dojo.declare() I
• Simple object + single inheritance:
// no parent, inherits from Object
var A = dojo.declare(null, {});
var a = new A();
// single inheritance
var B = dojo.declare(A, {});
var b = new B();
a instanceof A; // true
b instanceof A; // true
b instanceof B; // true
29

30. dojo.declare() II
• Mixins:
var Duck = dojo.declare([Bird, Swimmer], {
constructor: function (name) {
this.name = name;
},
say: function () { return “Quack!”; }
});
var duck_1 = new Duck(“Donald”);
var duck_2 = new Duck(“Daisy”);
var duck_3 = new Duck(“Daffy”);
30

31. dojo.declare() III
• Conventions:
• All mixins and base classes are sorted
according to C3 MRO (topological sort used
by Dylan, Perl, Python).
• All dups are eliminated.
• Order of dependencies is satisfied.
• Native prototypal inheritance is used to
chain all bases and mixins.
31

32. dojo.declare() IV
• Conventions:
• Constructors are called in reversed order.
• The deepest one is called first.
• A super call: this.inherited()
• No need to know who is "next in chain".
• Automatic after/before chaining can be
specified for methods.
32

33. dojo.declare() V
• In general dojo.declare() operates in terms of
dojo.delegate().
• It automates a frequently occurring pattern
using simple conventions.
• The only non-trivial addition is a super call.
33

34. How to reach me
• My web site: http://lazutkin.com
• Twitter: http://twitter.com/uhop
• Email: eugene@dojotoolkit.org
• Slides: http://www.slideshare.net/elazutkin
34

35. But wait! There is more!
• Dojo offers much more:
• AOP tools:
• Discussed in http://lzt.me/dBc
• Pete Higgins will talk more about it today.
• FP tools:
• Discussed in http://lzt.me/dB6
35

36. And even more!
• Even more tools:
• EDP:
• dojo.Deferred is included in the Base to
handle asynchronous events.
• dojox.lang.async provides high-level
primitives to combine/synchronize events:
seq(), par(), any(), select(), ifThen(),
loop().
36

37. That’s all for now!
37