It's funny to me that people should look at this situation and say "this is OK".
The upshot of all these projects to make JS tools faster is a fractured ecosystem. Who if given the choice would honestly want to try to maintain Javascript tools written in a mixture of Rust and Go? Already we've seemingly committed to having a big schism in the middle. And the new tools don't replace the old ones, so to own your tools you'll need to make Rust, Go, and JS all work together using a mix of clean modern technology and shims into horribly legacy technology. We have to maintain everything, old and new, because it's all still critical, engineers have to learn everything, old and new, because it's all still critical.
All I really see is an explosion of complexity.
So, what's your counterproposal?
Each of these tools provides real value.
* Bundlers drastically improve runtime performance, but it's tricky to figure out what to bundle where and how.
* Linting tools and type-safety checkers detect bugs before they happen, but they can be arbitrarily complex, and benefit from type annotations. (TypeScript won the type-annotation war in the marketplace against other competing type annotations, including Meta's Flow and Google's Closure Compiler.)
* Code formatters automatically ensure consistent formatting.
* Package installers are really important and a hugely complex problem in a performance-sensitive and security-sensitive area. (Managing dependency conflicts/diamonds, caching, platform-specific builds…)
As long as developers benefit from using bundlers, linters, type checkers, code formatters, and package installers, and as long as it's possible to make these tools faster and/or better, someone's going to try.
And here you are, incredulous that anyone thinks this is OK…? Because we should just … not use these tools? Not make them faster? Not improve their DX? Standardize on one and then staunchly refuse to improve it…?
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.
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.
> We have to maintain everything, old and new, because it's all still critical, engineers have to learn everything, old and new, because it's all still critical.
I completely agree but maintenance is a maintainer problem, not the consumer or user of the package, at least according to the average user of open source nowadays. One of two things are come out of this: either the wheels start falling off once the community can no longer maintain this fractured tooling as you point out, or companies are going to pick up the slack and start stewarding it (likely looking for opportunities to capture tooling and profit along the way).
Neither outcome looks particularly appealing.
Yes, this just sounds like the run-of-the-mill specialization issue that is affecting every industry (and has been affecting every industry before AI). Web devs learn Javascript/Typescript/frameworks, "middleware" developers learn Rust/Go/C++/etc. to build the web development frameworks, lower-level devs build that, etc. There shouldn’t be a strict need for someone who wants to make websites or web technology to learn Rust or Go unless they want to break into web framework development or WASM stuff. But again, this is just over-specialization that has been happening since forever (or at least since the Industrial revolution).
> All I really see is an explosion of complexity.
I thought this was the point of all development in the JavaScript/web ecosystem?
In retrospect, the tolerance for excess complexity in the JS/npm/yarn/web framework ecosystem was an important precursor to the wanton overconsumption of today's LLM ecosystem.
It's definitely an explosion of complexity but also something that AI can help manage. So :shrug: ...
Based on current trends, I don't think people care about knowing how all the parts work (even before these powerful LLMs came along) as long as the job gets done and things get shipped and it mostly works.