WebAssembly Specification Prototype | Hacker News Reader

WebAssembly Specification Prototype

github.com

179 pointssunfish107 comments

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?

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

All that is planned though, just not for the MVP: https://github.com/WebAssembly/design/blob/master/GC.md

No idea why you've been downvoted. I'm interning at Mozilla right and as that design document says, GC and DOM access for WASM are very much on people's radar - they just won't make it into the initial roll-out.

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.

I just hope that when it happens we will be able to view and read the source of WASM in the same way we can with javascript now. This is one of the foundations of WWW, please don't turn it into a closed source app store.

We lost that years ago with minification. Source maps can work as well for WASM as they can for minified JS.

Then make browsers require full source maps for every website, or refuse to run them.

That’d be finally a solution.

Or require source maps by law.

EDIT: Why the downvotes? The only way to preserve the right to modify and decompile in the long term is by creating technical or legal measures enforcing it. JS was one technical measure, so now we need alternatives.

That would be awfully slow to transfer (or just verify) when most people never view the source map.

What's a "valid" source map anyways?

Furthermore, debugging with sourcemaps is suboptimal. WebAssembly wants to support much better debug information than this.

And it'd imply you need a source map even with unminified JS. And what's to say the source map maps to non-minified JS?

It’s not about debugging, it’s about the legal "right to decompile", which is intended to give customers and companies the right to take apart products and software they bought (even from competitors), and gain knowledge from that.

It’s also intended to allow them to modify it for their own purposes, and provide the modifications to others who have a license to the original product.

Especially on the web this was finally possible, and now you’re suggesting to take this away again?

I know of no country (or other jurisdiction) where a legal "right to decompile" exists.

The EU has a very, very limited right to decompile for the sake of interoperability.

See Article 6 on http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:...

And for personal modifications, and so on.

And "copying the decompiled source of the part of MS Word that reads .doc files" counts as covered, so, it's quite a lot.

Especially with websites, where you might want to interact with, or write addons interacting with, WASM threatens those rights.

Many countries allow reverse engineering, and you could infer a "right to decompile" from that in some cases, but as far as I know none of them place any requirement on the source to make it easy.

At most they legally protect someone who decides to run a disassembler or decompiler on a binary from prosecution or lawsuits (but only in as much as you don't use the result to violate copyright or other restrictions).

Browsers don't create laws. WebAssembly can't legislate. This is really out of scope!

You don't seem to want a right to decompile/disassemble (which you could do in the same form for WASM than for most other languages) but a right to directly view the original source code. Such a right does not exist in general. The owners of the source code (the intellectual property) may give you the possibility to view it, but they could also decide that they don't give it to you. The only exceptions I know of are if the creator incorporates other software parts which mandate releasing the source code, e.g. GPL libraries.

> Then make browsers require full source maps for every website, or refuse to run them.

> That’d be finally a solution.

No, it wouldn't. You'd end up with sites shipping "source maps" that map every function to a randomly generated identifier.

You seem to know a bit about web standards, was minification ever formally accepted by the W3C or did it just happen?

Just happened. It's just renaming variables and properties, after all—there's no actual change to anything standardised.

As an aside, JS is standardised by Ecma, as ECMAScript: the W3C doesn't have anything to do with it.

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.

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.)

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

Step 1) Replace the 2d library of your desktop GUI language to draw using HTML canvas API. Step 2) Compile to wasm

