diff options
| author | Dan Gohman <sunfish@mozilla.com> | 2015-07-06 15:39:10 -0700 |
|---|---|---|
| committer | Dan Gohman <sunfish@mozilla.com> | 2015-07-17 15:53:10 -0700 |
| commit | 58d19dcf38405246cd21816bc2ff9a9aa996b385 (patch) | |
| tree | ae77df3cf4558dcdaad45421715710527be4f65e /NonWeb.md | |
| parent | 0d19a06e1e15803ebc729837703a364aea94992e (diff) | |
| download | nanowasm-design-58d19dcf38405246cd21816bc2ff9a9aa996b385.tar.gz | |
Say "on the Web" rather than "in a browser" when talking about Web use cases.
Diffstat (limited to 'NonWeb.md')
| -rw-r--r-- | NonWeb.md | 14 |
1 files changed, 7 insertions, 7 deletions
@@ -1,13 +1,13 @@ -# Non-Browser Embeddings +# Non-Web Embeddings -While WebAssembly is designed to run [within a browser](Web.md), it is +While WebAssembly is designed to run [on the Web](Web.md), it is also desirable for it to be able to execute well in other environments, including everything from minimal shells for testing to full-blown application environments e.g. on servers in datacenters, on IoT devices, or mobile/desktop apps. It may even be desirable to execute WebAssembly embedded within larger programs. -Non-browser environments may provide different APIs than Web +Non-Web environments may provide different APIs than Web environments, which [feature testing](FeatureTest.md) and [dynamic linking](FutureFeatures.md#dynamic-linking) will make discoverable and @@ -18,11 +18,11 @@ library. However, certain features that are core to WebAssembly semantics that are found in native libc *would* be part of the core WebAssembly spec as either primitive opcodes or a special builtin module (e.g., `sbrk`, `dlopen`). -Where there is overlap between the browser and popular non-browser environments, +Where there is overlap between the Web and popular non-Web environments, shared specs could be proposed, but these would be separate from the WebAssembly spec. A symmetric example in JavaScript would be the in-progress [Loader](https://whatwg.github.io/loader) spec, which is proposed for both -browser and node.js environments and is distinct from the JavaScript spec. +Web and node.js environments and is distinct from the JavaScript spec. However, for most cases it is expected that, to achieve portability at the source code level, communities would build libraries that mapped from a @@ -31,7 +31,7 @@ source-level interface to the host environment's builtin capabilities blocks (feature testing, dynamic loading) to make these libraries possible. Two early expected examples are POSIX and SDL. -In general, by keeping the non-browser path such that it doesn't require -browser APIs, WebAssembly could be used as a portable binary format on many +In general, by keeping the non-Web path such that it doesn't require +Web APIs, WebAssembly could be used as a portable binary format on many platforms, bringing great benefits in portability, tooling and language-agnosticity (since it supports C/C++ level semantics). |