While not directly as popular, Blazor allows you to make the entire website in C#/ASP.NET and ship it as wasm.
It's pretty much up to every language to make some library that allows it to work on the web though wasm.
this post was submitted on 06 Nov 2024
42 points (97.7% liked)
Ask Lemmy
26831 readers
2133 users here now
A Fediverse community for open-ended, thought provoking questions
Please don't post about US Politics. If you need to do this, try [email protected]
Rules: (interactive)
1) Be nice and; have fun
Doxxing, trolling, sealioning, racism, and toxicity are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them
2) All posts must end with a '?'
This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?
3) No spam
Please do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.
4) NSFW is okay, within reason
Just remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either [email protected] or [email protected].
NSFW comments should be restricted to posts tagged [NSFW].
5) This is not a support community.
It is not a place for 'how do I?', type questions.
If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email [email protected]. For other questions check our partnered communities list, or use the search function.
Reminder: The terms of service apply here too.
Partnered Communities:
Logo design credit goes to: tubbadu
founded 1 year ago
MODERATORS
The biggest hole in WASM right now is being able to DO anything really useful in it, natively. The only thing you can do natively right now is use the CPU. Can't manipulate the DOM. Can't access local storage or cookies or networking APIs, etc. You can call out to arbitrary JS code, but that's it.
This is great for some of the big JS libraries that have very CPU-heavy workloads they can optimize in WASM and call to from JS. Like frequently parsing and re-parsing HTML. Or doing game physics calculations.
I haven't heard word one about WHEN any of this will be available. Which is particularly troubling, given how long people have been begging for it.
Of course, none of this stops you from using WASM in the real world, to do quite a lot of things. You're just gonna have to deal with JS interop, still, do do anything really useful.
Right now. WASM has been supported by every browser for a while now, and most webapps are made with WASM. That said, it's not a replacement for Javascript, most people only use it on things that need to be high performance like heavier apps and web games. Nobody really makes websites that rely on WebAssembly instead of JS to my knowledge.
From my understanding, it’s because WASM is pure (deterministic) and needs stateful entry points in order to work. For this reason, a JavaScript bit to interact with it is a requirement at the moment.
Also WASM can't directly manipulate the DOM so it can't really be used for handling HTML/CSS, all front-end stuff still has to be done with JS.
While it’s true you can’t do it in WASM directly, there are frameworks that interoperate between WASM and JS, such as Yew
One only needs to create an interface between them, since WASM is capable of calling JS functions. DOM manipulation then becomes as simple as calling a function in your language of choice, such as with web-sys
We've got a WebAssembly web-UI at $DAYJOB. Implementation language is Rust, we use the Leptos framework (although other mature frameworks are available for Rust).
Pros:
- Same language and similar tooling as in the backend. Most libraries work the same way (obviously excluding libraries that read from the filesystem, for example). This is especially good, if you've got lots of "full stack" devs.
- Same model classes as in the backend. If you change a field, the compiler will force you to fix it on both sides. It is compile-time guaranteed that backend and frontend are compatible.
- Rust is a nicer language than JS/TS. I find especially Rust's error handling via
ResultandOptiontypes + pattern-matching works really well for UI stuff. You just hand theResultvalue over to your rendering stack and that displays either the value or the error. No unset/null variables, no separate error variable, no ternaries. - Having a strict compiler makes it less bad when you're lax on testing, and frontend code is a pain to test.
Cons:
- If you've got pure frontend folks, or people who are deep into React or Angular or whatever, those are not going to be as productive.
- The JS ecosystem is massive, you just won't find as many component libraries for Rust, which can definitely also reduce productivity.
With me being in a team with few frontend folks, I would definitely opt for it again.
Ember seems like it's getting support. Rust has native hooks. C++ is still being supported. It's in a good place.
Unfortunately most front ends don't use wasm.