NinjaWarrior's comments

This article won't help much. Many people are saying this issue occurs without any plug-ins. I doubt it is the true cause. There are many Google Chrome Helper CPU eating up issues. Some are obviously not plug-in and extension related.

Chrome for Mac is almost useless because of this issue. I first encountered this just after Maverics release and Google has not fixed it until now. Very odd.

Issue 373923 - chromium - Google Chrome Helper Process Taking up >100% CPU on Macs

https://code.google.com/p/chromium/issues/detail?id=373923

Issue 397642 - chromium - Google Chrome Helper (not responding) on Yosemite Beta 1

https://code.google.com/p/chromium/issues/detail?id=397642

Issue 399960 - chromium - Video playback, CSS transitions, and other GPU operations drastically heat up 13" Retina Macbook Pros

https://code.google.com/p/chromium/issues/detail?id=399960

Issue 367593 - chromium - Multiple Google Chrome Helpers are spawning and slowing severely slowing down my browser

https://code.google.com/p/chromium/issues/detail?id=367593

Google Chrome Helper using far too much CPU power - Google Group

https://productforums.google.com/forum/#!topic/chrome/LfBqIl...

> Both Unity and Unreal have their engines running well

Running well? You'll know there are still tough problems next year. No one download 100 MB or 200 MB scripts and assets to play a game. In the past, all such resource rich Flash or Unity Web Player games have failed. No exception.

The relief is Mozilla people actually know this problem (I talked with them at GDC).

AAA games are just too rich to "browse" on the web. People close their browser windows within several seconds. Typical home internet bandwidth is narrower than Blu-ray or DVD-ROM, even in advanced countries. Furthermore, browser cache can't handle big resources. You won't even gain server costs.

I think Unity can distribute their runtime library via CDN (just like three.min.js or something). It will able to cut down the initial some megabytes.

Progressive downloading technique (like AssetBundle) is a must for both loading time and server costs. Every developer should use it because if many games have massive long loading time (like Epic Citadel or BananaBread or Monster Madness. Whatever Mozilla says, these demos are not commercial ready), end-users will hesitate to click game links. I feel many gamers already stopped considering the web as a game platform these days. Kids know how to download games from App Store, but they don't know how to use Mobile Safari. All App Store, Google Play and Steam are growing. Many users will continue to prefer download apps for a long time.

Ultimately, time may solve the problem. The internet bandwidth is growing 50% per year. Many PC browser games will start instantly 5 or 10 years later, Mobile will have more trouble.

You imply the web is the blue ocean? :)

I've experienced countless hotlinkings, rippings, clones, insults, DoS attacks and cybersquattings as a former Flash game developer. Luckily, I have not been involved in any trademark issues, but it is happening also on the web, isn't it?

I think the above poster is talking about UX...

> 3. It works on mobile devices, flash doesn't.

False. Many (120000+) Flash apps are actively running with Adobe AIR on App Store and Google Play. AIR is a technology to package SWF as a native app.

> 4. The tools are out there. Check out appcelerator or unity's tools.

Unity can not export for HTML5 yet. Apparently they are working on it but I don't think it's that easy (As for the original article, I DO MIND the initial load time. That will be a big problem for Unity as well).

> 5. Flash never had the native performance or hardware acceleration that modern JavaScript has.

False. plain (non asm.js) JavaScript is slow. Don't trust micro benchmarks. And at least ActionScript is faster than plain JavaScript (http://j15r.com/blog/2013/07/05/Box2d_Addendum). And Flash Player 11+ has Stage3D which utilize GPU acceleration as well as WebGL. For instance, please watch this Facebook game (http://www.youtube.com/watch?v=vBIJVt05jwc). Note that this is a commercial product. Not an experiment. Moreover, the same "Epic Citadel" demo was released for Flash on Mar 2012. One year earlier than HTML5 (http://epicgames.com/news/epic-games-releases-epic-citadel-i...).

> Compiled other languages to ActionScript?

Adobe Alchemy...

