4 ms·

I'll be down voted by JavaScript lobby for saying this but I'll still say this. Never use JavaScript on the server side. The amount of bugs that can happen is

I'll be down voted by JavaScript lobby for saying this but I'll still say this. Never use JavaScript on the server side. The amount of bugs that can happen is insane. JavaScript is just a specification with varying implementations across various versions. A proper language like Java, Go, or Rust ensures that your code will have fewer logical bugs of this type. https://ashishb.net/tech/javascript/ https://ashishb.net/tech/javascript/

Rumudiez 1y ago
this issue was caused by a framework that's trying to do too much, relying on "magic" interfaces to supposedly reduce developer burden. the function is very unambiguously written and the language did nothing wrong I also support using whatever language you and your team prefer when you can. that's the glory of backend: no restrictions on what you can run. but sometimes you need to write client software, and those are strictly easier to manage in the platform's native tongue: Swift, Kotlin, JS, and so on
- MangoToupe 1y ago
  > this issue was caused by a framework that's trying to do too much, relying on "magic" interfaces to supposedly reduce developer burden. the function is very unambiguously written and the language did nothing wrong The function is unambiguously written, but the runtime functions differently, and this is not a language problem? This is incoherent; one of these statements is incorrect.
- bigstrat2003 1y ago
  > the function is very unambiguously written and the language did nothing wrong The language absolutely did something wrong, by trying to evaluate a non-boolean type as a boolean. That is a horrible footgun and JS is absolutely at fault for doing so.
nzeid 1y ago
I'd say this was React, not JS. And I do feel that all the back end conventions that have emerged around Node.js, etc. are a clusterfuck. Can JS succeed in the back end? I say yes, but not like this.
llbbdd 1y ago
You'll be down voted appropriately for muddying the difference between the language runtime (on the server side there is one runtime people use and several small competitors) and the framework, which was the issue in this case
- grebc 1y ago
  The fact it’s possible is the problem he’s pointing out.
  - llbbdd 1y ago
    That's nonsense. Code has bugs and you're always writing for a particular target runtime anyway. "Someone might run this on a version of the runtime that implements an incomplete or nonstandard version of the spec" is not a concern
    - grebc 11mo ago
      That my compiler or interpreter may insert code that has a completely different outcome to the intended source code is way down the list in terms of thoughts when stumbling upon a bug.

Rumudiez 1y ago

this issue was caused by a framework that's trying to do too much, relying on "magic" interfaces to supposedly reduce developer burden. the function is very unambiguously written and the language did nothing wrong I also support using whatever language you and your team prefer when you can. that's the glory of backend: no restrictions on what you can run. but sometimes you need to write client software, and those are strictly easier to manage in the platform's native tongue: Swift, Kotlin, JS, and so on

MangoToupe 1y ago
> this issue was caused by a framework that's trying to do too much, relying on "magic" interfaces to supposedly reduce developer burden. the function is very unambiguously written and the language did nothing wrong The function is unambiguously written, but the runtime functions differently, and this is not a language problem? This is incoherent; one of these statements is incorrect.
bigstrat2003 1y ago
> the function is very unambiguously written and the language did nothing wrong The language absolutely did something wrong, by trying to evaluate a non-boolean type as a boolean. That is a horrible footgun and JS is absolutely at fault for doing so.

nzeid 1y ago

I'd say this was React, not JS. And I do feel that all the back end conventions that have emerged around Node.js, etc. are a clusterfuck. Can JS succeed in the back end? I say yes, but not like this.

llbbdd 1y ago

You'll be down voted appropriately for muddying the difference between the language runtime (on the server side there is one runtime people use and several small competitors) and the framework, which was the issue in this case

grebc 1y ago
The fact it’s possible is the problem he’s pointing out.
- llbbdd 1y ago
  That's nonsense. Code has bugs and you're always writing for a particular target runtime anyway. "Someone might run this on a version of the runtime that implements an incomplete or nonstandard version of the spec" is not a concern
  - grebc 11mo ago
    That my compiler or interpreter may insert code that has a completely different outcome to the intended source code is way down the list in terms of thoughts when stumbling upon a bug.