Let’s talk about the rise and fall of technologies. There’s a neat graphical representation of the life-cycle of a technology called an S-Curve:
- New language features: ES6 generators, template strings, SIMD, …
- Package manager/module ecosystem upgrades: parameterized scripts, private repositories, …
- Framework updates: Angular 2, koa, …
Now, these are all quite exciting. New language features let us write more expressive code, and do faster computations. New frameworks help us write more robust applications. npm is amazing, and it is certainly the innovation that made node so successful, so any improvement to it is just icing on the cake.
S-Curves don’t exist in isolation. Something else is on the horizon, and it’s not going to be an incremental improvement. This is why I think it was fantastic that TJ made a high-profile jump to a different S-Curve. Go has its own set of problems, but that’s not the point; he recognized the limits of the tools at hand, and tried something different. It’s far easier to pour more effort into the tools you are already familiar with than it is to try something completely different.
Pick any technology out there and you’ll find someone who can wax poetic about how its better than what you’re using right now. It doesn’t matter if you think they’re right or wrong, listen like you’re wrong, because eventually, you will be wrong. Eventually, you will be the cranky administrator who still believes that JSP is the holy grail of web development. Eventually, you will have to do something insane like write a new VM for the aging technology you’re locked into. Eventually, you will still be concatenating strings like this when everyone else is using the
What is next-generation web development going to look like? I don’t know, but I do have a small wish list:
- Lower-level access to rendering: Lose the HTML/CSS, and go straight to the canvas
- Multithreading support: We’re close to the limit of single-core performance, and even cell phones have multiple cores now
- Lower-level access to memory: This is a compliment to multithreading, and its nice to not have to rely on garbage collection if you know what you’re doing
- Static verification: This should be an option for applications where correctness is important
- Better error handling: This is a real pain in node right now
What do you want to see next?