From Asm.js to WebAssembly
brendaneich.com
brendaneich.com
It may have taken a while, but with all these individuals and organizations cooperating in an open space, we may finally advance yet again into another new era of innovation for the web.
I am really excited about this, much like others in these comments.
We have been beating around the bush to have a true assembly/development layer in the browser for a long time: Java applets, Flash, Silverlight, you name it - but no true standard that was open like Javascript is open. This component has the possibility of being the neutral ground that everyone can build on top of.
To the creators (Brendan Eich et. al) & supporters, well done and best of luck in this endeavor. It's already started on the right foot (asm.js was what lead the way to this I think) - let's hope they can keep it cooperative and open as much as possible for the benefit of everyone!
Is Apple participating?
So, the effort to get buy-in from the big companies that matter has been going on for some time, and now that we've done that, here's the result: Every big company that matters except Apple.
It's not as though the list of the four big companies that matter is too long to reasonably be expected to name the fourth, and the name of the fourth is not webkit.org or Fil Pizlo.
So, it seems to be either an "Oops, we accidentally left one of the four out of this important announcement," or there is still enough of a problem with Apple that we decided not to delay the announcement any longer to wait for them.
Since Fil opened a webkit bug to implement wasm, I would at least hedge my false-dichotomy bet and avoid getting my mad on. Free advice, take it or leave it.
(The first paragraph is actually me telling you pretty much what happened. Same thing as with WHATWG launch in 2004, BTW. Does not mean "OMG there is something WRONG and only TRULY SHINY COMPANY noticed and OBJECTED". Yeesh.)
How can we know what concessions these players have made or what kinds of collusion they have agreed to?
Shouldn't the Web be built in the open -- not subject to a cabal of corporate overlords who won't reveal their intentions or thoughts?
As for "getting my mad on," you seem to have gone off on some sort of tirade at the end there implying--how ironic--that I actually wanted TRULY SHINY COMPANY to save us from wasm, and your caps-lock key seems to have gotten stuck when you banged on it.
I hope you can relax. All will be clear pretty soon, I am certain. There's no need to be nervous. Well, no need to be more nervous than usual! ;-)
I'll watch these pages and let out a woot! the minute Apple officially makes it unanimous.
Expect to see it implemented, sites like iCloud made to take advantage of it, performance metrics aka marketing collateral gathered and then a slide or two at an upcoming Apple Event with cheers from the audience.
Apple is a product company first and a technology company second.
I'm all for making the web faster/safer/better and all that. But I am worried about losing the web's "open by design" nature.
Much of what I've learned and am learning comes from me going to websites, opening the inspector and stepping through their code. It's educational. You learn things you may never read about in tutorials or books. And it's great because the author may have never intended for their code to be studied. But whether they like it or not, other people will learn from their code, and perhaps come up with [occasionally] better versions of it on their own.
This has helped the web development to evolve faster, and it's obvious how democratizing this "open-by-design" property is, and I think we should be concerned that it's being traded away for another (also essential) property.
Human beings cannot read asm.js code. And a bytecode format will be more or less the same. So, no matter how much faster and more flexible this format/standard is, it will still turn web apps into black boxes that no one can look into and learn from.
The problem of uglify can be mitigated if someone invented a binary format for JS that was interchangeable with the current text format. The format would reduce the code's size, while keeping it readable (you'd just have to run it through a binary-to-text decompressor).
I should also say that you can read uglified/obfuscated code. It just takes more patience. Example: if PS was written in JS and then obfuscated, how hard do you think it would be to find out how their color transformation algorithms are implemented?
You can't say the same thing for asm.js code though.
And reading from that data could be much faster. And with a supposedly smaller file format, it probably wouldn't be so necessary for a minifier to rename symbols to single-letter ones to save a few more bytes.
[Edit: added the following paragraph]
This could yield a smaller file format (which is what people usually want from JS minifiers), without sacrificing the readability of the JS code.
After all, if people cared about leaving their files readable, they'd just publish the non-minified version as well. Those who don't, won't avoid renaming either.
But that should only be tested in practice, so ... :)
If we shrink that other 90%, so that the formerly 10% is now 80%, renaming becomes more attractive.
This doesn't hold if people have a fixed problem with a fixed solution and fixed constraints... but problems and solutions grow.
Convinced :)
We already have gzip, although even with gzip minifying is useful, because gzip isn't content-aware. You can also enable source maps in production if you care about openness. The client doesn't have to fetch the maps/sources until developer tools is opened.
In fact, WASM's binary format is intended to be that way and apparently is yields more compression than using only gzip: https://github.com/WebAssembly/design/blob/master/BinaryEnco...
Saying that the open web lives on through open/free software also seems dubious to me. Most SaaS don't have their offerings up on Github.
I wonder if we're about to discover yet again with the browser itself why the browser beat several cross-platform VMs.
And on the subject of Web Assembly, if asm.js is the inspiration, great thing will come for it, really a new era for the web. For example, things like that https://github.com/audiocogs/ogg.js, and to me that's just a tiny glimpse on what the possibilities will become.
Smaller JS parses faster. gzip doesn't affect parse time.
https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...
I do agree though that asm.js is less readable than handwritten JS. However, as others pointed out, when handwritten JS is minified, it also becomes quite unreadable.
Overall, I think WebAssembly will keep the web about as human-readable as it currently is.
I think this argument is sort of a nostalgic one, especially with the advent of mobile apps. Mobile apps, their quality and responsiveness, are the standard on which software is judged. For the web to be a positive, competitive, open platform going forward, it's extremely important that user experiences (as in end user, not software developer js user) are the priority. As Brendan points out, parsing to turn something that's actually bytecode into bytecode becomes a hotspot, so this is a way of removing that hotspot. ASM.js has enabled webgl and canvas to have the ability to compete with native experiences... so progressing this out seems like the best way for the web to get better.
I don't think these two features, fast+readable, oppose each other. Not in the long run at least. I'm sure we can find a solution to keep the two together, as long as we consider both to be essential.
We could define a standard discovery mechanism for embedding a source URL, e.g. github repo + changeset, or PGP-signed javascript.
This would be even better than "View Source" (e.g. source provenance, change history and human reviews/comments), and the browser can still correlate runtime inspection with relevant source code.
I think many people would gladly opt-in to adopt the standard you proposed, but perhaps commercial projects won't have the incentives to do so.
We can culturally transform "view source" into a reputation metric that impacts visibility and revenue.
Look at the code snippets in the recent Bloomberg article, "What is Code", http://www.bloomberg.com/graphics/2015-paul-ford-what-is-cod.... Imagine a weekly NY Times list of Top 10 New Code, or Genius.com annotations, or CC-BY code comments which appear in search engine results, etc.
Society will increasingly care about coding, as writing code|prose influences thought, and more people will seek to understand the tools that make us as we make them.
Thanks for raising this important requirement.
Are there any books/studies/examples of commercial companies doing something like this?
Web site easter eggs and job ads-in-code are a precursor, http://www.bbc.com/news/technology-25826678 & https://www.smartrecruiters.com/blog/the-5-most-creative-dev...
W3C has an Annotations Group working in this area, which includes commercial companies and educational institutions, http://www.w3.org/2014/04/annotation/report.html
I suspect, though, that we still have not come far enough to be able to deal with this problem culturally in the mainstream. The technical solution you present would work exceptionally well along side licenses like the AGPL and would definitely be a boon to the free software community. However, are people as eager to provide freedom to others as they are to take advantage of it?
I choose to mention the AGPL on purpose because it goes a fair way beyond what you propose. It grants all 4 free software freedoms, not just the freedom to inspect code. I could well understand if someone felt that they were very keen on the one freedom to inspect code, but couldn't bring themselves to champion the other 3. The problem is that many, many other people feel exactly the same way about all of the 4 freedoms. Not only do they not see particular value, but they are actively opposed to it.
I think you would fight a losing battle trying to implement this in a standard. In the same way that I couldn't realistically expect to convince most people to use the AGPL in their web projects, despite the obvious benefits that I see, you probably could not convince enough of the powerful players to do this. As a programmer, once you live in a world where this freedom is ubiquitous, it is obvious and even jarring when the freedom is witheld from you. As a decision maker protecting corporate interests, it is merely a matter of tradeoffs and the value is not apparently clear. Certainly, it is not something that most people outside of the programmer community would want to encourage as the default course of action, even if they are willing to engage in it as an exceptional case.
Of course, I would love to be proven wrong ;-)
Github would have a lot to gain from such a standard, as they are already in the code history and metadata business. It could be prototyped with a browser extension, prior to standardization. In time, businesses will care more about software supply chain transparency, for open and closed code. A "View Source" standard could optionally request authorization before the source is made visible, e.g. from a private Github repo. The value comes from the run-time coupling of source and behavior, and it can be derived from source anywhere on the licensing spectrum between proprietary and public domain.
Or they could make a protocol to select which version you want to see: the webm or the plain JS. No need to mix external websites like Github in the loop.
It might be time for a WebDwarf debug format, though, to help us. Source maps aren't quite robust enough.
These alternatives wouldn't exist (or be so widely used) if the web provided the benefits that these tools give.
For example, look at how many people switched from CoffeeScript to ES6/7 once these languages started providing most of (and not all of) the benefits that CoffeeScript provides.
In all honesty, I don't think sourcemaps are the answer to the black-box problem.
If I'm right, we won't see wasm overused such that the web becomes a sea of monolithic and opaque apps (as too many mobile OS homescreens are). Per the FAQ, wasm is also for hot kernel code and reusable libraries helping mostly-JS apps.
It's up to web devs to keep innovating ahead of browsers, to keep pushing for better HTML, CSS, JS, and beyond. One way to do this might be via wasm modules that extend the web. The https://extensiblewebmanifesto.org/ project continues.
And I'm not sure if that's gonna be true.
For example, I'm sitting here, arguing for an open and readable web, and yet I can't wait for a rust-to-asm.js workflow to get stable enough so that I can move the perf-critical parts of my app to rust (you know, the part that could be learned from and hacked on by another developer).
WebDWARF then would be to WebASM, as DWARF is to ELF files.
Anyway, I think I should explain my thoughts better instead of only pointing out a problem. I wrote this comment: https://news.ycombinator.com/item?id=9743859
For example I may chose to write my code in Rust and that imposes a burden on you (assuming you know only Javascript), but it does not curtail your freedom. Not as convenient as before for you since you now need to learn Rust. I think the freedom has spread to the person who is creating the content (code). The general consumer does not care, but the tinkerer/hacker now needs to put in more effort to parse the creation.
If it's a one-way Rust source -> wasm transformation, even a Rust user might have a hard time following what wasm spits out.
i dont think view source has been instrumental to the web or education. yes there have been good moments and uses of it, we all have our anecdotes, but it's not a killer feature.
i would happily remove the ability to view source in favor of a faster, richer web site.
I think this feature is instrumental, or rather should be instrumental.
We are talking about the platform that will soon define the main medium of human expression. It's no less significant then everyday language. It should be open, by design.
there's 7 layers on the osi stack. there is no internet without them. do you need to know how all of them are designed to be "open"? even if you go on wikipedia and read the designs, you'll get an abstract view of them. but does that tell you enough? the implementations are all different.
focusing just on layer 7, the page you are viewing, do you need to see the actual html blocks, css, javascript to be "open"? of a sizable website, this front facing page is only represents a fraction of all the tools to produce the site. do you need to know how those hidden parts work too to be "open"?
i think the big distinction for me is HTTP vs Internet. if i click on a page and it includes a remote javascript file, i want to know that my computer is connecting to another server to get that file, but do i really have to be able to read it? my computer already connects to others over the internet in non-HTTP settings where I cant read what i'm getting.
Same thing with WebAssembly: wishing WebAssembly didn't exist isn't going to make it go away. It exists because there is a real need for it: the need to securely and efficiently run high-performance C++ codebases in a web browser. Not everyone has this need, and not everyone will use it, but WebAssembly (and asm.js and Emscripten) solve a real problem for some people, and they simply cannot realistically target the web without this technology.
I've written a more complete discussion here: https://news.ycombinator.com/item?id=9743859
That said, just as you can convert LLVM bitcode back and forth between binary and textual representation, you will be able to with WAsm as well.
It's still not as good as raw source, but I have definitely analyzed obfuscated/compiled JS without incident.
Good news then, because even when loaded from the binary representation, browsers will apparently be able to show a canonical text format representation. (more info here: https://github.com/WebAssembly/design/blob/master/TextFormat...) Citation:
> Will WebAssembly support View Source on the Web?
Yes! WebAssembly defines a text format to be rendered when developers
view the source of a WebAssembly module in any developer tool.In the demoscene it was very rewarding to be able to match other demos without having any help how the others have done it.
Now you just look at the code and be done with it.
WebAssembly is in itself probably a good thing, but yeah, as is evident from the replies you're getting, for lots of people readable sources simply isn't a priority or even a goal.
Which is probably why we have the GPL. But unfortunately, it's not seeing much use on the web.
There is a TL/DR at the bottom.
---
My main point is that we should see openness as a primary goal in the design of the web platform, alongside other primary goals such as performance and safety.
What do I mean by openness?
A web app is open, when I, a developer interested in how that app is implemented, can look at its code, and say "hey, this code handles that video, these functions manage those audio nodes that make the sounds I'm hearing, and this code decides what happens when someone clicks on that button," as opposed to "these are some ones and zeroes and I don't know what they do." [1]
What's the benefit of this openness?
I think the benefits are obvious, but for starters, when web apps are open, everyone can learn from everyone else's work. And they can build on each other's work. Web content evolves faster. And all of this is there by design. Authors don't have to opt into it. It's there and it's ubiquitous and it's just how things are. [2]
How does WASM endanger this openness?
WASM doesn't necessarily endanger anything. It's good. It allows devs to make faster apps, experiment with different semantics, and discover better ways to define the higher-level features of the web (as per the extensible web manifesto).
But it could also be bad. Here is a hypothetical example:
Imagine someone writes a graphics library for their app. It doesn't have the bloat of DOM. It's fast. And it allows him to make really cool apps.
But it's in WASM. It's not really a web app. Sure it has a URL and can't hijack your computer. But it's not HTML; others can't read it. It's not hackable. It's not mixable. It's not even indexable. Adblock can't tell its content from its ads. It's just a portable black box with a URL.
And devs have many incentives to write apps this way. Not all apps need to be indexed. And everyone could use the better performance.
So imagine a future where most web apps are made this way, each using a different rendering engine, written in a different language. I think it's clear why that could be bad. (Tell me if it's not.)
So, what do I propose?
I don't propose that we ditch ASM or WASM. These are steps in the right direction.
But we need to recognize that while safety/perf/better semantics are natural needs that drive the design of WASM, openness is not a natural need and it won't naturally affect WASM's design. Let me explain:
People need web apps to be safe; if web apps aren't safe, people won't open their browsers. People need web apps to be fast; if not, they'll have a reason to prefer native apps.
So, we have strong natural incentives to make the web safer/faster/etc. But we don't have any strong natural incentive to make it "open." So "openness," naturally, won't get enough attention.
But if we think that this openness should be a feature of the web, then we should treat it as a first-class feature, among the other features like perf and safety. Meaning that when making a decision about adding a functionality to the web platform, we should not only consider how it affects the web's safety and performance, but also what it does to the web's openness.
And we should communicate that to the community, especially when news like this come out. So that readers just don't assume that the web is only gonna get faster, but that it's openness is still gonna be a goal. This will also help create momentum and community feedback for this goal.
What does having openness as a goal mean in practice?
It probably means that committees would constantly look at what devs do in WASM land, and create standardized, high-level versions of them to be used by all developers [3], and also couple these features with great tooling and other benefits that are hard to replicate for WASM. [4]
This makes sure that developers have all the incentives to try to remain within high-level APIs and standard structures as much as possible (thus, keeping web apps readable/interoperable/etc), and only venture into WASM land when they absolutely need to.
I should conclude by saying that I realize this is probably what WASM's authors intend to do. But imho, it is just not being communicated very well. Many people don't notice that openness is a goal, some don't see its benefits. That's why we should communicate openness as a primary goal and write it in our documents, in huge black letters :)
>> TL/DR: Openness is important. There isn't much community momentum behind it (unlike perf and better semantics). There aren't natural incentives to focus on openness, so it might become an afterthought. Web apps might turn into high-performing black boxes. The black box part is bad. To prevent that, we should take openness as a primary goal, and communicate that with the community.
---
[1] WASM is more high-level than ones and zeros, but you get the point.
[2] Today's web apps aren't really open, per my duck-typed definition of "open." They're only open to some extent. It takes a significant amount of time and patience to understand how a certain feature is implemented in a typical web app. And I believe there is an opportunity to make that much easier.
[3] This is to some extent covered in the extensible web manifesto.
[4] It doesn't mean we should deliberately limit WASM's capabilities though. Let me know if I should explain better.
ps. I use compile-to-js languages exclusively. This discussion is definitely not a matter of taste or resistance to having to learn something new :)
So is PNaCl, with pepper.js. The difference there is that PNaCl also provided a more full-featured API, which nonetheless was harder for other browsers to support. Personally, I would have been happy to see NaCl-minus-Pepper standardized, since the sandbox would have been much easier to support than the APIs; browsers could then choose what superset of APIs to expose to that sandbox.
The difference between PNaCl and WebAssembly is simply that WebAssembly doesn't come with a pile of API expectations established by a single browser, and that it has the blessing of multiple browser vendors. Ignoring the API, the latter could have worked with PNaCl just as well.
I'm glad that asm.js is the starting baseline for this work, because its exact semantics are standardized via ECMA-262. All that has to be done to define its behavior precisely is to create a new syntax for it. LLVM bitcode, by contrast, has a lot of undefined behavior. You could try to spec a subset of it, but why go to that trouble when TC-39 has already done the work for you?
> Or if you mean that PNaCl has more features than asm.js, then the solution is to add those features to JavaScript.
Nope. A polyfill is a temporary solution, and will not be a permanent design constraint. I'm very glad to see that the constraints of JavaScript will no longer be a limiting factor on the web. I look forward to the day (already anticipated in the linked post) when a JavaScript polyfill is no longer a design constraint.
I see no good reason to add features to Web Assembly and not to JS. A Web Assembly engine is virtually always going to also be a JavaScript engine, so the implementation effort needed to keep them at parity will be minimal. And the demand from Web authors to add all the new Web features to JS will remain high. The likelihood of Web developers suddenly fleeing JS is comparable to the likelihood of WordPress migrating away from PHP. It's just not going to happen.
In terms of language: Myriad features from C, Python, Rust, and other languages. Static typing. Integers. Tagged unions. Real data structures. Efficient native code (asm.js does not suffice), which would allow implementing those.
In terms of libraries, a few off the top of my head: OpenGLES (no, not WebGL), real file APIs (both provider and consumer, and including memory-mapped files), raw TCP and UDP sockets (not WebSocket), a better and more efficient low-level rendering API...
> A Web Assembly engine is virtually always going to also be a JavaScript engine
Definitely not; browsers will include both for the foreseeable future, but a WebAssembly engine/JIT will be substantially different from a JavaScript engine/JIT, and compilation for WebAssembly won't go by way of JavaScript in browsers with native support. The article itself says the polyfill will be a temporary measure.
> And the demand from Web authors to add all the new Web features to JS will remain high.
> The likelihood of Web developers suddenly fleeing JS is comparable to the likelihood of WordPress migrating away from PHP.
There are web developers who actively like JavaScript, and there are web developers eagerly desiring another language; the latter motivates things like CoffeeScript, TypeScript, Dart, Emscripten, asm.js, Native Client, and many more, none of which would exist if every web developer was completely thrilled to write nothing but JavaScript.
And on the flip side, people who love JavaScript have created environments like node.js so they can use it outside the browser.
Everyone who loves JavaScript will keep using it, and it certainly won't go away. And JavaScript will be able to call almost all new web APIs. But not everyone will keep using JavaScript.
WordPress won't migrate away from PHP, but plenty of sites choose not to use WordPress.
Sure I do, with explicit permission granted. For instance, consider a web-based VNC client, without needing a server-side WebSocket proxy.
And there are far more where those came from.
Also, the advantage of making low-level web APIs is that any new high-level APIs built on top of them run inside the sandbox, so their implementation is not part of the attack surface.
[x] share all my contacts
[x] rummage through my images
[x] tap into microphone and camera at any time
[x] set my house on fire
Ideally they should be designed in a way that those feature unlocks get delayed randomly, so that they always "break" any code relying on those APIs by default. I.e. stuff should still work if the user doesn't give you the key to the city.
The lack of any kind of standard library comes to mind. The ability to use something other than Javascript, without having it compile to Javascript, would be fabulous. Being able to use something, anything other than a hodge-podge of HTML/CSS and JS for making a UI would be wonderful.
Sooner or later someone is going to invent a browser that can browse something other than HTML and HTML, CSS and JS will become legacy.
I'd be interested to know where/when this "polyfillable" term came about. It's not readily Google-able yet.
If there was no standard API, then sites would have a different API they had to use for each browser. Then we're back to the `UserAgent` days.
Unfortunately, I think it must be an all or nothing ordeal :/
> [...]browsers could then choose what superset of APIs to expose to that sandbox.
Pepper can already do that. All Pepper APIs are retrieved by calling a function provided to the module at start with a single string argument (ie `"PPB_Audio;1.1"` or `"PPB_Audio;1.0"` or `"PPB_FileSystem;1.0"`). It's impossible to use PPAPI without first getting the specific interface structures from that function.
You would need an API to send and receive messages between NaCl and JavaScript, but otherwise you could get away with just a sandbox that runs native code. Everything else could be incremental.
EDIT:
I see an optimizing JIT is planned for future versions: https://github.com/WebAssembly/design/blob/master/FutureFeat... while the MVP is primarily meant to serve as a target for C/C++.
Yes, but JavaScript can't be compiled to efficient WASM code. Dynamic-dispatch languages need an optimizing JIT -- compiling once runtime behavior is known -- to produce good machine code. In any event, it seems like it's a planned feature for a some future release.
(We may not be in disagreement here—I agree that JS can't be effectively compiled to Web Assembly as it stands.)
The design documents clearly state that WASM is intended to be a compilation target for C-like languages, and in the future may also contain a GC and an optimizing JIT.
Languages requiring a GC and/or not amenable to AOT optimization should -- at least for the time being -- continue to target JS as a compilation target (or implement their own runtime in a C-like language and embed it in WASM).
WebAssembly should support:
Producing a dynamic library and loading it into the current WebAssembly module.
Define lighter-weight mechanisms, such as the ability to add a function to an existing module.
Support explicitly patchable constructs within functions to allow for very fine-grained JIT-compilation. This includes:
Code patching for polymorphic inline caching;
Call patching to chain JIT-compiled functions together;
Temporary halt-insertion within functions, to trap if a function start executing while a JIT-compiler's runtime is performing operations dangerous to that function.
Provide JITs access to profile feedback for their JIT-compiled code.
Code unloading capabilities, especially in the context of code garbage collection and defragmentation.
I'd like to see something that works more or less to the effect of:
const wasmCode = new Uint8Array(...);
if (typeof executeWasm !== 'undefined') {
executeWasm(wasmCode);
}
else {
compileToAsmjs(wasmCode);
}If there were a way to flexibly invoke wasm in any scenario where asm.js currently works, I think it would be a lot friendlier and truer to the "it's just JavaScript" goal.
Furthermore, tying this to ES6 seems unnecessary to me. How does this affect those of us using Babel or TypeScript to output ES3 code? The purposes of wasm and ES6 just strike me as completely orthogonal.
---
1: There are good reasons we have to do this, but they're beyond the scope of this thread.
Could you import a module, and then call the resulting functions from within your Worker?
> If there were a way to flexibly invoke wasm in any scenario where asm.js currently works, I think it would be a lot friendlier and truer to the "it's just JavaScript" goal.
"it's just JavaScript" is a goal of asm.js; I don't see anything about WebAssembly that makes it a stated goal of wasm. "It works anywhere JavaScript works, and can call and be called by JavaScript" would be a more sensible goal.
> 1: There are good reasons we have to do this, but they're beyond the scope of this thread.
I'd be interested to hear them.
I have more detail here[1], but what it comes down to is that our application's security model is dependent on the ability to pack all of its code into one file.
I'm admittedly not too familiar with the ES6 module system (we're using TypeScript modules), but it looks like importing necessarily requires pulling in an external file. Workers are problematic in a similar way, but simple enough to work around using a few different methods (that I can't think of how to apply to ES6 modules).
> For workers, it should ... to a worker constructor.
In our case, the asm.js modules aren't being used as standalone workers, but rather pulled in to a worker that does a bunch of other stuff, so that probably couldn't be applied here exactly.
If that blob URL setup worked with ES6 import, though, that could work. (It might make things messier for generated TypeScript code though, not sure.)
> I wouldn't say this is "tied" to ES6, but rather intends to integrate nicely.
When I say tied, I mean in the sense that ES6 looks to be the only method of arbitrarily executing wasm code.
To use wasm, I'd need the ability to drop it in the middle of a block of JS.
---
1: https://docs.google.com/document/d/1j5KnpVyDdIXVwEDCQpHGxbs0...
Or maybe data uris.
> How does this affect those of us using Babel or TypeScript to output ES3 code?
Well, if you're already transpiling the whole load of ES6 features then it's just one more shim to consider, no?
[1] https://developer.mozilla.org/en-US/docs/Web/API/URL/createO...
Doing something similar for Workers, one of the problems we've had is that IE and I think Safari block that, so to make it work we have to fall back on a permanently cached shim that puts an eval statement inside self.onmessage. (Obviously no equivalent to eval exists for wasm, or I wouldn't have a problem here in the first place.)
(That link pointed to another link on module loading, a long page I didn't find an answer on right away. Admittedly I'm only curious for now.)
Added: https://github.com/lukehoban/es6features#module-loaders shows module loading of runtime-generated JS code, so the answer is probably yes, hurray.
As far as compiling within the browser, it sounds like compiling the wasm will be the same process as compiling to asm.js – except the final bytecode format won't be directly executable as JS. If that's the case, then I'd imagine any asm.js compiler could have wasm support added the same way emscripten will.
I think in both of our use cases it all just depends on how easy it will be to execute the code from there. (In your case, the worst case scenario is that you have to post the generated code to a server and redownload it – ridiculously ugly, but not a blocker.)
[1] https://github.com/berkus/Juice/blob/master/intro.htm [2] ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf
Oberon had name-based public/private methods, like Go. It had ahead-of-time compilation of bytecode, as you pointed out. It had CSP-style concurrency, again like Go. The web for the last two years feels like we're rediscovering Smalltalk and Oberon and acting like we've just invented everything anew.
My pal Michael Franz at UCI studied under Wirth. Michael and a PhD student, Chris Storck, did an AST encoder years back that influenced me and that I referenced re: wasm.
Oberon's great. JS was in the right place and right time. What can I say? I've been taking all the best ideas from the best projects and trying to get them incorporated, ever since 1995.
Someone did a similar article 'go vs brand X' https://news.ycombinator.com/item?id=943554
I get the feeling that this loop thing is slowing down. Genes have been passed vertically and horizontally enough times for everybody to be aware of them. So many languages get the same features now: closures, optional static types, generators, streams, list/map/set types, channels.
The next generation of programming languages should address safety and ||ism. Rust takes these on based on prior work (e.g. Cyclone) but with influence from C++ best practices, which I think is winning.
https://en.wikipedia.org/wiki/The_Pilgrim's_Progress
https://en.wikipedia.org/wiki/Whig_history
We'll see how Rust fare, especially with the recent stable release. Personally I'd like to see programming to aim at Haskell, even Idris. But let's not fantasize too much (especially in a thread about WebAssembl*).
ps: why on earth did cyclone not catch on ? I'd think people would jump on a C with less rope... https://en.wikipedia.org/wiki/Cyclone_(programming_language)...
Haskell, Idris, and I must add PureScript are great, but will not sweep all before. Especially when "systems programing".
Cyclone was (a) a research project and language; (b) too heavy on sigils. Rust started with sigils but ended in a great spot, with only & and region (lifetime) ` annotations. Usability, developer ergonomics, matter.
Of course, there would still be UI differences required between the 3 platforms, but you would no longer need 3 separate development teams.
But Java ran as an embed, not a browser-level feature, and was much slower to load than Flash (which came to offer much of the same functionality in an easy-to-use IDE).
For quite a while, I've been thinking about how instead of hacks like asm.js, we should be pushing an actual "Web IR" which would actually be designed from the ground up as an IR language. Something similar to PNaCl (a subset of LLVM IR), except divorced from the Chrome sandbox, really.
Edit: Really, it's annoying this didn't happen sooner. If Microsoft would have thought of this early on and pushed it, they could have gained a lead in compilers and developer tools, for instance.
Hopefully this will take more inspiration from actual assembly language and virtual machines, rather than from bytecode languages.
Most likely an API will be provided for interacting with a garbage collector, but it's completely optional.
The linked 'future feature' reads more to me like a mechanism to access the garbage collector already present in the browser to allow interoperability with JS and the DOM.
I'm hoping WebAssembly doesn't inherently imply a runtime.
What Rust needs is just a better RC implementation. This is because only a small part of your data is reference counted, so it fits better with how Rust works, so an efficient implementation allows it to combine with ownership semantics to outperform even very advanced generational GCs.
With WebAssembly, it sounds like they want the same sort of thing- let manual/Rust-style/etc. memory management work, but still allow the necessary integration into the runtime for a GC.
The present documentation seems to suggest that it won't really include a full-blown runtime, but may include a small number of builtin modules:
"The WebAssembly spec will not try to define any large portable libc-like library. However, certain features that are core to WebAssembly semantics that are found in native libc would be part of the core WebAssembly spec as either primitive opcodes or a special builtin module (e.g., sbrk, mmap)."[1]
This brings up the natural question of libraries and dependency management in WASM. Will there be a WebAssembly equivalent of Maven/npm/et al.?
[1]: https://github.com/WebAssembly/design/blob/master/NonWeb.md
Threads themselves may be "ugly", but to build all the pretty abstractions you need them as foundation.
While this is welcome news, I am also torn. The possibilities are pretty amazing. Think seamless isomorphic apps in any language that can target WebAssembly and has a virtual dom implementation.
However, it finally seems like JS is getting some of its core problems solved and is getting usable. I wonder if it might have short term productivity loss as the churn ramps up to new levels with a million different choices of language/platform.
Either way, it will be an interesting time... and a time to keep up or risk being left behind.
This announcement means JavaScript can no longer rely on "you must target JavaScript to work on the web" as a motivating factor. The set of people who like JavaScript as a language in its own right can keep using it, and will have the advantage of new JavaScript engines and extensions implemented on top of WebAssembly. However, the set of people who would rather write in another language will no longer be constrained by waiting for JavaScript to catch up.
Personally, I think this will be a good thing for both JavaScript and other languages.
Scala.js[0], GHCJS[1], and Js_of_ocaml[2] among others.
Ah, missed that, assumed OP meant if only there was a way to write JS without having to write JS.
I am really enjoying it and I don't see myself going back to writing JavaScript by hand anytime soon. I use it to do some frontend stuff that involves DOM manipulation, XHRs, WebSockets. Another use is WebGL, it allows me to write simple multi-platform games in Go that target OS X, Linux, Windows, but also the browser. I would not be writing those games in JavaScript by a long shot.
"Prepare for"? As if that hasn't happened already, with virtually every modestly popular language having at least one web-use-oriented compile-to-JS transpiler, and several new languages being invented whose only implementation is such a transpiler.
WebAssembly makes the process easier, and may make it easier to maintain those along with the non-web implementations of the languages, but its a little late to prepare for the onslaught of web-targeting language implementation.
Assuming wasm delivers on its promises, that should change, and that is when those languages will stop being mostly experiments but real viable platforms.
* GC
* Interoperating with browser objects (even strings)
* Debugging and other tooling
I don't think any high level language will be able to compete with JS on an even playing field until that language can use the high performance GC that's already in every browser.
If your language has to either not use GC (huge productivity loss) or ship your own GC to the end user with your app (huge app size), it's an unfair fight.
And that won't change in the MVP of this, where JS will still have capabilities that WebAssembly-targeting languages won't have. But their clear vision is to make WebAssembly a VM that puts languages on equal footing, with tooling and debugging that works cleanly for all targets.
Meanwhile, this is going to allow people to port really dumb things into the browser and expose all sorts of new crazy.
Still neat, I agree, if you prefer native code. That said, it's not an unalloyed good.
I'm not even joking when I say an RPG IV compiler would probably make you some cash.
Of course, I knew people who wrote their website in COBOL (Micro Focus COBOL to be specific). This would probably please them greatly.
No! WebAssembly is designed to be a complement to, not replacement of, JavaScript (JS). While WebAssembly will, over time, allow many languages to be compiled to the Web, JS has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. "
https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...
The WebAssembly team is being incredibly thoughtful and open about their motivation and long-term plans, which is very refreshing.
Any language can now target that specific bytecode without the need for javascript transpilation.
For instance Flash can target this format in place of the Flash player, making swf files future proof since backed by standard web techs.
So it's basically the return of Flash,Java applets and co on the web. And web developers won't have to use Javascript anymore.
The only constraint is obviously the fact that the bytecode has only access to web apis and cant talk directly to the OS like with classic browser plugin architectures.
What might be the reason?
Nos Oracle isn't interested in Web.
1. They impose Java's class and primitive type model. 2. They allow irreducible control flow. 3. They aren't very compact. Lots of redundancy in constant pools across classes and still a lot of possibility for compression. 4. Verification of JVM class files is an expensive operation requiring control and dataflow analysis (see stackmaps added in the Java 7 class file format for rationale). 5. No notion of low-level memory access. WebAssembly specifically addresses this, exposing the notion of a native heap that can be bit-banged directly by applications.
There are at least two distinct types of content - structured/unstructured content that should be exposed and can be indexed via some known mechanism by external visitors, and application content that perhaps need not be indexed.
This might be a time to evolve/establish what those mechanisms are for the betterment of both application development and content development/sharing.
Similarly, just because it'll be possible to implement a full web engine efficiently in WebAssembly doesn't mean sites will suddenly stop paying any attention to standards or accessibility.
As for adblockers, I can think of several ways to block ads in such a world, including hooking the sockets API to block or sandbox access to ad-serving hosts, or providing hot-patches that stub out common ad-serving libraries. It'll get harder, but not impossible.
(And a disaster for the companies that build them and get sued later.)
I'm saying that div-itis is possible today, but it's a bad idea, and as far as I can tell many new sites still use semantic markup when available.
Along the same lines, I would expect that even if people implement a web engine in wasm, many will still use semantic markup.
That said, I agree that people don't pay enough attention to accessibility, and should. But I don't think wasm or wasm-based rendering engines will make that worse.
If you go all-in on wasm to do "your own rendering", external software won't know where to find a "DOM" or how to understand it, unless some other kind of reinvented HTML-for-a-wasm-rendering-engine-defacto-standard is invented?
(This is more a rant against "let's reinvent html/css in canvas" rather against a VM-based javascript replacement in general. Even though the latter sounds a bit terrible as well for the open web; imagine what the web would have looked like if .js never existed, and a flash/java .swf/.jar engine was the only way to do scripting in a webpage.)
So when you start talking about ignore-the-DOM stuff, my strong suspicion is that it would all be completely and totally inaccessible.
I’d argue we already lost.
The browser becomes a simple kernel which knows how to execute a bytecode (their so-called "Syphon Interpreter.") The browser itself provides much simpler, lower-level APIs for doing I/O.
To actually render a page you still need a layout engine, a renderer, and maybe a scripting runtime. The difference is these components are provided _as bytecode at runtime_, they're not shipped as part of the browser itself.
Your page then specifies the environment it needs by requesting the different components you need. Then you just let the environment go to work on whatever page you served.
---
[0]: http://research.microsoft.com/apps/pubs/default.aspx?id=1546... [1]: https://www.youtube.com/watch?v=4c0DdOvH6lg
The Web evolved to do incremental/progressive rendering, it's one of the best aspects. Undumping a frozen Dart heap was a goal to speed up gmail, but over long thin pipes (my "LTE", most of the time), incremental/progressive wins.
Sure, games come in big packages and good ones are worth the download time. For most other apps, small is beautiful. iOS app update still sucks, not just because semi-automatic.
LLVM bitcode is simply not a good fit for this:
* It is not portable.
* It is not designed to be compact.
* It is not designed to be quick to decode and start up
* It has undefined behavior
* It is not sandboxed.
* It is a moving target (see recent big changes to LLVM IR on geps and loads/stores)
Each of those can be tackled with a lot of effort. But overall, better results are possible using other approaches.
They are doing great work. The client's operating system matters little now, but it will not matter at all soon.
e.g. if I allocate a callback function, and hand it to setTimeout, I have no way to know when to collect it.
Sure, you can encode rules about some of the common functions; but as soon as you get to e.g. attaching an 'onreadystatechange' to an XHR: you can't follow all the different code paths.
Every time a proposal comes up to fix this:
- GC callbacks
- Weak valued maps
- Proxy with collection trap
Unless this is attended to Javascript remains the required language on the web.
Note turn-based notification. No way will exact GC schedule be leaked via callbacks from the GC. Ditto anything like Java's post-mortem finalization.
But your "e.g." is unclear, though. Why do you need to manually deallocate a callback function passed to setTimeout?
Got a link to the memo? I haven't heard about this one.
> Why do you need to manually deallocate a callback function passed to setTimeout?
One of my use cases is running lua in the browser. see lua.vm.js: https://kripken.github.io/lua.vm.js/repl.html
When you pass a lua function to a javascript function, I create a 'proxy' object that holds a reference to the function in the lua VM. Only if javascript tells me it's "done" with it can I drop the ref inside the lua VM.
We'd need to synthesize a JavaScript function that holds a wrapper object for the C++ function, and that wrapper object would need to be deallocated when the timer is done. For general callbacks, this is a hard problem, and finalizers would provide a clean way to solve it.
https://esdiscuss.org/topic/weak-event-listener#content-2
It's hard to find something fresh. I will stir the pot at the July TC39 meeting and get the committee on the record for weak refs with turn-delayed notification, or bust!
> https://esdiscuss.org/topic/weak-event-listener#content-2
> It's hard to find something fresh. I will stir the pot at the July TC39 meeting and get the committee on the record for weak refs with turn-delayed notification, or bust!
As recently as September last year you told me it may happen... but with an indeterminate timeframe: https://mail.mozilla.org/pipermail/es-discuss/2014-September...
WeakMaps are only really useful when you don't control the referenced object's lifecycle. Even then, you can simply invert your map or check in your callback.
That works well for JS... but if you are trying to use asm.js (or now wasm), you need to act on things getting garbage collected inside of your code.
Any asm.js code that calls into DOM apis is going to need this. Otherwise they don't know when to free stuff.
Most of the current asm.js code out there just binds a single canvas element, and works with that. But if you want to actually call anything else....
For that matter, though in the short-term this will be polyfilled via JavaScript in browsers, it'll be fun to see the first JavaScript-to-WebAssembly compiler that allows you to use the latest ECMAScript features in every browser.
Currently wasm can't access web APIs except by calling out to JS, which would then call the API, but in the future, direct calling paths are intended.
This sounds absurd. I can't even get through getting Clang, LLVM, and Emscripten built from source as it is, it's such a house-of-cards with configuration and dependency settings. Have any of you tried building Chromium from scratch? I have, on three separate occasions, as I'd like to try to contribute to WebVR. End result: fewer gigs of free space on my hard drive and no Chromium from source.
Part of that is my impatience: I'm used to C# and Java, where dependencies are always dynamically linked, the namespacing keeps everything from colliding, and the semantics are very easy to follow. But even Node's braindead NPM dependency manager would be better than the hoops they make you jump through to build open-source C++ projects. I mean, I just don't get how someone could have at any point said "yes, this is a good path, we should continue with this" for all these custom build systems in the wild on these projects.
I could be way off. I'm only just reading the FAQ now and I'm not entirely sure I understand what has actually been made versus what has been planned. There seems to be a lot of talk about supporting other languages than C++, but that's what they said about ASM.js, and where did that go? Is anyone using ASM.js in production who is not Archive.org and their arcade emulator?
I don't know... I really, really want to like the web browser as a platform. It has its flaws, but it's the least painful solution of all of the completely-cross-platform options. But it's hard. Getting harder. Hard enough I'm starting to wonder if it'd be smarter to develop better deployment strategies for an existing, better programming language than to try to develop better programming languages for the browser's existing, better deployment strategy.
This telephone game being played by translator tools and configuration management tools and polyfills and frameworks and... the list goes on! This thing we consider "modern" web development is getting way out of hand. JS's strength used to be that all you needed was a text editor. Everyone--both users and developers--can already use it and run it.
If it's just one tool, I'll get over it. But stringing these rickety, half-implemented tools together into a chain of codependent systems is unacceptable. It just feels like they're foisting their inability to finish and properly deploy their work on us. Vagrant recipes are nice, but they should be a convenience, not a necessity.
Sorry. Good for them. Just finish something already.
Don't you think developer tools should have good UX, too? Microsoft does, and Visual Studio just works. Oracle does, and Java and Netbeans just work. Even setting up Node and NPM was a better overall experience than trying to get Emscripten working correctly and integrated into my projects.
Emscripten and NaCL are both like 4 years old now. Why hasn't there been greater adoption of these tools? I postulate it's the bad UX. I mean, Emscripten only working with VS2010, three whole versions behind latest, is a pretty good indicator that there is a whole class of users that have just written it off. Is there any concern for that with WebAssembly?
Things took a while because vendors had their own prior paths to pursue, while asm.js had to prove it could get close enough to native perf. (You could say Mozilla's prior path was JS.)
Tools for JS are pretty good; VS does TypeScript and JS, will do wasm. Firefox devtools are giving Chrome devtools a run for their (bigger) money.
I think tools are the least of it, while agreeing they make a difference (see Mandreel with VS integration, vs. Emscripten).
NaCl (PNaCl, you must mean) never went cross browser as such, nor could it. WebAssembly is the PNaCl end-game, and a pretty good one.
As for Emscripten, it's a huge win that both Unity and Epic (Unreal Engine) support JS/WebGL as first-class targets. This happened over the last few years, tools built into the game engines. Doesn't disprove your point, you could be right! Let's find out.
For myself, I've had very little to complain about web development since '08 or '09. It became an application platform for me with the emergence of the canvas tag, and since then it has grown into a full operating environment of sorts. There have always been awkward and limiting features to the web because it is such a hodgepodge and I think that's where most of the complaints come from. But the browser compatibility situation continues to improve, which has always been my biggest gripe.
I worry a bit about the exploit potential of WebAssembly as more features are layered atop what Asm.js offers. Don't add too much, okay? ;)
I see any web-scale runtime standard inevitably having versions spread across the installed base of any server, so prone to the same pressure JS was, which led to polyfills, graceful degradation, object detection, monkey-patching in full. People who complain about this are complaining about physics.
You're right to worry about security, which is why the "MVP" for wasm is co-expressive with asm.js, just faster-to-parse syntax. After that, we must be even more careful.
And great work, this is very exciting news.
Not really. NaCL was limited to a single browser, and asm.js was a stepping stone towards a bytecode for the web. WebAssembly has support from the major browser makers, plus a (mostly) clean slate for developing a bytecode suitable for the web. This is a golden opportunity for the web to evolve into a high performance application platform.
As for tooling, C# and Java are anomalies, no other languages come close. What sets those two languages apart? They're very popular in the commercial world, and they're based on virtual machines (C++ and JS may have decent tools, but I'd rather debug C# than, and part of that is the ability of the compiler to understand the program structure). A universally supported bytecode for the web is very likely to decent tooling.
I spent a bit of time to write a set of python cmake wrapper scripts which make cross-compiling to 'esoteric' targets easier (see here: http://floooh.github.io/fips/), it doesn't solve the problem to directly develop/debug for emscripten or NaCl in an IDE, but it lets you easily switch between cross-compile-target configurations, with the idea that you write and debug your code as native desktop application in VStudio, Xcode or QtCreator (or any other IDE supported by cmake), and then only cross-compile to emscripten, NaCl or Android NDK on the command line. In my experience, 99% of bugs happen in the platform-neutral high-level code, and are caught by debugging the native desktop version.
Is there a possibility for JS tooling? Babel etc? Or any compile-to-JS language like CoffeeScript, TypeScript etc being able to emit/convert to wasm?
Or maybe I'm missing the whole point of this? :)
I did notice that es6 import/export works for Wasm, so I can write performant segments in C. Whew!
If you want that from your JS codebase, I'm sure it would happily compile to Wasm - you'd probably find that a JS-to-Wasm compiler would be one of the first proofs-of-concept for Wasm.
In contrast, wasm is for C and C++ first, and in due course many languages. The C/C++-first design point is a way of limiting scope creep and catering to important native-code use-cases (games, AI, CV, etc.). It's the starting point, not the final state. But it involves the usual static types trade-off that reduces runtime overhead.
Therefore a full JS engine in wasm would not run very fast compared to today's in-browser JS VMs, which are evolving to be JS/wasm VMs. For dynamic languages to compile to efficient wasm, we'll need the future JIT-generated wasm support and other desiderata on the roadmap. These come after the "MVP" that is co-expressive with asm.js.
So the proof of concept for wasm must start with asm.js and grow to PNaCl in full (which has had APIs and optimizations that asm.js or JS and the Web APIs have not provided yet), and then on to dynamic language runtime support. HTH.
Another dynamic language support part of wasm's roadmap that's post-MVP: GC support, both for GC of allocations from wasm code, and for references from wasm memory into the JS (DOM whatever) object space. One GC to rule them all, and one VM too.
I have no experience building emscripten, but clang/llvm, i do.
Clang/LLVM are really easy to configure using cmake on any platform, and the configuration process just works. So why don't we start with: "What is the exact problem you seem to be hitting in doing this"?
Among all dependency managers I've used, npm is by far my favourite so this comment took me a bit by surprise. Which dependency manager do you like ?
I guess nobody ever said that. What people most likely were saying was: "This is a mess, but the expected costs of continuing this path will probably not be greater than the expected costs of changing course".
Note that there's a double "expected" in there. Making decisions under uncertainty is hard. On the other hand, taking a look from the outside and replacing every "expected costs" with whatever turned out to be the case is easy.
"A binary encoding of JS ASTs, maybe (arithmetic coders can achieve good compression; see Ben Livshits' JSZap from MSR, and earlier work by Michael Franz and Christian Stork at UCI). But this too is just a gleam in my eye, not on TC39's radar."
And WebAssembly is indeed a compressed AST encoding, not a stack bytecode. Shhh, don't tell anyone. You can still call it bytecode if you like.
(And thanks for the info!)
This might even go as far as languages, though for this to work well, the code would have to cover an intersection of the functionality in all the languages "rendered" to.
(Haven't watched the presentation yet. I'm in public without headphones.)
Both well tested, well executed, great tooling, supported on many platforms, compilation targets of many existing languages.
Serious question.. is it licensing ?
I was about to ask the same question. Because once you require browsers to support something other than JavaScript, that's equivalent to requiring browsers to come with a Java plugin or CLR plugin or Flash or Silverlight installed.
It seems to me the only difference is that the web.asm plugin's inventor is the influential inventor of JavaScript, and can harness the support required to add a plugin to all browsers going forward. (unless of course i don't understand this proposal, which is entirely possible).
2. If you have both the CLR and a JS engine in the same browser, you have problems with cross-VM GC cycles and the overhead that causes. That is one reason why WebKit opposed adding Dart bindings, for example. WebAssembly is designed to integrate with existing JS VMs.
3. Both Java and the CLR are open source, but both are patented. Both have licenses for those patents, but this has been the cause of much debate, as there are corner cases in those licenses (e.g. if you do not fully implement all of the VM per the license, you may not fall under its protection). This could be resolved - all existing patents could be offered up to the public domain - but I don't see Microsoft or Oracle (and there may be others with patents) doing so.
One question though - I found a proposal somewhere on a Mozilla run wiki about a web API for registering script transpiling/interpreter engines. I've lost the web address, but if anyone know any more about this is love to see it rekindled.
For our use case, what I like about this is that we can continue to use emscripten and the technology will come to us, rather than requiring app developers to invest in yet another technology (our switchover from NaCl to emscripten was very time consuming!)
Politically it appears to be a fantastic collaboration.
Technically it looks like they have really thought through this hard -- if you look through the post-MVP plans (https://github.com/WebAssembly/design/blob/master/FutureFeat...) there are a lot of exciting ideas there. But it's not just pie-in-the-sky speculation, the amount of detail makes it clear that they have some really top compiler people who are really rigorously exploring the boundaries of what can be accomplished inside the web platform (SIMD, threading, GC integration, tail calls, multiprocess support, etc).
http://llvm.1065342.n5.nabble.com/RFC-WebAssembly-Backend-td...
We will probably need a package manager after that (like apt or npm).
A use case could be with ImageMagick, OpenCV, OpenSceneGraph or qemu inside the browser. All of them are huge and useful projects with many common dependencies.
This made me laugh, sadly. They get the modern Web because they aren't winning at native app development.
Does anyone know when all this started? I ask because only 83 days ago Brendan was on here telling us pretty emphatically that this was a bad idea and would never happen.
Anyway great work man. It's a happy day.
Here's Tim Sweeney on diff between "bytecode" and wasm:
https://twitter.com/TimSweeneyEpic/status/611237145857138688
Not quite the Tetralogy of Tony Stark (genius, billionaire, playboy, philanthropist) but I'll take it! ;-)
And no, webworkers don't cut it, because they don't support structural sharing of immutable data structures in an efficient and flexible way.
https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...
This means the MVP wasm likely includes threads (same timeframe, later this year), and post-MVP wasm can go for full-strength pthreads.
Ironic that Eich is the one to pull the trigger on JS.
Sure it is. Step 1: get all browsers to support WebAssembly, so that sites can drop the polyfills. Step 2 (specifically noted in the article): make WebAssembly more full-featured than JavaScript, ignoring the ability to polyfill it because browsers have native support. Step 3 (potentially doable before 2): implement JavaScript in WebAssembly, so it becomes just one of many possible languages, and its implementation is no longer beholden to browser quirks.
That'll make JavaScript a better language for its proponents (latest ECMAScript features everywhere), and entirely avoidable for people who prefer other languages.
We can wager about when it might actually die (I said it might given something like wasm, at Strange Loop 2012), but that's beyond the horizon by years if not decades. Gary Bernhardt knows!
And anything caring about performance can start targeting WebAssembly directly rather than JavaScript. CPU-bound JavaScript performance will start mattering a lot less. (DOM-access performance will still be critical, but it will be for WebAssembly too.)
S'ok, I'm obv. a supporter of the latter, although it'll take some time to make win for smaller programs.
I'm not suggesting dropping JS; that's too much to hope for. If nothing else, backward compatibility with existing sites will require supporting it approximately forever. I never intended to imply dropping it, just that WebAssembly becomes the interoperable baseline, with JavaScript and other languages being peers on that common baseline.
I disagreed with the statement that "JS isn't going anywhere"; I don't think it's going away, but it's clearly going to evolve and go new places.
It won't have zero performance overhead, since unfortunately it will still require translation to native code. But it'll be far higher-performance than asm.js, and precompiling JavaScript to WebAssembly could produce higher performance than a JavaScript JIT.
> and still doesn't address the fact that JavaScript "binaries" will be much larger than today's scripts that rely on a JavaScript interpreter being present inside the browser.
You don't need to do the compilation in the browser; do the compilation ahead of time and ship wasm bytecode. The DOM and all other web APIs will still be provided by the browser, so I don't see any obvious reason why wasm needs to have substantial size overhead compared to JavaScript.
If wasm is already intended to be crippled relative to Javascript, it really throws into question why wasm should exist at all. When the response to eventually implementing Javascript on top of browser wasm support is "dream on," like because Javascript on top of wasm will suck because it leaves too much performance on the table, that raises the question of why we think building on top of wasm will be acceptable for languages other than Javascript. If building on top of wasm is unacceptable for Javascript, why isn't it unacceptable for everyone else?
Maybe this also throws into question whether any discussions supposedly shaping the development of a new cross-vendor standard are really in good faith, if the reality will be that nothing new is made other than a new spelling of Javascript, and that wasm will be forever steered by Javascript and incapable of meaningfully hosting an implementation of Javascript because it has been intentionally crippled to require an implementation of Javascript.
Anyone who wants wasm to become a real thing has to be cautious that it is not crippled in order to prevent it from being capable of replacing Javascript (whether it actually does replace Javascript is another issue which can really only be asked if we assume wasm is not already sabotaged to be incapable of that).
Web sites move to new technology at a glacial pace. You're posting this comment on a Web site that, by and large, hasn't even adopted CSS 1.0 for layout yet.
https://mail.mozilla.org/pipermail/plugin-futures/2010-April...
The collaborative aspect is important, but one side of a coin whose other side is polyfillability. Nick Bray of the PNaCl team stubbed out Pepper.js more recently, and JS finally got some SIMD and threads love. It's all converging, finally. Yay!
Ditto for data structures (with actual layout, not JavaScript "bag of key-value properties" objects).
Ultimately, I'm hoping new web APIs will be specified as a WebAssembly ABI, without taking JavaScript into account; the JavaScript interface to those APIs can be responsible for questions like "how do I call a function specified as taking a 64-bit unsigned integer?".
It's a fine example for today's browsers that don't have those. Fixing that for future JavaScript doesn't help APIs being designed today, or existing APIs. And it doesn't invalidate the point that JavaScript limitations should not be web limitations.
For instance, how about efficient structs with defined in-memory layout?
Targeting web APIs to WebAssembly means that the web can tell JavaScript to keep up, rather than JavaScript telling the web to wait up.
Please use the same yardstick when comparing.
Important that JS grow too, including SIMD, shared memory, value types including 64-bit int. Does not alter the case for wasm, per the FAQ: parse time win soon, divergence to relieve JS from serving two masters in longer run.
"Fixing that for future JavaScript doesn't help APIs being designed today, or existing APIs."
and I asked
"Wait, how does wasm help APIs being designed today?"
Your different yardstick is the shift from "today" to "future". WebAsm that is a super of JS is in the future, past the polyfill era of co-expressiveness. Fault JS today for lacking int64 by the same (temporal) yardstick should fault wasm today.
In general we agree, but you are arguing carelessly. There is no essential difference between int64 for JS in the future, and int64-equipped wasm in the future. Both are in the future.
The solid ground on which to argue is where browsers all update to support wasm, whose syntax and extension model(s) stabilize, and then wasm can run ahead of JS. But it'll be a managed standards, so don't expect a huge iteration-time win. It'll be good for both JS and wasm in that farther future to decouple concerns, I agree.
Are we done yet?
Even the planned future ABI for interoperable dynamic linking is a guideline; any caller and callee that agree can use a different, extended ABI.
> The solid ground on which to argue is where browsers all update to support wasm, whose syntax and extension model(s) stabilize, and then wasm can run ahead of JS.
Of course, and that's exactly the world I'm talking about.
> But it'll be a managed standards, so don't expect a huge iteration-time win.
WebAssembly is in a very critical way smaller than JavaScript, so its iteration time is less important. wasm iterations will be important for performance (to provide constructs that will efficiently translate to the native machine code you or a compiler would have written), and we'll need new APIs for things like thread-spawning, but new language features and functions using those features won't require any changes to wasm.
> Are we done yet?
By all means let's stop violently agreeing with each other. :) Thanks for working on WebAssembly; I look forward to using it.
Has there ever been such a thing?
See: Adding Delimited and Composable Control to a Production Programming Environment
Even worse, it's like Flash but where the flash 'plugin' has been written from scratch by each web browser, giving us endless possibilities of incompatibilities which are a nightmare to fix.