4 ms·

Sebastian keeps mentioning how all these different kind of tools could re-use the same infrastructure for the things they all do, but... It's still not quite cl

by Vinnl 6y ago

Sebastian keeps mentioning how all these different kind of tools could re-use the same infrastructure for the things they all do, but... It's still not quite clear to me what benefit that brings to me as a non-contributor? I can see how it could be beneficial if the entire ecosystem would rally around the same tools and then be able to move faster, but given that that has not yet happened... Why would I use this to lint my code? The nicer error messages?

acemarke 6y ago
Two immediate potential benefits: - Only one tool to configure, instead of many - Many tools revolve around parsing your code and generating an AST, then manipulating / processing that AST (Prettier, ESLint, Babel, TS, Webpack, ....). That's a lot of extra processing that has to be done. In theory, doing all that processing _once_, and reusing the AST, would potentially run a lot faster.
- k__ 6y ago
  Also, fixes in the shared libs would be directly available to the tools build on top.
Jarred 6y ago
I don’t work on Rome and haven’t looked at their code much, but if I were to guess: performance and better error messages If you can do the same work in fewer passes, it will often be faster So instead of every file change, webpack runs its own parser, then Babel runs its own parser, then ESLint, etc — Rome probably just runs the parser once and sends the AST to other plugins And then if you invest in making the parsing stuff really good, that makes the linter better, the Babel-equivalent better, etc
_greim_ 6y ago
I'm not an expert in the internals of these things, but presumably Prettier, Webpack, TypeScript, Babel, Istanbul, and ESLint each build their own separate, private ASTs from scratch. Maybe a project like this could pipeline a sequence of ASTs one to the next, and skip some of that overhead?
Vinnl 6y ago
Thanks for the answers everyone. Just wanted to point out this comment by Sebastian that also perfectly explains it: https://news.ycombinator.com/item?id=24096744 https://news.ycombinator.com/item?id=24096744 (And it would be good to put something to that extent prominently on the website, if it isn't yet.)

by Vinnl 6y ago

acemarke 6y ago

Two immediate potential benefits: - Only one tool to configure, instead of many - Many tools revolve around parsing your code and generating an AST, then manipulating / processing that AST (Prettier, ESLint, Babel, TS, Webpack, ....). That's a lot of extra processing that has to be done. In theory, doing all that processing _once_, and reusing the AST, would potentially run a lot faster.

k__ 6y ago
Also, fixes in the shared libs would be directly available to the tools build on top.

Jarred 6y ago

I don’t work on Rome and haven’t looked at their code much, but if I were to guess: performance and better error messages If you can do the same work in fewer passes, it will often be faster So instead of every file change, webpack runs its own parser, then Babel runs its own parser, then ESLint, etc — Rome probably just runs the parser once and sends the AST to other plugins And then if you invest in making the parsing stuff really good, that makes the linter better, the Babel-equivalent better, etc

_greim_ 6y ago

I'm not an expert in the internals of these things, but presumably Prettier, Webpack, TypeScript, Babel, Istanbul, and ESLint each build their own separate, private ASTs from scratch. Maybe a project like this could pipeline a sequence of ASTs one to the next, and skip some of that overhead?

Vinnl 6y ago

Thanks for the answers everyone. Just wanted to point out this comment by Sebastian that also perfectly explains it: https://news.ycombinator.com/item?id=24096744 https://news.ycombinator.com/item?id=24096744 (And it would be good to put something to that extent prominently on the website, if it isn't yet.)