Unravelling the Dojo Widget(Dijit)

The Widget framework in Dojo solves 2 problems and both of them, elegantly.

For a UI application developer, widgets are essential. Before I continue, It would be useful to define what a widget's purpose is, to better understand its usefulness. A UI application will consist of well-defined visual controls that a user interacts with, to view/input information. For example: Dropdown lists, Text-fields, Buttons etc. It would be extremely beneficial if these were readily available rather than having to build something application-specific. Dojo addresses this problem with its rich set of widgets - Dijit Theme-tester link.
[I wont get into a lengthy discussion of why the native HTML controls are just not enough or compare Dojo's widgets with an other framework.. Did I hear someone say jQuery UI or ExtJS :) ]

Second, and the one which I think has been solved by Dojo really well is the Widget authoring framework. It is the same architecture that's used to build the widget set seen earlier. Developing new widgets\Customizing existing widgets is a streamlined software engineering process because of this architecture. 
From here, we will dive into the internal workings of this system. It is not going to be a 101 course in building Dojo widgets. It assumes that the reader if familiar with developing widgets.There are excellent articles for those:
Understanding _WidgetBase - Tutorial
Writing your own widget - Reference Guide
dijit._WidgetBase - Reference Guide
Creating Template-based Widgets - Tutorial

By the end of this post, I hope to have explained some of the magic hidden in these framework classes: _WidgetBase and _TemplatedMixin will be the focus of this deep-dive. 
Every Dojo widget that is readily available or any new widget that you would develop would utlimately subclass _WidgetBase. This is the basic contract of building a Dojo Widget - a Dijit. Hereafter, when I use the term widget, it means that I am referring to a Dojo widget.
The _TemplatedMixin allows widget developers to specify the UI of the widget in a seperate file which will be processed during the widget construction.
Github links to these classes:

• _WidgetBase Source code 
• _TemplatedMixin Source Code

Here is a dojo-sandbox link to a very minimal widget built using these classes:
http://jsfiddle.net/deepakanand/hxxx220q/
We will copy-paste a code snippet from that link for the purposes of our discussion here:

1 2 3 4 5 6 7 8

var MyWidget = declare([_WidgetBase, _TemplatedMixin], { baseClass: "myWidgetBaseClass", templateString: "<div></div>" }); var widgetInstance = new MyWidget({}, "widgetcontainer"); widgetInstance.startup();

MyWidget is the new widget which has its own baseClass and a simple template which consists of a single div element and no attach-points or attach-events.

widgetInstance is an instance of the MyWidget class.
The startup() method is the last of the lifecycle methods that needs be explicitly called(but oft forgotten) after instantiating a widget and placing it in the page.

A class diagram showing the architecture:

TODO:  Detailed description of code-path

My experience with Dojo

I have been working on UI for a few years now. About 1.5 years ago, I started developing JavaScript using the Dojo framework. I wish I had been warned before I started, that its not yet another JS framework. It is/has eveything that an organization needs to build single page applications.
I felt it important to write about my experience with JS and all of the jQuery goodness before Dojo.
JavaScript is a still a new language despite the countless blogs and tutorials to help understand its good, great and not so-great parts. As a web developer who worked on different web-sites at school I naturally picked up jQuery. With it's expressiveness(chaining etc) and cross-browser support, it was easy to get addicted to it. The introduction of the jQuery UI framework was everything a web dev could ever ask for. Both(jQuery Core and jQuery UI) these frameworks together helped reduced tons of boiler-plate, provided great APIs and a rich widget set. Note that I never mentioned code organization so far. I still used to modularize my JS into functions and some name spacing. I would split code into short script files and include all of these on my page. Code organization was a problem I pretended did not exist. 

With the influx of all the jQuery plugins, I jumped head-first noodling with them and eventually using them in my projects without understanding that some of them do not have full-time support or are not maintained by their owners reliably. 

It was then that I realized that it takes a much more disciplined approach to build large web applications.

Forward to today, it has been a rich learning experience developing JS code using the Dojo framework. The require, define and declare functions, underpin the code organization. I learn of different ways every day to utilize one of dojo/_base super useful modules. It's refreshing to see the toolkit's approach to providing enhanced functionality but deferring to the browser default if native support is available, without polluting the global objects. The widget system known as Dijit, is fantastic. It not only has a rich set of widgets, but has a set of rules governing how widgets must be built. It's supports template-based widgets which is so much easier to maintain than widgets coded completely in JS. 
I look foward to sharing more of my dojo experiences as code samples in future posts.