Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm interested to see what the API side of WebAssembly looks like in browsers; hopefully this will make it easier to expose more full-featured sandboxed APIs to languages targeting the web, without having to tailor those APIs to JavaScript. For instance, API calls that actually accept integers and data structures rather than floating-point and objects.

For that matter, though in the short-term this will be polyfilled via JavaScript in browsers, it'll be fun to see the first JavaScript-to-WebAssembly compiler that allows you to use the latest ECMAScript features in every browser.



The API story for wasm on the web is the set of existing web APIs. That provides the same security model and capabilities as the web has right now.

Currently wasm can't access web APIs except by calling out to JS, which would then call the API, but in the future, direct calling paths are intended.


My hope is that WebAssembly will start motivating a set of lower-level APIs, with higher-level APIs being provided on top of those by WebAssembly "libraries". JavaScript tends to motivate much higher-level APIs, and you can't turn high-level APIs into low-level APIs, only the other way around.


This seems orthogonal to WebAssembly. This is already a goal for its own sake--see the Extensible Web Manifesto.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: