docs: update website

1 files changed, 5 insertions, 21 deletions

diff --git a/docs/book/ASYNC.html b/docs/book/ASYNC.html
index af56864..aa1ddf7 100644
--- a/docs/book/ASYNC.html
+++ b/docs/book/ASYNC.html
@@ -7,7 +7,7 @@
 
 
         <!-- Custom HTML head -->
-        
+
         <meta name="description" content="">
         <meta name="viewport" content="width=device-width, initial-scale=1">
         <meta name="theme-color" content="#ffffff">
@@ -190,12 +190,12 @@ let c: T = await async fetch_html()
   ... todo ...
 </code></pre>
 <pre><code class="language-puck">pub func await[T](self: Future[T]): T =
-  while not self.ready:
-    block
+  while not self.ready do
+    # block
   self.value! # apply callbacks?
 </code></pre>
 <p>This implementation differs from standard async/await implementations quite a bit.
-In particular, this means there is no concept of an &quot;async function&quot; - any block of computation that resolves to a value can be made asynchronous. This allows for &quot;anonymous&quot; async functions, among other things.</p>
+In particular, this means there is no concept of an "async function" - any block of computation that resolves to a value can be made asynchronous. This allows for "anonymous" async functions, among other things.</p>
 <p>This (packaging up blocks of code to suspend and resume arbitrarily) is <em>hard</em>, and requires particular portable intermediate structures out of the compiler. Luckily, Zig is doing all of the R&amp;D here. Some design decisions to consider revolve around <em>APIs</em>. The Linux kernel interface (among other things) provides both synchronous and asynchronous versions of its API, and fast code will use one or the other, depending if it is in an async context. Zig works around this by way of a known global constant that low-level functions read at compile time to determine whether to operate on synchronous APIs or asynchronous APIs. This is... not great. But what's better?</p>
 <!-- Asynchronous programming is hard to design and hard to use. Even Rust doesn't do a great job. It *shouldn't* need built-in language support - we should be able to encode it as a type and provide any special syntax via macros. Note that async is not just threading! threading is solved well by Rust's rayon and Go's (blugh) goroutines. -->
 <h2 id="threading"><a class="header" href="#threading">Threading</a></h2>
@@ -204,7 +204,7 @@ In particular, this means there is no concept of an &quot;async function&quot; -
 <p>References:</p>
 <ul>
 <li><a href="https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/">What color is your function?</a></li>
-<li><a href="https://kristoff.it/blog/zig-colorblind-async-await/">What is Zig's &quot;colorblind&quot; async/await?</a></li>
+<li><a href="https://kristoff.it/blog/zig-colorblind-async-await/">What is Zig's "colorblind" async/await?</a></li>
 <li><a href="https://ziglearn.org/chapter-5/">Zig Learn: Async</a></li>
 <li><a href="https://morestina.net/blog/1686/rust-async-is-colored">Rust async is colored and that's not a big deal</a></li>
 <li><a href="https://old.reddit.com/r/elixir/np688d/">Why is there no need for async/await in Elixir?</a></li>
@@ -245,22 +245,6 @@ In particular, this means there is no concept of an &quot;async function&quot; -
 
         </div>
 
-        <!-- Livereload script (if served using the cli tool) -->
-        <script>
-            const wsProtocol = location.protocol === 'https:' ? 'wss:' : 'ws:';
-            const wsAddress = wsProtocol + "//" + location.host + "/" + "__livereload";
-            const socket = new WebSocket(wsAddress);
-            socket.onmessage = function (event) {
-                if (event.data === "reload") {
-                    socket.close();
-                    location.reload();
-                }
-            };
-
-            window.onbeforeunload = function() {
-                socket.close();
-            }
-        </script>