Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly’s post-MVP future

hacks.mozilla.org

Post reply on HN
Print view View original

181–190 of 207 posts

Re: WebAssembly’s post-MVP future

#181

Post by lambda »

skybrian wrote: post #12

I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…

> On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough?

Docker has won to a degree, though it still requires complex orchestration technologies like Kubernetes built on top of it, which are rapidly developing and not a particularly stable target.

> Although serverless and edge computing often use JavaScript.

Yes, this is where I see WASM really hold its own. Serverless and edge environments want to be able to have code running in a persistent process that is completely managed by the environment. Right now, they frequently offer just JS, or a couple of language runtime environments like Python as well; for serverless environments, you can generally load native modules if you want to, but its awkward, while edge environments will only run JS, though now they're starting to offer WASM.

It's the places where being able to run multiple tenants within a single process, without paying IPC and process isolation overheads, that make the overhead of WASM more likely to be worth it.

> On mobile this seems to depend on Apple and/or Google deciding to support WebAssembly for native apps, which seems unlikely.

I don't think it would be too unlikely for Google to support WASM for native apps. For one, it would allow them to do architecture independent apps without ART, on Fuchsia, for example. Right now, I think Dart + Flutter compiles to ARM code, but if they want to target a wider range of devices then platform independence could be important.

Re: WebAssembly’s post-MVP future

#182

Post by marcosdumay »

edflsafoiewq wrote: post #70
marcosdumay wrote: post #34

Earlier quoted context omitted.

> Wasm isn't really for pretty apps you can quickly make in Vue. Why not? Developing pretty apps in Vue (or anything in JS-land) is an horrible experience, why shouldn't we use WASM to port some better environment into there?

If there's some better environment to be found in non-JS-land, why is Electron and its ilk so popular?

Because JS runs on the browser, so anything else is less portable.

Re: WebAssembly’s post-MVP future

#183

Post by rkangel »

amelius wrote: post #81
rkangel wrote: post #73

Earlier quoted context omitted.

You've already got 2 co-operating languages - JS and whatever is compiler to WASM.

True, but once you're using WASM, you probably don't need to hold references to JS objects that point back to the objects created in WASM. We've been interfacing C with e.g. Python without needing a garbage collector that crosses language boundaries. So why would we need one now?

> We've been interfacing C with e.g. Python without needing a garbage collector that crosses language boundaries. So why would we need one now?

Because C doesn't need garbage collection, it uses 'manual' memory management. This scenario is exactly analogous to the WASM-JS world that exists now (WASM is manual, and JS is GC).

The goal here is to have a GC that's usable in WASM, and WASM is going to be interoperating a lot with JS for many applications, so it needs to cope with that. A better analogy in this case would be IronPython which is Python built on the .NET framework rather than C. In that case, the Python GC is the .NET GC, so that objects can be passed back and forth 'between worlds'.

Re: WebAssembly’s post-MVP future

#185

Post by kentonv »

steveklabnik wrote: post #178
chrisweekly wrote: post #175

Earlier quoted context omitted.

1. Thanks for your multiple well-informed, articulate comments. 2. "BSG"?

I think your parent is referring to Battlestar Galactica; it had no computer networks, and therefore was not able to be effectively attacked by the Cylons.

Yep. :)

The Battlestar Galactica was the only ship in the fleet that hadn't networked its computers, because the captain was paranoid. When the Cylons (AI) attacked, they instantly hacked all the other ships, but the Galactica stayed under human control and got away.

It's fiction, but I'm honestly really impressed with this bit of writing. It's both an entirely plausible and almost realistic strategy, and it gives the writers an excuse for the crew members to interact rather than let the computer do everything. Whereas on Star Trek one wonders why they bother with a bridge crew -- the captain might as well be punching everything into a computer directly rather than inefficiently giving orders to humans.

Re: WebAssembly’s post-MVP future

#186

Post by marcosdumay »

eksemplar wrote: post #140
marcosdumay wrote: post #34

Earlier quoted context omitted.

> Wasm isn't really for pretty apps you can quickly make in Vue. Why not? Developing pretty apps in Vue (or anything in JS-land) is an horrible experience, why shouldn't we use WASM to port some better environment into there?

I don’t think it’s horrible, could you point me to something better? We used to work with, first WPF then web forms and later MVC with razor, and we very quickly bought Telerik because the standard UI components in .Net are horrible. Aside from that I’ve worked with JAVA I can’t recall what we used before FX but both were terrible. In the JS CSS environment I can literally make an interface that doesn’t look like ass…

