I originally posted this proposal in the GitHub Discussions for Microsoft's TypeScript Native (typescript-go) project. I personally feel it might receive more dicussions on Hacker News, so I've reposted the full text here. Comments and feedback are welcome.
[ORIGINAL]
Title: Proposal: Extract the Parser of TypeScript Native into a standalone Go Module to fill a gap in the Go ecosystem and benefit this project
I suggest extracting the Parser component from typescript-go and publishing it as an independent Go library.
Currently, the Go ecosystem severely lacks a complete, standard-compliant JavaScript/TypeScript/JSX parser. typescript-go actually possesses what is likely the most comprehensive Parser in the current Go ecosystem. If this could be decoupled, it would become a foundational cornerstone for frontend tooling within the Go language.
Rationale:
1. It fills a structural gap in the Go ecosystem.
In the JS ecosystem, TypeScript doesn't need a standalone Parser because tools like Babel are already very mature. However, in the Go ecosystem, there is currently no comparable infrastructure.
As frontend toolchains migrate toward high-performance native languages, Go is highly attractive to the vast community of JS/TS developers due to its ease of learning and concurrency advantages. By filling this void, Microsoft would allow external tools to reuse this core capability without needing to reinvent the wheel.
2. An independent Parser will attract integration from numerous external tools.
This means massive amounts of real-world codebases will be used to test this Parser. Edge cases discovered and fixed by the community can be fed directly back into typescript-go. This is far more efficient than relying solely on internal test cases and will significantly improve the robustness of the Parser.
3. From an engineering perspective, decoupling the Parser helps define project boundaries and improves maintainability.
Implementation-wise, this does not require rewriting core logic; it only involves adjusting the project structure to support Go Module referencing, making the engineering effort manageable.
4. TypeScript has, in a sense, become a de facto standard.
If Microsoft provides an official Go version of the Parser, it ensures that Go-based frontend toolchains maintain high consistency with the native TS compiler in parsing behavior. This prevents the community from creating various incompatible "dialect" parsers due to a lack of standards, thereby avoiding ecosystem fragmentation.
My worry isn't so much about the tech itself, but rather the governance issues—and it's not about "Make Webpack Great Again."
1. I genuinely like Vite's design and UX (I actually started my frontend career with Vite + Vue). My only concern is the ecosystem getting vertically integrated under a single commercial roadmap (Oxc => Rolldown => Vite). It feels like shifting from a community-driven ecosystem to a VC-driven product suite. I am worried about vendor lock-in, especially with commercial suites like "Vite+" existing.
2. Regarding Rspack/Rsbuild, I do treat them as one of the Webpack alternatives. Although ByteDance doesn't rely directly on build tools for profit like Vercel or VoidZero, and Rspack/Rsbuild reuses community results, I feel the vendor lock-in risk isn't that high. But Rspack/Rsbuild's current volume isn't huge -it's obviously much smaller compared to Webpack/Vite. So I think I might need to wait and see.
3. I previously valued Webpack 6.x mainly because of the governance structure. Like Node.js, it belongs to the OpenJS Foundation after all. I guess I feel that for such critical infrastructure, neutrality is quite important. When choosing tech for frontend projects, I also focus heavily on community governance. The only regret is that it's a bit old and has performance issues. So, I was kind of hoping it could solve some of its downsides.
I'd love to hear your thoughts on what I said above. Also, I am curious about your take on the current shift in the JS ecosystem. I think in the current JS ecosystem, commercial companies are increasingly dominating core infrastructure *directly*, and using that infrastructure as a core part of their business plans. Objectively speaking, this leaves *less and less room for neutral, community-driven governance*.
I agree with your point. From my observation, bundlers in the JavaScript ecosystem are indeed becoming more specialized. Meanwhile, tooling libraries and backend code are genuinely moving away from bundlers due to the growing popularity of the "Pure ESM" concept. If that's the case, bundlers may truly be relevant only for frontend scenarios now. Given this shift, it makes more sense to focus bundlers specifically on frontend use cases, and we no longer need those "general-purpose" bundlers. Moreover, Webpack really is overly complex.
I originally posted this proposal in the GitHub Discussions for Microsoft's TypeScript Native (typescript-go) project. I personally feel it might receive more dicussions on Hacker News, so I've reposted the full text here. Comments and feedback are welcome.
[ORIGINAL]
Title: Proposal: Extract the Parser of TypeScript Native into a standalone Go Module to fill a gap in the Go ecosystem and benefit this project
I suggest extracting the Parser component from typescript-go and publishing it as an independent Go library.
Currently, the Go ecosystem severely lacks a complete, standard-compliant JavaScript/TypeScript/JSX parser. typescript-go actually possesses what is likely the most comprehensive Parser in the current Go ecosystem. If this could be decoupled, it would become a foundational cornerstone for frontend tooling within the Go language.
Rationale:
1. It fills a structural gap in the Go ecosystem.
In the JS ecosystem, TypeScript doesn't need a standalone Parser because tools like Babel are already very mature. However, in the Go ecosystem, there is currently no comparable infrastructure. As frontend toolchains migrate toward high-performance native languages, Go is highly attractive to the vast community of JS/TS developers due to its ease of learning and concurrency advantages. By filling this void, Microsoft would allow external tools to reuse this core capability without needing to reinvent the wheel.
2. An independent Parser will attract integration from numerous external tools.
This means massive amounts of real-world codebases will be used to test this Parser. Edge cases discovered and fixed by the community can be fed directly back into typescript-go. This is far more efficient than relying solely on internal test cases and will significantly improve the robustness of the Parser.
3. From an engineering perspective, decoupling the Parser helps define project boundaries and improves maintainability. Implementation-wise, this does not require rewriting core logic; it only involves adjusting the project structure to support Go Module referencing, making the engineering effort manageable.
4. TypeScript has, in a sense, become a de facto standard.
If Microsoft provides an official Go version of the Parser, it ensures that Go-based frontend toolchains maintain high consistency with the native TS compiler in parsing behavior. This prevents the community from creating various incompatible "dialect" parsers due to a lack of standards, thereby avoiding ecosystem fragmentation.