3 ms·
Want to understand this as well. I was looking at using Rust for some static analysis of JavaScript files recently. My impression is that despite there being m
by rty32 2y ago
Want to understand this as well.
I was looking at using Rust for some static analysis of JavaScript files recently. My impression is that despite there being multiple parsers written in Rust -- the ones in swc, rslint and maybe others -- they are not as production ready as something like acorn, in terms of passing test262, features, documentation, and simply the amount of example code out there. There are bugs like https://github.com/swc-project/swc/issues/2038 https://github.com/swc-project/swc/issues/2038 that haven't been fixed after a few years. (I am aware that swc is "production-ready" in the sense that it is already used by Next.js, but that's not a high bar if you look at all the fallbacks and limitations)
These projects also seem to be very broad but don't have enough developers to support them. They are aiming to provide an "all-in-one" solution with the parser, transpiler, bundler etc all in one place. Which means they have perhaps too much work to do. While in the current JavaScript ecosystem, there are many projects for each part of the toolchain, the unexpected upside is that there are many people working on one thing to make it really good. Just look at webpack. It's not the best thing out there, but the sheer amount of features and the support for almost every use case is amazing. For parsers, acorn is very good, because the author can focus on the parser instead of also working on the bundler.
As an end user, I would much rather see effort concentrated to make the toolchain really good to make it more production ready, rather than seeing another tool popping up.
- magnio 2y ago> There are bugs like https://github.com/swc-project/swc/issues/2038 https://github.com/swc-project/swc/issues/2038 that haven't been fixed after a few years. I tried all those examples on the swc playground[0] and all of them pass, so the issue seems to be fixed, but maybe they forgot to close it. By the way, swc, oxc, and biome all pass test262. [0]: https://swc.rs/playground https://swc.rs/playground (version 1.6.5)
- rty32 2y agoTheir documentation says "passes almost all tests": https://rustdoc.swc.rs/swc_ecma_parser/ https://rustdoc.swc.rs/swc_ecma_parser/ Which could be outdated as well. But if that's true, it's the problem isn't it? If some of the most important information about a critical part of the toolchain isn't up-to-date, how can I have confidence in this? (Also for my specific use case, I need to set an ecmascript version, something that is common in JS based parsers, but it's not available in swc ecma parser. At least I didn't find it.) For context, I contributed to acorn to fix an issue I found while using it in one of my projects. But that happened because I extensively used acorn in the first place. I don't quite have the confidence to adopt these Rust based tools yet.
- genuine_smiles 2y ago> They are aiming to provide an "all-in-one" solution with the parser, transpiler, bundler etc all in one place. Which means they have perhaps too much work to do. They seem to re-use quite a lot. I don’t think any of them, besides ESBuild, roll their own transpiler. For example, Farm uses SWC: https://github.com/farm-fe/farm/blob/main/crates/toolkit/Cargo.toml https://github.com/farm-fe/farm/blob/main/crates/toolkit/Car...