3 ms·

I'm being a little coy because I do have a very detailed proposal. In want the JS toolchain to stay written in JS but I want to unify the design and architectu

I'm being a little coy because I do have a very detailed proposal. In want the JS toolchain to stay written in JS but I want to unify the design and architecture of all those tools you mentioned so that they can all use a common syntax tree format and so can share data, e.g. between the linter and the formatter or the bundler and the type checker.

notnullorvoid 8mo ago
Yeah it's a shame that few people realize running 3 (or more) different programs that have separate parsing and AST is the bigger problem.
- conartist6 8mo ago
  Not just because of perf (though the perf aspect is annoying) but because of how often the three will get out of sync and produce bizarre results
nicoburns 8mo ago
Hasn't that already been tried (10+ years ago) with projects like https://github.com/jquery/esprima https://github.com/jquery/esprima ? Which have since seen usage dramatically reduced for performance reasons.
- conartist6 8mo ago
  Yeah, you are correct. But that means I have the benefit of ten years development in the web platform, as well as having hindsight on the earlier effort. I would say the reason the perf costs feel bad there is that the abstraction was unsuccessful. Throughtput isn't all that big a deal for a parser at all if you only need to parse the parts of the code that have actually changed
9dev 8mo ago
You can rip fast builds from my cold, dead hands. I’m not looking back to JS-only tooling, and I was there since the gulp days.
- conartist6 8mo ago
  All I can say for sure is that the reason the old tools were slow was not that the JS runtime is impossible to build fast tools with. And anyway, these new tools tend to have a "perf cliff" where you get all the speed of the new tool as long as you stay away from the JS integration API sued to support the "long tail" of uses cases. Once you fall off the cliff though, you're back to the old slow-JS cost regime...
  - 9dev 8mo ago
    > […] the reason the old tools were slow was not that the JS runtime is impossible to build fast tools with. I don't have them at hand right now but there are various detailed write-ups from the maintainers of Vite, oxc, and more, that are addressing this specific argument to point out that indeed the JavaScript runtime was a hard limitation on the throughput they could achieve, making Rust a necessity to improve build speeds.
    - conartist6 8mo ago
      Why do you need high throughput though? Isn't that a metric of how fast a batch processing system is? Why are we still treating batch processing as the controlling paradigm for tools that work on code. If we fully embraced incremental recomputation and shifted the focus to how to avoid re-doing the same work over and over, batch processing speed would become largely irrelevant as a metric

notnullorvoid 8mo ago

Yeah it's a shame that few people realize running 3 (or more) different programs that have separate parsing and AST is the bigger problem.

conartist6 8mo ago
Not just because of perf (though the perf aspect is annoying) but because of how often the three will get out of sync and produce bizarre results

nicoburns 8mo ago

Hasn't that already been tried (10+ years ago) with projects like https://github.com/jquery/esprima https://github.com/jquery/esprima ? Which have since seen usage dramatically reduced for performance reasons.

conartist6 8mo ago
Yeah, you are correct. But that means I have the benefit of ten years development in the web platform, as well as having hindsight on the earlier effort. I would say the reason the perf costs feel bad there is that the abstraction was unsuccessful. Throughtput isn't all that big a deal for a parser at all if you only need to parse the parts of the code that have actually changed

9dev 8mo ago

You can rip fast builds from my cold, dead hands. I’m not looking back to JS-only tooling, and I was there since the gulp days.

conartist6 8mo ago
All I can say for sure is that the reason the old tools were slow was not that the JS runtime is impossible to build fast tools with. And anyway, these new tools tend to have a "perf cliff" where you get all the speed of the new tool as long as you stay away from the JS integration API sued to support the "long tail" of uses cases. Once you fall off the cliff though, you're back to the old slow-JS cost regime...
- 9dev 8mo ago
  > […] the reason the old tools were slow was not that the JS runtime is impossible to build fast tools with. I don't have them at hand right now but there are various detailed write-ups from the maintainers of Vite, oxc, and more, that are addressing this specific argument to point out that indeed the JavaScript runtime was a hard limitation on the throughput they could achieve, making Rust a necessity to improve build speeds.
  - conartist6 8mo ago
    Why do you need high throughput though? Isn't that a metric of how fast a batch processing system is? Why are we still treating batch processing as the controlling paradigm for tools that work on code. If we fully embraced incremental recomputation and shifted the focus to how to avoid re-doing the same work over and over, batch processing speed would become largely irrelevant as a metric