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.
Edit: The lesson here is that if you want to predict the future, try to do it by making a prediction so ridiculous it could only be a joke.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.
{"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.
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.
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)