Shared publicly  - 
Oh No, Dojo -

Just now getting around to looking at +Dojo Toolkit 1.7, currently version 1.7.2. The 1.7 branch has actually been out for a few months. It's supposed to be backwards compatible. Well, it isn't. =/

Here's the problem: if you are doing a custom build, which I hope you are, the you probably have optimized your page loads by including necessary modules or layers as <script> tags in your header. Instead of using a bunch of redundant dojo.require() calls, you are putting exactly what you want to load in reusable modules to optimize download times for each page of your app. These modules are, of course, defined in your build profile. However, now, with Dojo 1.7, your development environment will no longer work with <script> tags. They've changed the loader such that you must use dojo.require() to include modules or layers of your custom build... (See for more details.)

Say what??

This would mean that to just jump right in and get running with Dojo 1.7, you'd need to make your development environment build against a non-source release of Dojo. Granted, you don't really need to care about download-time optimization in development so much, but having the uncompressed source code handy in your IDE sure is helpful when you are using that certain undocumented part of Dojo that just isn't working as expected. (Let's face it; that happens a lot.)

In other words, Dojo 1.7 is not backwards compatible for any reasonable build system you were already using for your production deployments. This is very disheartening. I like Dojo and have been using it for many years now. I had a nice, tidy build that would compress the scripts in-place for production deployments and leave them alone for local testing. Now, I'll have to keep the source tree on-hand somewhere it can be compressed and then shifted into place while using a pre-compressed build simultaneously in development. Ugh...
Note that many core and dijit modules have been converted to use minimal dependencies in 1.7, to support lighter footprint when used in conjunction with async loading, and AMD module format and async ...
Add a comment...