Please don't denounce Flash without a knowledge of Flash. I'm already not a user of Flash and currently developing with Unity and Cocos2d-x instead, but I feel I need to advocate Adobe guys from unfair bashing.

Indeed. Every trial to replace "standards" is called "evil". From this perspective, the web platform is far from open. The result is we all are in a local optimum trap. I already gave up expecting cool future and decided to stick to the native development for a while (for a decade or more).

BTW, as a game developer, it would be nice if this rendering latency issue will be fixed soon.

- http://phoboslab.org/log/2012/06/measuring-input-lag-in-brow...

- https://code.google.com/p/chromium/issues/detail?id=168459

I think this response time issue is a real show-stopper than JavaScript performance.

> Native will always fundamentally beat non-native, that's a plain fact.

The problem of WebGL is simply it has very low penetration. By my research, currently only 35% of desktop users can use WebGL with GPU acceleration (FYI, Flash 10: 95%, Flash 11: 75%; Flash 11(Stage3D with GPU): 70%). Now that IE11 is supporting WebGL, this might be a matter of time. However I foresee it would take 5 years or so to achieve 80%.

And, note that WebGL only has functions of OpenGL ES 2.0. Currently WebGL2, which has functions of OpenGL ES 3.0 is being developed. On the other hand, native games already utilize OpenGL 4.x. What API is used in native games when WebGL2 becomes popular? I imagine raster-based rendering might be obsolete at that time.

And I think people already know the web can't handle Oculus Rift, probably one of the most interesting, innovative and fun gadget in this decade. Of course you can use it on browsers with a NPAPI plugin. Oh, hey, the web people said plugin is obsolete and evil! Don't use plugins!!! Don't play with Oculus Rift, you, PLEASE!!!

I admit the web platform has some value on some points, but if people think HTML5 is the (only or most) cutting-edge and innovative technology, that's not correct. Absolutely not.

I still completely disagree making the web an application platform. Because of the absurd HTML5 cult, many websites are obtaining unpredictable and inconsistent behavior. The difficulty of explaining it to my old parents is increasing day by day. Moreover, browsers are getting fatter unlimitedly and only a few vendors can survive and develop them. It gives browser vendors special privileges. As we are experiencing now, no one can stop this "Disable JavaScript" removing. How can people say this is "open" movement? The good old web is dying.

