Hacker News Reader

Comment by mises | Hacker News Reader

I keep wondering what the deal is with JS on the backend? Why does everyone love it so much? Let's not forget the 10-day design, dynamic typing (and weakly typed, compared with python), slowness, null vs. undefined, etc. JS is a scripting language; they're supposed to be for controlling the behavior of applications (i.e. browsers), not writing applications in and of themselves. Not to mention the dependency hell, NPM insecurity, etc. I see the purpose for limited use in websites, but definitely not the PWA or backend stuff.

Can someone who uses it happily on the backend talk about why they like it and why it's good?

View on HN

It sounds like you read a lot of articles about why JS is bad, but don't have a lot of experience with it.

* 10-day design? Nobody is using Javascript 1.0 anymore.

* Typing is available to various extents thanks to Flow and/or Typescript.

* Slowness... I don't know what you're referring to. Javascript isn't slow.

* null vs undefined. What about them? They are two different things with different meanings.

* Dependency hell. I assume you refer to the many small modules on NPM with dependencies on other modules. Not sure what the problem here is per se. Avoid them if you don't like dependencies.

* NPM insecurity - what?

I like JS on the backend because it's a nice, flexible language to work with, with a healthy and cheap (cost-wise) ecosystem. I get a lot of stuff done very quickly, and I can run my stuff pretty much everywhere.

>NPM insecurity

NPM packages can contain malicious code. There's no NPM review process, and you can't point to specific versions to lock in your own reviews (package administrators can change whatever files they'd like). There's no such thing as a verified-safe dependencies list because the file you reviewed last month might not be downloaded today.

>and you can't point to specific versions

Yes you can.

>no such thing as a verified-safe dependencies list

There are audits.

You definitely can point to specific versions.

That being said, most package managers can contain malicious code and very few of them actually review their packages.

Besides, any company using NPM seriously probably has their own proxy in front of it, so there's no case of "the file might not be downloadable anymore" if that was already a problem with NPM itself.

NPM insecurity: lots of malicious packages discovered. Also, left-pad.

Slowness: Yes, it is. Look at all the benchmarks comparing it to, say, go.

People were using Ruby and Python (and before that Perl and PHP) on the backend in many cases. I think it's likely that those are the kinds of projects which are using JS on the backend now, while the Java and C# people are continuing to do their backends in Java and C#.

One of JavaScript's big advantages over Ruby and Python was performance, both because the standard runtime is faster (JITing JavaScript turned out to be a lot easier than JITing Ruby and Python) and because its fundamentally asynchronous nature was a better match for webservers.

And although NPM sucks in a number of ways, I've always found it easier to use than Python's dependency management.

Anecdotal, but as developer who has done mainly C# for the last decade-and-a-half, I've switched to Node.js for -a lot- of my non-enterprisey work.

> JITing JavaScript turned out to be a lot easier than JITing Ruby and Python

Why was this the case?

I suspect that a lot of the impediment to JITing Ruby and Python effectively was due to large and important libraries (standard and third-party) being written in C using interfaces that were not JIT-friendly. JavaScript in the browser also depends on C/C++ interfaces to important functionality, but the entire stack for each engine was controlled by a single organization, and was always released as a unit (the web browser). I think this largely eliminated library inertia (or whatever you want to call it) as a problem when replacing a JavaScript engine.

The other advantage JavaScript had was that there were large, well-funded organizations (notably Google and Mozilla) competing on performance. Python and Ruby were always community projects and they had a strong emphasis on maintaining backwards compatibility with a large and diverse ecosystem, and there wasn't a lot of demand for faster implementations.

JavaScript is a relatively small and simple language with relatively constrained semantics that allow it to be implemented relatively simply.

Ruby and Python are the opposite of that. Ruby and Python are I'd say literally a thousand times more complicated to compile than JavaScript.

I don't like JS very much so I wouldn't want to use it anywhere it could be avoided, that being said it's pretty clear why some people think otherwise, regardless of the qualities and defects of the language.

Using JS in the backend means that you don't have to learn a new language if you're already familiar with it in the browser. Given that webdev is extremely popular with new developers these days, it's not surprising that they might want to reuse the technology when they have to write backend code instead of learning a whole new language. Similarly companies can reuse their pools of webdevs to write non-web applications instead of hiring new personnel or having to retrain the existing coders.

It also means that you can reuse code from the browser in the backend.

Sure if you find JS a clunky and subpar language it might be disappointing to see it spread the way it does but hey, at least it's not PHP!

How is it slow? [Citation needed]

The async model is easy to use so you get good performance before even optimize it. It comes out of the box with good json serialization/parsing, so that’s one less dependency. Not really sure where you’re coming from.

Reply on news.ycombinator.com