I don't really see a need of replacing the DOM. It has some problems, but nearly everything around has at least as many problems, just different ones. Indeed, that's the reason I want to see WASM interact well with it.

The largest problems of the web programming are lack of componentization and Javascript, we may be able to solve that last one soon!

The thing with JS is that it is a no batteries, no novelty, no shortcut, not very productive language, that manages to be both old-school and novel on all the bad ways. You can't just carelessly gather code and use it, because there are no safety boundaries; most code that is not at the frontend (yeah, like Apollo) have no consideration about security, so you can't simply expose it; the entire ecosystem is a house of cards; and the language itself is a pile of WTFs just waiting for you to discover another one.

Besides, the web stack is pretty much controlled by Google nowadays. Yes, they manage development resources better than Microsoft, but I would prefer working on a stable and free environment.

Re: WebAssembly’s post-MVP future

#187

Post by PowerfulWizard »

iainmerrick wrote: post #171
PowerfulWizard wrote: post #5

Earlier quoted context omitted.

Agreed on the stdlib concept. I'm sure people are working on it, the benefit would be massive. Just the amount of mobile data transfer that could be saved by 1MB of software pre-distributed to all browsers would be huge. I wonder if anyone is trying to do it based on the javascript integrity hashes. In theory, if you took the top 100 javascript libraries and established a blessed build pipeline that would produce ref…

Just the amount of mobile data transfer that could be saved by 1MB of software pre-distributed to all browsers would be huge. That would be great. I’m normally a fan of multiple competing implementations, but this might be an area where a single common library implementation, developed in partnership by all browser vendors, would be beneficial. All the code would be in wasm so it would be portable by definition. And…

Yeah agreed, it is extra complicated since it requires coordination between browsers and also enough websites to make it worth it. If it were released today it could take years to register in i.e. global internet statistics. I guess in theory shared CDN's and caching should be almost as good as well if major website could agree on dependency sharing.

Re: WebAssembly’s post-MVP future

#188

Post by kllrnohj »

cm2187 wrote: post #160
kllrnohj wrote: post #41

Earlier quoted context omitted.

WebASM really only makes sense in the context of embedding untrusted code, which outside of the browser is a concern that largely doesn't exist. Otherwise you are severely crippling yourself for no real gain. You're going to lag the hardware features by years if not decades, you're not going to get arch-specific optimizations as readily, and you're going to have huge startup costs. You're also stuck with sandbox rest…

In what language can you just “compile 4 times” to target android, iOS, windows, linux, macos and any future platform?

Literally all of them? Since you scope creaped to add macos to the list even though it doesn't exist in the server or mobile space you'll need to increase that to 5 compiles instead of 4, though.

But C, C++, Rust, Go, D, etc... all support compilation to those platforms. This is a really common thing to do.

Re: WebAssembly’s post-MVP future

#189

Post by [deleted] »

ConanRus wrote: post #64

This is all right and all, but I have one question: why the hell it needs to be inside of a browser? To do what exactly? I don't care about browsers, I care about applications. I don't want freaking Photoshop in my browser, because I want a browser to die. This should be a part of the OS, not a freaking browser. Give me a built-in runtime with sandboxing, a delivery method, and an AppStore. Give me next generation Ja…

[deleted]

Re: WebAssembly’s post-MVP future

#190

Post by tabtab »

pcwalton wrote: post #97
tabtab wrote: post #95

Earlier quoted context omitted.

With Win32 and Cocoa you pretty much have one vendor with roughly 3 or so major releases. But with browsers you have roughly 8 vendors above 1% market-share with 3 or so (notable) major releases each. Therefore, you have to target roughly 8x more variations of the UI engine. Look how hard Wine's job is to be sufficiently compatible. I believe we need to either simplify the front-end standards (pushing as much as poss…

Interoperability, and the standards process, is how we get specs that are sensible. Whenever I have to program using Win32, Cocoa, etc. I inevitably spend a ton of time reverse engineering how the proprietary APIs work. For DOM APIs, things generally work how they are supposed to work, because they were actually designed in the first place (well, the more recent APIs were). Wine isn't comparable, because the Web APIs…

Re: "the standards process, is how we get specs that are sensible." - They are not sensible: different vendors interpret the grey areas differently. A sufficiently thorough written standard would be longer and harder-to-read than the code itself to implement such.

Re: "Your proposals break Web compatibility" -- Web compatibility is whatever we make it. A one-size-fits-all UI/render standard has proven a mess. What's the harm in at least trying domain-specific standards? We all have theories, but only the real world can really test such theories.

Post reply on HN