It’s been a few months since the storm erupted around this post on Node.js by Ted Dziuba. Ted writes in a deliberately controversial style with comments like “Software development methodology is organizational Valtrex.” raising the ire of readers and his post on Node.js was no exception. When he pointed out the Achilles heel of event loop frameworks – that any computationally expensive operation in the main loop will cause the whole system to grind to a halt, fans of Node rallied round and did one of two things – they either missed Ted’s point and pointed out that his method of calculating the Fibonacci series was sub-optimum (and missing the point that it was supposed to be an example of an expensive operation) or pointed out that Node is still young, addresses many common use cases in web development and fits a useful niche with real business benefits.
- Is promoting the idea of one language for all domains a good idea?
- If we need to create sub-processes or workers for potentially blocking tasks, aren’t we just recreating threading but with crappy scheduling?
- We know that threading is bad but does that automatically make event loops good?
Is promoting the idea of one language for client and server domains even a good idea?
If the recent explosion of languages has shown us anything, it is that not all of us think alike. Some of us love functional programming, some prefer object orientated programming. Some love prototype inheritance and some prefer class based inheritance. Some love static typing and some prefer dynamic typing. Now some of this is going to be decided by how we think, what shape our “mindcode” is. But some of this is going to be based around how the shape of the language fits the domain model. As an example, PHP is a horrendous language by any technical standard but it is phenomenal at allowing developers to get a web application up and running faster than almost anything else. Likewise, Java is boring and staid compared to the likes of Python and Ruby but offers an enormous pool of developers with superb tooling on a high performance platform with unrivaled support from major vendors which is just what a large company is going to want. These are different domains that have different requirements and different languages offer differing levels of suitability for each set of problems. Having a single language for your entire stack means you are compromising somewhere.
If we need to create sub-processes or workers for potentially blocking tasks, aren’t we just recreating threading but with crappy scheduling?
Probably the biggest bit of truth in Ted’s post is that any computationally expensive activity is going to block the main event loop and render your application useless. The common response to this is to fire off the long running operation in its own process/thread. That sounds a perfectly reasonable way to avoid blocking your main event loop except that you are effectively recreating a threading model that you have to manage. An example of this is knowing which requests can be handled in the main loop and which need to be spun off. If you the developer has to know in advance how to handle requests, you have got it wrong.
We know that threading is bad but does that automatically make event loops good?
The adoption of node indicates that there is a real need for web developers to have frameworks that enable them to write fast full-stack applications in one language. Node’s focus on productivity and ease-of-use to a population of developers who had no other option has made it very successful and the community that has risen up behind it can be rightfully proud of what they have created. But anyone adopting it needs to be aware of the inherent limitations and maybe ask the question; do we improve the frameworks to help the developer or improve the developer to help select a better framework.