Slashdot Mirror
Major Browsers Add Experimental Support For WebAssembly (thestack.com)
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)
You keep using that word, I do not think it means what you think it means.
Now this?????
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 dialup.
Now I have a 64bit quad core smartphone with 128 gigs of storage sitting in my pocket. We've come a long way.
Four major web browsers have announced support for bullshit.
This technology has been brought to you by the game Angry Bitch.
Now this?
...to assembly-level performance than Javascript.
Is this the whole HTML 2.0 thing where it's not HTML at all, but compiled code to "run faster"? If so, I want no part in this. The Web is perfectly speedy, but it's the Ads and garbage slowing it down. Combined with the MPAA and RIAA mafia's, ALL 4 major browsers simultaneously announcing support... and my conspiracy meter goes off.
Sounds like a lovely form of DRM.
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.
This development can very much be a big reason of concern. Setting aside the fact that this will bring closed source software to an arena where it is mostly non-existent (the scriptable part of the web) this will also open a new vector for malicious scripts to hide.
If it is already a vector today imagine when it is a binary that you cannot even cursorily inspect before running.
Pretty darn sure they will work out a way slip in anti-ad blocking functionality.
Modern app appers ONLY use AppScript because it's the appiest apping app, NOT LUDDITE languages like assembly!
Apps!
It's like expecting sensible language design out of PHP core devs: You're looking at the wrong people for the job.
The natural language butchery is just a bonus.
like javascript weenies even know what op codes are.
don't worry, it will never be used for DRM or adware
^^^ funniest joke all day! ^^^
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.
i thought once I was found, but it was only a dream.
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 original FF on top of that.
In any case, I thought and posted about it a year ago that things will go full circle. The mobile apps will eventually run directly in the browser (which incidentally will allow a mobile browser app to run inside a browser on your desktop, because why not).
You can't handle the truth.
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.
-1, Too Many Layers Of Abstraction
Aren't the vast majority of web APIs text based anyway? Why would webassembly change anything about that?
Simply put, it's a new attack surface.
Goodbye.
Subject Matter Experts (TM) agree that WebAssembly (TM) makes your browser Webscale (TM) and able to parse Big Data (TM) stored in the Cloud (TM) or in your personal IoT (TM). While traditional web applets are slow, WebAssembly (TM) is Fully Robust (TM) and Scalable (TM) capable of delivering Real-time Data (TM). WebAssembly (TM) will bring Artificial Intelligence (TM) to ever desktop and Smart Phone (TM).
Hi, I am Robert Tappan Morris and I approve this message.
/Oblg. https://www.destroyallsoftware...
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.
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.
a huge ass plugin
[hyphenation needed]
systemd is Roko's Basilisk.
Let's dispell the myth that Skullcode.com doesn't know what it is doing.
Skullcode.com knows exactly what it is doing.
It me that's having a time of trying to figure out what that is.
IMHO, there's something fishy going down at 6666h.
Last December I took an extensive look at ASM.js and WebAssembly, from the point of view of an old-school C/C++ developer, and wrote an article about it: A look at asm.js and the future with WebAssembly.
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.
Site & blog: http://www.mayaposch.com
If done right it's a pretty cool idea. How cool would it be to be able to compile language whatever you like (I dunno... C++? Java? Fortran?) on platform whichever one you have access (windows? linux? shouldn't matter) to run on a standardised browser? Infinitely nicer than the current hideous mess that is javascript and co.
I guess the test will be (a) how standard it really is (universality), (b) how well sandboxed it is (security) and (c) how fast it is (usefulness).
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 (well, besides 1 bit of "Does this browser support WebAssembly, yes/no?").
WebAssembly will benefit all complex JS applications, and is a must for the very complex ones. Currently, one of the big problems with running Unity games in the Chrome browser is the memory and CPU requirements of parsing the game JavaScript code. Not running the game code, but just parsing/compiling it, which will often cause the Chrome tab to crash for larger games. WebAssembly solves this problem (among others).
I thought it was just a joke
Have gnu, will travel.
>> 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.
>> 2) Javascript does not support threads.
Not a big deal for most applications.
>> 3) So yes. I am excited about it. It will make may games more accessible to my users.
I'm excited too, but not because of performance issues.
Internet browser based games have a bright future,
but I disagree with you about javascript, it will be the biggest part of making that happen.
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
To balance your points 1) and 6) somewhat I present the following little anecdote:
I was development lead on a rather complex app used to model and monitor large streaming media networks.
We were using D3.js to render large graphs of the system on the browser, and we had performance issues.
When one of the engineers suggested switching from D3.js to GraphViz (A C++ graph library) using asm.js I was like "You can't be serious!"
It turned out that GraphViz compiled to asm.js outperformed the D3.js implementation by a factor of about 2-3x. And it ran perfectly on Chrome as well.
The only thing we lost was the swishy-swoshy (and completely unimportant) animations when the graph changed.
The only thing we lost was the swishy-swoshy (and completely unimportant) animations when the graph changed.
In the business world where impressing clients is #1, that alone would kill your superior solution unless it could be monetised to improve the balance sheet.
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 hardware and assorted driver for it to run).
I'm concerned about 100% or nearly 100% CPU use on all cores : many PC will overheat and shut down (even mine needs the CPU's thermal paste changed again, which is all there is to it really). The browser may need a setting, not buried down in about:config, for the max amount of hardware threads it's allowed to use or some way for it to not use over e.g. 75% of the whole CPU.
Perhaps it shouldn't be your own concern if you're developing serious browser games, but if this ends up happening all over the regular web I can see it creeping up as a common issue.
That's my view. We have the JVM for all Java languages, albeit controlled by Oracle now - Java, Scala, Clojure, Groovy.. .NET for C#, F#, ClojureCLR etc.
We have
We have LLVM which is the stated original VM target for Web Assembly.
What do we have for the web??? .NET have already started a target back end to Web Assembly.
F***ing Javascript. Of al the things, after decades of language devlopment and such a rich repository of languages, the one and only all-prevasive web language is Javascript. LLVM, and
With these new backends, people won't be limited to the transpiling cul de sac that is Typescript.
We wil have a genuine new platform - a true web platform. Adn people can still use Javascript. It's not going anywhere. It wil just be joined by many other languages.
Javascript may remain the web language of chouce for many of us but not all, certainly not me.
I read somewhere that there are 2 types of langes - ones people complain about ad ones nobody uses.
Languages like Scala, Clojure, F# etc. are used and people do complain about them too. It's not just about JS. We need alternatives and let's face it, the we is used for practially everythig these days. There are instances when you would want something like C# for the web, and others when you want somethig like Javascript or Groovy.
This will hapen eventually. And when it does we can be on the right or wrong side of history. Transpiling to javascript just isn't enough. Typescript will eventualy target Web assembly too.
>> 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 integers, an array of floats, an array of strings, or an array of any combination of them and the function would still be valid. So at runtime, the code would have to check the type of each individual entry in the array to figure out what the + operator really means, and in each pass, the + operator might be a completely different function. In other words, the best compiler ever would have to come up with assembly that follows this pattern:
function sum(values) {
let result = 0;
for (let i = 0; i < values.length; i++) {
tmp = values[i];
if (tmp instanceof int) {
result = addint(result, tmp);
} else if (tmp instanceof float) {
result = addfloat(result, tmp);
} else if (tmp instanceof string) {
result = concat(result, tmp);
}
else {
throw exception;
}
}
return result;
}
Actually that is an oversimplification, since the variable "result" would also be have to checked for type. It might have been turned into a string in the previous pass for example. You can see that is a lot of code that is generated to check the types if all I want is to sum up some numbers.
Now consider a similar code in C or java or any other statically typed language:
function sum(int values[], int length) {
int result = 0;
for (int i=0; i < length; i++) {
result = result+values[i];
}
return result;
}
The compiler knows that every single entry in values is an int, and no matter what "result" will remain an int. Therefore there is no need to check what type it is. The + operator can be simply replaced by an integer add instruction in assembly. And yes, a smart compiler could even use SIMD to optimize this code, but even without SIMD, any half brain compiler will do better than the best javascript compiler.
Now you can actually see some numbers. V8 is an amazing javascript engine, and all cases except one its an order of magnitude slower than equivalent code in C++.
a huge ass plugin
[hyphenation needed]
A huge ass-plugin
There, fixed it.
You know the problems I've been having with plugins...