Don’t get tied to one JavaScript framework


Marriage to one JavaScript framework can be limiting. Here Marco Cedaro argues for putting long-term relationships aside and experimenting a little

Back in September I was trying to find some inspiration for a talk proposal for Italian JavaScript Day. I was giggling over some different ideas when I came across a ‘love fact’: two out of five people marry their first love.

How sweet, I thought. And suddenly I knew what to talk about: JavaScript and Love.

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 can’t stand working with people who choose a JavaScript library without thinking about an application’s needs, life cycle or anything else. People who just come straight to a conclusion that they’re in love with one framework rather than others (which often they don’t know anything about).

Changing times

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
JavaScript of a few years earlier. Yet problems were around the corner: we were a product
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.

History repeating

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

It’s healthy to write in vanilla JavaScript when possible (and it’s faster too, if you care about that – which you should). It’s healthy to have a namespace and wrap external libraries’ invocations in their own functions (think about UI components such as lightboxes, carousels or tab managers). It’s healthy to choose a specific (micro)framework if you don’t need a general purpose one, and not load a lot of unused code in your web page.

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
framework, there are a lot of benefits for your personal development too: JavaScript developers unable to detach themselves from a framework (an architecture, a coding style …) will be in trouble when a new one takes the lead, or even when they join organisations relying on frameworks chosen in 2006.

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.

JavaScript can be extremely fun if you put romance aside and start playing with it. Go on, be a JavaScript pervert.