diff --git a/README.md b/README.md
index 36dee44..39e5270 100644
--- a/README.md
+++ b/README.md
@@ -48,7 +48,7 @@ sudo npm install -g typescript
 
 ## Compiling Code
 
-Netjs works with .NET assemblies built with any compiler ([limitations][Limitations] not withstanding).
+Netjs works with .NET assemblies built with any compiler ([limitations](#Limitations) not withstanding).
 
 ### Compile to TypeScript
 
@@ -117,7 +117,7 @@ Since all the references and assignments of all fields with accessors, including
 
 ## Philosophy
 
-[History][] is filled with other IL to JS compilers, why Netjs?
+[History](#History) is filled with other IL to JS compilers, why Netjs?
 
 Because I am not happy with the JavaScript generated by current solutions.
 
@@ -183,10 +183,11 @@ When it comes time to use the Person class from JavaScript, that code should als
 
 Netjs is not the first project that compiles .NET IL to JavaScript. It is, in fact, my second attempt at such an app. The first worked, but wasn't good enough for release.
 
-Microsoft built their own named Project V. It was glorious, as was the amount of JavaScript it created. "Hello world" generated gigabytes of JavaScript. Serisously, I once calculated that the heat death of the universe would occur before it had finished outputting a foreach loop. You see, the JavaScript it output rigorously obeyed .NET semantics - it was as if a virtual machine vomitted all over your code. Glorious. Anyway, Microsoft cancelled the project.
+Microsoft built their own named Project V. It was glorious, as was the amount of JavaScript it created. "Hello world" generated gigabytes of JavaScript. Seriously, I once calculated that the heat death of the universe would occur before it had finished outputting a foreach loop. You see, the JavaScript it output rigorously obeyed .NET semantics - it was as if a virtual machine vomitted all over your code. Glorious. Anyway, Microsoft cancelled the project.
 
-Then the world was blessed with [JSIL][]. This is Project V done right. It's still a virtual machine vomitting all over your code, but it's a clean nice kind of vomit that is measured in megabytes instead of gigabytes. It's powerful enough to compile the BCL and MonoGame - a truly powerful compiler. It's going to generate a lot code and you're might end up with a loading screen, but it does its job well.
+Then the world was blessed with [JSIL][]. This is Project V done right. It's still a virtual machine vomitting all over your code, but it's a clean nice kind of vomit that is measured in megabytes instead of gigabytes. It's powerful enough to compile the BCL and MonoGame - a truly powerful compiler. It's going to generate a lot code and you might end up with a loading screen, but it does its job well.
 
+If your primary goal is portability, you may want to consider the [WebAssembly](https://webassembly.org) SDK for the Mono Project.
 
 ## Limitations
 
@@ -197,11 +198,15 @@ Then the world was blessed with [JSIL][]. This is Project V done right. It's sti
     - Overloads that have the same argument count and accept values that can be null (runtime type checking is used)
     - Overloaded constuctors that call different base constructors probably don't work
 * **Async** does not work
-* **Gotos** only sometimes work
+* **`continue`**, **`break`**, and **`goto`** only sometimes work
 * **Regexes** have some problems:
     - Named groups don't work (we rely on the browser's regex implementation)
     - Match Group Index only works if you capture everything
-* Integer casts with the expectation of performing a Truncate operation don't work ()
+* Integer casts with the expectation of performing a Truncate operation don't work
+* Default values for interfaces don't work
+* Auto-implemented, mixed property accessors don't work, e.g. `public float TopSpeed { get; }`
+* **Lambdas** often cause issues where a loop can be used
+* **Method chaining** tends to result in unrecognized function calls
 * **Seriously,** watch it with those overloads
 
 If any of these bother you, then please go use [JSIL][].