A quick history
Although the improvements to the shared ecosystem, tooling and browsers in general have been great for developers and users alike, it has meant a shift by many individual developers away from adding their work to larger projects to instead releasing their work as small standalone modules.
The YUI blog post touched on this by saying:
We don’t think it has to be one or the other!
A vision for flexibility through modularity
It may not be as sexy today to provide a larger toolkit that does many things, but our users actually appreciate this, and choose this path for a reason. When building mission critical software, the last thing you want to do is to figure out how to make 20 different projects and their multitude of various dependencies work together, let alone determine how to maintain that house of cards for the lifecycle of the application.
Our approach has been to provide tested tools to build robust and flexible software in one unified release with a shared core and philosophy so that you can focus on building your app instead of endlessly tweaking the new shiny things to get them to play together nicely. At the same time, there are no walls, you can extend Dojo to your heart’s content.
Dojo has, and has always had, a module system. In fact we helped pioneer AMD, a flexible module loading format that is most popularized by the Dojo Foundation Project – RequireJS. Our vision has always been for a more modular and interoperable ecosystem. But even as more developers have recognized the usefulness of packages, the vision remains unfulfilled. Something as simple as modules has led to a plethora of module formats and metaformats to try and wrap all other formats (e.g. UMD, CJS, AMD, ES6 modules, Browserify), and then on top of this there’s a divergence on package managers (NPM, Bower, volo, etc.). The community suffers greatly from this fragmentation, where we cannot agree on interoperability and de facto standards, and then work to make it so things can truly be used together more efficiently and coherently.
Dojo 2 – Building on the Vision
We will stay true to our base of users that have selected Dojo over the years, while making it possible for people to more easily mix and match across projects. When Dojo 2 ships, it will be a fully documented, tested, and coherent set of packages that work well together, that can also be used and upgraded independently with other modules. This is already possible with Dojo 1.x, but it will be how the entire project is run in 2.x.
What now for YUI users?
If you are a user of YUI and wondering what to do now, you could choose an amalgam of projects, or you could look at Dojo, either in its current incarnation or in its planned Dojo 2 form, and hopefully get the best of both worlds: A flexible collection of packages that contain a consistent approach and architecture.