I always feel like the most obvious use for it is to start writing truly hateful and abusive code.
I'm sure this is because I'm getting old.
You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse.
The JavaScript environment on the web reminds me of the "walled gardens" that were Lisp machines back in the day, that force you to write code in Lisp, or if you wanted to write in C you would get end up with a bit of a nightmare on your hands. The Lisp machines were beautiful and integrated and the source code was everywhere, but they weren't for everybody, and in the end it was the diversity of Windows, Unix, and Mac OS that replaced them.
WebAssembly is Unix, JavaScript is a Lisp machine.
It's pretty straightforward. Both tend towards the Big Binary Blackbox Blob.
It's true that WebAssembly has advantages Flash, Java, and Silverlight didn't really have in terms of being freely reimplimentable and (potentially) native to the browser. And it's probably a good thing that a browser can be a VM via a target-intended subset of JS. BBBB may be the right thing for some applications.
But to the extent that the browser becomes something developers see primarily as The VM That Lived (and there are clearly a lot of developers in this boat) yes, we're forgetting lessons we should have already learned from the difference between Flash/Java and the open web.
> You already can't just read someone's JavaScript code if they're using a transpiler or uglify or something like that, it looks like line noise and you basically have to go through a lot of work to reverse engineer it. WebAssembly is no worse.
I'm clearly in the minority, but I had qualms about uglify and other source manglers from the beginning for the same reasons people have qualms about Web Assembly: they break the benefits of view source.
I get that they can also be tools that help squeeze out performance, and I use them selectively for that reason, but as far as I can tell, most of the web development world uses this as an excuse to stop actually thinking about the issue -- and for that matter, to stop thinking about how they're putting together their web app ("we're using minification and gzip and doing an SPA using Ember/Angular/LatestDesktopLikeFramework because that's what professionals do now, why do we have performance problems?").
Similarly, I've seen a lot of people use compiling to JS as an end run around what are essentially aesthetic/subjective issues with JS as a language when they'd probably do just as well spending more time learning to use it (as far as I can tell in years of working with all of them, JS is in exactly the same league with Python and Ruby and Perl other similar dynamic languages). That doesn't mean there are no beneficial cases for JS as a target (personally, I'm intrigued by Elm), but I think I'm justified in being afraid that people will use it as insulation from superficial problems.
> that force you to write code in Lisp
Lisp doesn't force you to write code in Lisp. That's one of the reasons why it's awesome -- and potentially horrible. Transpiling/compiling can be similarly awesome and potentially horrible for a lot of the same reasons.
Lisp machines come with Fortran and C compilers.
The irony of this is that almost no UNIX offers a compelling, complete developer integration outside of things which produce slavishly detailed C-compat layers that introduce an ever growing number of undefined behaviors.
It also ignores that many lisp machines actually shipped with compilers for competitive languages. LispMs just had a lot of work (for the time done) on optimization for lisp environments. We take for granted the trivial execution overhead of interactive environments but this was no small feat back in the feat.
Isn't this an argument against WebAssembly? We've already made the mistake once.
Most of the program logic can remain standard Javascript, but the little kernels of hot numerical code can be much more effectively optimized.
This gives Javascript/browsers the ability to handle problems which were previously only possible to tackle with native C programs.
JavaScript will continue to be dominant, but we desperately need to be able to write things in the language of our choice.
You are better off re-inventing Java or Python, but in a container and streamed over the Internet from an URL.
I've used a lot of different languages including Java, C#, C++, AVR Assembly, Python and others but JavaScript is my favourite and I would not want to go back.
I think its a shame that some people just didn't seriously try JavaScript. It's a very powerful, expressive language.
Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like redefine entire objects, properties or methods at runtime (for stubbing).
Also, JS is great for writing asynchronous logic.
If we turn the web into an anything-goes bonanza using binary code without any keys, credentials, or permissions, WebAssembly (and Turing complete CSS as well) may be well the beginning of end of the web as we know it, giving raise to a new, leaner and more restricted platform (for which some are already on the lookout, BTW).
[Edit] A small real world example: Client asks me to implement a third party plugin to allow them direct communications with their users via their website. A quick scan of the source code tells in a minute that the script isn't just doing that, but is also tracking user behavior and is phoning home related data. Now I can ask the client, if they really want to expose their users to this. With WebAssembly, there's no chance to do so.
Flash presents a single platform with a single vendor that can innovate as quickly as they like. The web platform is inevitably cumbersome and slow in comparison -- over a decade later they're still playing catch-up.
I'm looking forward to WebGL ads that eat battery life with excessive shaders.
The whole "anyone can look at it, learn from it" part is gone?
We’re steering towards more proprietary code.
Say, for example, if I want to run Google’s "Star Wars" easter egg in Firefox. With JS, I could grep through the de-uglified and de-obfuscated code quickly, and find that its useragent detection would work if I’d just append "AppleWebKit Chrome/45.0.0.0." to the UserAgent. With WebAssembly, I’d have to spend far more work.
1. Performance critical code 2. Sneaky stuff I really don't want the user to be able to read.
Category two seems like the sort of thing that I would absolutely want to be able to write binary code that executes without user interaction.
It seems like right now the focus is quite rightly on #1, but that #2 seems like it will inevitably become an issue.
> I always feel like the most obvious use for it is to start writing truly hateful and abusive code.
Sure, but it will also developers to have a better experience by allowing them to chose the language they want, and not to be forced to use JavaScript. Choice is good, it's something you cannot deny.
Only if you miss the obvious and blatant technical and license differences.
Current (desktop) operating systems were not designed for a world where you routinely run code from someone on the other side of the planet who you have no relationship to, and don't trust, so you can see cat pics or read a forum.
Browsers have a lot of problems, but their security model and ephemeral install model are inspired designs, which directly enable the safety of the modern internet.
Having to fall back to classic desktop apps for real speed or power is a terrible thing for end-user security. Either browsers need to get more powerful, or desktop OSes need to take on a browser-like security model.
So the process model is not fundamentally different than the browser model, but WebAssembly enjoys two advantages:
1. The browser security model sagely segmented privileges by origin rather than user.
2. Like bytecode, WebAssembly AST does not target a specific processor.
I see no reason why each domain couldn't have a chroot for example, the browser doesn't need to implement those things.
Actually it can sandbox them already.
Web browsers have been like operating systems all along, because they execute programs, albeit with different performance and safety characteristics. That the two are converging upon the same solution to the problem of hosting apps should be reassuring, not concerning.
And before that in the 80s, there was UCSD Pascal. I know it was available for the Apple ][ (used it in high school) and the IBM PC (one of three operating systems available when IBM launched the IBM PC in August of 1981) and probably a few other platforms I'm blanking on. A defined VM and "executables" could run on any platform running UCSD Pascal.
And even before that, IBM pioneered VMs for their own hardware, which is probably what inspired UCSD Pascal in the first place.
Cross platform is a red herring. The iOS and Android app stores are not cross platform. Ease of use is also increasingly a red herring. The Windows and Mac app stores have been around for a long time and are quite easy to use. Yet they have not ushered in a shift away from Web apps on the desktop.
I think we should be looking at why Web apps have been successful on the desktop rather than pretending they have no advantages.
The number of layers of in our software stacks grow faster than Moore's law can handle.
Er, because that would be really silly.
I like reading HN from time to time. I would never install an app, because I don't use it frequently enough. I definitely would never go through the pain of installing a HN app every time I wanted to read HN. I really doubt I'm alone or even abnormal in that regard.
That's the beauty of a browser: I can be reading HN in under a second when I want to, with no cluttering of my desktop just so I can read HN from time to time.
Because users want it to be. Whenever there isn't a significant performance hit people will always choose the browser solution. The only reason people download apps is because of performance and data limitations. Take those away and people will use the web based version.
You should look at the data on that.
Since Swift is built on LLVM and there's direct LLVM support for WebAssembly, I wonder if Apple will get behind WebAssembly so they can get Swift in the browser.
The reason I ask is that asm.js is really painful and cumbersome to write by hand and wasm seems substantially nicer, but I only have small bits of numerical hot loops which I want to use wasm/asm.js for, and I have no desire to bring a bunch of code written in C into my little project.
For anyone interested, the code is in wasm2asm.h: https://github.com/WebAssembly/binaryen/blob/master/src/wasm...
If you just want to compile a few small functions with hot loops, it might be easiest to write them in C, and use a new option in emscripten that makes it easy to get just the output from those functions (no libc, no runtime support, etc.), see
https://gist.github.com/kripken/910bfe8524bdaeb7df9a
and
1. Web code is portable. The Java dream of “write once, run anywhere” is alive on the web. All you need to run a web app is a device with a browser. No need for a specific CPU architecture or operating system.
2. Web code is accessible. Just click a link and BAM. No need to download anything, no need to install anything, no need to worry about where to put something you might not want later. The web is the lowest friction platform (for users/customers) yet created. Even better, it’s easy to access web data from anywhere in the world on any device: I can read my web email on my grandma’s iPad or on the library’s computer or on a 10-year-old backup laptop, without worrying about whether I’ll have the data I need.
3. Web code is mostly safe. Anything that runs in a webpage is theoretically sandboxed away from harming other webpages or user data stored locally, and web users have come to expect that clicking arbitrary links won’t harm their computers. Untrusted blobs of compiled C code are a completely different story.
4. Web products can very easily be kept up-to-date for all users. This is double-edged for customers, because often website feature changes make later versions more confusing or less effective than earlier versions (cf. most Google product changes from 2008–present). For developers though, it dramatically simplifies support, because every customer can be presumed to be running the latest software version.
The big question is, what do you mean by “everything”? I don’t think everything is being put on the web, or should be. For example, professional “content creation” software is not going to be put on the web anytime in the next few years, because the initial barrier to entry is small in comparison to the required time investment to learn and use the software, and because such applications need hardware access and fine-grained control over compute resources.
Personal anecdote: I like building programming environments- sandboxes for playing with unusual languages. My target audience is people who are interested in programming and generally people who are very computer literate.
I spent about 3 years working on a complete development toolchain for a fantasy game console- compilers, profilers, documentation, examples- the works. It was spread around, and has hundreds of stars on github. Problem: you need to have a java compiler on your system to install and work with the tools. Number of people who developed programs using these tools aside from me: close to zero.
More recently, I built a browser-based IDE for another obscure game console. I made a complete toolchain, wrote docs, loads of examples, etc. This time, though, you could share your programs with a hyperlink, and there was no installation required. You could easily remix other people's programs from a public computer. The difference was huge. Dozens of other people wrote hundreds of programs using this system over a matter of months.
If you're making a project you want to share with other people, a web browser removes friction to a degree which cannot be underestimated. Believe me, I _hate_ working with broken, incompatible and terribly designed browser tech, but removing those barriers to entry is invaluable.
[1] http://www.digitalafro.com/samsung-smart-fridge-serves-up-re... [2] https://productforums.google.com/forum/#!topic/calendar/Uhfp...
Now, what you get with all this is software that runs on any system a capable browser is present. Like how you can open a video or audio on any system with a capable media player.
Basically you will need to drop back down into javascript and handle that there (basically how asm.js does it now).
But there is a proposal to eventually integrate direct DOM access into Web Assembly, but that's for after they get it up and running.
You can also run Ruby and Python in the browser by just compiling their C or C++ VMs. But that won't still work "like JavaScript" - their objects won't be native VM objects in the browser, it won't use the browser's GC, they won't be observable in the browser's debugger, etc.
So far all of that was already possible, and done, with asm.js.
In the future, it is a goal to work to do GC object integration, so that something like Ruby or Python could actually compile down to something with native VM objects, and that would also allow calling DOM APIs directly. (This will likely still require a compiled VM, though.)
In its first version, it will not be able to access any/most web APIs directly (so you won't be writing a web app in 100% C++ any time soon).
The goal is to allow "Computationally intensive" bits of code to be compiled, while leaving JS to act as the glue for it all.
In short, the WASM layer is IMO the wrong layer for GC. I think the closest-layered applicable solution is caching & pinning guarantees for common libraries, which may already be addressed by the same solutions for common JS libraries (use a common CDN & let the browser caching keep it pinned).
I think it only makes sense, seeing as interaction with the native JS VM will be inevitable for a long time.
I'm more worried about more specific things like hardware access (GPU, mouse inputs, networking, windowing)
It seems wasm runs at native speeds and take full advantage of optimization, but can it really be a solution fits all? There must be some things wasm can't do. And so far, since JS did almost everything, I don't see the point of wasm if it can't do what other language can.
The main point of wasm, from my perspective, is startup speed. wasm will allow much smaller downloads of large codebases, and much faster parsing (due to the binary format). For small programs this might not matter, but for big ones, it's a huge deal.
thank you for sharing. I am a Computer Science Master student and i would like to contribute to the development. The git looks really full and i don`t know where to start.
For Binaryen specifically, this bug could be a good starting point: https://github.com/WebAssembly/binaryen/issues/2
Other issues in the tracker there as well.
Bigger topics are to make progress on wasm2asm, and to start an implementation of the current binary format (link is in the design repo), which Binaryen needs to support.
Are there plans for a properly WebAssembly LLVM backend that does not depend on forking LLVM (like emscripten)?
If one were to build a Go -> WebAssembly compiler, what are good routes to take? I can see there's going to be multiple possibilities.
But if I'm not mistaken, WebAssembly won't accept just any llvm bitcode. It's similar to how emscripten will work with the bitcode that clang outputs, but not other llvm compilers like rust or ghc.
WebAssembly is to JavaScript what WebGL is to Canvas
Does WebAssembly address either of those points?
And call them "applets". Nobody's ever done that before, right? :trollface:
If an organization doesn't want you reading their JS, there are already plenty of tools to make it nearly impossible as-is. Do you really learn anything from reading minified, obfuscated code? At some point you're just reverse engineering, which is obviously still possible with WebAssembly.
'Open source by default' is a problem to be solved at a cultural level, not a technical one.
[0] https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...
You'll still be able to find and read source of open source web projects, like like you can for open source non-web projects.
> 'Open source by default' is a problem to be solved at a cultural level, not a technical one.
Highly agree.
