Angles

I have a number of philosophical differences with JavaScript, and it doesn’t help that it’s the new duct tape of the Internet.

Anyone who prizes readability and maintainability will probably share quite a few of my gripes regarding it even without tossing in the utter lack of clear, consensual patterns (have you ever seen two implementations of anything in JavaScript that are clearly alike?), poor syntax, worse modularity and an overall tendency for reinventing the wheel with chromed rims, spiked tires and pentagonal layout.

Even after reading The Good Parts I’ve tried to keep my head while delving into it, but in the end there’s simply too much brittleness to ignore, and given that I don’t partake of the “sure, I know jQuery, that’s all I need” mindset I’ve been hacking away at it in the back of my mind, always looking for something better.

After all, there has to be a better way to deal with the syntax, the arbitrary inconsistencies of the language, the insanity of four major browser environments and all the mental noise that comes with trying to build a rich web application with the equivalent of chicken wire hung off a thresher.

In the brave new Clojure world I’m dipping into these days, frameworks like Pedestal solve a few of these issues by way of paradigm shifts – not only are you able to abstract away most of the boring stuff by casting an application in terms of state transitions, but you can also write common (or, at least, very tightly bound) code for client and server thanks to the Clojure/ClojureScript duality.

I’m wary of committing everything to a single language, though, and as such I’ve been focusing on ways to cut down on the JavaScript insanity first (keeping the back-end in Python or another known quantity).

The first thing I investigated was data binding – i.e., the ability to update a client-side model and have those updates reflected in the DOM without the demeaning job of pushing elements around manually. JavaScript’s next frontier isn’t about performance (it’s not going to get any better) or standardization (even if ECMAScript 6 pops out of the oven anytime soon, it’s not going to fix everything) – it’s about sane, maintainable abstractions that you can build upon.

At SAPO, where I work, the issues of modularity and maintainability have been foremost in people’s minds for many a year, and our client-side framework (recently made available under a MIT license) has a clear, structured approach for building reusable components – both visual and logical, even though the visual side of things has gotten a bit more traction lately thanks to the solid and exceedingly nice CSS foundation.

But toss in Knockout to extend Ink in such a way that you can perform both data binding and data-driven, dynamic module loading, and you have the makings of a nice, easy to maintain and extremely flexible way to build highly complex applications with each Ink module mapping easily to a model and its set of observables, behaviors, etc.

The icing on the cake (and the hardest selling point to get across), however, is that with Ink’s dynamic module loading tied to data binding you can have your app load piecemeal as required, making for a more lightweight, snappier app (i.e., without lumps of application logic you’ll never use cluttering up your runtime). And an easier to test one, too.

That’s part of what I’ve been mulling of late, and something will eventually come of it – besides a couple of internal apps already using this, there’ll eventually be a demo app and a set of samples, but time (and not just mine, of course) has been thin on the ground lately.

Still, given the drawback of still having to write JavaScript, I went looking for ways to achieve similar goals in ClojureScript, even though it’s currently joined at the hip with the Google Closure Compiler (no relation to Clojure itself) and has a somewhat annoying runtime penalty – you need to put up with a little overhead in terms of compiled code size, which may be an issue for mobile environments¹.

I had trouble finding a way to get data binding to tie in nicely with ClojureScript until I found clang – which provides a rather nice and idiomatic way to create AngularJS models that tie in directly to the richer, saner ClojureScript data structures.

I’m not fond of AngularJS (I’d rather keep using Knockout, which is smaller and more focused²), but early results are encouraging enough for me to press on – I can start with known quantities and abstractions and gradually work my way up the Clojure ladder to functional nirvana.

Now all I need is a month’s worth of quiet Sundays to see if I can get something properly done with it.