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

171–180 of 207 posts

Re: WebAssembly’s post-MVP future

#171

Post by iainmerrick »

PowerfulWizard wrote: post #5
kodablah wrote: post #2

Here's a newly created proposals repo to keep track: https://github.com/WebAssembly/proposals . > Skill: 64-bit addressing As a WASM backend implementer in an environment w/ only 32-bit addresses, I hope people don't move to 64-bit addresses too soon. Are we really reaching the limits here already? > Skill: Portability [...] A POSIX for WebAssembly if you will. A PWSIX? A portable WebAssembly system interface. Yes pl…

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 with everybody using exactly the same implementation there shouldn’t be any sneaky incompatibilities. With a single master repo it could be versioned and updated cleanly.

Just as long as it’s kept small (1MB sounds like a good goal) and there isn’t too much churn -- those are the real challenges.

Re: WebAssembly’s post-MVP future

#172

Post by AnIdiotOnTheNet »

voltagex_ wrote: post #125
AnIdiotOnTheNet wrote: post #54

Earlier quoted context omitted.

> Developers need laptops to run their development environment in. I hear a lot of developers going on and on about laptops these days but I can't figure out why. Is working out of a coffee shop the norm now or something?

I can't carry my desktop everywhere and I don't always want to be at home.

Personally, I'd rather not take my work everywhere, but even then there's RDP. If you happen to spend a lot of time developing in locations without decent internet, then I guess a development laptop is a good idea.

Re: WebAssembly’s post-MVP future

#173

Post by roblabla »

nchie wrote: post #164
roblabla wrote: post #46

Earlier quoted context omitted.

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.

Adblock works on the network layer, for the most part, so this would continue to work. Furthermore, most content isn't going to migrate to canvas-based rendering, as that's much more complicated to setup.

The GP I was answering too was talking about figma, a sort of content creation app in the browser. Being able to write those tools and deploy them via the web is a net positive for the web. Just like all the good ol' flash based games were an awesome thing for the web.

When flash was a thing, most web content didn't move to flash. Not only did Flash behave in a foreign way, breaking the user's habit, it was significantly harder to create flash content than web content. Similarly, it's delusional to think most web content will move to wasm. The barrier of entry is enough to prevent that.

Re: WebAssembly’s post-MVP future

#174

Post by Certhas »

6nf wrote: post #121
Game_Ender wrote: post #84

Earlier quoted context omitted.

64 bit addressed cannot come soon enough. In certain domains the entire data set you want to work with is many times the 4GB limit, and JS has no such restriction so it’s a PITA that WASM does.

Do people actually use JS for data sets larger than 4GB in the browser?

I wouldn't be suprised with Jupyter notebooks and all that.

Re: WebAssembly’s post-MVP future

#175

Post by chrisweekly »

kentonv wrote: post #105
jeremyjh wrote: post #103

Earlier quoted context omitted.

V8's developer guide doesn't recommend running untrusted code in a shared process with "sensitive" data. How do you know if your different customers data is sensitive? https://v8.dev/docs/untrusted-code-mitigations#sandbox-untru...

This is a relatively new recommendation on V8's part specifically in response to Spectre-type vulnerabilities. We've spent a lot of time thinking about and building mitigations for speculative side channel attacks. For example, early on in the project -- before anyone even knew about Spectre -- we made the decision that `Date.now()` would not advance during code execution, only when waiting for I/O. So, a tight loop…

1. Thanks for your multiple well-informed, articulate comments.

2. "BSG"?

Re: WebAssembly’s post-MVP future

#176

Post by jaipilot747 »

Certhas wrote: post #174
6nf wrote: post #121

Earlier quoted context omitted.

Do people actually use JS for data sets larger than 4GB in the browser?

I wouldn't be suprised with Jupyter notebooks and all that.

Wouldn't that data be held in the language's kernel? When I load a 4GB file into memory in Jupyter, the memory is allocated in the python kernel, not the browser. Although I guess your point would be valid for iodide.io which seems to run everything in the browser.

Re: WebAssembly’s post-MVP future

#177

Post by chrisweekly »

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?

JavaScript.

Re: WebAssembly’s post-MVP future

#178

Post by steveklabnik »

chrisweekly wrote: post #175
kentonv wrote: post #105

Earlier quoted context omitted.

This is a relatively new recommendation on V8's part specifically in response to Spectre-type vulnerabilities. We've spent a lot of time thinking about and building mitigations for speculative side channel attacks. For example, early on in the project -- before anyone even knew about Spectre -- we made the decision that `Date.now()` would not advance during code execution, only when waiting for I/O. So, a tight loop…

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.

Re: WebAssembly’s post-MVP future

#179

Post by upofadown »

>People have a misconception about WebAssembly. They think that the WebAssembly that landed in browsers back in 2017—which we called the minimum viable product (or MVP) of WebAssembly—is the final version of WebAssembly.

They do? When people point out that WASM can't do stuff they are simply pointing out that WASM would need to be extended. That is a pretty simple concept and a very important observation because historically that is the phase where everything falls apart.

Creating an intermediate language that all the higher level languages can compile to is not a new idea. It has been done over and over again with little practical result. Some current scepticism is in order.

Re: WebAssembly’s post-MVP future

#180

Post by mwcampbell »

int_19h wrote: post #114
tabtab wrote: post #92

Earlier quoted context omitted.

Re: like seeing a flying car advertisement Ditto the feeling. I don't "get" WASM from a typical in-house CRUD development. Game makers, maps, movie editors; sure they need the speed. But some say it's gonna revolutionize most browser-based application dev, but I can't get specific examples that are relevant to us. And even for those domains listed, relying on inconsistent and buggy DOM as found in browser variations…

Between WASM and modern graphics APIs, we might be able to actually kill DOM altogether. Something like this: http://blog.qt.io/blog/2018/05/22/qt-for-webassembly/

Let's not do that until we have a way to make non-DOM-based web applications accessible to screen readers and other assistive technologies.
Post reply on HN