wasm?

[swc-project]

wasm?

[anurbol]

Hey people, SWC Parser can be built for Wasm! If someone needs, I think, you could make the whole SWC project Wasm-compatible easy enough. So when you build for Wasm you'd likely see the inconsistent resolution for an import error. To fix that, you should get rid of dependency renaming in Cargo.toml files across the whole SWC project. Example is here

[anurbol]

@kdy1 Hey, I've managed to compile the Parser (nothing more) with --target wasm32-unknown-unknown! It turns out that dependency renaming is broken for the Wasm target. Therefore I did this...
In ecmascript\parser\Cargo.toml
Changed this:

ast = { package = "swc_ecma_ast", version = "0.10.0", path ="../ast" }
parser_macros = { package = "swc_ecma_parser_macros", version = "0.4", path ="./macros" }

...to this...

swc_ecma_ast = { version = "0.10.0", path ="../ast" }
swc_ecma_parser_macros = { package = "swc_ecma_parser_macros", version = "0.4", path ="./macros" }

...and minor things, including replacements throughout the swc_ecma_parser crate.

Is it OK? Are the new names OK? Can I make a pull request?

BTW this project is incredible, I am your fan, are you even a human? Because humans can't do such amount of work 😄

[kdy1]

I've implemented transformSync and transformFileSync. It seems like wasm is 3 ~ 4 times slower than native binary.

Please tell me if is it ok. If it's ok, I'll implement other methods for wasm and make it fallback for the swc.

I uploaded the benchmark result at:: #691

[alubbe]

Came here to further express my interest in a wasm release. If the performance is roughly similar, then I believe going wasm would be a tremendous boost to the reach and usage of swc because it suddenly works on every modern browser, every modern version of node and on every operating system that v8 supports - without needing to configure a build system or pre-building binaries.

Personally, I think a great way to continue the discussion would be for @anurbol to contribute his work as a PR and then discuss the feasibility of the changes and measure the performance impact. Happy to help out!

[kdy1]

#691 Is merged. Closing. Please comment or file a new issue if it's not enough.

[dennythecoder]

You may want to check out #87

[anurbol]

@kdy1 Continuing #87 (comment)... So what are those cfgs to build a wasm binary? I've tried to build only the Parser for WASM and got this error I am not sure if it relates to SWC or to Rust. Do you have any clues?

[kdy1]

@anurbol

So what are those cfgs to build a wasm binary?

#[cfg] should be placed on some structs in swc_common. Other codes do not use os-specific features.

got this error I am not sure if it relates to SWC or to Rust. Do you have any clues?

I think it's rustc's bug related to wasm target. I'm not sure about the way to fix it.

[kdy1]

@anurbol I'll be happy with a such PR. Thank you for the interest on swc!

[3cp]

I would love to see a swc wasm release. Even a separated npm package name is fine.

I am using babel and tsc in both nodejs and browser env. But they are both too slow and consume too much memory for my taste.

Very interested on swc!

[anurbol]

@alubbe I have already contributed a very simple PR that restored Wasm support for SWC Parser alone. Yes, the whole SWC-Project is WASM-ready, mostly, just some configuration files should be fixed. Regarding performance impact, in my case WASM was 2 to 3 times slower than native binary, but still this is like x30 times faster than JS.

[alubbe]

Ah awesome, I hadn't seen that! So the next step would be a for a second PR to rename the dependencies and then possibly a third PR to introduce wasm building to the CI process, so that it doesn't get broken going forward?

[anurbol]

@alubbe Yep, seems so! Currently I don't have time for this, but this is simple enough so if you have time you could try.

[alubbe]

Out of interest, could you include babel or other pure JS alternatives in your benchmark?

[kdy1]

@alubbe I included babel, but I didn't benchmark tsc because it does much more work than swc. It will be very slow, but it's expected as it does much more work.
For the same reason, I didn't include sucrase because it cannot compile to es3 / es2015.

[alubbe]

Ah you're right, it's at the end of the benchmark. So for es2015, the WASM version is around 4-5 times faster and the native one is around 9 times faster than babel, right?

[kdy1]

@alubbe Oh. I made a mistake. es2015 in swc is equivalent with es5 because there's no es2015 -> es5 pass. I added a description to the pr.

So the native version is 17 times faster than babel.

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.