Update README

README.md

@@ -6,7 +6,7 @@
 
 
 WAForth is a small bootstrapping Forth interpreter and dynamic compiler for
-[WebAssembly](https://webassembly.org). You can see it in a demo
+[WebAssembly](https://webassembly.org). You can see it in action
 [here](https://mko.re/waforth/).
 
 It is [entirely written in (raw)
@@ -20,15 +20,19 @@ and the I/O primitives to read and write a character to a screen.
 The WebAssembly module containing the interpreter, dynamic compiler, and 
 all built-in words comes down to 13k (6k gzipped), with an extra 7k (3k gzipped) for the JavaScript wrapper and web UI.
 
-WAForth implements all of the [ANS Core
+WAForth implements all [ANS Core
 Words](http://lars.nocrew.org/dpans/dpans6.htm#6.1) (and passes
 [Forth 200x Test Suite](https://forth-standard.org/standard/testsuite)
 core word tests), and several [ANS Core Extension Words](http://lars.nocrew.org/dpans/dpans6.htm#6.2)
 
+You can read more about the internals and the design of WAForth in the [Design
+document](doc/Design.md).
+
+
 ![WAForth Console](doc/console.gif "WAForth Console")
 
 
-## Using WAForth in an application
+## Using WAForth in a JavaScript application
 
 You can embed WAForth in any JavaScript application. 
 
@@ -83,11 +87,11 @@ import WAForth from "waforth";
 Here are some of the goals (and non-goals) of WAForth:
 
 - ✅ **WebAssembly-first**: Implement as much as possible in (raw) WebAssembly. Only call out to JavaScript for functionality that is not available in WebAssembly (I/O, loading compiled WebAssembly code).
-- ✅ **Simplicity**: Keep the code as simple as possible. Raw WebAssembly code requires more effort to maintain than code in a high level language, so avoid complexity if you can.
-- ✅ **Completeness**: Implement a complete (and correct) ANS Forth system, including all the ANS Core words.
-- ❓ **Speed**: If some speed gains can be gotten without paying much in simplicity (e.g. better design of the system, more efficient implementation of words, simple compiler improvements, ...), then I do it. However, generating the most efficient code would require a smart compiler, and a smart compiler would introduce a lot of complexity if implemented in raw WebAssembly, so speed is not an ultimate goal. Although the low level of WebAssembly gives some speed advantages, the design of the system will cause execution to consist almost exclusively of indirect calls to small functions, so high speed isn't to be expected.
+- ✅ **Simplicity**: Keep the code as simple as possible. Raw WebAssembly requires more effort to maintain than code in a high level language, so avoid complexity if you can.
+- ✅ **Completeness**: Implement a complete (and correct) Forth system, following the [ANS Standard](http://lars.nocrew.org/dpans/dpans.htm), including all [ANS Core words](http://lars.nocrew.org/dpans/dpans6.htm#6.1).
+- ❓ **Speed**: If some speed gains can be gotten without paying much in simplicity (e.g. better design of the system, more efficient implementation of words, simple compiler improvements, ...), then I do it. However, generating the most efficient code would require a smart compiler, and a smart compiler would introduce a lot of complexity if implemented in raw WebAssembly, so speed is not an ultimate goal. Although the low level of WebAssembly gives some speed advantages, the design of the system will cause execution to consist almost exclusively of indirect calls to small functions, so there will be languages targeting WebAssembly that run faster.
 - ❌ **Binary size**: Since the entire system is written in raw WebAssembly, and since one of the main goals is simplicity, the resulting binary size is naturally quite small (±12k). However, I don't do any special efforts to save bytes here and there in the code (or the generated code) if it makes things more complex.
-- ❌ **Ease of use**: I currently don't make any effort to provide functionality to make Forth programming easy (helpful errors, ...). However, the compiler emits debug information to help step through the WebAssembly code of words.
+- ❌ **Ease of use**: I currently don't make any effort to provide functionality to make Forth programming easy (helpful errors, ...). However, the compiler emits debug information to help step through the WebAssembly code of words, and I hope to add more debugging aids to the compiler in the future.
 
 ![Debugger view of a compiled
 word](doc/debugger.png "Debugger view of a
@@ -95,15 +99,12 @@ compiled word")
 
 ## Development
 
-You can read more about the internals and the design of WAForth in the [Design document](doc/Design.md).
-
-Below you can find instructions on setting up a development environment.
-
 ### Install Dependencies
 
 The build uses the [WebAssembly Binary
 Toolkit](https://github.com/WebAssembly/wabt) for converting raw WebAssembly
-text format into the binary format, and [Yarn](https://yarnpkg.com) for
+text format into the binary format, and [Yarn](https://yarnpkg.com) (and therefore
+[Node.JS](https://nodejs.org/en/)) for
 managing the build process and the dependencies of the shell.
 
     brew install wabt yarn
@@ -114,11 +115,11 @@ managing the build process and the dependencies of the shell.
 
 To build everything:
     
-    make
+    yarn build
 
 To run the development server:
 
-    make dev
+    yarn dev
 
 ### Testing
 
@@ -126,4 +127,4 @@ The tests are served from `/waforth/tests` by the development server.
 
 You can also run the tests in Node.JS by running
 
-    make check
+    yarn test