The web should be words and documents first (I think this page is worth reading http://justinjackson.ca/words.html). It's too late to say but if you want a sandboxed application platform, develop it out of the web. I still believe the plug-in was not a that bad idea, not the best idea though. At least you can disable it anytime and you have freedom of choice.

I suspect that the back button will be eliminated next. Because it collapses most web applications and "user experience".

If the web want to become a perfect application platform, all virtue of the web will be lost.

FYI, current mobile browser caches are very weak and unreliable. For instance, iOS clears all cached data just by exiting Safari. Android is also in a similar situation (unpredictable and can't explain).

I guess it is caused by the storage limitations. We can't rely on the mobile browser cache, at least for now.

> Emscripten builds taking between 10 and 50 times longer to compile than the native code ones.

Hey, this is fatal. With this massively long iteration time, you can't run actual big projects. Only executing 1,000,000 lines of C++ code is not enough. We care the build time as well as the perforamnce.

BTW, have you heard that the next Haswell processors can get only 5% performance improvement? We should assume that we have no free lunch anymore. One of the UNIX philosophies is already broken.

Yep, if Google implements DRM, no one can stop it. The web is a platform for big software vendors after all, because no other player can virtually implement and maintain this enlarged platform and browser runtimes. Evil browser vendors will take over the role of evil plug-in vendors. Game over.

I predicted this catastrophe when everyone was attacking Flash.

And the web highly relies on the native ecosystem. Since we have freedom of the native development on PCs, a number of browsers have been created and improving. However in mobile devices, that ecosystem is totally broken. When you have trouble with browsers on restricted OSs (such as iOS and Firefox OS), you can't do anything! I feel something like free riding is happening. This is far from "open" movement.

The web platform can't exist without native platforms after all, since browsers are native applications.

Sure, the Unreal Engine 3 demo (Epic Citadel) had been already ported to Flash one year ago. http://www.unrealengine.com/flash/ Since ActionScript VM is far slower than JavaScript, I'm afraid I have to say the Mozilla's demo does not prove the performance of asm.js at all.

And here's the latest Unreal Engine 4 demo. http://www.youtube.com/watch?v=dO2rM-l-vdQ

I know there are improvements on the web platform each year but I wish people would be very very cautious to say "we've achieved nearly native performance!".

To begin with, I think it's difficult to run 3D games (including Flash and Unity) on browsers because of the asset loading (and AOT compilation) time. If people must wait for seconds and even minutes to start a game, we can't do business with it. As many web developers says, immediate page loading is must. I'm personally running Flash and HTML5 games and I observe 80% people leave just in a few seconds loading.

To solve this issue, game stores (PS3, Xbox 360, App Store, Google Play, Steam and many others) are using the "reserve download and play it later" model. After all, traditional install apps are not that bad architecture...

> I would imagine that people would rarely write asm.js code, but instead they would generate it from statically typed languages (TypeScript, Dart, Haxe).

Current asm.js is just for C/C++. Those altJS languages can't make use of asm.js (Haxe->C++->LLVM->Emscripten->asm.js might be possible but I think it's meaningless).

asm.js is the answer of Mozilla for "the web standards can't handle AAA games" but I believe this is far from an ideal solution. And I agree with the worry of the poster that this ugly hack makes JavaScript more ugly, both on the specs and VMs.

To be honest, I trembled when I saw the Math.imul proposion to see how some people are so obsessed with JavaScript...

I often imagine offloading everything to GPU is the realistic solution to workaround the mess of standards...

How about evaluating both (asm.js and PNaCl)? Looks like we are stuck in the "monoculture" you said you dislike. And this IS the reason I never love web standards. I don't like monocultures too.

I feel you are biased to preserve JavaScript because you are the creator of JavaScript. IMO, asm.js might beat Flash but has a clear dead-end to beat native. We all are in a local optimum trap, I think.

Math.imul is just an ad-hoc patch to improve the performance of Emscripten. It's totally for Firefox. Is there a motivation to standardize and implement such a thing for other browser vendors? I'll star the V8 issue though...

Yes, from the viewpoint of a game developer, the DOM is extremely, painfully, awfully, ridiculously slow and completely useless other than static HUDs. With the DOM, we can move only hundreds of sprites at 60 fps (on the latest Core i7!). HTML5 Canvas can achieve thousands but it's also far from native (and the function of Canvas is very poor).

WebGL can gain acceptable performance in many situations, but there is still much overhead.

I suspect today's most web developers don't know the true performance of computers they are actually using.

If you don't like monocultures, you shouldn't have hated plug-ins. And Firefox OS should allow users to install browsers other than Firefox.

I'm very sad that not only Flash 11 but also Silverlight and Unity Web Player are all doomed by the enthusiasm of the "open" standards. Therefore, I feel that current Mozilla is full of hypocrisy.

And Mozilla, you must implement the Web Audio API ASAP. Without this, all interactive "HTML5" demos with audio will be developed only for WebKit browsers. "We innovate early, often"? I don't think so.

HTML5 is not the only way to achieve cross-platform. In native world, HTML5 is just "one of them". There are many cross-platform frameworks and you can choose any one you like. Look this report.

Cross-Platform Developer Tools 2012 | VisionMobile http://www.visionmobile.com/product/cross-platform-developer... > the landscape of 100+ cross-platform developer tools

Actually this is a big reason I dislike HTML5 (or I think HTML5 is wrong). Developers don't have freedom on languages and APIs. There are no healthy competition.

And don't forget that web browser itself is a multi-platform application. You can use Chrome and Firefox on Windows/Mac/iOS/Android. These are written in a "cross-platform language" C++.

In addition, most video games are written in C++ so many games are released on multi platforms (Xbox360/PS3/PC/iOS/Android). I suspect most web developers don't even know this...