If you need some make-up to boost a bland HTML Web page, resorting to (quite script/function oriented) jQuery is the ‘right’ thing do. I say this in favor of jQuery even though dojo/dijit can do that too to – some extent.
Your bias shows blatantly…’ I hear you muttering…
…and – yes – you are right: it all depends what has to be ‘done’. If there would be no bias, there would be no jQuery vs. dojo…
Other rationals than function, such as multi-tier suitability, matter though as much…
Great bang for the buck you get with jQuery. jQuery’s brilliant features transform frugal (groups of) Web page elements into really good looking, function rich ones that deliver a very pleasant, ‘wow’-user experience. But beyond using what jQuery gives you out of the box and its compounds, jQuery becomes very challenging. When you find in jQuery’s box what you need, there is no need to look out for greener grass… (Why fix it, when it’s not broken! Why complicated (objects), when simple (function) is sufficient). Same can be said for quite often used PHP for jQuery front-ends, even though PHP – and also jQuery – support implementing in strong object-oriented discipline. And even if you cannot find it in the box, rarely you will break out (right away): You stay within and use your gained experience to tinker together what you need in a ‘nice’ kludge tower. Only when the tower’s operation / maintenance becomes unmanageable you wonder if there is something out there with a potential for growth beyond the current limitation (Btw, nothings is safe from tinkering, instead of doing ‘the right’ thing.)
With dojo, it is (quite) a bit different. To get dojo – or dijit (the visual part, widgets) – off the ground and (visually) flying as brilliantly as jQuery – you need a bit more bucks: more bucks not just in terms of time, but also in terms of proficiency in computer science of your builders.
DTP – Graphic Design / Desk Top Publishing – and CS – Computer Science – are two different skill domains – and both are needed to succeed in today’s www era. Both started approaching www from their base with tweaking the tools they had at hand and served them well, and (could) understand. Therefore it depends not only on what you want to achieve, but also what kind of resources you have available to get there. Therefore, in the past, it was either this or that framework.
To reap that benefit, both DTP/Graphic Design and CS have to work very closely together to deliver both of their best breed as an easy to consume package than rather fight each other.
Total rewrites in a different world with the expensive (re)start from scratch are not required anymore to move beyond the limitation of the initially chosen framework(s). It is rather a ‘smooth’/gradual and ongoing replacement of not so suitable components of one framework with more suitable ones from another ones.
For reaching the state of ideal coexistence – and actual TCO decline – still a lot of ground has to be covered… not just by the framework builders, but also by the ‘users’ – developers, just like me – to let go outdated experience biased from my origins, experience that now has become prejudice. I have to open up as well and acknowledge that all frameworks have mended (most of) their weaker areas. Also, I don’t need anymore to hide my envy for the cool (visual) jQuery features behind a discussion of ‘this is better than that’ by pointing out (just) the other framework’s (may be) not so strong areas.
Now, I can enjoy all (of both) worlds, move on, and focus on solving the actual problem… a win-win situation for all involved parties – most notable so for the end-user.
PS: Origins always stick… but there is no shame on staying a fan for the team of the town in which you grew up… and it’s no war either – just a game… 😉
(Initially posted as a comment @ worthofweb.com/blog/is-jquery-better-than-dojo/)