Please take a look at the application I have built, the build step is just two commands: https://github.com/amitu/dkudos/blob/master/build_dojo, and the "require boilerplate" is just 7-8 lines: https://github.com/amitu/dkudos/blob/master/prof.js (if you ignore the comments).

A lot is happening in dojo, the dojo development has picked up pace lately and dojo2.0 is going to be a huge step forward for simplicity and richness.

I have mentioned at the beginning, if you just want a jquery like work, Google's CDN is available for dojo too, and the CDN has all the modules required to get jquery level functionality baked in.

IIRC HTML templates never quite let me auto-detect what JS to include in the builds. The manual configuration was too much of a pain. That 7-8 line file is sitting there saying RTFM for something that is trivial when taking the path of least resistance. Copying a one-liner to load jQuery into a base template is as simple as it will get.

I'm basically resistant to any and all JS compilation. It's like multi-threading in pure Python. It's more complex, doesn't leverage the existing strengths, and in the end doesn't even really do what it says it does.

If you do not do JS compilation then you are either forced to not split up your project into logically different files, or you incur too many HTTP requests over head.

If a project is just a few lines copy pasted here and there, then sure, but for any more complex project you have to build.

My opinion is that dojo should forget about backward compatibility once, or create a dojo2 fork, there is too much new things happening that are quite exciting. But dojo is slowed down due to legacy code support.

jQuery is good for another 20 years. But is backbone? or angular? or Would it be the new components thing google released?

Remember dojo is not just jquery, its jquery+backbone+requirejs and few things put together.

I really did have some hope for being able to use some of the DB-like tools and integrations with Django, and even started work on using the graphics library to write an SVG converter to display on all browsers. What a dead end all that turned out to be. Libraries like lawnchair, history, and kinetic or some other canvas library just seem to run circles around the larger libs for whatever it is that the focused libs do.

I really like larger web frameworks like Django because a lot of what those frameworks provide is only won at a high-cost to the programmer if not done as part of the architecture. Going more micro means more work in those cases. Going more macro with JS when 99% of pages need a contact form is not making me feel empowered.

JS libraries are to me like single-celled organisms. Sure they spring up and die a lot, but out of all that change and natural pressure to remain small and decoupled, it's not necessary to tie one's future to any one of them if they act up. Dojo 1.8ish made me greatly loathe not being able to swap out that one misbehaving part because of commitment to the larger scheme.

I take your point. Dojo has tried to do a lot of things, and some of those have not panned out as well as the other parts.

I am getting your point. I would prefer if dojo lowered the marketing on the rich set of existing widgets, as very few people will every use dijit/Button over native button.

But dojo's object store/MVC, dojo's widget system itself, the build system/AMD, they have proven themselves over a period of time.

Don't use dijit widgets, but do create widgets using dijit/_WidgetBase is my recommendation to everyone learning dojo. And none of the grids, and layouts and SVG etc etc. They inclusion in dojo code base is one of the reasons so many developers get put off by dojo.