Google, Microsoft, Mozilla and Others Team Up to Launch WebAssembly
techcrunch.com
techcrunch.com
Sure, there are going to be nitpickers who will point out that we had that in 2005 and it was called Java, but what do they know about innovation.
Java-in-the-browser wasn't a terrible idea per se. Some aspects of it were poor but the tech landscape back then was very different both in capability and in politics.
But lets discuss further, we also should admit the reality, not just reject with satirical statements. Java didn't dominate the web front-end technologies. It's worth to consider why. The points I see:
- user needs to download and install JRE
- bad integration with HTML document,
applet is just a rectangular self contained box
on the page; and it's very inconvenient to
script DOM nodes, handle events from applets
- browser vendors (especially microsoft)
were against java becoming the dominating platform
- in 2005 java was the only language running on JVM (unlike today).
It's not so much of a problem now that we all have broadband and fast CPUs, but in the '90s it was enough for me to bin Java as "a slow piece of shit" and avoid it like the plague. That probably contributed to it not taking off as a client-side web platform.
I do believe Java failed mostly due to politics -- and more precisely, due to this:
> browser vendors (especially microsoft) were against java becoming the dominating platform
Everyone agreed, in principle, that a portable, high-performance VM was what we needed. The problem was that every vendor insisted it had to be theirs, while ever so slightly sabotaging other vendors.
In the meantime, they all had to provide a working web browser.
http://www.pcworld.com/article/2030778/researchers-javas-sec...
Honestly, that is why I always avoided it.
The other issues (slow startup, lack of page integration, unattractive UI) were dominant before that.
CSS also should be optional.
Otherwise, long live adblock, noscript, user stylesheets, ...
Unfortunately, every other web designer today seems to think I don't want to read a bloody article, but rather to be engaged by an interactive article-reading application that's basically impossible to distinguish from native applications, except for those eighty quirks that are definitely going to be solved by morehacks.js and those new CSS perversions.
Web browser developers seem to cater towards those needs, which is how we ended up with browsers where I can run fifty gazillion floating-point instructions per second in JavaScript but it takes me five seconds to find a bookmark, three of which are spent hovering over the titlebar until I remember there's no menubar anymore.
Even in the latest nightly – press [Alt], click "View", "Toolbar" and check "Menu Bar".
It can be frustrating to have to go through this process of navigating to a site, realizing I've broken it, and then reloading with all the crap turned back on, but yeah, like you said, it's better than having my CPU revved up just to have those "SIGN UP FOR OUR NEWSLETTERS!" modals flying around the screen.
[1]Totally made this up.
Security ought to be the strong point of Java, not its weak point.
When Netscape became Mozilla, it shipped with XUL runner, that is exactly that, but nobody used it.
Firefox OS is that, again, sold for smartphones.
If they come out with a good VM (measured by the languages it can run), and a good DOM-like organization, it will happen in no time. But if we get another XUL, it just won't happen.
i would hazard to disagree with that statement - the company i was working for at the time shipped thousands of devices our with the XUL runner, and i wrote several XPCOM objects to support the custom hardware we were shipping at the time.
i still miss some of the niceties that came from that.
But you are right in that there's no similarity in structure at all.
But also it means the end of the native apps. Apparently Microsoft and Google are playing hard against Apple.
"Why: asm.js is great, but once engines optimize for it, the parser becomes the hot spot — very hot on mobile devices. Transport compression is required and saves bandwidth, but decompression before parsing hurts."
JavascriptCore is a top-notch javascript engine for the web. If Web Assembly takes off, Apple will just integrate Swift with it, ship a low-power, high-performance engine, and keep selling a ton of devices.
You still have network issues such as latency, download limits, black spots etc to deal with.
And personally I don't like the idea of sending my contacts, photos, mail, calendar etc to every third party under the sun just to do anything.
A lot of the problems we run into are people treating DOM nodes as if they were UI widgets, when in reality they are lower-level primitives for drawing and capturing input.
Edit: I don't see how future addition of GC to WebAssembly changes anything I wrote above.
I replied to "Hopefully we will not need compiler to have high-performance C# engines in browser", because that does not make sense.
Unity3d does too many things (except new versions of C# :P) and ties to itself. There should be a direct C# -> WebAssembly compiler in future.
Really, how many useful web pages need to execute much code? Games, sure. Other than that, not so much. Is this trip really necessary? We just got rid of Flash, after all.
(And, of course, it's basically Java, round 2. "Write once, debug everywhere.")
Yeah, good luck with that. Ta ta Javascript :-)
You will be able to compile Ruby implementation to WebAssembly, but you can already compile that to asm.js. That is different from compiling Ruby to WebAssembly.
And I think the whole point of WebAssembly is to have a choice, not "perfect language".
WebAssembly also can be new JVM for desktop apps and widgets.
How does this compare to WebAssembly?
Quoting the wikipedia article of p-code:
> In computer programming, a p-code machine ... is a virtual machine designed to execute p-code
On the topic of JIT, the whole point of WebAssembly (and asm.js) is that it is so simple that you don't need JIT to execute it. You can AOT it fine.
Don't get me wrong; I like JavaScript. It has its warts, and it can cause all kinds of problems in the wrong hands, but both of those things are true of all popular languages.
However, performance has always been a sore spot for the current JS-to-machine-instruction process. Being able to write code that will execute faster is important, regardless of the language that code was originally written in.
It seems to me that consumers have spoken that they prefer native apps (especially mobile ones) that they can quickly find on their phone's home screen. Consumers are using desktop web apps less comparatively to native mobile ones.
So rather than people making web apps and then trying to port them to native, we're going to have a bunch of native apps that port to the web?
OR
... maybe web goes back to being the defacto standard if people start making insane unity engine powered byte code based web apps that perform like native..
I cannot see why FSF will have problem with this then, since if you are distributing a .wasm file you can construct an isomorphic text source code representation from it. This is in spirit with the user should get the source code of whatever they are executing. (Though I agree, it would not be equally readable as original C/C++ source code from the .wasm file was compiled, but then something is better than nothing)
[1] https://github.com/WebAssembly/design/blob/master/TextFormat...
Minification & obfuscation can only do so much without changing the logic of the script. Sure, spaces are removed, variable and function names make no sense, but most of the logic is still there just as the developer intended.
If we look at compiled Java/C++/Any high level language code, how the application logic is presented is substantially different from the original logic of the application. Making it so much harder to understand how the application works.
E.g. an obfuscator could make all method calls into one identical named overload, while a compiler could emit appropriately named subroutines. The compiler preserves the logic better in this case.
Minimization is something different, but minimizers do not attempt obfuscation, it is more of a side effect of their goal.
Source: Am college student, for fun I disassemble websites, including the funny VM Google built for ReCaptcha.
Additionally, I wonder what the EU thinks about this, as anyone who has the ability to use a software has the right to take it apart, inspect it, and learn from it. This right can not be signed away with contracts (making the "Do not decompile" clause invalid) and is violated by all these closed source web projects.
Tbh, I should probably just decompile, deobfuscate and refactor the Google Inbox client source, and publish it on GitHub over summer break, just to show Google how useless and annoying their obfuscation is.
[1] https://en.wikipedia.org/wiki/WebAssembly The WebAssembly team decided to go with a binary
format because that code can be compressed even
more than the standard JavaScript text files and
because it’s much faster for the engine to decode
the binary format
And it might also be the final blow on Flash.
Maybe not so many "websites", but there a lot of javascript applications will benefit greatly cutting down on the size and parsing time.
http://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-fe...
Why would you compile your application into x86 code if you can compile into WebAssembly, distribute inline on your web page, and just cache it at the client's machine?
(Yes, there'll be plenty of whys. There'll also be plenty of applications for what none of the whys apply.)
It doesn't add Value Objects yet though—that's a separate proposal.
I wonder how long it'll take until browsers implement JS in WebAssembly, to make it easier to maintain/upgrade.
But they are leaner than piles of javascript which is in turn leaner (at least from a dev stack point of view) than a full compilation stack and process.
We have quite a range of useful options for our needs now:
* Plain text. Sometimes it is all you need. Just server text/plain via HTTP and be done. Add markdown or similar as you see fit.
* HTML+CSS for most occasions because you want to add at least a little style.
* Add in a little JS when you need some basic interactivity or because you are presenting a lot of information and the option to hide/collapse some of it is useful to the user.
* Add a lot of JS and libraries once you are getting into proper "application" territory rather than just a fancy page of information.
* Start compiling form other languages when for your project needs some constructs not available or easily emulatable.
* Start considering WebAssembly when your project really really needs the performance gains possible over JIT compiled JS (or you want the binary format for obfuscation purposes)
None of those options invalidates the ones before it, so it really does come down to having a good selection of tools and picking the right one for the job. The fact it is all cross-platform (at least it is if you ignore "legacy" browsers like IE6 and Android 2.3.x, don't mind using less efficient polyfills for the not-quite-legacy-yet options, and are careful to remain compatible with a range of screen sizes and (once you introduce interactivity) input methods) and the big names appear to be playing nice enough is icing on the cake.
I think we are living in good times in this respect.
Deleted comment