move from wasm-pack to wasm-bindgen
benmkw opened this issue · 11 comments
wasm-pack is not getting maintenance anytime soon and is broken in many ways :/
As I understand, wasm-bindgen is a bit more low level so it might require additional effort but is partially maintained.
Also, as I understand, rollup might not be the preferred way to develop with svelte soon https://svelte.dev/blog/whats-the-deal-with-sveltekit so this project might be less relevant/ another integration will need to be developed.
wasm-pack is not getting maintenance anytime soon and is broken in many ways :/
Could you explain how it is broken?
rollup might not be the preferred way to develop with svelte soon
How is svelte relevant to Rust Wasm?
another integration will need to be developed.
It would be cool to have a Snowpack plugin (we already have a Webpack, Parcel, and Rollup plugins), but I'm not sure how that's relevant for rollup-plugin-rust.
Could you explain how it is broken?
https://github.com/rustwasm/wasm-pack/issues and https://github.com/rustwasm/wasm-pack/pulls list many things although I'm only directly impacted by the missing arm/m1 support. I know thats kind of self inflicted though :D
How is svelte relevant to Rust Wasm?
As I understand rollup was developed by Rich Harris as well and is thus a preferred way to bundle svelte apps, although its of course also useful for others.
It would be cool to have a Snowpack plugin (we already have a Webpack, Parcel, and Rollup plugins), but I'm not sure how that's relevant for rollup-plugin-rust.
I just added that information to indicate, that I'm not sure if this plugin would be superseded by the svelteKit/ Snowpack workflow anyway and thus questioning if the effort to change this plugin to rust-bindgen would be worthwhile. This might have been a wrong assumption if many/ most people use rollup for non svelte projects which is probably actually the case.
The rust wasm community seems to have a certain issue with maintenance currently https://www.reddit.com/r/rust/comments/lzirze/gloo_an_official_rustwasm_project_needs_a/ so I'm not sure how the ecosystem will evolve/ whats the best path forward.
I want to say thanks for your work, the plugin was very nice to use, e.g. live reload worked great!
Indeed wasm-pack development has stalled and it's missing many features, but I am unaware of any breakage.
although I'm only directly impacted by the missing arm/m1 support
Does wasm-bindgen support arm/m1? wasm-pack is just a tiny wrapper around wasm-bindgen, so if wasm-bindgen doesn't support it then wasm-pack can't support it either.
As I understand rollup was developed by Rich Harris as well and is thus a preferred way to bundle svelte apps, although its of course also useful for others.
Rich Harris has not contributed to Rollup since 2018, instead development is primarily done by Lukas Taegert-Atkinson.
I'm not sure if this plugin would be superseded by the svelteKit/ Snowpack workflow anyway and thus questioning if the effort to change this plugin to rust-bindgen would be worthwhile. This might have been a wrong assumption if many/ most people use rollup for non svelte projects which is probably actually the case.
Indeed Rollup is very commonly used outside of svelte, so we will always need to support this plugin, it can never be replaced by Snowpack. Instead we would have to support both Rollup and Snowpack.
The rust wasm community seems to have a certain issue with maintenance currently https://www.reddit.com/r/rust/comments/lzirze/gloo_an_official_rustwasm_project_needs_a/ so I'm not sure how the ecosystem will evolve/ whats the best path forward.
Yes, since I stopped contributing to Rust the only active contributor is Alex Crichton, and he is also moving away from Rust.
Does wasm-bindgen support arm/m1? wasm-pack is just a tiny wrapper around wasm-bindgen, so if wasm-bindgen doesn't support it then wasm-pack can't support it either.
I have not tried wasm-bindgen yet. I looked into what it would take to update wasm-pack for arm and it seemed to be just a few strings. I was struggling with how to replace/ patch it as this plugin pulls wasm-pack from npm and thus I saw no easy way to override that with a local patched version. If I were to maintain a patched version this would also still break for others and even if I fixed the arm issue I would probably run into the other issues down the road.
Thus I think the only viable solution is wasm-bindgen as PRs/ fixes have a chance to be upstreamed there.
Yes, since I stopped contributing to Rust the only active contributor is Alex Crichton, and he is also moving away from Rust.
Yes its all very unfortunate 😞 ....not sure what to make of it 😄 maybe just wait until something happens I guess, or lean how JS bundlers work and really dive deep into it 🎉 😭 🤣
Thus I think the only viable solution is wasm-bindgen as PRs/ fixes have a chance to be upstreamed there.
The problem is that wasm-pack does a few things which wasm-bindgen doesn't do, so we can't just replace wasm-pack with wasm-bindgen.
The ideal situation is for wasm-bindgen to handle everything, and then we won't need wasm-pack anymore. I had made a proposal for that.
The other solution is to just maintain a fork of wasm-pack, and then I can change the plugin to use the fork. I was planning on creating a fork of wasm-pack after wasm-pack breaks, but it's been working fine so far.
Also see #13
sorry I missed that
I disagree with the points brought up for wasm-pack though (given the current circumstances):
It automatically installs the wasm32-unknown-unknown target.
I don't think thats a sufficient selling point as this can be easily noted in an error message with a hint or in the wasm-bindgen/ this plugins Readme
It parses the Cargo.lock and downloads a version of wasm-bindgen-cli which exactly matches your project's version of wasm-bindgen. This is super important, the versions must match exactly.
I see this as a benefit, downloading wasm-pack from npm makes it also possible to have different versions for different projects on the same machine. However given the current situation I think its worthwhile to push the burden to the user such that they have to update everything to the latest version or install older versions when switching projects which is also not terribly hard using cargo. I assume a error message indicating this to the user could be emitted to avoid mysterious breakage.
It downloads and runs wasm-opt, which produces smaller binaries.
this is something that seems to have issues in wasm-pack anyway rustwasm/wasm-pack#919 rustwasm/wasm-pack#957 and I think it would be reasonable to require users to install it themselves and this makes versioning/ updating also easier for users and makes them less reliant on merged PRs
I think wasm-pack was a great idea at the time it used to be under active development but because there is a bit of an maintenance issue I think it's reasonable to reevaluate priorities and require users to do more work/ give users more flexibility. As a side note I also think it actually benefits users to understand more of what they do, although this is certainly of tradeoff between explicitness and magic which can also be considered user friendliness when it works.
@benmkw I disagree that the solution is to just abandon wasm-pack and leave those features to the end-user. That doesn't fix anything, and that wouldn't magically make new features happen. The only viable solution I see is a fork of wasm-pack.
I think this is something we can agree to disagree about. I tried to outline the reasoning as to why it would in my opinion be beneficial to end users to do the maigc which wasm-pack does by themselves but I also see that it might not be the workflow that this plugin wants to advertise.
Indeed Rollup is very commonly used outside of svelte, so we will always need to support this plugin, it can never be replaced by Snowpack. Instead we would have to support both Rollup and Snowpack.
Indeed, many of the web's most important libraries (e.g. D3) use rollup so rollup itself and this library will be relevant for a while.
The only viable solution I see is a fork of wasm-pack.
The wasm pack folks seemed pretty open to add new maintainers so I don't know whether a fork is necessary.
We were having a lot of issues with wasm-pack, so I removed wasm-pack in version 2.0.0
All of the functionality of wasm-pack has been ported to this plugin, so everything will continue to work the same.