diff options
| -rw-r--r-- | _posts/2020-02-11-on-webassembly-killing-javascript.md | 9 |
1 files changed, 4 insertions, 5 deletions
diff --git a/_posts/2020-02-11-on-webassembly-killing-javascript.md b/_posts/2020-02-11-on-webassembly-killing-javascript.md index bab3b6e..998c176 100644 --- a/_posts/2020-02-11-on-webassembly-killing-javascript.md +++ b/_posts/2020-02-11-on-webassembly-killing-javascript.md @@ -14,14 +14,14 @@ If you think of WASM strictly as a optimization of JavaScript, that's where you'll end up: WASM is the same as JavaScript, but faster. But there's a more interesting aspect (to me) of it: portability. That means you -can now write multiplatformr code that runs everywhere. I mean, everywhere, even +can now write multiplatforme code that runs everywhere. I mean, everywhere, even in the browser. Let's imagine how you could write SQLite and mke it run on the Web. # SQLite - If I were to create, say, SQLite today, I would consider adding -web support for it. SQLite already is available everywhere[^1]. This is due to -it having very few dependencies and +If I were to create, say, SQLite today, I would consider adding web support for +it. SQLite already is available almost everywhere[^1]. This is due to it having +very so few dependencies, Imagine having writing SQLite today @@ -148,7 +148,6 @@ httpd.serve_forever() ``` Dependency graph: -FIXME api-posix.c api-wasm.js api.h add.h |