Hacker News Reader

You may like Lin Clark's posts on the subject:

https://hacks.mozilla.org/2017/02/a-cartoon-intro-to-webasse...

https://hacks.mozilla.org/category/code-cartoons/

I don't think it is a particularly great explanation of what WASM is.

>> Wait, so what is WebAssembly?

>> WebAssembly is a way of taking code written in programming languages other than JavaScript and running that code in the browser. So when people say that WebAssembly is fast, what they are comparing it to is JavaScript.

A better definition:

> WASM is a binary instruction format for a stack-based virtual machine[1]

This goes into some details that could answer the question raised in this thread:

> WebAssembly modules will be able to call into and out of the JavaScript context and access browser functionality through the same Web APIs accessible from JavaScript.

More useful details:

>> Engineers from the four major browser vendors have risen to the challenge and collaboratively designed a portable low-level bytecode called WebAssembly. It offers compact representation, efficient validation and compilation, and safe low to no-overhead execution. Rather than committing to a specific programming model, WebAssembly is an abstraction over modern hardware, making it language-, hardware-, and platform-independent, with use cases beyond just the Web. WebAssembly has been designed with a formal semantics from the start. [2]

More details from Wikipedia:

>> Wasm does not replace JavaScript; in order to use Wasm in browsers, users may use Emscripten SDK to compile C++ (or any other LLVM-supported language such as D or Rust) source code into a binary file which runs in the same sandbox as regular JavaScript code. ... There is no direct Document Object Model (DOM) access; however, it is possible to create proxy functions for this. [3]

I hope this helps.

1. https://webassembly.org

2. https://dl.acm.org/citation.cfm?doid=3140587.3062363

3. https://en.wikipedia.org/wiki/WebAssembly

I found this [1] quite interesting. It doesn't really answer any of the questions you asked, but I think it gives some interesting insights into WebAssembly, which might make it easier to put other things in context and also give a good low level understanding of it.

It's the closing keynote talk at this year's PyCon India. From the description:

> In this talk, I live-code a simple stack machine and turn it into an interpreter capable of running WebAssembly. I then use that to play a game written in Rust.

https://www.youtube.com/watch?v=r-A78RgMhZU

This was my first Hello World type intro to it.

https://codelabs.developers.google.com/codelabs/web-assembly...

So far, most of the good demos of it seem to be for gaming. But I think once b2b type companies figure out what it's capable of, a lot will change.

Not sure about frontend frameworks, but I was able to successfully write some computational components or components without relevant JavaScript libraries in Rust with wasm-bindgen.

wasm-bindgen docs have some examples to get you started.

https://rustwasm.github.io/docs/wasm-bindgen/

When was the last time you were able to unminify a javascript file that you wanted to investigate and were able to make sense out of it?

Javascript is pretty accessible even when minified and optimised via something like closure.

WASM requires a lot more knowhow to reverse engineer; I've had to do it a few times for CTFs and some blockchain-related tools that use them, and it's a lot trickier compared to JS.

The wat format seems decently readable. You can convert between the two easily unless there’s obfuscation tools already.

Within the last month or two, certainly.

You have to be willing to edit it, start renaming variables to describe what they hold, rename them again if they get something unexpected assigned, rename functions once you have a good idea of what they're trying to do, and repeat until everything has a name.

So it sounds like you're having to reverse engineer it, similar to any "binary blob".

Sounds very "open" to me.

I'm not arguing openness. Merely that minified js can be understood with some effort.

Wasm is very easy to understand. I guess it lacks tools for proper reverse-engineering, to allow defining meaningful names, to use some sane language instead of default Wasm text format, but once tools will be there, it'll be much easier to understand than minified JavaScript because it's so simple.

WebAssembly is a programming language described in this document: https://github.com/WebAssembly/spec/blob/master/papers/pldi2... .

But in practice, WASM files will be exported from one tool automatically, and imported into another tool automatically. It is similar to SVG or PDF. You know what to do with it, but you don't care what is inside (what each character inside means).

Can't speak on the learning resource. I'm not even sure there would be any meaningful resources given the scope of WebAssembly is still entirely niche anyway.

