[martinlev]

Definitely agree with this. I have been switching from developing in ruby into Node 2 years ago as I thought this was "the new thing" for web apps. Now I just want to move away from Node. Large scale Node applications looks like 20 years ago, copy and paste all over the place, cheap libraries, no developer happiness, you have to reinvent the wheels, etc.

[selestify]

Why did Node become so popular if this is the case?

[RobertKerans]

It's very easy to build small things with (small API servers, proxies, tools for example), development of those things is quick, the development feedback cycle is extremely rapid, JS is a bit of a lingua franca (for better or for worse), it is extremely easy to get set up (again, for simple things). In turn this created a huge community, which in turn triggered a virtuous (?) circle, and gave easily-installable libraries for almost anything you can think of. It also should be said that it is good at what it does. The reactor pattern works well in specific use cases and is easy to understand -- which I guess is the main cause of it being used as a general purpose hammer. Yes, it has glaring issues, but the "silly JS programmers with their toy language wanted to write backend servers" meme is a bit annoying.

[smacktoward]

Because there are an awful lot of JavaScript programmers out there, and Node let them apply the skills they already had on the server side for the first time [1].

[1] Technically, Node didn't invent server-side JavaScript; Netscape's application servers supported a version of the same idea in the '90s, back when Netscape was still a thing. But there was a long period where JS was effectively ghettoized as a language for browser scripting only, and Node is what broke it back out of that.

[lbotos]

"WebScale"

and

a generation of programmers that grew up on Javascript thinking it would be cool to write JS on the server too.

[martinlev]

I believe for small projects it can be interesting, you can have an instance up using 50 MB ram. Also the language is widely used. JS is used in the frontend so they believe it's great for the backend also because you "reuse" the code. In my experience close no code is reused from frontend to the backend and vice versa.

[laumars]

Laziness I think. People wanted to use the same language for the backend as the frontend rather than picking their tools based on what does the job the best.

[chrisweekly]

Agreed that picking the right tool for the job is essential. But you might want to revisit your assumptions about the benefits of baking in such a hard separation of "frontend" and "backend". See Gatsby for example.

[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).

[winrid]

What you're describing is just bad code. That happens in any runetime. This is not specific to Node.

[martinlev]

I agree, but from my observation bad code is more significantly more widespread in Node. The tooling is just incomplete by default, you have to setup yourself. Further the projects structure is completely different on every project (and typically not nicely done).