Explain the State of WebAssembly to Me

twitter logo github logo ・1 min read

Explain JavaScript (5 Part Series)

1) Explain React to Me 2) Explain Vue to Me 3) Explain Angular to Me 4) Explain the Frontend Webdev Ecosystem to Me 5) Explain the State of WebAssembly to Me

I'm not looking for an explanation of WebAssembly, but more the WebAssembly ecosystem. What kind of support structure is in place for the technology as of November 2019?

twitter logo DISCUSS (16)
markdown guide
 

Angular - When mommy packs you a Lunchable for lunch
React - When mommy packs you lunch but forgets the pudding
VueJS - When mommy packs you leftover pizza for lunch
Mithril - When mommy packs you multiple Nutrigen bars for lunch
Svelte - When mommy packs what she calls a "better lunch" but you don't eat it because you just want what you're used to eating.
WebAssembly - When mommy has you make and pack your own lunch

 

I knew there was a reason I loved React. And WebAssembly seems really interesting, I like cooking.

 

So you're saying VueJS is the best? Or you only use it on Wednesdays?

 

I haven't followed it closely and it's on my TODO to learn, but this interesting Tweet just popped into my timeline.

 
 

WebAssembly is an open-standard, stack-based VM that includes: a bytecode format, an S-expressions text-based format, among other things. One can implement a VM in whatever language they chose, and be running WASM modules in that language. It's one of the most portable executable bundle formats due to its adoption. Despite its name, it is not limited to running only on the web (Google "Mozilla WASI", for example).

This means that one can write code in whatever source-language, bundle it into a WASM module, and begin executing it in various environments.

It does have limitations: the largest one, for example, is that the spec does not include a garbage collector, so the best source-languages for WASM (right now) are Rust/C++.

I look forward to (soon) being able to write Rust that can be imported into NodeJS, Python, etc. What is not clear to me, however, is how to expose APIs that my WASM module will need to the underlying code, without manually injecting it.

 

This is on my todo list this weekend. Using WABT (github.com/WebAssembly/wabt) create a WebAssembly Binary for my Conway's Game of Life calculation, and see how much faster it can be in WASM vs plain Js.

More or less my plan is to create a WAT file (a textual representation of a WASM binary) use the WABT's wat2wasm tool to create the module, and then call that module in my current Game of Life implementation.

There are other ways to compile to WASM, but using WABT seemed the most friendly initially, because I don't know much about C, C++, or Rust.

 

Ever thought of the web browser as an operating system just like Windows / Linux?

That's what web assembly is about, so that now we can use languages like C or Rust.

Why:

FASTER PERFORMANCE.

Use Cases:

Heavy desktop apps or games

 

For me it's not really about performances.

Most of the slowness of in-browser apps isn't because of JavaScript but because of bad designs, of bad frameworks, of bugs like memory leaks, of developers badly understanding how a browser computes and renders things.

For me it's about correctness and code ergonomics.

That's why my next in-browser application will probably be in Rust/Wasm.

 

Hmmm, so you tell me that it is possible to create a performance-greedy game like GTA V in the browser?

This isn't the usual use case, so I wasn't really answering this problem.

For such a game, the problem is also less the language (but it matters, yes) than the underlying solution to render on screen. Even with webassembly you still have no direct access to low level primitives, best you can do is using webgl.

Well, I see it as the main problem webassembly is solving...

Since as you mentioned already, most apps are slow cuz of bad code.

But webassembly is here to let you write desktop-like performant apps/games.

Here are some discussions in this regard: github.com/WebAssembly/WASI/issues/53

 

A very nice example is squoosh.app/
You compress images right in your browser. Image compression is a very intensive task. Here it is performed using web assembly modules so it is fast and doesn't slowdown your browser

 

WebAssembly is promising defiantly for porting games to the web it is the way,
however will it kill JavaScript I doubt, everyone is talking because no one likes JavaScript and everyone hopes WebAssembly will replace it, so they can use the language they already know.

The current support looks like this:

few insights about above

  • Emscripten is mostly about converting existing C++ apps.
  • TeaVM is awesome and maybe most promising, they have their framework and it works teavm.org/live-examples/todomvc/#/ the size is small and it is a viable alternative even today, it is not only for porting existing apps. Poor documentation.
  • Blazor is a joke, it downloads 2.5mbs of file always, adds about 2 seconds for loading of each page even static and on top of that on the server side it keeps state for every connected client so scales so so badly. As everything Microsoft ever written: nice for a demo, but nothing more.

For me the most promising are TeaVM (Java, Kotlin) and GO as it has official support (even as beta)

More info about other languages:

stackoverflow.com/questions/435408...

 

Regarding WASM... At least ... In regard to the state of joining Facebook groups about Web Assembly boils down to people that deeply hate javascript so it pretty much blows any good learning experience you can get out of those groups on fb, and I joined them all, and it always devolved into WASM vs Javascript and how much many of the folks that actually talk in those groups have devout hatred toward the language Javascript. After 25 years coding the web, it was my first ever experience being called a "hack" was in a WASM group... TLDR; WASM is slowly moving forward and is being spear-headed mostly by elitists who say things like "This is how the web should work.. " more than once... Full Disclaimer, ive watched exactly 3 tutorials averaging 3 hours each, and have high hopes for compiled browser apps and this standard known as WASM.

 
Classic DEV Post from Jul 29 '17

There is No U in CRUD

REST is built around the concept of

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. He/Him.