When node.js was released in 2009, I didn’t understand why it got so much hype. I understood what it did, but since it didn’t let me do anything I couldn’t do before, it just wasn’t very interesting.
But since then I’ve put a few thoughts together:
1) Javascript *is* the ubiquitous client-side ‘platform’ in today’s web world. You might not have chosen things to be that way. But we could be a lot worse off. So, in today’s world, everyone has to know javascript.
2) Javascript is today what BASIC was in the ’80s. You get immediate feedback without compile/deploy cycles. You can futz around without any infrastructure. You don’t type ‘RUN’ any more, you just hit refresh in your browser. I learned BASIC then Z80 assembler as my first languages. Today, you’d learn javascript.
3) Not everyone knows C#/Java/C++/ruby or similar “server side” languages. I do, but only because of my career track to date. Everyone in the world has a different background and experiences. If you already know javascript, I suspect it’s not really that attractive to have to learn a second language just to do server-side programming?
4) Even if you did choose to use a ‘real’ server-side language, you end up with two sets of every library – a javascript version for the client, and a ruby/java/etc version for server. Two sets of collections, two different network libraries, etc, etc. This is boring. Why not pick one and use it on server and client? Oops, except your hand is forced because History has fixed the client-side language.
5) Event-based programming is an old, old idea. Desktop GUIs have always all been event-based. Threads were only added to windows in, IIRC, Win95. But node.js may well have been many web programmers’ first exposure to the idea. There are upsides and downsides to the event-based approach, compared to threads. But if your language runtime is single-threaded, you never even had a choice. If you’re a good salesman, you sell the upsides regardless. Ruby chose multi-process concurrency, whereas node.js chose event-based concurrency (augmented by processes) .. as did windows ..
6) Lots of well-funded people have a vested interest in making javascript run better. Speedups for client-side javascript translate into speedups for serverside javascript. Moore’s law delivered us into an era where even dumb interpreters were “fast enough”. Ruby and Javascript are both “fast enough” for most of the hobby webapps I’ll ever write.
7) The old split of “clever server code” and “dumb client code” is fading anyway. Client code is doing more. Webapps on mobile devices are able to better handle flaky networks. Client side code quickly gets to the stage of needing all the design patterns which ‘real apps’ have used – mvc, events systems, stuff that backbone provides.
So, javascript on the server makes some kind of sense – with or without hype. It’s not a slamdunk though. I still like my advanced static type systems thankyouverymuch. Quite possibly, javascript is more like the assembly language of the internet; whether at a superficial level like coffeescript or a deeper level like links.
(Thanks to Cameron for interesting conversations on this topic!)
1 reply on “Node.js and a changing world”
A quick though in passing re your point 4 and final paragraph: seems you could write a JVM in JS these days, to get your choice of client-side language back?
But the reason I’m responding is your point 2.
See, I *love* anything that empowers people by giving them a way into coding.
To my mind, there was an alarmingly long period between the era of the home computer with BASIC or whatever (my own way in) and that today of the browser with Javascript. During this dark age you had to jump through quite a few hoops to get started on developing software. For a while it seems the entrance points were CGI scripts under your place of education’s web server, or going via Excel to Visual Basic. A real baptism of fire! There have been attempts to address the need for something simple and useful (I was a Hackety Hack fan myself – see http://anthonybailey.net/tumblelog/2007/04/28/hacking-it-for-the-kids) but these never get traction.
So yay for the modern browser that can pose as a Javascript application IDE.
We are where we are with the language in question, which could be much worse. But there are two directions in which I wish we could nudge the default ecosystem to unlock some of the remaining gates a beginner developer still has to pass through as they begin their development journey.
Javascript is a rather unopinionated language, and the resulting lack of initial constraints reduces its effectiveness as a framework for first-time learning. TIMTOWTDI can be great for later explorations, but when you start then it’s easier to learn Python than Perl. The DOM helps a bit, so writing code on top of a single page (e.g. a GreaseMonkey script) can be quickly rewarding. But where do you go from there? Can we supply better signposts?
And it bugs me that at the point you want to use code assets outside the first page that you load then you have to jump all the way to running a local webserver, because the default security model in all modern browsers will trust localhost, but not your local file://-system. Seems this is really going to get in the way of a neophyte. (I may be projecting here – but hell, it put me off some of my own experiments with Backbone.js – I wanted to be able to write and distribute a simple offline web app, but I can’t ask my user to run a webserver!) I don’t see why browsers can’t trust e.g. subdirectories of the filesystem.