3 ms·
Neat, would love to understand how this would affect Node.js performance. Tooling like esbuild[0] exists for the very reason that compiled languages are signifi
by gmaster1440 5y ago
Neat, would love to understand how this would affect Node.js performance. Tooling like esbuild[0] exists for the very reason that compiled languages are significantly faster, so I wonder how viable of an alternative (in terms of performance) is it to build an esbuild in `node --sparkplug`.
Or take the existing Webpack CLI which is written in Node, what kind of improvements can we expect there, if any?
[0] https://esbuild.github.io/faq/#why-is-esbuild-fast https://esbuild.github.io/faq/#why-is-esbuild-fast
- klodolph 5y agoIt's not really a good blanket statement that compiled languages are significantly faster. There are a lot of problems getting tools written in JavaScript to run fast, and the fact that JavaScript is "not compiled" is a bit farther down the list. There are other pressing issues, like the fact that code written in Go, like esbuild, is free to run multiple threads and freely share data structures between threads. The distinction between compiled and interpreted languages is also a bit fuzzy to begin with.
- gmaster1440 5y agoYes, as the link I shared mentions, there's concurrency via actual threads, and proper memory sharing—by no means implying compilation is all there is, but it does seem at the very least to be a contributing factor, and understanding the change to bottom-line performance would still be welcome.
- wonnage 5y agoThis would mostly benefit performance the first time some code is run, before v8 has a chance to gather runtime data and optimize it. Since all JS execution goes through this phase, this should make everything a little faster, but it will probably benefit short-lived processes (e.g, a website script) more than something like a bundler.