| ESBuild’s author and docs[1] are quite clear about its future scope: > [… a list of features that are already done…] > After that point, I will consider esbuild to be relatively complete. I'm planning for esbuild to reach a mostly stable state and then stop accumulating more features. This will involve saying "no" to requests for adding major features to esbuild itself. I don't think esbuild should become an all-in-one solution for all frontend needs. In particular, I want to avoid the pain and problems of the "webpack config" model where the underlying tool is too flexible and usability suffers. That said, now quoting you… > But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about. In this respect, ESBuild’s firm stance has a major strength, and a major weakness: - Strength: the Unix philosophy is easy to achieve, with esbuild-plugin-pipe[2]. There’s just one, simple plugin API, everything follows that same format - Weakness: since ESBuild doesn’t expose its AST, plugins are often slow which can undermine the benefits of the tool 1: https://esbuild.github.io/faq/#upcoming-roadmap 2: https://github.com/nativew/esbuild-plugin-pipe |
I think by the time we even care about the performance of a plugin being "golang" fast, we will have rome built in rust.
Rome will be the full kit and caboodle at native speeds (bundler, tree shaking compiler, linter, type checker, etc...), whereas esbuild will be the rome-lite for when you just want to bundle some code and have it done.