Major Browsers Add Experimental Support For WebAssembly (thestack.com) 118
An anonymous reader writes: Four major web browsers have announced support for the near-native compiling technology WebAssembly, and collaborated to bring an initial common game demo of Angry Bots, running via Unity and WebAssembly, to experimental builds of Chrome, Firefox, Microsoft Edge and, shortly, Safari. WebAssembly was launched last year in a joint project between Microsoft, Mozilla, Apple and Google as a potentially more efficient route to assembly-level performance than asm.js, which is in itself a low-level subset of JavaScript.
assembly-level performance from Javascript (Score:2, Funny)
You keep using that word, I do not think it means what you think it means.
Re: (Score:2)
You're anonymous, how am I supposed to mod this up?
Re: (Score:1)
Re: (Score:2)
I think the conflation comes about due to Javascript compiling to assembly code.
Re: (Score:2)
Obviously you haven't worked with compilers long enough to understand the "compiling to assembly code" is the defacto standard nomenclature (regardless of pedantry) even if you emit bytecode on the backend, or technically compile to Lithium, an IR (intermediate Representation) like you do in V8 in the latter case.
* http://www.mattzeunert.com/201... [mattzeunert.com]
* http://jayconrod.com/posts/51/... [jayconrod.com]
Hell, even the V8 engine uses that terminology:
* https://github.com/v8/v8/blob/... [github.com]
We got rid of flash and applets (Score:1, Funny)
Now this?????
Re:We got rid of flash and applets (Score:5, Insightful)
Right, now we have an open standard byte code that any language can target, and any browser can implement, along with several competing implementations, and lots of eyes looking at the security of those implementations.
So yeh... HELL YEH, NOW THIS!!!!
Re:We got rid of flash and applets (Score:4, Interesting)
Up until someone finds a way to introduce either a patent encumbered functionality (like H264) or one inherently proprietary (like EME for DRM) to poison the well and keep real independent implementations out of scope for everybody else except the incumbents.
Re: (Score:2)
Flash was an open standard byte code (well documented too) with at least once complete F/OSS implementation.
The difference is now ads in JS can bypass the easy "do not play Flash except from whitelist" method of killing nasty ads.
For the love of holy things, wh
Re: (Score:2)
Because you remember what a single-browser hegemony was like and you don't want us to go through that again.
Re: (Score:2)
Runtimes != Browser. See, Chrome, Chromium, Opera and others.
Also, IE6 was bad because it didn't play well with established standards, and was greedy of MS, but it wasn't actually horrible.
Re: (Score:2)
That's somewhat revisionist. IE 3-6 when they were released were much more standards compliant than other browsers, particularly Netscape Navigator. (Layer tags, seriously?) IE was the first browser to fully comply with CSS1. The problem was that once IE6 was out they had so far outpaced their competitors (and abused their monopoly position) that there was no more competition, and since Microsoft was not a web company and had no interest in seeing the web advance, they did nothing for years. Of course years
Re: (Score:2)
That's kinda what I said by "didn't play well with.."
I remember the late 90's, when if it worked in IE6, it shipped. And if it worked in any other browser, neat, but who cares.
That's kinda my point. If you only developed for IE, it wa
Re: (Score:2)
Because when there's only one single, or a very few implementations, that implementation gets rapidly stale and shitty.
See for example, Flash, and Java, or just with generic web techs... IE.
Add two implementations of generic web techs (i.e. Gecko and WebKit), and suddenly the quality has gone sky high.
Re: (Score:2)
Flash had at least three implementations: Flash, Gnash and a Mozilla one. I believe Google also implemented a Flash runtime for embedded Chrome.
It's a fucking platform. Why shouldn't it get stale? You say stale; I hear "stable"
Fuck plugins (Score:1)
This is awesome. Bring it on.
Last month I saw a JS x86 virtual machine running DOS and windows 98 in a chrome tab.
That is fucking awesome. Need some special feature that no browser will support? Fuck it. Ship your own weird pseudo micro-OS and have your web application load it up on the fly.
I remember my first time on the internet. Someone set up Next stations in the Exporatorium in San Francisco. This is when the www was just a handful of web pages.
My first internet at home was on a 3.11 machine with dialu
Re: (Score:1)
I miss my 2400 baud modem hooked up to my Radio Shit computer with my 40x24 display. Now get off my lawn!
Re: (Score:2)
It sure made the cost of flying across the Atlantic far more reasonable though.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Flash was a technology developed by a single company and parts of it were just cheap copies of the back then still limited html4/js environment, while other parts were reasonable extensions. The extensions added by flash were added over time into html5 and related APIs.
Applets were a technology developed in the flash age, built by a company that mostly targeted the enterprise market. It only needs to work, not work well. Having a JVM with platform independent bytecode is a great idea, but it has failed for
Re: (Score:1)
the enterprise market. It only needs to work, not work well.
That's probably the most accurate succinct explanation of 'enterprise' software I've ever seen. Except the 'needs to work' part is generally a mild suggestion rather than a rule.
I'm just amused when people speak of 'enterprise grade' software as if typical enterprise software is something to actually look up to...
Re: (Score:1)
Enterprise Grade means it has bells and whistles that only a CTO would love. Such as the ability to backup to legacy mag-tapes. Or runs on hardware that the software company would be willing to support. Or plugs into a single-sign-on that actually works, or SSL gateways, Citrix solutions, VDI, etc. Things that "save" money for a large company.
End of the day - enterprise just means one throat to choke.
Re: (Score:2)
I think the only universal truth of enterprise software is software selected for someone based on executives having enjoyable golf games/trips. I see plenty of 'enterprise' stacks that are like you say, but also ones that are an unholy amalgamation of disjoint things from different companies.
Re: (Score:2)
I thought enterprise grade meant you had to pay 6 to 7 figures for maintenance.
Re: (Score:2)
I'm just amused when people speak of 'enterprise grade' software as if typical enterprise software is something to actually look up to.
The mistake some people make is thinking that an IE6 intranet website is enterprise-grade software.
Re: (Score:1)
Enterprise only means one thing: SLA. Nothing about 'enterprise' is in any way better, most often enterprise means monotone, monolith, boring but there is somebody to talk to (or at least there is a piece of paper that is signed that says there is somebody to talk to).
That's all it is, that's all it was and that's all it will be.
Re: (Score:2)
If Javascript programmers wrote in assembly they'd probably end up with code that's even slower than Javascript. Thus their assembly-level performance might be very very slow.
Re: (Score:2)
If Javascript programmers wrote in assembly they'd probably end up with code that's even slower than Javascript. Thus their assembly-level performance might be very very slow.
Likewise If all C programmers wrote in assembly they'd usually end up with code that's even slower than C, i'm sure a higher portion of C programmers are less likely to write completely shit assembly but you are really missing the point... The idea is to define a type of assembly language that browsers can compile appropriately on their platform and then add appropriate annotations to JavaScript to compile into it... or just use some other high level language, not to turn JavaScript into an assembly languag
Re:Hard to find a worse route... (Score:4, Interesting)
You're in luck, the workflow is typically C/C++ (or some other language than JS) -> Emscripten (or other compiler that targets ASM.js / WebAssembly.
Then the browser notices the "use asm" tag, and validates a code block as ASM.js / WebAssembly. If it conforms to the strict standards of no GC, arraybuffer memory accesses, no function pointers, etc. then the code is compiled into machine code (and cached for faster loading next time).
So it's not Javscript programmers, but C programmers, who are running code in ASM.js / WebAssembly, via LLVM's translation.
The cool thing is that ASM.js is just a subset of Javascript. It's pretty gnarly to program in directly because of the kludgey way it handles data types. However, this means that if the browser doesn't understand ASM.js then it just runs it as regular javascript and it still works.
This is what has been needed to transition away from Javascript. ASM.js lets me opt-out of Javascript's slow GC and even slower prototype system (which is a pain to optimized, since objects can change their properties at any time).
I've taken to implementing some things, like SHA256/512 hashing functions in ASM.js by hand, and get even better performance than running the C code through LLVM and into ASM.js. However, I'm a language designer and code in many other languages than just Javascript.
Just because I know how to code in Javascript doesn't mean I can't proficiently code in C, Perl, Lua, Python, C++, Java, COBOL, Fortran, FORTH or even x86, AMD64, or ARM assembly. In fact, it takes people like me to get performance out of languages. Some say that the OS and hardware is irrelevant, users don't care about the OS or hardware, they just care about what software runs on it. An OS is just an API for talking to hardware. Well, I don't care about languages, languages are irrelevant, they're just APIs for talking to hardware. Let me at the machine code.
Google's NaCl had a good approach: validate a subset of opcodes that were guaranteed not to be able to escape a sandbox. However, it tied itself to x86 opcodes. WebAssembly wants to do the same thing in a cross platform way. I think it's the right way all programming will go (is going, has gone) -- code compiles to cross platform bytecode and then the bytecode is translated per machine (Android does this, Perl6 uses this strategy, There's Java, C#, etc.).
TL;DR: All javascript programmers are writing in ASM.js already, since ASM.js is a subset of Javascript.
Re: (Score:1)
Re: (Score:2)
That's what the canvas tag [wikipedia.org] and WebGL [wikipedia.org] are for; yes, you use DOM APIs to gain access, but the APIs for using them are essentially bypassing the complexity of the full DOM; canvas is a raster image, that's all, no internal interactions with CSS or the rest of the DOM, the DOM just positions the square and you draw into it directly.
As for "nobody is really going to develop new games inside a web browser", what do you think all the free to play stuff on Facebook is? Or every old Flash game? WebAssembly just mean
Re: (Score:2)
The other day I was thinking about how it would be awesome to get some new adventure games in the vein of Full Throttle, and that much of what we do on the web seems more demanding already (e.g. youtube).
Having such a game web-based would be great, since you don't even have to worry whether this is a game for Windows, Linux, Android, console or other. Just run it from anywhere!
Getting people to pay for the content is what I think would be the hard part, especially if you'd want the game to be able to run of
What is webassembly? Never heard of it before... (Score:2)
Re:What is webassembly? Never heard of it before.. (Score:5, Funny)
don't worry, it will never be used for DRM or adware
Re: (Score:1)
^^^ funniest joke all day! ^^^
Re: (Score:3)
This is Web 3.0. The search for more money.
With ads running at assembly speeds they can play a dozen videos ads per page at the same time.
Re:What is webassembly? Never heard of it before.. (Score:5, Insightful)
It's a replacement of two previous ideas... Mozilla's asm.js ("let's specify a subset of JavaScript that can run faster") and Google's NaCL ("let's ship x86 code directly to the browser"). As best I can tell, the replacement resembles putting a Java/.NET-style virtual machine into the browser to execute a new form of bytecode (.wasm files).
This is good for speed, which is in turn good for developers who want to deliver complex ("Photoshop-like") apps from the cloud.
It's bad for security (expanded attack surface), and it's bad for privacy (more ways to fingerprint the browser).
It's a wash for transparency: today's minified JavaScript is pretty much unreadable anyways.
Probably my biggest concern off the bat is wondering how the ecosystem for web API's is going to work when everyone's developing in their own favorite programming language. Traditionally, JavaScript has been a uniting force in this regard.
Re:What is webassembly? Never heard of it before.. (Score:5, Interesting)
Aren't the vast majority of web APIs text based anyway? Why would webassembly change anything about that?
I am a game developer and I am really excited about webassembly.
There are many challenges a game developer faces today:
1) Javascript has awful performance. Some game related code such as procedural content generation is very cpu intensive, and it would just take too long in javascript. Webassembly is meant to _always_ be compiled to native code and it is statically typed which allows the compiler to optimize the code much better. It will perform many times faster than javascript.
2) Javascript does not support threads. This is one stated future goal for webassembly. This is useful when you want some work to happen in the background (again, procedural content generation).
3) Plugins suck. If I deploy my game, say with the unity plugin, I am asking my customers to download a huge ass plugin in order to run my game. Some won't because they don't trust the plugin, some wont because the download takes to long, some wont because they don't have the required permissions, some won't because it does not work in their platform. Whatever the reason, I am losing a lot of potential users by using a plugin even if I get better performance. Webassembly will not require plugins.
4) Download time. If I compile a game to asm.js, just the game engine runtime require several megabytes downloads. Webassembly does reduce the size of the download significantly. This is one of the stated goals. This is one of the reasons webassembly is binary instead of text based. The smaller the download, the faster the player can start playing and the less users I lose.
5) Startup time. If it takes 30 seconds to parse all the asm.js or javascript before the game actually starts, that is an eternity, and many people will actually close their browser before the game starts. Webassembly is binary because parsing it will take orders of magnitude less time than parsing the equivalent asm.js.
6) Browser compatibility. Today, only 2 browsers are serious about asm.js: Edge and Firefox. webassembly is being developed by all major browsers. It is also quite likely it will be implemented in mobile or even outside browsers altogether.
So yes. I am excited about it. It will make may games more accessible to my users.
Re:What is webassembly? Never heard of it before.. (Score:5, Funny)
a huge ass plugin
[hyphenation needed]
Re: (Score:1)
a huge ass plugin
[hyphenation needed]
If it's Unity, it's a huge-ass plugin.
If it's Flash, it's a huge ass-plugin.
If it's Java, it's a huge, ass plugin.
Re: (Score:2)
I'd think javascript is fast enough for quite many a thing, but I only have to launch some simple Space Invaders clone or similar and here is it, it stutters every couple seconds. So e.g. a javascript mp3 decoder works fine, but something that looks like a primitive Windows 3.1 action game fails, although perhaps the game wasn't properly written.
2) Javascript does not support threads. This is one stated future goal for webassembly. This is useful when you want some work to happen in the background (again, procedural content generation).
Great, with that or other performance improvements maybe a smooth Space Invaders clone will be possible (ignoring WebGL there, as you need recent enough graphics ha
Re: (Score:2)
>> 1) Javascript has awful performance ... perform many times faster than javascript.
Not true at all. SIMD does a provides performance advantage, but that is hardware optimzation.
It is more than that. Consider the following code fragment in javascript:
function sum(values) {
var result = 0;
for (let i=0; i < values.length; i++) {
result = result+values[i];
}
return result;
}
should be a straight forward function right? should perform the same in c++ right?, well, not so fast. I could pass an array of integ
Re: (Score:2)
The important thing to realize is that this isn't a new VM, nor a new set of APIs. Just like asm.js, it's still JavaScript, executed inside the same JavaScript VM as the browser already uses. WebAssembly is about delivering that JavaScript in an optimized format: binary instead of text (for smaller downloads and improved parse speed), and enforcing a JavaScript profile that enables improved JIT'ing (like asm.js).
As such, the attack surface is the same. There is no new way to fingerprint the browser either
Re: (Score:3)
Don't forget that Javascript is slowing it all down too. Content loads fast, but the web-as-an-application-framework is what's wrong with the web. This is essentially Java applets reinvented but with the wrong lessons learned.
my-pntbtr-add(list_eria) (Score:1)
Ugh. Performance hacks.
I understand that a lot of people want to be on the cutting edge all the time, but aren't all those people already pretty firmly in the native code camp? This seems like a compromise solution that will satisfy no one. Speaking for myself, in general I prefer to just wait for the computers to get fast enough to run the inefficient-but-maintainable code over dealing with some uber-optimized smegma.
Re: (Score:2)
Re: (Score:2)
Why do people want to stick everything in a web browser? It's like they want us to have only one tool (the browser), to rule them all ...
Many people would like an ecosystem similar to when all computers had Windows and Internet Explorer, where you only had to worry about writing for a single platform. Many changes to web standards are an attempt to get the benefits of a single platform to target but without a single corporation owning that platform. Time will tell how it works out.
Re: (Score:1)
Re: (Score:3)
I'd disagree, for the most part-
* Consumers are asking for something like this. Not everywhere, and often because they know it's generally not up to them, but platform lock-in is a pain for many people. "I have to buy a PS4 for this game." "This product isn't going to support Mac." "Only on iOS." "Requires Flash."
* Devs are definitely asking for something like this. "Can we afford to port to platform X? Can we afford not to?"
How things are now, we're talking about a lowest-common-denominator problem, so onl
Re: (Score:2)
Someone who has to buy a PS4 because the game won't play on a PS2 or PS3 is in the same situation. Big deal. You can't achieve the same performance from one-size-fits-all code, so gaming is going to continue to require code adapted to each platform.
Most devs are smart enough to understand that one-size-fits-all means going with the lowest common denominator for functionality. And let's ber honest - web platforms are the sh*t. They always have been. They always will be. Just one more layer to be compromised
Re: (Score:3)
It's the one platform that's OS-independant, at least in theory.
It gives me hope that all four major browsers are in this together but at the same time it's going to give me nightmares about what the advertising companies are going to do with it.
I hope nobody messes up the sandboxing of this whole thing.
Re: (Score:2)
Re: (Score:2)
If Java was really OS-independant, Minecraft would be able to run on all operating systems. But it's Windows-only, so there you go.
Re: (Score:2)
Re: (Score:2)
Your prejudice is worrying.
Re: (Score:2)
Re: (Score:2)
Single point of failure is easier for the casual users.
Re: (Score:2)
Re: (Score:1)
Javascript as maintainable? :-) Native code folks have a big lead on tooling that JS is slowing getting. But I also believe it comes down to language support. There are so many things about JS that I don't like that I can't believe people are building great stacks on top of it. Sure JS has plenty of happy features (like closures) - but I think it is growing old quickly. What people want to use it for is causing stress marks to appear.
Lint is still weak. People are still writing unit tests just to ve
Re:my-pntbtr-add(list_eria) (Score:5, Insightful)
That's a pretty naive interpretation of Webassembly. Let's address your comments.
1) Yes, the target audience are in the native code camp. But outside of mobile, there is no good delivery mechanism, other than the web. This is basically doing that: brining the web to native apps.
2) There is no cross platform sandbox for running native apps, and this delivers on that. All modern browsers at least attempt at security, whereas non mobile platforms offer very little in terms of security against native apps.
3) Computers aren't getting "fast enough" (or much faster, for that matter). Especially not for mobile, which will always be slow because of power requirements. This spec will greatly help with that.
So it serves many purposes, and I think is a wonderful boon to the web.
A reason for concern (Score:3)
If it is already a vector today imagine when it is a binary that you cannot even cursorily inspect before running.
Re: (Score:3)
> sudo npm install -g uglify-js
And then get the options:
> uglifyjs -h
So if I have a source file foo.js which looks like this:
> function foo(bar,baz){console.log("something something");return true;}
I can beautify it like so:
> uglifyjs foo.js --beautify --output cutefoo.js
uglify uses spaces for indentation by default so if I want to convert the 4-space-inden
Re: (Score:2)
Look at most sites that deploy javascript nowadays. The variable names are mangled beyond recognition, all whitespace and comments have been removed. It's already as difficult as debugging assembly code, but with limited upside. In theory at least, embracing a reality of bytecode rather than making an interpreted language behave like bytecode can get some gains.
Re: (Score:2)
Re: (Score:2)
Webassembly runs inside the browser's sandbox, which is at least as good as running it natively on your OS in terms of security. That and NaCl/asm.js has been around already, so I'm not sure how this will be an issue.
Welcome the Ads (Score:2)
Yo dawg (Score:1)
I guess Mozilla just can't sit still until they have an OS behind their name that creates the buzz unlike FF OS and more like Android. But seriously, blocking a JVM plugin (instead of maybe working to fix it by submitting fixes to Oracle if that was necessary) but creating a completely new VM to run bytecode inside browser directly... I guess so that eventually they'll just supply the VM and the browser itself will be written as an add on to it in WebAssembly, so that eventually somebody could port the ori
Re: (Score:1)
it's a clear improvement over what's in web browsers now
- I doubt it. [xkcd.com]
Re: (Score:1)
completely new VM to run bytecode inside browser
It isn't a new VM. WebAssembly targets the existing JavaScript VM that's already there in your browser. You should do some reading [github.com] on WebAssembly.
One more step to "Birth & Death of Javascript" (Score:2)
/Oblg. https://www.destroyallsoftware... [destroyallsoftware.com]
WebAssembly isn't that impressive (yet) (Score:3)
The short of it is that while interesting, the JavaScript runtime both asm.js and WebAssembly run in impose such major limitations on the applications being written that its actual uses outside of game ports is fairly limited.
Web Assembly? (Score:2)
I thought it was just a joke [imgur.com]