
WebAssembly Specification Prototype - sunfish
https://github.com/WebAssembly/spec/blob/md-proto/md-proto/WebAssembly.md
======
minionslave
I have a question about WebAssembly.

1- With WASM, would developing for the web become similar to how desktop apps
are written? For example, could I use C# and design a UI in xaml, compile to
WASM for the web?

2- No more JavaScript?

~~~
spankalee
WASM doesn't have access to the DOM, or a GC, or very easy interop with
JavaScript, so the answer is mostly "no".

~~~
warbiscuit
I hope DOM access comes very close on the heels of the initial design...

Javascript is an interesting language (particularly after it's recent
revival), but IMO it's recent jumpstart would never have happened if it
weren't for one killer feature: access to the HTML DOM. People would (and
have) forgiven many other things, just for the utility of that as the
presentation layer.

I certainly would have picked up _whatever_ language the browsers were
pushing, where DOM access was a requirement.

Conversely, I remember trying to get java applets to interact with HTML -- you
have to message things through a tiny hole to/from javascript; which was (one
of the many) things which made everyone hate java applets.

~~~
comex
It depends what you mean by "access". The MVP won't have _direct_ DOM access,
but it's not really necessary. WebAssembly code can _synchronously_ and
efficiently call JavaScript functions (with numeric arguments), so it should
be pretty easy to write a WebIDL-based stub generator to provide natural
syntax for calling DOM functions from any given compiled language, with a
little JavaScript stub on the other end. A future spec might make things more
efficient by providing direct access, but it's really a micro-optimization.

~~~
pcwalton
Well, the tricky part is not getting the basic FFI to work but getting the
memory management right. Making sure that DOM nodes that are not part of the
document stay alive and that dead nodes die is the hard part, especially if
JS/wasm cycles are involved.

(This is not a criticism of wasm, by the way. It's merely motivating potential
future GC extensions to the spec.)

~~~
bluejekyll
How does that differ from today? Don't all rendering engines have to deal with
that GC now?

------
legulere
⌘⃣F⃣ "todo" ⇒ 29 finds

The binary and text representation sections still lack almost anything. This
really seems like an early prototype.

~~~
icefox
And the project is in search of a logo. You can find a bunch of proposals
here:
[https://github.com/WebAssembly/design/issues/112](https://github.com/WebAssembly/design/issues/112)

~~~
grenoire
Some of these are atrocious... Do NOT let programmers design brand identities.

~~~
andybak
It's nothing to do with being a programmer - it's to do with not being a
designer. Believe it or not some people are good at both.

------
icefox
It looks like Wasm.instantiateModule(b, m) currently takes the binary wasm and
memory to create a module, when would you pass in a linear memory object? Does
converting a wast always produce two files?

~~~
sunfish
WebAssembly modules can still import an external linear address space, but
they can now also define their own linear address space, with their own
initialization data included in the module file.

~~~
icefox
So if I understand that correctly unlike the current text ast format that is
floating around the Binary Format doesn't include the contents of (memory
...)? So foo.wasm + foo.mem = foo.wast?

~~~
sunfish
wasm modules can include their own initializers now, so .mem files won't be
needed. This is the Data Section in the WebAssembly docs.

.wast is actually just a testing file format that's currently serving the
purpose of a text format in the absence of a real one. It isn't expected to be
part of typical user workflows.

------
dccoolgai
I can't wait until the first time I have to maintain something someone
compiled into this monstrosity. The minimal performance gains will be _so_
worth destroying the debuggable web.

Sorry for the snark, but watching this slow-motion trainwreck plow into the
Open Web that I love is excruciating.

Pre-edit to respond to the inevitable "But you already can't read and debug
minified JS": yeah, you actually can if you're good enough. I do it all the
time... my complaint is that the bar for "good enough" is being moved from
"can read and debug scripting language" to "can read and debug Assembly"...
which I know you _can_ do, but geez. I guess what I'm saying is the Open Web
should only run on (reasonably) readable languages. Hate JS? Stand in line,
but if you want to replace it on the web, replace it with something a normal
person could interpret without a compiler.

~~~
JasonSage
This is a popular negative remark when it comes to WebAssembly, and I'm
getting a bit disappointed at how often it comes up. We really need to get
past the flood of comments on having an assembly for the web. They're usually
uninformed and opinionated (a bad combination), and do nothing to help real
efforts that are in place to combat what they're complaining about.

Check the GitHub pull request below (linked from the article we're commenting
on...). The WebAssembly spec includes a work-in-progress Text Format
specifically to make it readable by JavaScript developers:

> This proposes an official text format for WebAssembly, aimed at browsers to
> use in "View Source", debugging, and related tooling. It uses a JavaScript-
> like syntax for readability and familiarity on the Web, though it differs
> from JS in several respects, as it aims to reflect the underlying
> WebAssembly language.

[https://github.com/WebAssembly/design/pull/704](https://github.com/WebAssembly/design/pull/704)

If you're strongly opinionated about WebAssembly having a readable format for
the Open Web (and it would seem that many are with the volume of comments like
this), then subscribe to this pull request. You'll have an opportunity to see
the text format take shape and provide input on it. Developers are not
oblivious to the number of subscribers on a PR or issue, so you'll also be
making it known that it's important enough for you to be looped in on.

Please check out the Text Format pull and related links so that you can be
informed about this issue.

edit: formatting

~~~
dccoolgai
Thanks for the link to that PR. That's good advice. The truth is, it's hard
for me to read what they are recommending as the readable version. Maybe that
makes me an idiot...certainly a lot of comments in this thread are suggesting
that's the case... but I bet I'm not the dumbest guy who codes for the open
web... so for that other guy I'm sharing my opinion, misinformed as it may be.

~~~
jacobolus
Have you considered that there could be use cases where the performance gains
are _not_ trivial? For some code, we’re talking about more than an order of
magnitude speed difference.

What kind of language target would _you_ prefer for running optimized
numerical algorithms? Or do you just think we should keep computational
photography, natural language processing, physics simulation, 3d graphics
rendering, game AIs, etc. off the web?

Remember, to make their code run at full speed, developers need the ability to
use a variety of numeric types and processor-specific instructions (e.g.
SIMD), implement low level data structures, precisely manage memory, etc.

Even if these numerical algorithms get written in “plain” Javascript, after
being minified they become essentially unreadable. Often to understand even an
extremely clearly written implementation full of nice explanatory comments
requires reading the technical paper alongside the code. If you’re not only
missing the paper, but also have nonsense variable names and no comments,
deciphering the code becomes an incredible chore. As such, I don’t think
WebAssembly will have any significant effect on readability. Have you tried
reading and understanding asm.js output from Emscripten? That’s what we have
today, and it’s definitely worse than wasm.

