Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Where are we headed with all of this?

We are heading nowhere.

Hot take: WASM is a dead technology and has failed to displace vanilla JS. There are only a few very niche use cases, most of which have zero product-market fit (e.g., no one wants to play video games in a browser).

Furthermore, no one wants to seriously write C++/Rust/Java and then compile it to WASM. These days, WASM projects are a neat way to pad your resume or get tech "thought leaders" to tweet about you. As far as Extism goes, it sounds like a problem looking for a solution. We already have LUA and JS as embeddable scripting languages, so here we go overengineering yet again.



Yeah, they keep repacking ideas of bytecode formats that exist for decades, as if it was something novel.

Nowadays the whole hype about WASM containers is basically reselling what Java and .NET application servers have been doing for 20 years.


yeah I don't understand the hype. Every release of wasmwhatever seems to make the front page here. But the number of real products using the technology seems miniscule. It's been out for many years, if it was going to change the world it seems like it should be making more progress.


Have some hope on Component Model (this is kinda module system for the whole WASI thing). It wasn't growing because .. bespoke ABI for different langs and bespoke interfaces between host<->guest. Lack of guide too, it's mostly specification which is hard to read.


You are wrong and missing the point. I mostly agree with you and had the same opinion. BUT, the “money” is in the runtime and the real isolation of code and capability based access.

Forget about the browser, games, etc ( at least for now) and think about the server, dock and kubernetes.

If developers adopt a plug-in model of programming it will be a game changer. I don’t have a crystal ball but that’s what’s fueling wasm right now and it has merits


App developers wanted it to work. And if apple had allowed it to work in safari like it does on android, it might have made progress.


Erm, WASM works just fine on iOS Safari since a very long time now? I can't remember when I dropped the asm.js fallback for my WASM stuff, maybe around 2017/18? And unlike Chrome, the switch from asm.js to WASM actually made a massive performance difference on Safari, because the Safari team never bothered to add special support for asm.js.


Yeah, I meant on android you can use it to make a webapp that goes full screen, can be granted position info etc. by the user, and push notifications. A PWA in other words. Apple doesn't want PWAs, as they circumvent control of the appstore.


> And if apple had allowed it to work in safari like it does on android, it might have made progress.

WASM has been on Safari since version 11 released 5 years ago. Same year it became available on Chrome and Firefox.


Yeah, I meant on android you can use it to make a webapp that goes full screen, can be granted position info etc. by the user, and push notifications. A PWA in other words. Apple doesn't want PWAs, as they circumvent control of the appstore.


"PWAs" are a dozen different standards. And everyone selects a different subset of them to call "the one true PWA".

Apple has supported the absolute vast majority of them since forever. And they have literally nothing to do with doing anything in WASM.


WASM is involved because webapps would be a primary usecase for it. A way to deploy your webapp with more performance and less effort at obfuscation. If webapps aren't first class citizens, the effort to port buts of your native and webapp together to make a WASM based PWA has a lower ROI.

A quick search show plenty of articles talking about the limitations of webapps on iOS. Here is one, it is a year old, but then most WASM project repos I look at haven't had a commit in that long...

https://hub.tigrenpwa.com/pwa-on-ios/

I'm not attacking anyone's choices. I don't particularly love the idea of all these blackbox WebApps and the more stuff we let theough the sandbox the bigger the attack surface. Once again Apple's motive to retain complete control aligns with the motive to keep devices secure. I don't like native apps either for the most part, black boxes with even more attack surface. If webapps with less attack surface displace native apps with more, I mostly call that a win.

I write embedded numeric heavy code in c++/cuda and rust, so it is at best peripheral to my day job, meaning I don't have the expertise or motivation to have a strong opinion. I'm engaging in the conversation primarily to learn.


> A quick search show plenty of articles talking about the limitations of webapps on iOS.

Again: "PWAs" are a dozen different standards (or perhaps more). And everyone selects a different subset of them to call "the one true PWA".

For example, some may say that "omg I need direct access to Bluetooth or other hardware APIs". Well, those are Chrome-only non-standards that neither Firefox nor Safari will implement.

There are some like push notifications which are debatable (but arriving in Safari this year). And then there's background sync that Chrome enabled by default in 2016, and which still had issues in 2019 that both Firefox and Safari objected to: https://github.com/mozilla/standards-positions/issues/214 No idea what their position on it is now.

And so on and so forth.

But these articles and half of HN will scream until they are blue in the face claiming that "it's Safari that's holding the PWAs back". Where reality is more complex and the narrative is mostly driven by Chrome, unfortunately.


Thanks for the insight! That makes sense, Chrome trying to grab control from native apps feeds Google's ad machine.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: