Clarify that WebAssembly doesn't depend on JS

NonWeb.md

@@ -1,28 +1,32 @@
-# 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
 usable.
 
+Non-Web environments may include JavaScript VMs (e.g. node.js), however
+WebAssembly is also being designed to be capable of being executed without a
+JavaScript VM present.
+
 The WebAssembly spec will not try to define any large portable libc-like
 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 +35,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).

Web.md

@@ -1,7 +1,8 @@
-# Browser Embedding
+# Web Embedding
 
 Unsurprisingly, one of WebAssembly's primary purposes is to run on the Web,
-embedded in Web browsers (though this is [not its only purpose](NonWeb.md)).
+for example embedded in Web browsers (though this is
+[not its only purpose](NonWeb.md)).
 
 This means integrating with the Web ecosystem, leveraging Web APIs, supporting
 the Web's security model, preserving the Web's portability, and designing in