The future is here, in 1/4 of the time I thought it would take. I guess I have to go write a new prediction.
So. . .here's my prediction, taking into account the pace
of hardware development and the history of software
development. In 20 years, cheap hardware will be
ridiculously fast, but it will still look very much like
Intel hardware today. We'll have many, many CPU cores to
work with, but nobody will use a parallel programming
language designed to take advantage of multiple cores.
Instead, virtualization (i.e. VMware, Xen) will be
integrated into the operating system, and each process
will run on its own virtual machine.
Each web browser will have been expanded into a full blown
widget toolkit and have merged in something that looks
like Flash, but there will still be multiple incompatible
browsers. The latest craze will be a browser compatibility
layer written in a programming language that compiles
to "raw Javascript", and it will reduce the performance of
applications but allow you to use them anywhere.
People will set about re-writing a version of Photoshop in
the new compatibility layer, and everyone will wonder why
they'd do that, when the current version of Photoshop runs
in Internet Explorer just fine.
I was sceptical but this shows that asm.js is a much better approach than Google's ActiveX wanna be solutions.
Yeah yeah I get it. I like asm.js as much as the next person; I just wish this whole PNaCl-is-ActiveX meme would seriously go away. It's willful ignorance.
FWIW, I think it's fantastic that asm.js is turning out great. I also think that PNaCl is a worthy technical achievement. Two ways of solving the same problem given different constraints. I think Mozilla has a better chance and agree with their reasoning re- browser compatibility and third-party adoption. Still doesn't mean I'm going to go around calling PNaCl ActiveX when it clearly isn't.
https://developers.google.com/native-client/dev/pepperc/grou...
That said, I support using LLVM bitcode more than asm.js myself. I think asm.js is the dying breaths of JavaScript being hailed as its rebirth.
I think asm.js has technical advantages over LLVM bitcode. Neither were really designed for this purpose (for LLVM, you must strip the undefined behavior; for JS, you must strip the high-level semantics), but at least JS has a fully specified, multi-vendor standard specifying the execution semantics. Plus asm.js has a very minimal type system and is non-SSA (while retaining high-level loop constructs that can be easily used to construct SSA without dominance frontiers if needed), both of which I think are advantages for delivering bytecode over the Web.
I think that may be a false dichotomy.
{"success":false,"error":"DuplicateEntryException","message":"\u0027Anonymous1900\u0027 already exists."}
Un-be-lievable. I don't know who these Enterprisey IT managers are who are making these decisions but they seem to have a lot of power which they are using irresponsibly. And they seem to love IE.
quick google, this guy[0] got
IE10 = 11900,
chrome = 22500,
firefox = 40000
[0]http://www.beyondjava.net/blog/google-adds-asm-js-test-octan...
If IE is giving you half the performance of the nearest, free, easily downloaded competitor in your favourite online game, you might be tempted to switch. And this is for the few users that are on IE10!
Edit it seems pretty playable in firefox and chrome, don't notice much of a difference performance wise. Now please make a reverse case for PNaCL and pepper.js and we can all get really excited :)
1. Brings my browser to its knees (Firefox here)
2. Security. They seem to open themselves up to a whole lot of potential hacks (I hope their code deals with cookie jacking, csrf, sniffing, etc). While this would be a problem with closed source, this is made worse by running it in browser
3. Cheaters. How would they deal with people injecting code and creating bots?
3. The same way that companies currently cope with clients. It's not like client-hacking isn't so common-place that you have to design around it anyway.
3: Cheating has always been possible, in all games. The minified javascript source is still hard to grasp for a game that size.
WebGL + asm.js on desktop computers should be roughly equivalent to native iOS / Android applications on top-of-the-line mobile devices (with possibility to get better effects on desktop GPUs).
This is btw what's going on with these very fast Emscripten ports - they can be done so quickly because the bulk of the hardest work was already done before, when engine and game developers made their code and maybe even more importantly their assets work well on mobile devices.
If you noticed many of these fast Emscripten ports were not desktop ports but had already existing mobile versions before - Unreal Engine Citadel demo, Unigine Crypt demo, and now Monster Madness.
Nevertheless it's still very impressive, big kudos to Mozilla folks.
-----
[1] For example these iOS 3d games should be feasible on the web (runtime performance wise, big asset downloads may be pain): The Walking Dead, The Wolf Among Us, Grand Theft Auto 3 / Vice City, Infinity Blade series, Max Payne 1, Mirror's Edge, XCom: Enemy Unknown, Real Racing, Asphalt series, mobile Need for Speed series, etc.
Plus of course anything 2D - Angry Birds, World of Goo, Plants vs Zombies, Osmos, Limbo, etc.
Given that asm.js games tend to run at something like 15-30% of the speed of native code, I doubt we'll see Battlefield 4 or Starcraft 2 anytime soon. Additionally, given that the WoW game client is many gigabytes in size, I doubt we'll see that either, even if it could run.
So: Minecraft, yes. The rest? No.
This is from a link in the article for more information. These Monster Madness fellows found Firefox gave them 33% of native performance, and Chrome 20%. Presumably IE would give you fractions of these figures.
I figured that, rather than citing figures from benchmarks, I'd go for the real world scenario that this release has given us.
Can they put a CORS configuration up? http://docs.aws.amazon.com/AmazonS3/latest/dev/cors.html#how... and http://docs.aws.amazon.com/AmazonS3/latest/UG/EditingBucketP...
The problem is that video fails to explicitly point out that the only version relying on asm.js is the browser version, which is the least interesting, while they're all excited about different devices those are all supported thanks to Unreal's cross platform support and has nothing to do with the asm.js version.
Otherwise they can stick to javascript.
(And, of course, anything else that compiles to javascript)
This doesn't give anything to web developers. It gives C / C++ developers a way onto the web.
CUSTOMERS want ultra high performances, especially on mobile. Therefore businesses will have to deliver these performances.
Trust me, in a few years , getting a good client-side gig will mean knowing C/C++ .
The limitation today is the size of the "js" code produced, which is way too heavy.