From 9c2e6fd1338a5c03b2f4ba17d9b7dbe6fca08046 Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Sun, 16 Feb 2020 13:22:02 -0300 Subject: Tweak --- _posts/2020-02-11-on-webassembly-killing-javascript.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) (limited to '_posts') 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 -- cgit v1.2.3