5 ms·
When? We’ve been talking about wasm for years. When are we actually getting this future? It’s been 8 years since wasm 1.0, and still we don’t have a stable, eas
by hardwaregeek 2y ago
When? We’ve been talking about wasm for years. When are we actually getting this future? It’s been 8 years since wasm 1.0, and still we don’t have a stable, easy to use toolchain. Rust has maybe the best support and I still can’t get a basic async application with tokio to work on wasm.
To put it into context, Rust was released in 2012. 8 years later it was stable, had a solid toolchain and plenty of people using it in production. Wasm still feels like a toy compared to that
- octopoc 2y agoBlazor is stable and extremely easy to use. It’s just a little slow to load, although there are ways to mitigate that.
- catmanjan 2y agoBlazor is a great developer experience but when you put it side by side with the other technology solutions (react, angular, anything really) its so slow that you will quickly be told to use something else...
- octopoc 2y agoIt depends on the application. And gp was talking about stability and ease of use, not speed.
- zfg 2y agoAmerican Express uses WebAssembly for exactly this use case: https://thenewstack.io/amexs-faas-uses-webassembly-instead-of-containers/ https://thenewstack.io/amexs-faas-uses-webassembly-instead-o...
- dustbunny 2y agoEmscripten seems pretty stable and easy to use to me?
- pjmlp 2y agoStill not as easy a C++/CLI in .NET, in terms of tooling.
- otterley 2y ago> When are we actually getting this future? Around the same time Linux is ready for the desktop.
- milesrout 2y agoUnlikely as that was whenever you stopped having to write Xorg.conf by hand, ie the mid 2000s.
- pjmlp 2y agoAs long as, people use their computers as PC towers from 2000, without hardware video decoding, sleep states, modern UEFI features. There is naturally the version that works, keeping the Linux kernel, and replacing the userland with managed language frameworks, I have heard they are making a huge success in mobile devices and throwaway laptops.
- milesrout 2y agoHardware video decoding has worked perfectly for decades. Sleep worked perfectly until Microsoft decided that device manufacturers should replace sleep with overheating in your bag (a much better sleep mode than, y'know, actual SLEEP). Not sure what "modern UEFI features" means. Whenever something is described as "modern" that screams to me that someone is trying to conflate recentness with quality which is a red flag. UEFI itself has worked fine for as long as it has existed as far as I know? Why you would replace the userland with "managed language frameworks" is quite beyond me.
- pjmlp 2y ago> Hardware video decoding has worked perfectly for decades. That must be why Linux forums are full of VA-API tutorials and how to enable hardware decoding on Chrome then. > UEFI itself has worked fine for as long as it has existed as far as I know? Depends on the board, some boards don't play ball with Linux distros. > Why you would replace the userland with "managed language frameworks" is quite beyond me. Google has their reasons, as does LG, seems to work quite well in market share.
- azakai 2y agoLots of people use wasm in production right now, and toolchain support is in a good place across several languages. In that sense we are already there. You likely visited a website using wasm today without realizing it, and major apps like Photoshop have been ported to wasm, which was the original dream behind it all. That has all succeeded. But if you want to replace containers specifically, as this article wants, then you need more than wasm 1.0 or even 2.0. I don't know when that future will arrive.
- hardwaregeek 2y agoThere's a difference between a handful of sites that use wasm and it being the mainstream way in which we write web applications and run hosted software. It's still a very very niche platform that has not fulfilled its promise of either being a first party web tool or a universal runtime. Like, how easy is it to write a web application in Wasm? Or how easy is it to compile your average program written for a native platform to Wasm without hand picking your dependencies to work on the platform?
- azakai 2y agoYou're right, but wasm's goals were never to be a mainstream way to write web applications. It was designed very specifically to allow things like Photoshop, Unity, and other high-end applications to run on the Web, things that just didn't run at all, and were really important. But despite their importance, those applications are a small fraction of total websites. Wasm succeeded at its initial goals, and has been expanding into more use cases like compiling GC languages. Perhaps some day it will be common to write websites in wasm, but personally I doubt it - JavaScript/TypeScript are excellent.
- harrall 2y agoWASM is another VM and it reminds me of the difficulty that the JVM has faced. You can write-once-run-once a lot of languages like Ruby or JavaScript on the JVM and some of the runtimes are pretty good. But the rest of the community prefers using the original implementation. If some library that you want to use doesn’t work, no one is going to help you. You’re using the second class implementation.
- Dwedit 2y agoI tried out WASM for a very small project once. This was built from a freestanding C source file (no libraries at all, not even the standard library). Zig was the C compiler used to build the program. And I was able to get things working with an understanding of the whole system. You could instantiate the WASM from either a file, or from a byte array, pass in the byte array that held 'system memory' for the WASM program, call the WASM functions from the JavaScript code, and see results of making the function calls. The WASM binary was under 3KB in size. Now once you want to use libraries, everything light and small about WASM goes out the window. You're at the mercy of how efficiently the library code was implemented, and how many dependencies they used while doing so.
- jeroenhd 2y agoIf you skip the async stuff, Rust in WASM works quite well. I also found that Go has quite good WASM support. I think the "WASM as containers" and "WASM as .jar" approaches are rather silly, but language support is good enough to use the technology if you think it's a match. I don't think it will be for most, but there are use cases where pluggable modules with very limited API access are necessary, and for those use cases WASM works. Plus, if you want to run any kind of game engine in the browser, you're going to need WASM. While I'm not replacing my Steam install with a browser any time soon, I have found that WASM inside itch.io runs a lot faster and more stable than Winlator when I'm on my Android tablet.