4 ms·

If you care about performance that much you should be using neither. What you are buying into with these is DX, including features and language portability with

If you care about performance that much you should be using neither. What you are buying into with these is DX, including features and language portability with other parts of your stack. As long as they are the same overall performance class, it doesn't matter.

Ygg2 4y ago
DX? What's that?
- onlywicked 4y ago
  Developer Experience
- EamonnMR 4y ago
  Maybe Developer Experience?
echopom 4y ago
> If you care about performance that much you should be using neither. Unfortunately by the time the coding industry understand this , we'll already have a fifth JS runtime that will promise to solve all the performance issues that exist within the 4 others... Node.JS / Electron are some of my most favorite tech , but if I need performance I'll go with Kotlin / Go / Rust , it's just simpler IMHO.
- lucasyvas 4y ago
  I'm predominantly a React/Node/TS person by trade (just what I'm paid for), but like you I see this as a round peg square hole situation. There are too many front-end JS frameworks and now it seems to be leaking to the backend as well in the form of runtimes. I'm just waiting for one of these groups to say "productivity is priority 1, followed by performance/security etc." Because JS is sort of a nice sedan at its best - truly nice. But if you want a Ferrari, you're at the wrong dealership - that's a "you" problem.
- brrrrrm 4y ago
  Unfortunately?? Y’all don’t know how good you have it. I work in Python and desperately wish there were multiple competing legitimately used Python runtimes. It’s slow as molasses and not getting faster because CPython has an overwhelming monopoly. Node.js is getting faster, for free, because things like Deno and Bun exist.
jpgvm 4y ago
If you are buying into JS/TS the very last thing you are getting is DX. I have never worked with such a low quality ecosystem ever before and I hope I won't have to endure it for too much longer. If you want DX you are better off with JVM, Rust or something similarly well designed. Hell, Go has better DX than JS/TS and that is a pretty low bar. Real build systems, real module systems (instead of like 3 competing incompatible ones) actual compilers instead of transpilation BS. Actually good linters and static analysis. Actually good IDEs. The list of things all of these platforms do better than the whole JS/TS nightmare just goes on and on. What you are getting when you buy JS is isomorphic code with browsers. That is all. DX? Forget it.
- lucasyvas 4y ago
  You are free to think that - I personally don't think you give it enough credit, but if your general argument is that there's a best tool for the job and this isn't it, I would agree within the context of this topic: performance. Deno is objectively a pretty nice package and does a better job than its JS predecessors of delivering on DX. But my fear is that JS is inherently fragmented and this will never be truly resolved. I personally wouldn't dissuade those from using it - you can still achieve great results. But it's not a poster child for how we should do things. That undertone bothers me a lot more than the runtimes themselves.
- TobyTheDog123 4y ago
  You're getting downvoted, but I absolutely agree that the ecosystem is a problem. It's not the JS/TS language/syntax that is the problem per-se, but all the tooling that needs to exist around it for a decent DX. NPM, Yarn, Babel, Webpack, TSC, ESLint, Prettier, even VSCode itself all contribute to an ecosystem that is a nightmare if you are trying to do anything outside of a handful of common scenarios Tooling like Vite, Expo, CRA all try to reduce the headaches here, but at the end of the day just end up moving the headaches up an abstraction layer, and reduce the amount of supported scenarios. That being said, there's not much support for using those languages outside of the ecosystem. Typescript is an incredible language, and if it was possible to transpile it to a language other than Javascript, that'd be ideal for me.

Ygg2 4y ago

DX? What's that?

onlywicked 4y ago
Developer Experience
EamonnMR 4y ago
Maybe Developer Experience?

echopom 4y ago

> If you care about performance that much you should be using neither. Unfortunately by the time the coding industry understand this , we'll already have a fifth JS runtime that will promise to solve all the performance issues that exist within the 4 others... Node.JS / Electron are some of my most favorite tech , but if I need performance I'll go with Kotlin / Go / Rust , it's just simpler IMHO.

lucasyvas 4y ago
I'm predominantly a React/Node/TS person by trade (just what I'm paid for), but like you I see this as a round peg square hole situation. There are too many front-end JS frameworks and now it seems to be leaking to the backend as well in the form of runtimes. I'm just waiting for one of these groups to say "productivity is priority 1, followed by performance/security etc." Because JS is sort of a nice sedan at its best - truly nice. But if you want a Ferrari, you're at the wrong dealership - that's a "you" problem.
brrrrrm 4y ago
Unfortunately?? Y’all don’t know how good you have it. I work in Python and desperately wish there were multiple competing legitimately used Python runtimes. It’s slow as molasses and not getting faster because CPython has an overwhelming monopoly. Node.js is getting faster, for free, because things like Deno and Bun exist.

jpgvm 4y ago

If you are buying into JS/TS the very last thing you are getting is DX. I have never worked with such a low quality ecosystem ever before and I hope I won't have to endure it for too much longer. If you want DX you are better off with JVM, Rust or something similarly well designed. Hell, Go has better DX than JS/TS and that is a pretty low bar. Real build systems, real module systems (instead of like 3 competing incompatible ones) actual compilers instead of transpilation BS. Actually good linters and static analysis. Actually good IDEs. The list of things all of these platforms do better than the whole JS/TS nightmare just goes on and on. What you are getting when you buy JS is isomorphic code with browsers. That is all. DX? Forget it.

lucasyvas 4y ago
You are free to think that - I personally don't think you give it enough credit, but if your general argument is that there's a best tool for the job and this isn't it, I would agree within the context of this topic: performance. Deno is objectively a pretty nice package and does a better job than its JS predecessors of delivering on DX. But my fear is that JS is inherently fragmented and this will never be truly resolved. I personally wouldn't dissuade those from using it - you can still achieve great results. But it's not a poster child for how we should do things. That undertone bothers me a lot more than the runtimes themselves.
TobyTheDog123 4y ago
You're getting downvoted, but I absolutely agree that the ecosystem is a problem. It's not the JS/TS language/syntax that is the problem per-se, but all the tooling that needs to exist around it for a decent DX. NPM, Yarn, Babel, Webpack, TSC, ESLint, Prettier, even VSCode itself all contribute to an ecosystem that is a nightmare if you are trying to do anything outside of a handful of common scenarios Tooling like Vite, Expo, CRA all try to reduce the headaches here, but at the end of the day just end up moving the headaches up an abstraction layer, and reduce the amount of supported scenarios. That being said, there's not much support for using those languages outside of the ecosystem. Typescript is an incredible language, and if it was possible to transpile it to a language other than Javascript, that'd be ideal for me.