WebAssembly’s post-MVP future • Hacker News Board

Re: WebAssembly’s post-MVP future

#121

Post by 6nf » Tue, Oct 23, 2018, 3:13 AM UTC

Game_Ender wrote: post #84

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…

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?

Re: WebAssembly’s post-MVP future

#122

Post by deathanatos » Tue, Oct 23, 2018, 3:20 AM UTC

zmw wrote: post #117

jholman wrote: post #17

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway... I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS int…

You can access web APIs and access DOM in wasm today (from your comment you seem to be unware of that?). I just wrote a tiny web app in Rust with wasm-bindgen, and it’s pretty good already. With wasm-bindgen interfacing is pretty manual at the moment — you need to declare the APIs you need in Rust by hand, but an app without dependencies that modify the DOM generates a wasm file that’s only a few KB. My app pulls in…

I know wasm-bindgen exists, and I presume it works. But it's black magic.

Near as I can tell, it serializes everything through the linear memory; this would have a huge impact on the performance of both ends, would it not? (Particularly if you wanted to do DOM manip w/ it.) I believe this is what the article means here,

> You need to pass values into the WebAssembly function or return a value from it. This can also be slow, and it can be difficult too.

> There are a couple of reasons it’s hard. One is because, at the moment, WebAssembly only understands numbers. This means that you can’t pass more complex values, like objects, in as parameters. You need to convert that object into numbers and put it in the linear memory. Then you pass WebAssembly the location in the linear memory.

Re: WebAssembly’s post-MVP future

#123

Post by will4274 » Tue, Oct 23, 2018, 3:37 AM UTC

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?

Email services offer 50 gb of data storage for free. It's not so crazy that you'd want to load a substantial portion of that data into memory in an "offline mode" or while doing full text search across the database. Yes, there are probably ways to fit it into 4 gb, but I'm writing this post on a computer with 64 gb of RAM - why not write the next feature instead?

Re: WebAssembly’s post-MVP future

#124

Post by voltagex_ » Tue, Oct 23, 2018, 3:42 AM UTC

will4274 wrote: post #123

6nf wrote: post #121

Earlier quoted context omitted.

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

Email services offer 50 gb of data storage for free. It's not so crazy that you'd want to load a substantial portion of that data into memory in an "offline mode" or while doing full text search across the database. Yes, there are probably ways to fit it into 4 gb, but I'm writing this post on a computer with 64 gb of RAM - why not write the next feature instead?

You and I are in the minority though. The Web is already using too much RAM.

I'm still seeing laptops sold with 4GB which would be used really quickly.

Re: WebAssembly’s post-MVP future

#125

Post by voltagex_ » Tue, Oct 23, 2018, 3:44 AM UTC

AnIdiotOnTheNet wrote: post #54

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…

> 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.

Re: WebAssembly’s post-MVP future

#126

Post by voltagex_ » Tue, Oct 23, 2018, 3:45 AM UTC

thrower123 wrote: post #107

wild_preference wrote: post #93

Earlier quoted context omitted.

Meh, the issue with Electron is performance. The actual dev environment is decent, like how trivial it is to bring your own abstractions like React. Being able to inspect element and use Chrome's debugger. Being able to use whatever text editor you want. Using a compile-to-JS language. etc. I'm certainly not using Xcode + Cocoa + the MVC abstraction for iOS/macOS apps because it's the superior way to build software.…

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.

Re: WebAssembly’s post-MVP future

#127

Post by fulafel » Tue, Oct 23, 2018, 3:52 AM UTC

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?

Browsers don't support it without config flags, so rarely. But there certainly is demand in visualization, games, medical imaging, "data science", etc.

(Also these apps are not necessarily written in JS, it's a compile target too)

Re: WebAssembly’s post-MVP future

#128

Post by edflsafoiewq » Tue, Oct 23, 2018, 4:00 AM UTC

int_19h wrote: post #113

edflsafoiewq wrote: post #70

Earlier quoted context omitted.

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

Because all the better environments are not sufficiently portable. That said, even then, I'll take Qt over Electron any day of the week.

If they're not even portable between established systems, how are we going to port them to a comparatively exotic wasm+DOM target?

Re: WebAssembly’s post-MVP future

#129

Post by ec109685 » Tue, Oct 23, 2018, 4:07 AM UTC

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?

Having 64-bit addresses let you map files and not worry about address space limitations, even if resident size is < 4gb

Re: WebAssembly’s post-MVP future

#130

Post by fulafel » Tue, Oct 23, 2018, 4:16 AM UTC

amelius wrote: post #52

zimbatm wrote: post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

Why not implement the GCs themselves using low-level WASM code? That would enable a language-agnostic approach (though it would prohibit collecting garbage over multiple cooperating languages at the same time, which is a less urgent problem imho).

Yes, the target audience for WebAssembly seems to be performance-conscious application authors who use non-GC'd languages, and unpredictable GC is a headline reason for choosing WS in those circles. So giving authors control over GC would be a fine thing to deliver, it would let real-time app authors still use GC in a controlled fashion.

It could probably be done in a way that allowed multiple GC's to coexist and cooperate.