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

161–170 of 207 posts

Re: WebAssembly’s post-MVP future

#161

Post by sametmax »

justinclift wrote: post #110

On a semi-related point, TinyGo (a subset of Go for embedded devices) recently added a WebAssembly output target: https://github.com/aykevl/tinygo ) Unlike the current mainline Go's WebAssembly output (min ~2MB file size), the Wasm generated from TinyGo is practical in size. eg ~1kb for the toy examples This is all leading edge dev stuff too, so updates and improvements are happening pretty frequently. :)

Your comment just made me realized that, while using cPython => webassembly for something else than electron would be overkill, this would be kinda neat for microPython.

Re: WebAssembly’s post-MVP future

#162

Post by otabdeveloper1 »

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.

No.

Re: WebAssembly’s post-MVP future

#163

Post by amelius »

TomMarius wrote: post #90
amelius wrote: post #88

Earlier quoted context omitted.

Define "safe". Are you talking about security or correctness, or both, and please elaborate.

The point of WASM is the ability to safely run any untrusted code in a performant way, that includes seamless interfacing with other modules. https://webassembly.org/docs/security/

I'm sure that if you can make WASM secure without the GC part, then you can create a safe interface. Yes, it may leak memory (remember, so can a GCed program that forgets to unreference objects), but that's just something you have to deal with when programming at a low level; and languages built on top of WASM can make that a non-issue, actually.

Let's keep WASM simple. It's probably the best thing one could do in view of security.

Re: WebAssembly’s post-MVP future

#164

Post by nchie »

roblabla wrote: post #46
sk1pper wrote: post #39

Earlier quoted context omitted.

How does this not end up as Flash reincarnated though?

What part of flash was bad? - the (bad) sandboxing? WASM uses the same sandboxing model as JS, and thus provides the same security guarantees? - the requirement of an external plugin? WASM comes preinstalled in all browsers. - the proprietary aspect? Wasm is an open standard. - the obfuscated nature? WASM can be decompiled very easily. Besides, js served by modern websotes are already minimized and obfuscated beyond…

Having to reimplement things such as text selection, clipboard, and making it more or less impossible to write plugins which affect the pages being shown (adblock, reddit enhancement suit, etc) are a few huge reasons. I'd prefer to keep the web consistent for sites which don't actually need to be rendered on a canvas.

Re: WebAssembly’s post-MVP future

#165

Post by TomMarius »

amelius wrote: post #163
TomMarius wrote: post #90

Earlier quoted context omitted.

The point of WASM is the ability to safely run any untrusted code in a performant way, that includes seamless interfacing with other modules. https://webassembly.org/docs/security/

I'm sure that if you can make WASM secure without the GC part, then you can create a safe interface. Yes, it may leak memory (remember, so can a GCed program that forgets to unreference objects), but that's just something you have to deal with when programming at a low level; and languages built on top of WASM can make that a non-issue, actually. Let's keep WASM simple. It's probably the best thing one could do in vi…

Can you elaborate on how two WASM modules each with its own GC could safely interface without unnecessary overhead? Why would we want to have this overhead in the first place? It may not be that bad with 2 modules, but you might easily have 20 or (way) more.

Re: WebAssembly’s post-MVP future

#166

Post by justinclift »

sametmax wrote: post #161
justinclift wrote: post #110

On a semi-related point, TinyGo (a subset of Go for embedded devices) recently added a WebAssembly output target: https://github.com/aykevl/tinygo ) Unlike the current mainline Go's WebAssembly output (min ~2MB file size), the Wasm generated from TinyGo is practical in size. eg ~1kb for the toy examples This is all leading edge dev stuff too, so updates and improvements are happening pretty frequently. :)

Your comment just made me realized that, while using cPython => webassembly for something else than electron would be overkill, this would be kinda neat for microPython.

Yep. If you want to add it, that would be kinda neat. :)

Re: WebAssembly’s post-MVP future

#167

Post by de_watcher »

TomMarius wrote: post #165
amelius wrote: post #163

Earlier quoted context omitted.

I'm sure that if you can make WASM secure without the GC part, then you can create a safe interface. Yes, it may leak memory (remember, so can a GCed program that forgets to unreference objects), but that's just something you have to deal with when programming at a low level; and languages built on top of WASM can make that a non-issue, actually. Let's keep WASM simple. It's probably the best thing one could do in vi…

Can you elaborate on how two WASM modules each with its own GC could safely interface without unnecessary overhead? Why would we want to have this overhead in the first place? It may not be that bad with 2 modules, but you might easily have 20 or (way) more.

I've got multiple specialized GCs within one module, and they're doing fine.

Trying to shoehorn everything into one model isn't something that should have 'asm' in its name.

Re: WebAssembly’s post-MVP future

#168

Post by TomMarius »

de_watcher wrote: post #167
TomMarius wrote: post #165

Earlier quoted context omitted.

Can you elaborate on how two WASM modules each with its own GC could safely interface without unnecessary overhead? Why would we want to have this overhead in the first place? It may not be that bad with 2 modules, but you might easily have 20 or (way) more.

I've got multiple specialized GCs within one module, and they're doing fine. Trying to shoehorn everything into one model isn't something that should have 'asm' in its name.

OK, but could you share the specifics? I'd like to understand. Emphasis on combination of safety (primary) and performance (secondary) - remember that any number of completely unrelated, untrusted, maybe buggy and potentially even malicious modules might be combined. They're being very careful about not forcing languages into one model, BTW.

Re: WebAssembly’s post-MVP future

#169

Post by denniskane »

jholman wrote: post #141
bloomer wrote: post #115

Earlier quoted context omitted.

Yeah I'm really confused why working with 4GB+ datasets in the browser is a current need. Why does everything end up in web browsers these days? Is it only because developers aren't familiar with anything else?

You might similarly ask why app stores on iOS and Android are such a big deal, and why Steam is even a thing. It's because deployment is a harder problem than development (at least, it's harder for developers, because deployment is a social problem). The web is a pretty poor development target (though it keeps getting better), but it's a damn terrific deployment medium, and that's a winning tradeoff.

A truly web-browser-centric development/deployment workflow is slowly but surely becoming a thing. I call it "Linux on the Web":

Easy as A-B-C / Or 1-2-3 / It's L-O-T-W ~dot~ X-Y-Z!

Re: WebAssembly’s post-MVP future

#170

Post by thrower123 »

voltagex_ wrote: post #126
thrower123 wrote: post #107

Earlier quoted context omitted.

Every time I start doing anything moderately complicated in JS, I rage at how much more difficult it is compared to slamming together a UI in .NET.

WinForms or WPF? I can throw together a (terrible) HTML page faster than I can remember how MVVM is meant to work.

I'm a lover of WinForms, since I cut my teeth on VB6 and MFC... it's surprising how decent you can make things look with a little polishing.

It's nuts that visual layout editors for the web have, if anything, regressed from the WebForms editor in Visual Studio 2008.

Post reply on HN