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.
In short, I’m looking for a way out of Node.
In short, maybe I’m looking for something more akin to d3.js instead of knockout.
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.