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.
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.
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.
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 ...
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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
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.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
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.
You're anonymous, how am I supposed to mod this up?
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.
/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.
Single point of failure is easier for the casual users.
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.
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 language.
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.
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
Javascript isn't even the worst of this... if webassembly is running inside the browser, it's going to have the DOM as a bottleneck. It's great that bytecode can be loaded and run, and C++ programmers can work on front-end code, but now they'll still have to deal with the DOM and the browser API, and CSS, which they will no doubt complain about - and so this won't go anywhere very fast... except maybe for some games, but those will likely be limited because nobody is really going to develop new games inside a web browser.
Java is os-independant, and actually has fewer security flaws than web browsers. Solved problem, but people are too lazy to learn "real programming", even simplified as much as Java is. Web script monkeys are their desire.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Strange how that hasn't worked out too well ... and mathematically it's the inferior approach. Not to mention that a single point of failure hoses everything.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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 only a small subset of problems are solved. Hopefully this will improve over time, until the majority of problems are solved and only edge-case problems require specific platforms.
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.
That's what the canvas tag and WebGL 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 means that you can write the same games in whatever Emscripten supported language you like, then cross-compile, instead of using Flash, hand-coding JS, etc. And that's before we get into playing abandonware games; cross-compile an emulator like DOSBox to WebAssembly, and you can serve the original game files directly, only the emulator needs to be cross-compiled. Archive.org has already done that for hundreds of games using asm.js
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
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.
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.
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 off-line.
Yet another god damn account?
But at least, nearly every one with a computer should have a compatible browser.
Mid-90s were so nice, every one had DOS, VGA and Sound Blaster (or things directly compatible with them), I can't help but think things were easier lol.
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.
>> 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++.
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 and p0wn you.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Your prejudice is worrying.
I can write java code that will run on *nix and not Windows - doesn't prove that it is os-independent, just that you can get around that feature, so as you said. there you go.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Not to moi :-) In case you haven't noticed, there's been a huge push to make programming a low-cost commodity. That's possible with simple scripting languages, not so much with C, etc.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.