Hacker News Reader

Comment by kodablah | Hacker News Reader

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 please, but dev'd outside of WebAssembly. This is needed for interoperability between languages. Even just strings would be nice. A stdlib interface to rule them all, so to speak. If kept modular and avoided a lot of bikeshedding and had a full test suite, it could have a great benefit even outside of WASM.

View on HN

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 reference builds that would be bundled to the browser, and if anyone loaded a resource with an integrity hash matching the browser's pre-installed versions, it could just load from disk instead. That would give people who can tolerate less frequent library releases the ability to use all that functionality without networking related page load costs, and would provide a fallback since CDN's could host the file anyway if the browser doesn't have it.

You can probably build a poor man's version with Subresource Integrity and the DecentralEyes plugin.

https://decentraleyes.org/

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.

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.

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.

It is hard to imagine a tool less suited to working with multi-gigabyte data sets than JavaScript.

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.

Non-browser programming platfomrs terrible portability stories when your app needs many features from the platform, like accelerated graphics, networking, security etc.

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.

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)

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

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.

Good point.

https://github.com/CommonWA/cwa-spec

I've been following wasmjit quite closely and they are implementing a PWSIX interface for WebAssembly.

Reply on news.ycombinator.com