4 ms·
WASM is very useful for things outside the web. Consider that a WASM build can be run server side on multiple OS and arch. The same build. The API can be contr
by mfer 3y ago
WASM is very useful for things outside the web.
Consider that a WASM build can be run server side on multiple OS and arch. The same build. The API can be controlled and locked down (think security).
The web is not the most interesting place for WASM.
- 3cats-in-a-coat 3y agoYou can also run the same build when there's no OS fragmentation. Say all Windows machines run the same build. All iPhones run the same build (well not quite, but let's say they automated and hid the builds very efficiently on the App Store, zero effort). All in all, builds are not a problem. If they're a problem, it's a symptom of a fragmented, immature ecosystem, which indeed many Linux/BSD distros continue to be, in the big picture. However none of this matters. Because we have Java and countless other cross-platform runtimes. WASM is at best just another variation on the same theme thrown in the same pool. I definitely see how one could justify WASM hype by saying all the things will be WASM because it's so sandboxed and multiplatform. But that's the engine of all hype cycles. Truth is it likely won't happen, because WASM is nothing new and nothing unique. That niche is filled with solutions already. We could theorize everyone will have a WASM compiler backend because it runs in browsers, therefore it'll become more useful on servers as you have compiler backend for everything to WASM. However YOU yourself said the web is not the most interesting place for WASM. So what will supposedly drive the WASM ecosystem, that makes it interesting (the web) isn't interesting, but it has to be interesting so the server use of WASM becomes more interesting. Quite the chicken egg problem there. Might work, might not. I lived through a period on the web when every language had a JS compiler backend. You could compile Java to JS, Delphi to JS, C# to JS and so on. Maybe some of those solutions still exist in some half-dead form, but they're largely abandoned, because people realized the best language to write JS in... is JS. This is also why TypeScript has such success, because it's JavaScript itself (but with types). For WASM we can argue there's no such pressure to "write JS in JS" but there's just very little value for it, outside the nerd realm of "OMG assembly on the web". I know why Google wants it. It wants it because it indexes the web, and puts ads on the web, and so therefore it wants everything to be the web, because then it means Google can index and put ads on everything. That's good for them, but not for anyone else. Downloading and running hundreds of MB of code for an app like Photoshop, or whatever, over the web is an absolutely miserable experience. Not to mention the HCI input capabilities and OS services available to the app, which are understandably limited in a browser.
- robertlagrant 3y ago> All in all, builds are not a problem. If they're a problem, it's a symptom of a fragmented, immature ecosystem, which indeed many Linux/BSD distros continue to be, in the big picture. Can you give an example of how builds are a problem due to Linux/BSD distros?
- 3cats-in-a-coat 3y agoThey aren't? Well I guess then WASM doesn't matter, as there's no problem to solve.
- robertlagrant 3y agoI think you mis-read my question.
- 3cats-in-a-coat 3y agoMaybe, but there's either a problem with builds, which makes WASM a potentially exciting solution to them, or there isn't, and therefore the subject is not relevant to WASM in this thread.
- pjmlp 3y agoJust like plenty of bytecode formats that have been invented since 1960, while doing it worse than Java, .NET and BEAM.