[laumars]

I know this might be an unpopular opinion but I personally think a hard separation is required because the frontend and backend development solve different problems. Sure they're related but it's like the distinction between SQL and backend web service code. Sure there are tools like ORMs however they never compare well to well written SQL from engineers who understand databases. Likewise understanding the distinction of requirements on the frontend vs backend is just as important.

It's funny because many frontend web developers are keen to point out the distinction between Javascript, HTML and CSS and the importance of why HTML and CSS are distinctly different mark ups. Yet will then discuss frontend and backend code as if it's the same beast.

Maybe this opinion is an age related thing though. I've been publishing websites since the 1990s ('93 I think my first site went live). So I've always seen frontend and backend as separate entities - as they were for most of the web's evolution.

[chrisweekly]

I think you misunderstood me, or we're talking past each other a bit here; I've been at it professionally since about 1998, so any difference in perspective is unlikely to be age-related -- at least in the sense of depth of experience with the tradition.

"The right tool for the job", yes, of course -- but why would you insist that a particular set of traditional architectural constraints must needs be permanently enforced at the level of language and runtime? Being locked into a "3-tier architecture, server-side" perspective is a common trap for many senior developers. As is dismissing the real (and amazing) progress and expansion of possibilities inherent in the accelerating changes in front-end technology. Of course there are ignorant juniors. Of course the signal:noise ratio in the world of modern web and mobile dev is suboptimal; there's so much churn and noise and froth. But also progress, evolution, improvement. To write it all off, clinging to comforting notions that what we mastered a decade or more ago is the best -- let alone only -- way to do it?

"The difficulty lies not in grasping the new ideas, but letting go of the old."

[laumars]

I don't disagree that Javascript has evolved into a first class language now but it hasn't always been. Your rhetoric - while lacking a lot of technical content - are valid for the current state of play but not the question being asked. Back in the early days of Node it was complete garbage but people stuck with it because they wanted a single language to rule them all and browsers wouldn't support anything beyond JS (despite how crappy JS was back then). So the reasons node gained any momentum in the early days was simply because:

1. it was too difficult to get any other language first class support for browser scripting (the reasons for that are obvious)

2. frontend developers wanted to reuse the same language for front and back (often because they simply didn't want to learn another language).

Let's also circle back to my point about the right tools for the job. Javascript has always made some sense for frontend development - it might not be the best designed language from an academic perspective but it suited browser scripting well enough to get the job done. Plus in the early days we didn't need anything particularly pretty anyway. But JS definitely did not suite backend development when Node was first being deployed. In fact I'm pretty sure Node was just a hobby project where some guys thought "Chrome's JS VM can run headless - lets see where this takes us." (this part may be incorrect but I have a vague recollection of that being the case). However without tools like Docker nor any decent way of running parallel execution stacks (nor a first class web server supporting Node ala mod_perl / mod_php / phpfpm / et al) it meant Javascript was simply not a good language for backend development for a relatively long time because the tooling wasn't there and the language lacked the primitives to compensate (like how Python, Perl and Ruby could all self host their own threaded web server).

These days Javascript still doesn't support threading but it does have other primitives that do a reasonable job of compensating. Plus with tools like Docker, you can always scale sideways when your application failed to scale upwards. The tooling around JS has improves, the language itself has improved and the way we host web sites has also evolved (eg cloud environments running containers vs VMs or even bare metal servers running web servers written in C++ which spawn language VMs as separate processes). The whole landscape of backend development had to change as well as Javascript itself before it really because a first class backend language.

So to summarise, yes you're right to and extent. But you answer a subtly different question: "why is node still popular?" rather than the question I was answering: "why did it become popular?"

Ironically it was the popularity that gave node the momentum to improve; rather than node initially being good that gave it popularity (though obviously node improving would have had a snowball effect on node's popularity as well).

[chrisweekly]

Right on -- we're mostly in agreement.

Definitely a fair point about addressing the original question. IME, node _became_ popular in part because it allowed web developers to start solving problems themselves, directly, using a language they already knew [albeit a kind of terrible/problematic language at the time], to do things like CLI scripting for automation of tedious FE dev workflow tasks (a la Grunt and bower), or standing up dirt-simple web servers. At that point the floodgates had opened. With the concomitant (and ongoing) shift in architectures toward executing more and more of the application on the client side (with hugely popular services like gmail and google maps demonstrating the power of "Ajax"), the rest became almost inevitable. With Node, like Javascript in general, the quality followed the popularity, as world-class engineers set to fixing and improving what was available to work with, to shape it into something better-suited to the task. The process might even be ~akin to selective adaptation in biological evolution.

[laumars]

I like how you've phrased that. It's a lot better (and less opinionated) than what I put :)