The USS Quad Damage

My app, infonom is about half way to MVP. I decided to go full retard on javascript, mainly to force myself to learn the language, and how to use it in a decent context. Honestly, there’s a lot to like. I can see how a lot of people are into it. While I personally can’t survive without the velvet rope of type safety, I did enjoy the sort of flexibility that prototype based languages give you. It’s certainly an odd kind of flexibility, but also a good kind.

Prototypes still confuse me, mostly because of what properties are copied and what properties are mirrored, but it’s a fairly powerful concept. The idea that your “class” hierarchy is based on live objects that have the opportunity to be changed and updated can enable a bunch of tricks that generally require far more impressive language features. You can mimic a classes style system, or traits, or some functional semantics, all by using and abusing the idea of prototypes. In the end I’ve learnt enough about Javascript to make peace with it.

But I realised very quickly that I hated each of the three technologies I used: knockoutjs, node.js, and couchdb. But hold on because there’s a surprise twist coming.

Let’s start with node. There are a couple of reasons I like Node. One is that it makes it very hard to block. The code you must write to block is annoying to write. The second is that it “solves” multithreading in a novel way: By not having any. If you want your code to scale, it must work in a way that’s parallel. If you can “distribute” your code across several cores, you can distribute it across several machines. In normal multithreading there’s a huge discrepancy between many cores on a single machine and then switching to having the service go across multiple machines. Finally, it makes coding fun at first. You’re writing node and refreshing your browser and it’s all very quick and easy.

But it has problems. Incidentally, the node haters are just plain wrong. Without getting too distracted: Python runs slower than js, every language with blocking somehow has very slow frameworks (I wonder why), Node makes concurrency easy across computers, and “sharing code between front-end and back-end” is actually supposed to mean “I can decide later where I want this to run”, which you can’t do in, say, Java.

Where was I? Oh yeah! It does have problems! The first is that it’s javascript which is an awful language. I know, it’s got redeeming features, but that’s like saying “smoking helps you lose weight”. It also quickly scales to the point where it’s no longer fun. The language is no fun, the structure is no fun, the libraries are shit, and you start to wonder what the hell you’re doing in the baby pool. I could just as easily do this in another language by just removing all of the frameworks. It just all starts to grate. The language grates, the environment grates, and the benefit you had at the beginning: “quick” fades into the background.

In short, I’m looking for a way out of Node.

Now, onto knockout. I’m actually a big fan of MVVM. I think this is how applications should work, especially on the web. But after thinking about the zen of knockout, I’m finding myself increasingly at odds with the framework. The thing is, knockout treats JS as the view-model and HTML as the view, but HTML isn’t the view! If anything, it’s literally the view-model! It’s the representation of the model for the view (the browser). So, in a way, knockout is really just an elaborate translation layer between javascript and HTML. I still think there’s a kernel of knockout that’s valuable, but unfortunately it’s not the code.

In short, maybe I’m looking for something more akin to d3.js instead of knockout.

Finally, let’s talk about CouchDB. Couchdb is a document oriented DB written in Erlang. It has multi-master and effectively “solves” CAP in a particularly elegant way. However, it commonly uses Javascript to do map-reduce functions. It’s also no fun par excellence. Unlike “non-scalable” databases like SQL (or Mongo), Couch literally asks you to solve all the scalability problems up-front. It really does your head in. You want to make a simple website, and you have to start considering copy-on-write and merge conflicts. There’s also the temptation of doing micro-optimisations to lower the number of REST calls you make to Couch (talking to Couch is done using a REST interface, and it does so in JSON).

I can’t tell you how irritating it is trying to figure out how your data model is going to work when in reality you actually don’t care just yet and you promise to think about it later. However, you also know better and you won’t think about it later and it’s actually a good thing Couch is forcing you to do this. The good news is that once you’re done, you’re done. Start whacking the data in and... as they say... relax. Though it’s relaxing after like a year of constipation.

In short, I still like Couch but man I’ll really consider an intermediate data model before I use persistence in future apps.

So there you have it. Fuck node off, change knockout to be completely different, and keep Couchdb. In conclusion: Javascript!