
Sneak Peek at WebAssembly Studio - lainon
https://hacks.mozilla.org/2018/04/sneak-peek-at-webassembly-studio/
======
danShumway
I think WebAssembly is one of the most exciting efforts for the web right now,
second maybe only to Houdini or IPFS.

I say that even as someone who works pretty much exclusively in Javascript now
and who loves the language - a lower level format will be great for everyone.
I can't wait for more native languages to start supporting it.

~~~
haberman
I completely agree. I remember all the years where the prevailing wisdom was
"standard web byte-code isn't necessary/feasible/desirable/etc." It's nice to
realize that such pronouncements aren't necessarily the final word. It turns
out there is a way to give people the byte-code they always wanted.

(btw I know WebAssembly isn't, strictly speaking, byte-code. It's a compact
binary encoding of an AST. But it has all the characteristics that people
really cared about when they asked for byte-code: it's a low-level
representation that is a good compilation target for compiled languages)

~~~
pcwalton
Yeah, I was one of the PNaCl naysayers. :) But wasm has different
characteristics: (1) it has a forwards compatibility story because asm.js
exists; (2) it's a custom IR that was designed from the ground up to not have
undefined behavior; (3) it uses the Web APIs, rather than an alternate Pepper
stack.

Issue (1)--the forwards compatibility story--is the tricky one. Was it
necessary to have asm.js as a stepping stone, or could we have gone all the
way to Web Assembly from the beginning? I don't know, and we might never know,
but having asm.js around for browsers that don't support wasm certainly
doesn't hurt.

~~~
haberman
Oh yeah, my post wasn't about PNaCl at all (I wasn't even thinking about PNaCl
when I wrote it). It's very clear to me that wasm is a superior design
compared to PNaCl, and I'm glad history went the way it did. :)

I was talking about about the sentiment that byte-code _in general_ isn't
necessary/feasible/desirable for the web.

Here are some example of the sentiment as I remember it. There was a lot of
skepticism that it would be possible to design something that would be a
better compilation target than JavaScript while still being fast, portable,
and properly sandboxed:

