4 ms·

To be perfectly honest, the API changes from 1.7 to 1.8 were pretty much catastrophic. Might as well have included instructions on bandaging back lacerations.

To be perfectly honest, the API changes from 1.7 to 1.8 were pretty much catastrophic. Might as well have included instructions on bandaging back lacerations. It was like working with a different library. JQuery looks good to go for another 20 years. It's easy so it costs me no effort to maintain the skill. If it eventually dies, I will have moved on to native pastures already. The arguments about being able to do all kinds of crazy stuff without bloating code size just don't make me happy at all. Should we include an extra build step and production pipeline complexity for web, something that is supposed to have flexibility and speed-to-deployment as its evolutionary strengths? I can't even remember how much time I ended up spending on JUST the silly require boilerplate, which accomplishes mostly nothing because it's not like I ever want to fetch javascript asynchronously. CDN JQuery is a 304-not-modified and my code is gzipped by nginx if the page is over 4kb. Hey look, it's really fast and I didn't work at it. JQuery 2.0 is about to be out, so goodbye old IE bloat. I'm happy with ever increasing internet speeds, ever faster browsers, and a plethora of small libraries ideally suited for various legs of the journey. I've never used underscore, knockout, or angular, but I know that if I ever run into a problem that requires more architecture, I should go find out what they do. This can be one's approach towards almost all problems in web. Which comes first: a focused javascript library or an implementation of it on top of the Dojo (or any other) API?

amitu 13y ago
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.
- knappador 13y ago
  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.
  - amitu 13y ago
    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.
amitu 13y ago
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 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 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.
- knappador 13y ago
  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.
  - amitu 13y ago
    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.

amitu 13y ago

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.

knappador 13y ago
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.
- amitu 13y ago
  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.

amitu 13y ago

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 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 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.

knappador 13y ago
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.
- amitu 13y ago
  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.