4 ms·
WebAssembly allows you to program web pages in a language other than Javascript. The above statement might gloss over a lot of very important details: But that
by gwbas1c 3y ago
WebAssembly allows you to program web pages in a language other than Javascript.
The above statement might gloss over a lot of very important details: But that mindset also misses the point: The critical use case of WebAssembly, and the problem it attempted to solve, right now, is to creating a webpage in a language other than JavaScript.
Everything else that the article mentions is an impressive feat on its own, but what WebAssembly could do is very different than what it does now. And the fact that now you can program a website in a language other than Javascript (or TypeScript) is a very tangible accomplishment that people who aren't enamored with computer science can appreciate, understand, and repeat.
- bryanlarsen 3y agoThere are many places that have been using WASM for purposes similar to the ones in the article for quite a while now. For example, Cloudflare workers have been using WASM for a year and a half.
- steveklabnik 3y agoWorkers has supported WASM since 2018: https://blog.cloudflare.com/webassembly-on-cloudflare-workers https://blog.cloudflare.com/webassembly-on-cloudflare-worker...
- jauntywundrkind 3y agoI'm both excited about cross-language but also I think the people you describe as potential beneficiaries are those most apt to suffer under the new (anti-)regime. > And the fact that now you can program a website in a language other than Javascript (or TypeScript) is a very tangible accomplishment that people who aren't enamored with computer science can appreciate, understand, and repeat. Industrial software dev has resulted in gross difficult minified bundles & absurdities like vdom that are hard to view-source hack. But there's pretty ok un-minifying & it's surprisingly possible to get really far, if a user wants to seize the power & do some userscripting. And many in the webdev world have steadily been trying to push back against this rampant industrialization. HTTP2 and ESM were hopefully going to make unbundling more viable, but that's still long suffering (ex: import-maps don't work for workers, https://github.com/WICG/import-maps/issues/2 https://github.com/WICG/import-maps/issues/2), and now that the http cache doesn't work cross-site many of the possible re-use upsides are dead. Still a goal for many though. WebComponents is still a vast un-frameworking potential; in many implementations it unravels the descent into abstraction that React framework begat. Classic web devs have a lot of heart to make the web pro-user, to un-framework things, but the industrial demands are hard to re-satisfy on these better paths & so much momentum is elsewhere. Now compare to the wasm world. We have basically pure machine code running our web in wasm. It's utterly unintelligible. There's dozens of hundred of kb libraries that languages bring in to userland just to do the language thing. I think people will have an incredibly poor time learning the web, think the worst risk wasm has is in scaring people off from view-source, from casually observing & learning anything. Wasm is god smiting the tower of Babel, is a one language breaking & being cast down & a hundred different tribes speaking their own language. So much good will come from this diversity, we'll see so many different styles & tries from so many camps, and that will be a benefit, but it will in my view be drastically harder for those "who aren't enamored with computer science can appreciate, understand, and repeat." Intelligibility is the loser, when Babel falls.
- gwbas1c 3y ago> We have basically pure machine code running our web in wasm. It's utterly unintelligible. Whenever technology changes there's always an argument against the new thing. In this case, I don't think that argument has merit. We've been running various flavors of compiled code since (almost) the beginning of computers, and the merits and drawbacks of that approach are well understood.
- jauntywundrkind 3y agoThe web has been distinct & unique & closer to "the language of the gods" for being much better, more pro-user than the old industrial-computing compiled ways. Many webdevs got their start from view-source (and many would have been lost to computing if we were just another compiled blackbox). The aliveness of the web contrasts to the dead programming variety. The erosion of this aliveness & legibility has been mourned, and should be. It is worth fighting for the user. I don't think your argument has merit, that merits can be ignored because this is how computers always used to be. Wasm's return to the dark times of industrialized blackbox computing will cut off the best users from the joy of being closer to the machine that they had on the web, and that return to darkness is a sad plight for mankind, even if that's how it always used to be. I treasure the light of the open alive web, and hope somehow it can survive this voyage into shadow.
- ryukafalz 3y agoWe can and should provide a "view source" equivalent for native code as well. Package managers like Guix that know where to find the source and how to build it are a good step forward there. Text formats can be minified and obfuscated, binary formats can include mechanisms to see and experiment with the source. It's all about the tooling you have, what that tooling makes easy, and what it makes hard.
- c-cube 3y agoAnd what, pray tell, does view-source look like in typical SPA? Even in the debugger (if the beginner knows what that is), what will the minified bundle of 50 libraries look like?
- kccqzy 3y agoI'd argue that's actually besides the point. Before WebAssembly there were plenty of good ways to write web apps in a language other than JavaScript. Some for example integrate it into the language tooling (like ClojureScript which I have used and have fond memories of), some simply directly used asm.js (which I have also used). So if the only use case of WebAssembly is to enable that, it is an utterly unexciting piece of incremental improvement. Everything that's exciting about WebAssembly comes from where it can be used besides replacing JavaScript in a browser. It's a point I've repeatedly argued on this forum since two years ago (see https://news.ycombinator.com/item?id=30156799 https://news.ycombinator.com/item?id=30156799 and https://news.ycombinator.com/item?id=38138739 https://news.ycombinator.com/item?id=38138739)
- trgn 3y agoMaybe we're just splitting hairs on what it means to be "a webpage", but I feel like people are _not_ writing webpages in WebAssembly. Instead, you get video games, interactive animations, photo editing apps, ... Basically, desktop-app like things, but generally without a DOM, without CSS. The look and feel diverges quite strongly, a user kind of intuits they're no longer in a regular web-app. To my frustration, WebAssembly is not replacing JS/TS and it's abominable toolchains, it ends up delivering a new suite of experiences, by adding another layer of abominable toolchains. There's also low level "helper"-libraries getting developed in WASM, e.g. a database implementation, but wondering if that ever takes off, managing bindings is rough and library size/bootstrapping can end up bloated. And it certainly does't get us out of JS/TS-dev land.