x vs. y – jQuery vs. dojo

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.

When you need or want to write a client-side application with very dynamic, (meta) data driven UI layout and UI logic – or even a Web 2.0 application in Single Page Architecture (SPA) where all is written in JavaScript and executed in the browser except the backend services – you are better off with a framework or toolkit that implements all the concepts and paradigms you find in successful, matured, and hardened large software systems…

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…

But before moving on, let me finish the dojo section regarding SPA applications, where ‘the page’ is loaded only once and even that only partially. After initial (partial) load, everything additional is done on-demand through AJAX – for pull and push data and pulling code (html, css,…). Furthermore, SPA supporting backend services can be written in JavaScript too, and will then run under, for example, Rhino. There are worse language choices for writing backend services. Using JavaScript makes it possible to take advantage of the option to use the same ‘slang’ and code-identical implementations of model/data objects in client AND server, for sure something with great benefit. How many times hear we the complaint that the very same (custom) validations have to be implemented in different technologies for client vs. server? …and worse: the initially identically behaving validation implementations ran apart over their life time and lead to data corruption? Ventured into these thoughts show clearly that dojo with its strong abstraction, object-oriented, class-hierarchy, interfaces, and many not only UI aspects supporting components becomes the platform framework of choice. Just for the record: there are other similarly spirited JavaScript frameworks out there (see references @ on wikipedia.)

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.

Luckily, with recent development in the area of javascript frameworks and how these frameworks are implemented (in the namespace less javascript context), frameworks can be combined. Founders of once mutually exclusive – no coexistence – and absolutely incompatible javascript frameworks joined, for example, the common javascript module loader bandwagon to enable implementors to pick and chose and combine components from any framework and have not to become religious. This opening-up and growing together in the lower-level, technical layer of the once disjunct frameworks turns out beneficial for all and foremost for the user. The user gets the best of all what is out there, and management likes the potential for total cost of ownership (TCO) going down.

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/)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: