5 ms·

Here's a newly created proposals repo to keep track: https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals. > Skill: 64-bit address

Here's a newly created proposals repo to keep track: https://github.com/WebAssembly/proposals 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.

PowerfulWizard 8y ago
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.
- Immortalin 8y ago
  You can probably build a poor man's version with Subresource Integrity and the DecentralEyes plugin. https://decentraleyes.org/ https://decentraleyes.org/
- iainmerrick 8y ago
  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.
  - PowerfulWizard 8y ago
    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.
comesee 8y ago
I've been following wasmjit quite closely and they are implementing a PWSIX interface for WebAssembly.
TomMarius 8y ago
https://github.com/CommonWA/cwa-spec https://github.com/CommonWA/cwa-spec
Game_Ender 8y ago
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.
- dmitrygr 8y ago
  It is hard to imagine a tool less suited to working with multi-gigabyte data sets than JavaScript.
  - bloomer 8y ago
    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?
    - jholman 8y ago
      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.
      - denniskane 8y ago
        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!
    - fulafel 8y ago
      Non-browser programming platfomrs terrible portability stories when your app needs many features from the platform, like accelerated graphics, networking, security etc.

PowerfulWizard 8y ago

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.

Immortalin 8y ago
You can probably build a poor man's version with Subresource Integrity and the DecentralEyes plugin. https://decentraleyes.org/ https://decentraleyes.org/
iainmerrick 8y ago
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.
- PowerfulWizard 8y ago
  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.

comesee 8y ago

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

TomMarius 8y ago

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

Game_Ender 8y ago

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.

dmitrygr 8y ago
It is hard to imagine a tool less suited to working with multi-gigabyte data sets than JavaScript.
- bloomer 8y ago
  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?
  - jholman 8y ago
    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.
    - denniskane 8y ago
      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!
  - fulafel 8y ago
    Non-browser programming platfomrs terrible portability stories when your app needs many features from the platform, like accelerated graphics, networking, security etc.