We are finally reaching the point where dropping support for IE7 is pretty much a given, and the time when IE8 support can be dropped for even conservative audiences draws nearer. So we can finally join the brave new world of fully dynamic rich client applications written in cross-browser supported standard javascript. Well, not quite so fast…

Modules

Too many global functions pollute the global namespace, and your code becomes a mess, so after coming up with an only slightly less messy object structure, you decide to use a module system. Except javascript has no module system. Luckily, some people created substitutes. There’s AMD/require.js, or commonjs on node which you can use on the browser using browserify. Or you roll your own. Or the language itself will introduce a module system with the next version. Of course, any library you use may use either of those solutions, or none at all, and may or may not play nice with your choice. Anybody reminded of the Java logging situation, and what a joy that is?

Language

JS is a mess. So everybody clean it up and extends it in his own way. Until ES6, which might clean that up once it’s ratified and widely supported, some time in 2016 or 2017. In the meantime, you can use some ES6 features, and transpile to ES5 using Traceur. Or use Coffeescript and compile to JS. Or TypeScript, which is almost like some parts of ES6.

Templating

How many ways does one need to say “Take this text file, add code/params/data according to the keywords present in the text, and have the outcome be HTML”? According to the javascript world, at a minimum a choice of Jade, Handlebars, Mustache, Underscore templates, EJS,… – and those are just the ones most frequently seen in the wild.

JQuery

I love Jquery, and so does anybody who ever had to do DOM manipulation without it. And at least DOM manipulation is an area where everybody seems to have come to the same conclusion, which is to use JQuery rather than Prototype, Dojo or whatever else was briefly popular. So since everybody uses JQuery, you might also use it for utility functions, handling Ajax calls, providing UI components, and so one. Or not, or just for some of those. So for every kitchen sink query adds, any project might now do it the standard javascript way, the jquery way, or use some other library.

New Flavors of the month

So you found out that Jquery makes it really easy to add cool effects and do dynamic changes, and all was good. Then you added so many of them, that pages had several hundred lines of spaghetti code, and that was unmaintainable. So people came up with Backbone as a way to structure applications, and you rewrote your site, which was a lot of work, but was good. And then other people became more ambitious, and created Ember and Knockout and Angular, and now you’re tempted to throw away your 6 months old rewrite, and rewrite again.

It’s hard to promote Javascript (and when I say Javascript, I really mean the whole JS/HTML5/CSS/Client-sideMVC/browser-as-real-application-platform shebang) as a valid development platform as long as the platform is a rapidly moving target.

In the long term, betting against Javascript is usually an error, and I look forward to using cross-browser EcmaScript6 with a common stack of stable libraries. In the meantime: learn, experiment, prototype, promote and use the brave new Javascript world for the most compelling use cases.

(Post was inspired by somebody else’s decision to needlessly re-implement an existing, pretty conservative web application with AngularJS – something which the techie imp sitting on my left shoulder would just love to do, while the business imp sitting on my right shoulder cries…)