
WebAssembly 101: A developer’s first steps - blaze33
http://blog.openbloc.fr/webassembly-first-steps/
======
almostdigital
I recommend anyone wanting to experiment with WASM to check out
[https://github.com/dcodeIO/webassembly](https://github.com/dcodeIO/webassembly)
which takes a lot of pain out of setting up the toolchain and lets you produce
much leaner binaries as well.

Also keep an eye on
[https://github.com/dcodeIO/AssemblyScript](https://github.com/dcodeIO/AssemblyScript)
:)

~~~
reedlaw
How about
[https://github.com/WebAssembly/binaryen](https://github.com/WebAssembly/binaryen)
?

~~~
floatboth
It's a lower level tool that's used by most things, including the linked
project.

------
AriaMinaei
I wonder how it would be, had capability-based system architectures taken off
and become mainstream. I guess we wouldn't need WebAssembly to run untrusted
code safely, because in such a system, all objects – from whole programs to an
object as small as the number 4 – would be safe and sealed off from each other
on a hardware level.

I'm reading Capability-Based Computer Systems [0] by Henry M. Levy (1984),
motivated by wanting to learn about the Burroughs B5000 that Alan Kay has
praised multiple times. I've only started to learn about these things and I
don't understand the implications, but if I'm reading it correctly, such
architectures would obviate the need for web-style safety measures such as
process-sandboxing ala Chrome, shader sanitizing ala WebGL, etc, because
everything in the system would be safe that way.

[0]
[https://books.google.de/books/about/Capability_Based_Compute...](https://books.google.de/books/about/Capability_Based_Computer_Systems.html?id=eT6eBQAAQBAJ&redir_esc=y&hl=en)

More about this: [https://en.wikipedia.org/wiki/Capability-
based_security](https://en.wikipedia.org/wiki/Capability-based_security) and
[https://en.wikipedia.org/wiki/Capability-
based_addressing](https://en.wikipedia.org/wiki/Capability-based_addressing)

~~~
akavel
You may like browsing through comments by @nickpsecurity (e.g.
[https://news.ycombinator.com/threads?id=nickpsecurity&next=1...](https://news.ycombinator.com/threads?id=nickpsecurity&next=14474149),
etc.). He's _really_ knowledgeable about this stuff, and tries to popularize
it as much as he can.

~~~
thingification
On display in the bottom of a locked filing cabinet stuck in a disused
lavatory with a sign on the door saying ‘Beware of the Leopard.”, is this
mailing list:

[https://groups.google.com/forum/#!forum/cap-
talk](https://groups.google.com/forum/#!forum/cap-talk)

~~~
akavel
Ah; more off-topic than not, but this reminded me of another fairly obscure,
yet super interesting mailing list — The Risks Digest, on air since 1985:

[https://catless.ncl.ac.uk/Risks/](https://catless.ncl.ac.uk/Risks/)

------
jordigh
Remember when you could hit "View Source" to see how the web was built? I
don't like where this is going. Minification was bad enough, now we're going
to be getting more non-free blobs shoved into our browsers and this is being
touted as a great new feature for us.

It will end up being a tool of control and surveillance like always.

This guy says it a bit more eloquently than I can:

[https://lobste.rs/s/wjtu7c/webassembly_mozilla_won#c_yqsej7](https://lobste.rs/s/wjtu7c/webassembly_mozilla_won#c_yqsej7)

~~~
Houshalter
Bullshit. Wasm can't do anything js can't. Especially with asm.js. Don't try
to argue that minified or transpiled js is somehow more readable than wasm. At
least it's easier to decompile in theory.

It's absolutely not a "tool for surveillance". How exactly are you going to
surveil anything with it?

It's not even a replacement for js, or at least it shouldn't be used that way.
No GC for instance. And if you are doing any of the silly things mentioned in
your link you have no one to blame but yourself. Like accepting binary blobs
without source from contractors.

The link eventually admits you can't do a lot of stuff with js and should use
native code. Great, lets just have everyone download and execute untrusted and
unsandboxed code. In a way that is completely incompatible across platforms.
Maybe we can maked them locked behind "walled gardens" with a ridiculous tax
while we're at it. Future generations will laugh at us from their completely
wasm based PCs.

Or we can always go back to the old way of doing anything interesting with a
browser. By making proprietary, vulnerability ridden plugins. Don't you just
miss the days of flash and java applets? Because surely that was a much better
solution than wasm.

~~~
buu700
Yep. WebAssembly today is literally just a better/faster asm.js.

The argument against it linked above is nonsense. Most arguments like this
that I see tend to fall into one of these boxes:

1\. Using wasm as springboard to argue against something else they don't like.

— e.g. disliking closed source code / source obfuscation / minification is a
fair position, but it's not helpful to anyone to pretend that wasm introduces
anything different here (as has been pointed out, wast's inclusion of type
information actually makes it slightly _more_ readable than minified JS).

2\. Arguing against something that wasm could maybe one day become.

— Right now wasm doesn't enable anything​ you can't already do with​ asm.js,
so the idea that it somehow kills JavaScript or whatever is wrong; anything
that can compile to wasm can compile to asm.js. Sure, maybe one day wasm will
gain DOM/GC/etc. functionality, but asm.js could just as easily gain a lot of
the same proposed features. (And wasm/asm.js aside, plenty of languages
already compile to JS quite successfully; this hypothetical future wasm would
just make them faster.)

3\. Seeming to have only a vague sense of what wasm actually is. I think
arguments like #1 and #2 have led to a set of talking points that don't at all
reflect reality but sound correct to developers who don't have direct
experience with asm.js/wasm.

— e.g. the argument from the linked Lobsters comment that "It solves problems
that we don’t have. ... If performance is the important thing you pull on your
big kid pants and write C/C++/D/Rust and if ... performance isn’t important,
you just write in JS." neatly summarises exactly the point of wasm while
somehow trying to frame it as an argument against it.

~~~
angersock
And asm.js wasn't the correct answer either. Nor is minification, as is
pointed out in my original comment.

On (1), you're ignoring the fact that asm.js/wasm/low-level languages are in
general harder to reverse than uglified high-level stuff. You can see the
details perfectly, sure, but emitted compiled code (say, from Duff's device or
something) is a lot harder to back out of than the equivalent minified source
code--especially when you see crazy shit like "-O 3" would make. tl,dr;
compilation != minification, and acting like they are is at best incorrect.

Your (2) fails to address the entire complaint about wasm (aka asm.js) leading
to bad things and ecosystem bloat. You just say "well we can kinda already do
it", but fail to address any of the substance of the actual argument I made.

Your (3) misses the point completely about "write in native code" and not
"write in something that gets run in an interpreter". Like, you've missed the
whole point that if you need performance, _you need to be writing something
outside the browser_ , and if you don't need performance _existing JS is
sufficient_.

~~~
buu700
1\. Yeah, sorry, I was really speaking in general terms here and should've
been more clear about that, as your argument was explicitly that it's just
another step in a pre-existing wrong direction, not a big horrible thing all
its own. re: wast vs minified JS, the specific comparison I had in mind was
with asm.js code, which (minified or not) is from what I've seen less readable
than wast.

Generally speaking, my point here was that I think some arguments against wasm
conflate a pre-existing state of affairs that aren't liked with the delta that
wasm introduces.

2\. Hm, yeah, fair enough. In my mind this all boiled down to "the only
significant direct effect of wasm is to make what we're already doing faster",
which in itself is obviously good; but that was coming from my bias of being a
fan of asm.js, and ignored the other long-term impacts that would inherently
come with enshrining all that extra machinery — even just politically blessing
what asm.js already accomplishes in most browsers as the officially sanctioned
new normal in all browsers isn't _nothing_ if you think it will at least
politically help in pushing things further in a bad direction.

I'll have to reread your and other arguments against wasm with a more open
mind less stuck on the immediate delta.

And yeah, actual _harmfulness_ or lack thereof aside, it wouldn't help anyone
for all this effort and API surface expansion to go into building out a
feature that didn't add value ("ecosystem bloat"), so that's a fair point.

3\. I got what you meant by that, although on the first read it also sounded
like there was some sort of misunderstanding (mostly combined with the "bad
vendor incentives​" section — it wasn't clear why a vendee would be more
likely to accept compiled wasm without source code than minified/obfuscated
JS). In any case, I don't see why being required to leave the browser for
performance-sensitive code should be considered a feature and not a bug. Wasm
presents a very convenient method of sandboxing untrusted code with a high
performance requirement.

Agreed that this isn't a concern for typical CRUD apps or documents (although
I imagine CRUD apps will ultimately benefit in the form of frontend JS
frameworks incorporating wasm in critical paths), and I know I'm definitely in
the minority being a beneficiary of asm.js/wasm. However, it's a bit late at
this point to unmake all the more complicated applications we've built on the
web, and all wasm does is improve a subset of those applications that already
exist (as opposed to enabling entirely new applications), so I don't think
this is a good argument against it.

------
ThePhysicist
I'm trying to use asm.js to port Python to JS as a shared library, which would
allow us to load and run arbitrary CPython modules (compiled for JS) in the
browser. I generate code using emscripten, which is also able to generate WASM
(which I'm not using at the moment though).

My experience so far:

Emscripten is quite mature and compiles even very complex C/C++ code without
complaining. Statically linking code works fine, while dynamically loading
shared libraries is still a bit problematic it seems.

Here's the Github project btw, help is very welcome:

[https://github.com/adewes/cpython-
emscripten](https://github.com/adewes/cpython-emscripten)

~~~
kebolio
Slightly disconcerted that the first thing webdevs are rushing to do with wasm
is to port massive language runtimes to it, continuing the web tradition of
piling shit upon shit upon shit. Personally believe that this is totally the
wrong idea; compilation or transpilation from intermediate forms is far more
interesting and sensible in my view

~~~
pitaj
It's not like people are planning on using these in production. It's just some
fun hobby projects that are useful for, say, online Python tutorials and
stuff.

~~~
elcritch
Well actually, I would. But not for webapps.

There's a fairly large class of scientific computing oriented apps where
having a widely deployed and fast VM with CPython compatibility would be
fantastic. Python (for better or worse) has a large library of open source
computational libraries, but shipping an embedded CPython VM is a pain. As an
example, I helped advise an undergrad working on a program to calculate
collagen fiber orientation for biomedical research labs. Figuring out cxfreeze
or other Python packaging systems took longer than writing the actual app.

Unfortunately JavaScript doesn't have broad scientific library support and
grad students in non-CS fields don't always have the time to become versed
enough in C/C++ to create a usable app. So CPython & associated C libraries
ported to wasm could be quite useful... This could apply to R programs as
well.

Re: grandparent, just because a project offends your sense of purity doesn't
mean it isn't surprisingly valuable for others.

------
DamonHD
Nice!

With a BBC Micro (6502, 1MHz) I was able to achieve about the same FPS (I was
genlocked for UK PAL TV transmission so either 25FPS or 50FPS) but only for a
40x25 grid, using 6502 assembler embedded in BASIC!

~~~
kranner
Much as I miss the Beeb, this is completely irrelevant.

~~~
ABNWZ
... I don't share your sentiment at all. I find this relevant to the subject
matter as he is, albeit indirectly, mentioning the performance of WASM. I
would be surprised if you got the same performance using just plain old js on
the hardware he is referencing.

~~~
tomxor
The JS/WASM may be limited to 60FPS if it is being forced to draw every frame,
in which case it has to wait for the browser, it may be much faster.

CA are great fun to optimise, i've found ways to make them very fast in JS
alone, by using pure state machine method with TypedArrays and sliding window
algorithm. When letting it skip frames (only drawing when a frame is
available) it can go far beyond generations per second... when you get to
larger grids the ultimate optimisation is to use FFT, but on smaller ones
there is too much overhead and sliding window is way faster.

Algorithmic optimisation is always better, but this demo works for the purpose
of showing basic WASM compilation which was the authors intent, there may be
an order of magnitude improvement if a different implementation was used.

------
Cakez0r
Not very reassuring that two of the first steps are "copy and paste this stuff
from stack overflow to make it work", without any explanation as to why it's
needed.

~~~
RubenSandwich
Agreed. Setting up the environment with 0's seems like it should just be the
sane default:

    
    
      'env': {
            'memoryBase': 0,
            'tableBase': 0,
            'memory': new WebAssembly.Memory({initial: 256}),
            'table': new WebAssembly.Table({initial: 0, element: 'anyfunc'})
          }
    

But it is really early on and if the Portable updating SDK is any indication
it seems like they want to make it easy to get started.

------
mediocrejoker
I was disappointed that this doesn't really explain what webassembly is, and
the link that says 'if you don't know what webassembly is, click here' just
redirects to a tank game with no explanation.

I thought maybe it was some way to write x86 assembly in the browser, but
apparently it's a tank game.

~~~
blaze33
Thanks for the feedback, I should probably link to
[http://webassembly.org/](http://webassembly.org/) instead and link demos
after this.

------
BenoitEssiambre
I wonder where the world is going with this. At first glance it looks like
webassembly is a potential faster replacement for javascript in the browser.
However, javascript is an increasingly popular language everywhere. I'm not
sure people will want to move away from it for most development. The part that
is actually causing performance problems with web application is the
HTML/CSS/DOM layer which was not designed as a UI widget library but as a
document rendering and styling framework.

Webassembly/Webgl standardization enables the creation high performance
replacements for HTML/CSS/dom.

We might end up with applications that are still mostly written in javascript
but that call into new webassembly/webgl ui frameworks for rendering instead
of into the html/css/dom layer.

~~~
snarfy
> I'm not sure people will want to move away from it for most development.
    
    
        x = 1 + '2' //12
        x = 1 - '2' //-1
    

Oh yes, yes we do.

~~~
jswny
I mean, I agree with you but that's not even that bad of an example. I would
expect many languages to do something similar. Something like this might be a
better example:

    
    
        "\t\r\n" == 0                 → true
        "\t\r\n 16 \t\r\n" == 16      → true
        "\t\r\n 16 \t\r\n" == "16"    → false

~~~
smitherfield
_> I would expect many languages to do something similar._

Of the common dynamic languages I can think of, the only ones that do
something similar are Perl/Perl6 and PHP, and even they are still saner than
JS.

    
    
        $ $((1+\2))
          bash: 1+\2: syntax error: operand expected (error token is "\2")
        $ $((1-\2))
          bash: 1-\2: syntax error: operand expected (error token is "\2")
        $ ruby -e"1+'2'"
          -e:1:in `+': String can't be coerced into Integer (TypeError)
          from -e:1:in `<main>'
        $ ruby -e"1-'2'"
          -e:1:in `-': String can't be coerced into Integer (TypeError)
          from -e:1:in `<main>'
        $ python3 -c"1+'2'"
          Traceback (most recent call last):
            File "<string>", line 1, in <module>
          TypeError: unsupported operand type(s) for +: 'int' and 'str'
        $ python3 -c"1-'2'"
          Traceback (most recent call last):
            File "<string>", line 1, in <module>
          TypeError: unsupported operand type(s) for -: 'int' and 'str'
            >>> exit()
        $ python2 -c"1+'2'"
          Traceback (most recent call last):
            File "<string>", line 1, in <module>
          TypeError: unsupported operand type(s) for +: 'int' and 'str'
        $ python2 -c"1-'2'"
          Traceback (most recent call last):
            File "<string>", line 1, in <module>
          TypeError: unsupported operand type(s) for -: 'int' and 'str'
        $ perl -e'print 1+"2"."\n"'
          3
        $ perl -e'print 1-"2"."\n"'
          -1
        $ perl6 -e"say 1+'2'"          
          3
        $ perl6 -e"say 1-'2'"
          -1
        $ php -r'echo 1+"2","\n";'
          3
        $ php -r'echo 1-"2","\n";'
          -1
        $ racket -e '(+ 1 "2")'
          +: contract violation
            expected: number?
            given: "2"
            argument position: 2nd
            other arguments...:
             1
        $ racket -e '(- 1 "2")'
          -: contract violation
            expected: number?
            given: "2"
            argument position: 2nd
            other arguments...:
             1
        $ sbcl
          This is SBCL 1.3.18, an implementation of ANSI Common Lisp.
          More information about SBCL is available at <http://www.sbcl.org/>.
    
          SBCL is free software, provided as is, with absolutely no warranty.
          It is mostly in the public domain; some portions are provided under
          BSD-style licenses.  See the CREDITS and COPYING files in the
          distribution for more information.
          * (+ 1 "2")
    
          debugger invoked on a TYPE-ERROR in thread
          #<THREAD "main thread" RUNNING {1001F0EC33}>:
            The value
              "2"
            is not of type
              NUMBER
            when binding SB-KERNEL::Y
    
          Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
    
          restarts (invokable by number or by possibly-abbreviated name):
            0: [ABORT] Exit debugger, returning to top level.
    
          (SB-KERNEL:TWO-ARG-+ 1 "2") [external]
          0] 0
    
          * (- 1 "2")
    
          debugger invoked on a TYPE-ERROR in thread
          #<THREAD "main thread" RUNNING {1001F0EC33}>:
            The value
              "2"
            is not of type
              NUMBER
            when binding SB-KERNEL::Y
    
          Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
    
          restarts (invokable by number or by possibly-abbreviated name):
            0: [ABORT] Exit debugger, returning to top level.
    
          (SB-KERNEL:TWO-ARG-- 1 "2") [external]
          0] 0
    
          * (exit)
        $ erl
          Erlang/OTP 19 [erts-8.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]
    
          Eshell V8.3  (abort with ^G)
          1> 1+"2".
          ** exception error: an error occurred when evaluating an arithmetic expression
               in operator  +/2
                  called as 1 + "2"
          2> 1-"2".
          ** exception error: an error occurred when evaluating an arithmetic expression
               in operator  -/2
                  called as 1 - "2"
          3> halt().
        $ elixir -e '1+"2"'
          ** (ArithmeticError) bad argument in arithmetic expression
              :erlang.+(1, "2")
              (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6
              (elixir) lib/code.ex:170: Code.eval_string/3
    
        $ elixir -e '1-"2"'
          ** (ArithmeticError) bad argument in arithmetic expression
              :erlang.-(1, "2")
              (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6
              (elixir) lib/code.ex:170: Code.eval_string/3

~~~
kazinator
In the awk macro of TXR Lisp, I wanted to provide some of the convenience of
the "duck typing" in Awk, whereby a string which looks like a number can be
used like one. Instead of supporting such a thing directly (which I consider a
computer science flunk job in language design) I came up with a field
conversion facility that has a succinct syntax: clear and unobtrusive.

[http://www.nongnu.org/txr/txr-
manpage.html#N-018CCE37](http://www.nongnu.org/txr/txr-
manpage.html#N-018CCE37)

This demonstrates some of it:

    
    
      1> (awk (t (fconv i) (prinl f)))
      1 2 3 4 5
      (1 "2" "3" "4" "5")
      nil
      2> (awk (t (fconv i : r) (prinl f)))
      1 2 3 4 5
      (1 2.0 3.0 4.0 5.0)
      nil
      3> (awk (t (fconv : i : r) (prinl f)))
      1 2 3 4 5
      (1 2 3 4 5.0)
      nil
      4> (awk (t (fconv i : r : i) (prinl f)))
      1 2 3 4 5
      (1 2.0 3.0 4.0 5)
    

There are more conversion specifiers than just _r_ and _i_. There can be any
number in a row before the first colon, in the middle, or after the last
colon. Conversions are matched with fields and applied. If a colon occurs,
conversions after the colon are repeatedly applied to the remaining fields in
cyclic repetition. If two colons occur, conversions after the second colon are
applied to the trailing fields. There is intelligent prioritizing when these
rules overlap.

There are conversions with a _z_ suffix which treat junk as zero:

    
    
      8> (awk (t (fconv : iz) (prinl f)))
      a b c 1 2 3
      (0 0 0 1 2 3)
    

Without this, you get _nil_ which will blow up if used as a number -- but you
can test for it and handle the situation rather than getting a silent zero:

    
    
      9> (awk (t (fconv : i) (prinl f)))
      a b c 1 2 3
      (nil nil nil 1 2 3)
    

Basically the whole "anything can be used as a number, and junk makes zero"
nonsense can be avoided with only a small reduction in code golfing. Textual
duck typing is a wrongheaded solution for an ergonomic problem, which
sacrifices correctness and clarify of data representation for the sake of
absolutely minimizing the program character count.

------
radarsat1
I actually went through all the steps of getting rustc and emscripten working,
got it set up in Docker. It actually works, I was able to compile a rust
program to wasm. But.. because emscripten uses a custom version of LLVM and
clang, the image took up 25 GB of my harddrive! I just don't have that kind of
space to leave it lying around, so I'll have to wait until they integrate into
upstream I guess.

I might work a bit in Rust by itself and compile using emscripten later on the
server, but kind of hard to do that if I want to access DOM/canvas/webGL, etc.

------
NiLSPACE
I also found this which I'd like to try out later today:
[https://github.com/anowell/quasar](https://github.com/anowell/quasar)

------
MichaelBurge
It looks like the spec is here:

[https://webassembly.github.io/spec/introduction/index.html](https://webassembly.github.io/spec/introduction/index.html)

I feel like writing a mini-compiler after glancing through it. It looks closer
to a binary AST than an instruction set, though.

~~~
sidarape
> 32 bit integers also serve as Booleans and as memory addresses.

I'm already looking forward the day that 32-bit pointers won't be enough for
web applications.

------
flavio81
I am very excited by this project, it opens up a lot of possibilities. Finally
we can use our users' web browsers to the maximum potential, in the language
of choice.

Consider: If a good javascript engine like V8 can go as far as being able to
emulate hardware, how far can we go with something like webassembly?

All the power to Webassembly!

------
wcummings
I'm sorta afraid of what people will do with wasm. I'm fairly sure 99% of web
programmers won't need this but will use it to ship all kinds of stupid
garbage that will inevitably wind up executing on some page I'm debugging.

------
drumttocs8
Will this eventually let us use jQuery and have it perform just as well as the
latest framework? ;)

------
dandare
Surprisingly I am struggling to find such essential information as where
exactly is wasm supported right now. In latest Chrome? How about Edge? how
about the browser on my smartphone?

~~~
blaze33
CanIuse is very useful for this:
[https://caniuse.com/#search=wasm](https://caniuse.com/#search=wasm)

------
toni
Is there any about:config flag in Firefox to disable WASM all together?

~~~
livingparadox
Why do you want to do that? afict, this shouldn't be increasing the attack
surface any more than almost any new language feature. Its spec-ed to run in
the same VM as JS is currently.

------
jlebrech
someone port cocoa or a xib library to webassembler or even xlib.

------
pmontra
I hope they add support for garbage collected languages soon. I don't feel
like going back to work with malloc and free after 20 years.

~~~
CryZe
You are not forced to use C or C++. Rust has automatic memory management via
its Ownership System. Once you get used to it, it feels a lot like a garbage
collected language.

------
_pmf_
Why isn't the Emscripten SDK distributed via npm? Doesn't npm support host
specific binary artifacts?

~~~
almostdigital
Check this out:
[https://github.com/dcodeIO/webassembly](https://github.com/dcodeIO/webassembly)

Binaries are hosted on GitHub but will be downloaded for you

~~~
_pmf_
Ah, thank you!

------
baq
i've seen one blogpost where the author tried and apparently successfully
managed to run a QT app compiled to wasm. has anyone here tried that?

------
madrafi
So now I have to write C code ? XD

~~~
madrafi
One thing though How is taking the whole C in the browser approach ressource
wise ?

~~~
flavio81
It is not C in the browser. It is a sort-of-virtual machine in the browsers.

Browsers (i.e. Chrome) are already doing this to execute Javascript, for
example. Webassembly, to put it in a simplified way, allows you to "bypass"
the javascript layer and target directly the virtual-machine. And done in a
compatible, well-documented way.

So you can gain in performance, and flexiblity.

------
analognoise
Near native performance - what a joke.

~~~
sp332
Got a specific benchmark or task you think will be much slower than native?

~~~
analognoise
Anything?

You're carting around an entire browser, it's so far from native that it's
completely laughable.

As a point of reference: In 1984: MacPaint, 5,822 lines of Apple Pascal, 3583
lines of assembly QuickDraw (dependency): 17,101 lines, all assembly Compiled
Size: 0.05MB

Today, Chrome: Number of lines of code: 16 MILLION Webkit (alone): 10.3
MILLION Install size: ~200MB

We have a bunch of people who aren't skilled enough to deal with a real
machine who think they're still "near native". Every single thing won't be as
fast, or as small, as the underlying hardware can be using toolkits and
platforms that have been available for 20+ years (cross platform toolkits and
Java both). For god's sake, Java is a portable VM! wxWidgets is cross-
platform, and open source!

We accept an operating system in our way as it is, and now we accept not only
an operating system, but an entire browser as well? Our computers are faster
than supercomputers used to be - why does Photoshop (or ANY program) take so
long to load?

We have to go the other direction - start removing all the garbage from
computing, keep the best bits, throw the rest out. If you can't hack on a real
computer, that's fine - you have the Webassembly sandbox. But don't label it
"near native" \- it just shows you don't care enough about computers to read
about them. I hear that and it sounds like my gradma talking about computers -
that same level of understanding. Nana is amazing, but she's not so great at
computers. And these people are supposed to be developers?

~~~
sp332
Well I'm in favor of things running in a sandbox, especially random code
delivered over the internet and run automatically in my browser. But aside
from that, WebASM has a flat memory model and (so far) no built-in garbage
collection. It has very few features, it's very fast to parse and it runs fast
too. Even the asm.js version was fast back in 2013
[https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-
nat...](https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-
performance-gets-even-narrower-with-float32-optimizations/)

As for the rest, I don't know how you're measuring. Photoshop runs a lot
faster than programs on my Centris 610 did, and sure it's a bloated mess of
different programs glommed together but guess what, it does a lot more than
smaller programs do. Your comment counts the cost of everything and the value
of nothing. You can't click a link and get a brand-new full-featured word
processor running on an old Mac in 10 seconds like you can by clicking
[https://docs.google.com/](https://docs.google.com/) But I can run MacPaint in
my browser thanks to asm.js
[https://archive.org/details/mac_MacOS_7.0.1_compilation](https://archive.org/details/mac_MacOS_7.0.1_compilation)

~~~
analognoise
We used to have that back in the day. It was called...installing, I think it
was? Then the app...'program'? That was It! Program! Ran at native speed.

Amazing how we ever got anything done without carting around an entire browser
as an attack surface.

~~~
sp332
[https://xkcd.com/1367/](https://xkcd.com/1367/) I don't think I understand
your comment about attack surface. A Chrome sandbox is a lot harder to attack
than a Mac Classic installation - or pretty much any current method of
"native" installation.

------
johngruber
This can probably only be expected to get better and better. While JS engines
are squeezing hard to get some extra performance, WASM is just beginning its
life.

It'd be great if someone would make (when it's technological feasible) a way
to integrate this natively in node, something like:

const wasm = require('wasm-native');

(async () => {

    
    
      const mymodule = await wasm('mymodule.c');
    
      // use mymodule here
    

})();

~~~
smitherfield
Why not just write a native extension?

~~~
Matthias247
I think they have slightly different advantages:

\- WASM is platform independent, so it can easily be precompiled. Which means
just the .wasm module needs to be distributed (e.g. inside a npm package).
However WASM modules only have access to things that were already available to
JS before (no random C/C++ libraries can be included which e.g. call into the
OS, no multithreading, etc.). And the toolchain might be at the moment not yet
the easiest to set up.

\- Node native extensions have quite good tooling support. Write a binding.gyp
and the C++ files and everything works pretty smooth. The native code can also
do everything that native code is allowed to do on the platform. However node
native extensions are platform specific, which means either precompile them
for all target plattforms (and each node release) or deliver C/C++ sources
which are always compiled on the deployment plattform at npm install time.
They also can't be shared between browser and node plattform.

All in all I think they have slightly different usecases:

\- Node native extensions for accessing operating system APIs and other
libraries which are not already exposed through nodes JS APIs.

\- WASM for making existing C/C++ code including full applications (like
games) runnable in the browser

\- WASM for making modules which speed up pure algorithms (like audio
processing) and which can be used on both platforms.

------
dennykane
You can play my favorite arcade game ever in a wasm gameboy emulator (credit
goes to Ben Smith of Google:
[https://github.com/binji/binjgb](https://github.com/binji/binjgb)) in a web-
based OS I've been working on for 5 years. This is known to work in current
Chrome and Firefox. Keyboard game controls: 'w'=up 'a'=left 's'=down 'd'=right
'.'=A ','=B space=start enter=select. Also, standard (17 button, 4 axis) USB
gamepads should "just work" via plug'n'play.

Go to this link to test it out:

[https://linuxontheweb.org/desk?desk_init=bHMgL3B1YjtvcGVuIEF...](https://linuxontheweb.org/desk?desk_init=bHMgL3B1YjtvcGVuIEFyY2FkZSAtLWFwcGFyZ3M9ImZpbGU9L3B1Yi91c2Vycy9kZW5uaXMvZ2FsYWdhLmdiIg==)

The argument in the URL is the base64 encoding of an initialization script
that is being passed to the desktop environment. Going to the link in current
Edge should just open the "Arcade" app, with nothing else happening.

You should be able to drag-n-drop ".gb" or ".nes" ROM game files from your
native desktop right onto the Arcade app window, and it should just start
playing. You can also just drop them onto the web desktop to save them there,
then just double-click them when you want to play. That way, the file is kept
in the site's local storage.

Learn more about how to use the web-based OS here:
[https://www.youtube.com/channel/UCZkhPP7327fXcSsjD_lt67w](https://www.youtube.com/channel/UCZkhPP7327fXcSsjD_lt67w)

If anybody has wasm-capable Edge or Safari, let me know if you can play the
game.

