5 ms·

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 ty

by mises 8y ago

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?

atoko 8y ago
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.
curtis 8y ago
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.
- efdee 8y ago
  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.
- abstractcontrol 8y ago
  > JITing JavaScript turned out to be a lot easier than JITing Ruby and Python Why was this the case?
  - curtis 8y ago
    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.
  - chrisseaton 8y ago
    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.
efdee 8y ago
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.
- whatshisface 8y ago
  >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.
  - s_y_n_t_a_x 8y ago
    >and you can't point to specific versions Yes you can. >no such thing as a verified-safe dependencies list There are audits.
  - efdee 8y ago
    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.
- mises 8y ago
  NPM insecurity: lots of malicious packages discovered. Also, left-pad. Slowness: Yes, it is. Look at all the benchmarks comparing it to, say, go.
simias 8y ago
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!

by mises 8y ago

atoko 8y ago

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.

curtis 8y ago

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.

efdee 8y ago
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.
abstractcontrol 8y ago
> JITing JavaScript turned out to be a lot easier than JITing Ruby and Python Why was this the case?
- curtis 8y ago
  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.
- chrisseaton 8y ago
  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.

efdee 8y ago

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.

whatshisface 8y ago
>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.
- s_y_n_t_a_x 8y ago
  >and you can't point to specific versions Yes you can. >no such thing as a verified-safe dependencies list There are audits.
- efdee 8y ago
  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.
mises 8y ago
NPM insecurity: lots of malicious packages discovered. Also, left-pad. Slowness: Yes, it is. Look at all the benchmarks comparing it to, say, go.

simias 8y ago

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!