One of the words that I hear used to describe Dojo a lot is "framework", and it always causes me some concern when I hear it. Frameworks tend to control the way an applications is structured and manage them from the outside, but Dojo provides multiple points of entry. Internally, Dojo is just a layered set of libraries. Hopefully this diagram can help illustrate it better: When laid out this way, it's pretty easy to see that almost all of Dojo is "pure library"; JavaScript functions and utilities that can be used independently of each other. The package system binds them together by allowing one module to request another (and allowing your code to not worry about dependencies). The only part of Dojo that starts to feel "frameworky" is the widget system, and even that is only loose scaffolding around a widget's lifecycle. There's no requirement that widgets be instantiated from markup or be registered with the manager object. That most Dojo builds contain much of the infrastructure and make it *look* as though it's a cohesive whole has more to do with being able to unit-test the individual parts than with any top-down design. What's not obvious from this diagram is that the package system supports using Dojo as a library by letting you "build" a profile of Dojo that includes just the features you need. By placing the package system at Dojo's core, application developers can optimize builds transparently and speed up their development. Web application development professionals often wind up gluing together many of the layers outlined here from pieces which aren't tested together (or even on their own) and which may contain considerable overlap in functionality. Dojo provides all of these building blocks in one place. The most accurate way to describe Dojo is as a comprehensive set of libraries for JavaScript, from which you can mix-and-match to suit the needs of your application.