No need for the DOM anymore... (not saying it's a better approach, but it is technically possible).

If there is no GC, could a language like Rust or Swift still target WASM?

We plan on having Rust target webassembly, and there's already basic support for doing so.

Where can I learn more about this basic support?

There's the next full stack paradigm right there. I give it two years, and it will be called rustic-asm framework...

https://github.com/brson/mir2wasm

It's still very early, and there's other avenues as well: an LLVM backend, for example.

Cool, i appreciate the link.

haha :D. I also have plans for a Rust web framework. Nothing fancy, and it will likely suck, but it's a dream :)

Rust doesn't use a GC, so it should be fine. Is that what you meant ?

Languages that don't require a GC would be fine to begin with, other languages would have to implement a GC in WASM.

DOM and GC are on the plan list thought, fwiw. It will, as far as the planning is concerned.

1 - You could use C# (provided that a compiler exists), but this only gets you the language, not the APIs and libraries commonly used by it. In that sense, it's not much different from using Emscripten (a compiler that goes from other LLVM languages to JavaScript) today. For example, XAML won't work unless someone writes a library to translate it into the browser's usual structures. 2 - It's still JavaScript underneath (more accurately, it's asm.js underneath).

asm.js can interpret wasm as a fallback, but once wasm gets built-in to browsers, it won't be JS anymore.

I've read somewhere that so far the experiments for having asm.js polyfill webassembly isn't looking too promising anymore. I could be wrong though.

I've made some progress on this, but there's still a way to go: https://github.com/WebAssembly/sexpr-wasm-prototype/commit/8...

WebAssembly is not a replacement for JavaScript, and (IMO) it most likely won't ever be.

At the very least JavaScript will always be around as a "glue" language to use wasm binaries.

I think of the relationship between JavaScript and WebAssembly as the relationship between Python and C. JavaScript will call out to a wasm binary for some "heavy lifting" and JavaScript will be used to "glue" the data to the DOM. Also like the Python-C relationship, the wasm can be a compile target for non-javascript libraries.

But I honestly don't see writing non-javascript web applications being mainstream any more than it is now at any point in the near-ish future. It's possible (both now and in the future), but it's always going to be a leaky abstraction, or your language will end up being similar enough to javascript that targeting wasm is largely pointless (think TypeScript or Flow).

> But I honestly don't see writing non-javascript web applications being mainstream any more than it is now at any point in the near-ish future.

The performance of touching the DOM and browser APIs will be the factor that decides that, imo. I think you may be underestimating how many people are partially or heavily disgruntled at javascript, and would happily replace it if given the chance.

If speed is not an issue, and it's purely by choice of the user, i think there will be a lot of interesting changes to the web in the coming years.

Hell, for many applications i'd even be willing to accept a speed loss to use "my preferred language". And, in the event that certain tasks are indeed too slow, perhaps i'll be able to pass data back and forth between my WASM and JS to let JS deal with the performance critical DOM.

Regardless, i'm quite excited, and hope to see something fruitful from it.

Yes. With this we can finally be less restricted in our language choice.

I think the community of people who want tyoe safe languages is large, and this will the a target for them.

I just hope for Dom bindings through the WASM ABI.

Javascript is awful. If WebAssembly is anywhere near consistent across browsers, and there are better languages that compile to WebAssembly, I would go that way in a New York minute.

> how many people are partially or heavily disgruntled at javascript

It's not actually the nightmare many make it out to be with ES6. I actually enjoy writing it quite a bit (I have mainly a functional background)

Yea, fwiw these days it is much better. But i think the biggest issue is simply the lack of choice. On my OS, i can choose whatever language i want. Whether i choose for preference, or the right tool for the job, i have choices, many of them.

On the web it's.. well, just JS. Some languages that transpile to JS.. but ultimately they're all pretty much just JS.

If your language of choice comes with a runtime that's not shipped in the browser, WASM doesn't seem like it will make speed into a non-issue, it will just frontload the slowness.

ftr, when i mentioned speed i was mainly referring to WASM->DOM. So, if that ends up too slow for heavy DOM manipulation (eg, React style diffing/etc), then with any luck we can offload the DOM interactions to JS. Eg, WASM->JS->DOM

Screw that.

Writing glue code sucks.

Define an ABI for interacting with the DOM. And allow WASM compilers to target it.

I'm pretty sure there will be libs in various languages that allow to talk to the DOM directly (e.g. in C/C++ #include "dom.h"), under the hood they would still call out into JS but the library user wouldn't have to touch Javascript. This is how most of the C API wrappers in emscripten work (e.g. OpenGL wrapper which talks to WebGL). Calling out into JS sounds like a perf hit, but overall it works very well... as long as the JS code doesn't produce too much pressure on the garbage collector, I think this is the main problem with the current JS wrappers. But since DOM operations are slow anyway that shouldn't be a problem (it's fast enough for WebGL, so...).

I've heard that native DOM interaction (no JS middle man) is on their radar via WebIDL. They don't want people reinventing the DOM via custom canvas rendering and such so making DOM manipulation painless is a priority.

It's hard to speculate how the culture and philosophy of web development will change, so let's leave that aside and consider what's possible to do. It's certainly possible to compile into wasm a desktop program in a high-level language, even a program with a GUI. When the browser runs that wasm, the user will interact with your GUI instead of HTML elements. See webassembly.github.io/demo.

More excitingly, I presume it will one day be possible to compile a mobile app into wasm and execute it in a browser, achieving instant parity between mobile web and apps.

The greatest disparity between mobile and native is the level of sandboxing, browser chrome and restrictions on user interactions reserved by the browser. Taking those away is not what WebAssembly does.

Indeed, taking those away would be breaking the web rather than improving it...

⌘⃣F⃣ "todo" ⇒ 29 finds

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

Indeed; WebAssembly as a whole is still being designed. For example, it doesn't have an official text format yet, and while there is a binary format implemented in multiple browsers now, it's still evolving. The TODOs mark places where there are ongoing design discussions.

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

Hah. https://cloud.githubusercontent.com/assets/296238/8255083/14...

Something in text: https://github.com/WebAssembly/design/issues/112#issuecommen...

    \\//

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

Like two of them are pretty good though

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.

As sunfish mentions below, this spec document is being conservative in describing things that are still being discussed.

There are experimental implementations in Firefox, Chrome and Edge. See https://webassembly.github.io/demo/.

There's more information about the current binary format here: https://github.com/WebAssembly/design/blob/master/BinaryEnco...

There's a prototype spec interpreter here: https://github.com/WebAssembly/spec/tree/master/ml-proto

There's a build waterfall testing multiple tools here: https://wasm-stat.us/console, including the experimental LLVM toolchain, the emscripten-wasm toolchain[0], binaryen[1], and sexpr-wasm[2].

WebAssembly is still under development, but I don't think it's fair to call it an early prototype.

[disclaimer: I'm a WebAssembly contributor]

[0]: https://github.com/kripken/emscripten/wiki/WebAssembly

[1]: https://github.com/WebAssembly/binaryen

[2]: https://github.com/WebAssembly/sexpr-wasm-prototype/

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?

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.

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?

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.

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.

Would this be any different than debugging code currently written in a language that compiles to asm? For example, people debug C code, compiled to asm, on their computers. Would it be different to debug C code, compiled to webassembly, in a browser?

Although I can't disagree that debugging js directly in browser tools is a nice experience.

"Open and debuggable: WebAssembly is designed to be pretty-printed in a textual format for debugging, testing, experimenting, optimizing, learning, teaching, and writing programs by hand. The textual format will be used when viewing the source of wasm modules on the web."[1]

What would you like to see happen here? Maybe you should give them your input.

1. https://webassembly.github.io/

It's Assembly, hombre. In my class of like 40 kids in college I remember one who really like to read and code in that. Maybe you are that guy - and more power to you... but the web has to work for the other 39 of us. That's what WASM is taking away IMHO.

Do a little reading about the wasm text format. It's not assembly, its meant to be read by JavaScript developers.

First off, sorry for the downvotes. Your opinion is unpopular, but it breeds discussion. Now..

I'm so lost, why on earth are you reading binaries? You keep citing examples of cleaning up after other people for a job. Why don't you have their source code?

If your job was with any other language, you would have the source code - you would not be given a Go binary and told to "fix what those previous morons did" - you would demand the source.

Are you saying that you are frequently given minified javascript off of some website and that the previous workers left with the source code?

First, no worries. If I have karma, there is no better way to spend it than advocating for a more maintainable Open Web in my opinion.

As for "I'm so lost, why on earth are you reading binaries?"

Consider every Perl/Haskell`/Smalltalk/COBOL developer for a moment. Do you think it's more likely that when this becomes a production standard they are going to say to themselves "You know what, I feel bad for the guys that will have to maintain this I'm just going to learn JS so at least it can be maintained in the same language the rest of the web is"... because I think it's probably more likely that they will immediately start transpiling binaries from COBOL etc, into WASM to run the web. Great for them, really but that's what leaves us with binaries to deal with.

Would you mind answering the second half of that question? I'm curious.

> You keep citing examples of cleaning up after other people for a job. Why don't you have their source code?

Sure, let's have a karma bonfire: Sometimes I inherit minified code from someone who was hired years ago and for one of msny reasons is not available any more. It doesn't happen every day, thankfully. When it does, I'm happy that I can at least read and repurpose the JS that's left. Downvote away.

If that's the case then you (or your clients, or whoever owns the code) have some rather serious code management issues. The answer is to fix that problem, not to suggest the programming language is broken because the compiled result isn't readable.

If you were working in C/Java/etc I'm sure your first reaction to the same problem wouldn't be "C is broken because I can't debug a compiled executable easily!".

You seem to be suggesting that if I only had the source, that would solve all of my problems but that is one of my biggest fears about WASM to be honest- because the source of the web has always been JS or something extremely close to it, like coffescript or Typescript. Now someone could start writing source for the web in COBOL. I hope I'm wrong about this, and -50 karma from this thread is telling me most people think I am, but I genuinely fear a less maintainable Web.

I don't think that's a valid complaint given the number of languages that can already be compiled to JS. Including COBOL ... https://github.com/ajlopez/CobolScript

It's a long list: https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

Also, ultimately, there will be code that you can't maintain because you don't understand it. That might be because it's written in a language you don't know, but it might also be because it's written in a style you don't understand, or with a framework you've never used, or because it's about a topic that you haven't spent time with. That's OK. You don't need to be able to do everything.

I see what you're saying and I know a lot of the fear I have is somewhat irrationally based on the idea that my knowledge of JS should give me the ability to fix anything on the web - and you rightly point out that there already are a bunch of languages that compile to down to JS/EmScripten/asm - so what's the big deal? I guess for me, it's just the fact that they at least have to knock on JS's door on the way to the web - so, in a sense, as a JS dev you get the privilege of at least being there between COBOL and the web. I recognize that's a position of privilege and it always hurts when privilege gets taken away - it may be more in keeping with the spirit of the Web that COBOL devs should have just as much access to the platform - and an equal-access compile target - as I do. I know asm/emscripten are a "thing", but they seem like a foot in the door for the buffet of languages that want access to the web, where ASM is blowing it wide open. I'm going to cherish the time I have left with JS as the lingua franca of the web and just accept that the future of the web will be one that I can't read/fix quite as well because it's not possible to know every language and I need to be OK with that... and I think I am for the most part, I'll just miss the Web of One Language.

Also - thanks for taking the time to make a thoughtful reply instead of just suggesting I'm a complete ignoramus and downblasting my response because we have a marginal disagreement about the Open Web Platform - made my day!

It will definitely be interesting though, i will give you that.

Right now, if you are a frontend "web developer", you can pretty much assert what you know from the title alone. The title implies the toolset.

In ~5 years? It means.. what, HTML/CSS, and whatever language you prefer? Rust? C++? Python? JavaScript? An endless array of frameworks in a sea of different languages?

I mean, it's no different than most other development in that regard.. but the web certainly will go through a change when this day comes.

It would be an incredible feat of engineering to be able to "transpile" an existing executable to WASM - if you're familiar with dynamic linking, the ELF format itself (or Windows' PE), the common processor instruction sets, etc - you'll know that won't be a problem anytime soon. Short of an x86 VM written in JS, it just ain't gonna happen.

Now, about having other languages compiled to the web, we already have that. Looking at specifically Haskell, we have GHCJS, and it (thankfully) works pretty well.

You may not like the idea that there will be new web projects using technologies that you lack proficiency in, but this is no different then how the rest of the software world works. For example, Google's Go language is picking up steam - in fact, I use it at work. If I didn't take the time to learn Go, I simply wouldn't be employed to work on that project. Similarly, I know people who are enjoying an incredible competitive advantage in their market by using Haskell for their web development (both backend with GHC and front end with GHCJS). If you don't learn Haskell, you won't be hired for those jobs. I do, however, guarantee that they'll still have the source on hand.

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

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

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.

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.

Asm.js is hardly human readable; which is rather the point (not sure why this is so highly coveted, since we use source code for this purpose and the minification counter argument is nonetheless true just as it is for Wasm, but I digress). And you can debug text wasm, if you're good enough.

I'm sorry, and with all due respect, your argument is hilarious, NIMBY, and goes against the Open Web movement's goal of "...a special role for public, cooperative, and standard World Wide Web communications", which you claim to love, and I assume, support (as do I). Wasm has a required text format in the spec itself, expressly for individuals such as yourself, so wasm is still for the Open Web.

A text format will be delivered alongside the binary for debugging. It will be exactly as debuggable as Javascript is (very). Please research the subject before posting kneejerk reactions.

There is an effort under way to ensure wasm debugging is at least as easy as JS debugging: https://github.com/WebAssembly/design/pull/708

> But you already can't read and debug minified JS

How about "but you already can't read and debug minified Emscripten output"?

Many years ago I added a feature (image upload button) to a minified WYSIWYG editor code without prettifying it :)

And I know someone who modified the MS MPEG-4 Version 3 codec to use SIMD instructions for the RGB/YUV colorspace transform, which both sped up and improved the accuracy of it. We can all agree that source-code is more readable than binary code though.

That being said, as there are already many languages that compile down to non-human-readable javascript (Including C), it's fairly moot at this point anyway.

The performance gains are going to be massive. All of the browsers collectively demo'd this: https://webassembly.github.io/demo/

Webassmebly is just as debuggable as minified JS. So what are you on about?

There's something fishy about this argument... why doesn't it apply to the desktop? Would it be better if all desktop software was written in JavaScript, enabling debuggability in exchange for performance?

At that point you might have something like the lisp machines. I've not used one, but have heard more than one person talk about the very good debugging experience on them.

>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...

Even if you "do it all the time" there's like zero motive to do it for third party sites and services.

Does anyone (for the statistically significant meaning of "anyone", e.g. more than some lone outliers) seriously debugs and/or monkeypatches third party sites?

And of course for your own site, you already have the code.

So I'm not sure what you're losing here.

Reply on news.ycombinator.com