The final draft to finally finish. This one was started about nine months ago… And finally a tech-focussed post!

&

I’ve never been a web programmer. At least not in the real sense of the word.

That’s a gap I didn’t like but, until a couple of years ago, no problem presented itself requiring me to become one…

node

Until one did. A simple project at work that meant I could solve a problem (for the entire company, not just my department) and learn some form of web programming. A quick introduction to <form> from my father-in-law and I was off … this stuff’s easier than expected

I’d heard a lot about node.js being the daddy so I thought I’d try it out. Which meant learning javascript - an apparently invaluable tool for client-side web apps that’s now invaluable for the server-side too.

Browser hell

OMG in many ways I’m glad I came late to this party. Not all browsers are created equal. Especially IE. What a mess. Thankfully being late means there are a number of frameworks that help plaster over the cracks of incompatibility…

A different approach

One of the claimed benefits of node.js is its speed. And it derives that from its single-threaded nature. A good old event loop then…

It feels counterintuitive that a single thread should be faster than multiple threads. As ever though it’s a case of horses for courses. Work that can be efficiently broken up into a well-known number of isolated tasks is likely to be faster using a multi-threaded model. But if we’re dealing with an unknown number of tasks that may contend for the same resource, there are benefits to single-threading since CPUs (like many humans) find context-switching expensive.

That means a different approach to programming - asynchronous. I find that does require a certain amount of mental acrobatics but I like the implied efficiency: if one user’s session is waiting on I/O the thread will continue processing other sessions. From what I’ve read, this approach is so much more efficient, node.js can deal with thousands more sessions than the thread-per-session or similar approaches of Apache / IIS. I haven’t done any load testing so can’t confirm or deny my reality … but gut feel is good

Editing…

Yes, you can use vi. And I do when that’s all there is. But I prefer not to… And I’ve never really got on with emacs although I can’t help but feel that’s a bit of a hole in my claim to geekdom. Just as all geeks should know at least enough *nix to get by, that means knowing vi. Tick. But emacs falls into that camp too … you ought to know at least enough.

I started my javascript journey with TextPad. I’m used to it and it does enough. Then I tried sublime which is also fine. Then I thought I’d challenge the habit of a lifetime and buy some software … so of course a free trial beckoned. I’d read good things about WebStorm and after the trial I decided it was worth the £39 asking price even though debugging (an expected mainstay of an IDE) isn’t brilliant

Current state

I love node for small projects. It’s very easy to get something up & running quickly. And there’s a good ecosystems of components to re-use (and its dependency management, npm, is great). Although many don’t have good documentation, pretty much all are open source so it’s not that hard to find a likely candidate when searching for a specific method

However. I’m not sure I’d use it for large projects. For some definition of large.

If you’ve got a collection of microservices and you’ve got deployment down to an automated fine-art then node could suffice. I’ve proved a zero downtime deployment approach with node (pretty trivial for my imperfect but good enough example).

But javascript with a team of dozens of people? I dunno. But then I’m not a fan of large teams anyway … two pizza teams work well with java, perhaps they’d work well with javascript too Certainly the monolithic apps I’ve seen would be an even bigger disaster with javascript.

The main reason I feel this way is the lack of type checking. using strict helps a bit but there are still run-time issues I find related to type or, more often, inconsistently named variables (which, tbh, is also why javascript is so flexible). Perhaps ES6 or TypeScript would help.

Of course automated testing goes a long way to alleviate this problem too. I’ve played with mocha and rather like it…

Oh and before you ask, I’m not a fan of coffee. Nor coffeescript particularly. Probably just a lack of familiarity (because it does bring attractive brevity) but, for now, it can stay that way.