In the last few years I noticed that in some environments there are even more cultural wars over jQuery than over ‘Mac vs PC’. I’ve been involved in a few myself (OK, I did start a few as well).
I spent part of my career coding on Prototype.js for a corporate company. The choice of Prototype was made back in 2006 and it was a no-brainer: the product was solid, the community was solid and essentially anyone who was working within the Ajax bubble was looking into it.
At first it was awesome: a great shift from the unorganised/copy and paste way of doing
team, more focused on releasing than consolidating, and in spite of our efforts it became
impossible to upgrade the library from 1.4 to following releases.
Actually, and I still feel dirty about it, we patched Prototype in order to support new browsers and fix some bug rather than upgrade it. Our bad, for sure, but it’s a pretty common behaviour, isn’t it?
After a couple of years none of the newcomers knew Prototype.js anymore. Everyone was using this magical jQuery thing, and eventually it became hard to find community scripts and we were forced to write everything on our own. Nothing wrong with that, but sometimes you’d prefer relying on a good, community-tested and supported script instead of being forced to face the same problems over and over again.
“Those who cannot learn from history are doomed to repeat it.” (George Santayana)
What I learnt from my company dev history is that marriage to a general purpose framework – even if you love it, even if it is the best for you – can end up being a cage. I know this doesn’t sound romantic at all, but it’s way more realistic in terms of what may happen.
Don’t get me wrong, I’m not saying you shouldn’t use one – that would be crazy. Use whatever you want for your UI, play with it, enjoy the smoothness of jQuery plug-ins (better if you know what they’re doing on your page, but whatever …) or the data integration you’ll have with Ext JS modules, but keep your foundation core far away from this kind of specificity.
Speaking of Ext: recently I worked on a mobile/responsive website in which, to be able to
reuse some existing scripts, I was supposed to get the advantage of the event driven modular architecture on which the desktop version was built.
This requirement forced me to use Ext JS on mobile since the core of the architecture was
strictly bonded to it: I had no time and not enough tests to decouple it without taking too many risks. (You may have worked with and loved Ext – that’s perfectly fine – but you’ll likely agree with me that on mobile it can totally be bloatware).
Keeping it clean (or not)
There are really a lot of advantages in trying to keep your code clean, and sure: TEST IT!
Make sure that your wrappers are doing what you expect, and later on you’ll be able to
unplug a framework and plug another (maybe a new, shiny version when it becomes necessary to keep up with new browser versions), switch the whole UI to the new one and see your api SDK (for example) still working like a charm.
Beside the adavantages that your website or web app may have in not being bonded to a
Ask yourself if you want to be a jQuery/Backbone.js/whatever developer forever (trust me, even if you are saying yes, inside your heart you know that the right answer is no). Pick the right tool for the job without fear of experimenting or hurting your own feelings.