Rui CarmoRather to my amusement, this week I realized that over the past year or so I’ve spent a significant portion of my (quite limited) coding time doing JavaScript - and liking it.
This has probably more to do with the way frameworks like zepto.js and backbone.js enforce a degree of structure than to anything else, for in keeping with my usual approach to coding (i.e., handle everything as lists, use high-level abstractions for list handling whenever possible, and toss around hash tables with wanton abandon), I still get new opportunities to curse its idiosyncrasies every day - especially when trying to use or modify existing code (seriously, are there any sane coding conventions in the JavaScript world?).
Also, to be truthful, JavaScript is one of the few things you can work on using an iPad without any extra hardware whatsoever - lacking a “normal” environment, I can nevertheless code and test stuff in it using nothing but Textastic, even when I’m away for the weekend and trying to enjoy the countryside…
Still, tackling entirely client-side apps is rather more fun than I anticipated (I’m doing a couple of pet projects, as befits anyone who works in a high-octane geek environment, regardless of management role), and even though there is a lot to be said regarding testing and debugging, tools have probably reached the point where my gripes against the language can be (mostly) put aside.
Except on the server side. Seriously (and I know I’m going to annoy a lot of JavaScript folk with this paragraph), anyone trying to run a long-term production site on node.js and its mongrel, patchy frameworks seriously needs to have their head examined - the breakneck speed at which they’re evolving might be great for those caught up in it, but making sure you have a reliable upgrade path seems nigh on impossible - some of the (very) simple stuff I did on “stable” setups six months ago doesn’t even run today1.
Anyway, back to the client side. Doing functional programming in JavaScript feels somewhat like recollecting guilty pleasures of late night parties in college labs with curvy LISP interpreters, and were it not for the rather noisy syntax, might even be classified as aesthetically satisfying. Toss in labour-saving declarative approaches like AngularJS (which I’m not using - yet), and amazing visualization libraries, and suddenly doing client-side development (the canonical flow control nightmare) becomes positively sexy.
So yes, there is a degree of elegance and maintainability in modern JavaScript that I find good enough for me to put up with it on the client side. The real issue is, I think, the stupefyingly limited language and its limited expressiveness (i.e., you tend to rely upon libraries like underscore.js and zepto.js to have moderately sane selectors and iterators, and the “object” model borders on the schizophrenic).
That form of functional autism, so to speak, has caused more and bloodier wars than anything else I’ve seen in front-end development over the ages (probably even more than the Gnome-KDE wars), and it shows no signs of letting off - the new, trendy “full stack” frameworks that are now popping up are all fun and good, but in the end they’re just fancier templates and client-server bridging, doing nothing to make the client side any smarter.
So no, I’m not a convert. I’ll probably never really like any form of development that involves slicing up your application into portions written in different languages, pasting the public bits amidst HTML, and tossing them with wild abandon to the client in hope that they’ll attempt to call home and hold a dialogue with your server using the electronic equivalent of crayon-scribbled postcards.
But it’s the only game in town right now if you want to deploy interactive applications to any device, so I’ll just try to get better at it whenever I have the chance.