[https://news.ycombinator.com/item?id=1893686](https://news.ycombinator.com/item?id=1893686)

[https://web.archive.org/web/20101126142151/http://www.aminut...](https://web.archive.org/web/20101126142151/http://www.aminutewithbrendan.com/pages/20101122)

[https://www.infoq.com/news/2013/05/javascript-browser-
byteco...](https://www.infoq.com/news/2013/05/javascript-browser-bytecode)

------
kristiandupont
I have to say I am pretty excited about WebAssembly.

I've been through many programming languages. C# might be my favourite and F#
always seemed like it would be if I took the time to learn it properly but for
quite a few years now, JS has simply had such gravitational pull that I felt
like I had to go with it. And I have to say, I've learned to not only like but
to love it. Save for the mutable data structures that it supplies per default,
it offers solid functional programming features and the culture embraces
those. Still, there are times where I wish I could use something else.

NPM features quite a few packages written in other languages, with JS
"binaries" available which I think is pretty neat. To me, packages seem like a
much nicer place to choose language rather than, say, per microservice. A
parser might be much cleaner in some pure functional language while some I/O
library might work better in something else. But there is still only a subset
of languages that compile to JS and the quality varies. But with LLVM
supporting WebAssembly, I can see a future where it truly becomes the global
binary format. Which would allow you to either write a combination of desktop,
mobile and web apps (plus backend) in any language of your choice. Or, easliy
write different packages in different languages and combine them into one app.

~~~
pjmlp
Bytecode formats as portable binaries have always been a thing on the
mainframe world all the way back to the 60's, it has just taken quite a few
decades to become commodity across mobile, desktop and web worlds.

~~~
Koshkin
Googling this only turns up Java...

~~~
pjmlp
Then you need to improve your Google-fu.

Burroughs, Xerox PARC systems, ETHZ Lilith, Pascal UCSD, IBM TIMI, IBM
Language Environment, ...

~~~
puzzle
Also Oberon SDE...

~~~
kristianp
Is this it? [https://hokstad.com/semantic-dictionary-
encoding](https://hokstad.com/semantic-dictionary-encoding)

~~~
puzzle
Indeed. AKA slim binaries.

------
Promarged
If available it's better to use instantiateStreaming [0] for faster
compilation, e.g. this:

    
    
        fetch('../out/main.wasm').then(response =>
          response.arrayBuffer()
        ).then(bytes => WebAssembly.instantiate(bytes))
    

could be expressed as this:

    
    
        fetch('../out/main.wasm').then(response =>
         WebAssembly.instantiateStreaming(response))
    

[0]: [https://hacks.mozilla.org/2018/01/making-webassembly-even-
fa...](https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-
firefoxs-new-streaming-and-tiering-compiler/)

~~~
dmix
Wouldn't that still require `response.arrayBuffer()`? For ex (line 2):

    
    
        fetch('../out/main.wasm').then(response =>
            WebAssembly.instantiateStreaming(response.arrayBuffer()))
    

Otherwise it could just be:

    
    
        fetch('../out/main.wasm').then(WebAssembly.instantiateStreaming)

------
berdon
I came here to complain about it being yet another standalone app.

I came back, after RTFA, to say that I'm pleasantly surprised that it runs
completely in the web browser.

[https://webassembly.studio/](https://webassembly.studio/)

~~~
ropeadopepope
Funny. I came here to complain that it's not a standalone app and yet another
crappy browser app.

~~~
infogulch
I also would prefer standalone apps, but if my choice is between a browser app
and a "standalone app" made with electron, the browser app wins in a
landslide.

~~~
zaarn
With WASM this is no longer a problem. Just supply your own JVM-for-WASM. The
standard does expect it to be ported natively to platforms eventually.

It would be quite interesting when Browser Apps could also run as native apps
without relying on electron (ie, being able to pull up their own UI when not
provided one)

~~~
collinmanderson
> It would be quite interesting when Browser Apps could also run as native
> apps without relying on electron (ie, being able to pull up their own UI
> when not provided one)

What do you see as the advantage of native at that point - having its own
window?

~~~
imtringued
Most likely filesystem access and other native features like desktop
notifications.

Then there is the efficiency. My suspicion is that electron has a completely
misconfigured caching system. Usually only one browser is running on a system
and therefore many applications share the caching system. This means each
electron application has an oversized cache that wastes memory and disk
without meaningfully increasing performance.

~~~
collinmanderson
so is web or electron more efficient?

Also, web now has desktop notifications - right?

------
eridius
This is really cool!

I'd love to see the "Hello World" example template provided for all languages,
not just C (or at least, for Rust as well, since the C++ version would be
awfully close to the C one already).

EDIT: On a different note, I was confused when I loaded a template, hit "Run",
and got nothing. I assumed running would automatically build first. It would
be nice to somehow hint to the user if they run something that hasn't been
built yet.

~~~
steveklabnik
In my understanding, part of why they don't have that in Rust yet is the lack
of Cargo support; you'd want to use [https://github.com/rustwasm/wasm-
bindgen](https://github.com/rustwasm/wasm-bindgen) (and its README.md has said
hello example in it) but there's no easy way to use it just yet. It's coming
though.

------
alephnan
For those interested, this is using the Monaco editor
[https://github.com/Microsoft/monaco-
editor](https://github.com/Microsoft/monaco-editor)

~~~
wes-k
Yes! I was so happy when they pulled this out of VSCode. I really want to use
it on a future project and I love the idea of code in the browser for sharing
learning opportunities!

~~~
Vinnl
IIRC, Monaco was actually first, and VSCode was based on that :)

------
watty
_Started_ working on it late December? That's an incredible amount of progress
for less than 4 months.

~~~
mbebenita
Built on top of the great work of many :
[https://github.com/wasdk/WebAssemblyStudio#credits](https://github.com/wasdk/WebAssemblyStudio#credits)

------
geokon
The tools for working with WASM are here:
[https://github.com/WebAssembly/wabt](https://github.com/WebAssembly/wabt)

The compiler/converters are here:
[https://github.com/WebAssembly/binaryen](https://github.com/WebAssembly/binaryen)

Maybe someone who knows more could help me understand better. It looks the
toolchain "stack" is some-lang through LLVM to a special WASM LLVM backend
which then is converted to WASM - which is similar to the LLVM-IR.. but more
crossplatform-y.. I think? (can someone confirm?). So I guess going forwards
WASM is the new crossplatform bytecode and not necessarily tied to the web -
right? I don't really get if WASM has memory-managment / garbage-collection by
default or it's something optional available to things like Javascript? Or the
GC is written in WASM itself...?

With LLVM-IR/WASM/SPIR-V it's kinda a shame we have all these standards doing
very very similar things - but I kinda get the rational there

~~~
tom_mellior
> WASM - which is similar to the LLVM-IR.. but more crossplatform-y.. I think?
> (can someone confirm?)

Yes.

> So I guess going forwards WASM is the new crossplatform bytecode and not
> necessarily tied to the web - right?

Yes. Andreas Rossberg and other chief WASM people are touring conferences with
talks called more or less "WebAssembly: Neither Web nor Assembly". It's a
misnomer.

> I don't really get if WASM has memory-managment / garbage-collection by
> default

It doesn't. I'm not up to date, but last I heard the best that was offered was
"at some point there will be APIs available for calling into the browser's
runtime to get GC'd objects" or something like that.

~~~
geokon
Gotcha. After reading a bit more it sounds like WASM isn't supposed to really
be the common target for all "web-languages". ie. Javascript won't be
compiling to WASM any time soon. It's just a parallel mechanism to run code in
the browser that's more extendable/flexible (b/c people where writing monsters
to have their language compile to Javascript/asm.js)

~~~
tom_mellior
I think it's a bit of both, and maybe more. For one thing, I think there are
historical ties to asm.js (i.e., some of the same people went on to develop
WASM), and asm.js should compile nicely to WASM. Once they have GC figured
out.

For another thing, I think there is the long-term goal of using WASM as a way
to migrate away from JavaScript, if desired. Once you can compile all (or
most) of your JavaScript logic to WASM, you can start transparently replacing
parts of that code with code written in other languages that compile to WASM.
If the interfaces remain unchanged, the remaining JavaScript won't notice.

------
pjmlp
I love that AssemblyScript and bare Wat format are supported as well.

~~~
vanderZwan
I hope they'll add Walt

------
fizzledbits
I work with emscripten and webgl and this looks like a fantastic tool for
optimization in particular. Really looking forward to using it. Thank you!

~~~
huy-nguyen
How much optimiztion can you squeeze out of webgl + wasm? Don’t you still have
to call into JS?

~~~
flohofwoe
Yes, it's definitely good practice to reduce calls to WebGL as much as
possible (for instance through batching, instanced rendering, maintaining your
own state cache etc...). Performance behaviour of WebGL is very different from
a native GL implementation, but when keeping that in mind it's not too bad all
in all.

------
iTokio
What would be awesome is a way to easily visualize the code size.

------
z3t4
Whoa, that's a lot of wasm to show a hello world, compared to "hello world" in
assembly language.

------
AnonCoward222
I'm non-plussed. Their "Hello World" example in C is essentially unparseable
for anyone who doesn't already know what's going on. Anyone care to explain
it? I don't know how much of this example is written in js and how much in C,
how much is boilerplate or anything. It's awful.

~~~
tom_mellior
Well, that's kind of what the README file is there for.

Here is my understanding: The C program assumes the C standard library is
present. It _is_ present, somewhere. Where, and in what version, is not clear
to me.

Anyway, while the C standard library has an implementation of printf(), that
implementation doesn't _actually_ know how to do I/O. It relies on an
underlying operating system to do the actual I/O. In particular, the library
assumes that it is running on Linux, so once in a while it will emit system
call number 146, which is Linux's writev(2) system call
([http://man7.org/linux/man-
pages/man2/writev.2.html](http://man7.org/linux/man-
pages/man2/writev.2.html)). But there is no implementation of Linux running in
the browser! And if there were, its conception of I/O would probably be
different from what you expect. That is, you might want "output" to go to one
of many different places, and WebAssembly can't guess what you want. That's
why the program also implements a writev_c function to simulate this syscall.
The corresponding mapping from syscall number 146 to this function is
implemented in the accompanying main.js file.

So to program your browser in C-compiled-to-WebAssembly, you must implement
your high-level application logic _and_ the relevant low-level system calls,
making educated guesses (through testing) about what syscalls the hidden mid-
level library layer will emit. I'm a bit underwhelmed by this approach. But I
guess over time standard syscall libraries will pop up and included in
WebAssembly projects to allow you to go back to worrying only about your
actual application.

~~~
mbebenita
That’s a very nice description of what’s going on. The example is there to
illustrate how printf works. In fact this is a lot of what Emscripten does to
make C/C++ applications just work.

------
traviscline
typos: memeory, "pulling the struct iovec abart."

~~~
ateesdalejr
I thought the _meme_ -ory was on purpose...

------
singularity2001
not bad, but four(4) config files for a single code file?

~~~
bpicolo
Where do you see 4? I see package.json only. Arguably the build script. And
that number doesn't increase at all with more code.

The number of files is exactly the same as if you weren't using webassembly,
other than the one rust/c source file.

~~~
pjmlp
On AssemblyScript I see:

\- tsconfig.json

\- gulpfile.js

\- package.json

\- setup.js

~~~
mbebenita
AssemblyScript is slightly more involved because the author of the template
loads the compiler dynamically.

------
glibgil
The video is unlistenable

~~~
ElijahLynn
I listened to the whole video and it has good audio all the way through.

------
angersock
WebAssembly Studio is a neat project, and I'm very impressed at the quality of
tooling.

It's just a shame that WebAssembly itself is a concept so deeply flawed in
conception that it is unsalvagable, and that it'll hurt developers and users
alike. Does opening the door to frontend development in C, Rust, Java, and the
whole menagerie really seem like such a good idea?

Consider the mess we've made with Javascript--the spread of that mess to other
languages to enable WASM and web support is going to be even worse.

~~~
sctb
Would you care to add some information about why you feel this way?

~~~
angersock
Summed up here, pretty neatly:
[https://lobste.rs/s/wjtu7c/webassembly_mozilla_won#c_yqsej7](https://lobste.rs/s/wjtu7c/webassembly_mozilla_won#c_yqsej7)