From my (biased) perspective, one of the greatest potentials is for new languages with improved features, syntax, and semantics. These languages can be just as effective as javascript performance-wise to accomplish the same goals, without having to transpile to javascript, which comes with its own real costs. The interest is there, given the 100+ languages that came out as a 'replacement' for JavaScript since its inception. We'll see if language theory can usher in a better language for the web built on WebAssembly.

The other great boon is simply having more performant services or utilities that can be written in any language. If you like C syntax for doing everything non-ui then you can go ahead and write C no problem, and run it on the client's machine. Maybe we'll even get to run fully concurrent client side apps, at which point Java would be a wonderful language to jump into those capabilities, given they have a robust handle on it from a language standpoint.

WebAssembly and the Future of the Web (2018) https://www.youtube.com/watch?v=JWCr9vcpl3w

WebAssembly In Action (2017) https://www.youtube.com/watch?v=DKHuEkmsx3M

There's a nice video "WebAssembly In Action" here: https://www.youtube.com/watch?v=DKHuEkmsx3M

I am there with you, right now as I understand it it's used in very specific parts where you need performance you cannot get otherwise.

> not sure how this plays out in a practical sense / relative to the state of web applications as they are now.

How I see it it either there will be one big framework (or language) that will have all the things and compiles to WebAssembly or there will be JavaScript libraries that ship compiled WebAssembly which you can interface with.

We are still a long way from having a React like framework which compiles to WebAssembly let alone a thriving community for it.

Just take a look at Blazor for education-by-example. It's a framework like React&friends, but in C#, running in the browser via wasm. Build a SPA in C# - as practical as you can get.

If I'm already proficient with React+JS, what's the benefit of this besides using other languages?

The benefit would be not just a different language but the entire .NET ecosystem. If that ecosystem holds no compelling benefit for you, then I guess nothing. I was just answering OP's question looking for a concrete understanding of what wasm could do.

How is that helpful to explain what WebAssembly is? Anyway Blazor can (or at least used to) transpile to JS, so it's not like WebAssembly was required for Blazor to be a reality.

I just recently learned a lot about it just by reading spec and few articles on MDN. Wasm is an extremely simple bytecode, very similar to Java bytecode. You can even write it by hand.

Basically you're supposed to use it for some performance-critical parts in your application. You're not supposed to use it instead of React.

> Does anyone have any good intro resources for WebAssembly for noobs?

Wasm proper isn't really a technology for noobs. This is like asking "Does anyone have an introduction to x86_64 machine code, the ELF linker spec and the SysV ABI for noobs?". It's sort of the wrong part of the problem. What you want in that case is "C programming on linux for noobs".

So try googling for "emscripten tutorial" or (if you swing closer to rust) "wasm-bindgen tutorial". There are lots of other languages with wasm targets too, but quality tends to vary a lot.

But really IMHO the reason to use wasm isn't performance. Javascript interpreters are REALLY good these days for routine code. You use wasm when you need to target a big codebase in some other language to a browser, either because it's already written or because the problem area for the code isn't well suited to JS.

That sounds like the use case would be to insert some WASM component (that is a big heavy application / operation) into traditional web application framework as needed.

Less so an entire overhaul of web applications as it is a powerful tool to be deployed for things we don't do in the browser now because there is no way to / it would be a bear to do in JavaScript due to ... JavaScript being JavaScript ;)

Of course the amount of WASM to traditional JS or anything else could vary from application to application.

Granted we're predicting the future here so obviously it could be off.

Really the only available use case is inserting a wasm component into a traditional web application framework. Wasm code can only be loaded from JS, it can only be invoked from JS, and it's only way to affecting the world outside the VM is to call functions in JS that are going to do something to a user-visible DOM.

This is all still traditional web development. It's just a way to target other runtimes to a sandbox in the same environment.

>Wasm code can only be loaded from JS, it can only be invoked from JS, and it's only way to affecting the world outside the VM is to call functions in JS that are going to do something to a user-visible DOM.

Incorrect. WASM was designed from the beginning to be run both on and off the web[0], and native clients already exist[1].

[0]https://webassembly.org/docs/non-web/

[1]https://github.com/mbasso/awesome-wasm#non-web-embeddings

Actually with the WebAssembly System Interface you can interface WebAssembly with any platform, it doesn't need to be a javascript vm. https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...

> If you can't explain it simply, you don't understand it well enough.

Albert Einstein