Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasm? #106

Closed
jhpratt opened this issue Dec 30, 2018 · 18 comments
Closed

wasm? #106

jhpratt opened this issue Dec 30, 2018 · 18 comments

Comments

@jhpratt
Copy link

jhpratt commented Dec 30, 2018

Could this potentially be compiled to WebAssembly? This would allow full interop with the existing Babel packages, and would truly thrust this project into the spotlight.

@dennythecoder
Copy link

You may want to check out #87

@Skalman Skalman mentioned this issue Nov 30, 2019
@anurbol
Copy link
Contributor

anurbol commented Dec 9, 2019

@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
Copy link
Member

kdy1 commented Dec 9, 2019

@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.

@anurbol
Copy link
Contributor

anurbol commented Dec 10, 2019

@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
Copy link
Member

kdy1 commented Dec 10, 2019

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

@anurbol
Copy link
Contributor

anurbol commented Dec 11, 2019

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

@3cp
Copy link

3cp commented Jan 16, 2020

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!

@alubbe
Copy link
Contributor

alubbe commented Feb 3, 2020

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!

@anurbol
Copy link
Contributor

anurbol commented Feb 3, 2020

@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
Copy link
Contributor

alubbe commented Feb 3, 2020

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
Copy link
Contributor

anurbol commented Feb 3, 2020

@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.

bors bot pushed a commit that referenced this issue Feb 5, 2020
This PR supercedes #621 and tries to remove dependency renaming to enable WASM, as discussed in #106
This was referenced Feb 13, 2020
@kdy1
Copy link
Member

kdy1 commented Feb 26, 2020

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
Copy link
Contributor

alubbe commented Feb 26, 2020

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

@kdy1
Copy link
Member

kdy1 commented Feb 26, 2020

@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
Copy link
Contributor

alubbe commented Feb 26, 2020

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
Copy link
Member

kdy1 commented Feb 26, 2020

@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.

@kdy1
Copy link
Member

kdy1 commented May 14, 2020

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

@swc-bot
Copy link
Collaborator

swc-bot commented Oct 27, 2022

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.

@swc-project swc-project locked as resolved and limited conversation to collaborators Oct 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

7 participants