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.
replyNot 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
replyHasn't that already been tried (10+ years ago) with projects like https://github.com/jquery/esprima ? Which have since seen usage dramatically reduced for performance reasons.
replyYeah, 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.
replyI 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
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.
replyAll 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.
replyAnd 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...