This is more an argument for tools like Flashblock to be built into browsers (like they are on Android) than it is an argument against Flash itself. You can argue that Flash its inefficient but it's just as true that the tasks Flash is used to do are intrinsically complex and power consuming.

Spinning, blinking, scaled moving sprite advertisements. I don't think those are intrinsically power consuming; the GPU on most phones/laptops could handle them (blind guess) 50x more power-efficiently than flash.

I don't know if this applies to Android, but on a MacBook Air, you're best off using Adblock and/or NoScript to ensure that flash objects and advertising scripts never even get fetched over the network.

If you mean to say what you're saying, that Flashblock doesn't make a significant change from unrestricted Flash, you're dead wrong. Wireless transfer is a notable driver of power consumption, but generally it being on is the main driver, not use. CPU on the other hand draws much more under load, and Flash will put it under a lot of load.

This wasn't a case of the user doing a load of value add things using Flash which would be fine, it was basically adverts which the user cares about not one jot draining the battery.

It's easy in the midst of the current Apple / Adobe spat to see anything involving Apple and Flash as petty bickering but I think the scale of the impact and the nature of the activity (that is nothing the user is really actively doing) make is a story / fact worth reporting.

People who think Apple is just looking for excuses against Flash have never used a Mac. The only time the fans kick in on any of Macs I've owned in the past decade is when Flash is running. The only time any browser crashes it's because of Flash. Flash eats memory, CPU and anything else it can lay it's hands (okay, it leaves the disk alone) on until your Mac becomes either unusable or it has drained the battery.

Flash is the closest thing to malware on a Mac. Anybody who thinks it would have even been possible to have a usable version of Flash on an iPhone or iPad grossly underestimates the incompetence of Adobe.

Not running video encoding on your Macbook Air boosts battery life by 2 hours.

Not running 3D games on your Macbook Air boosts battery life by 2 hours.

Not watching 1080p movies on your Macbook Air boosts battery life by 2 hours.

I believe the people calling for its demise are actually calling for an end to sloppy programming by bad coders who work for ad agencies. If Flash ever actually dies, and gets replaced by "HTML5", people are going to be sorely disappointed when those very same bad coders simply start writing exactly the same sloppy code in javascript.

But Adobe isn't doing itself any favours either. Once every day or two the fans on my laptop ramp up for apparently no reason -- and a quick trip into the process monitor invariably reveals that the Flash plugin process has gone rampant and is eating 100% of my CPU, long after I've left the site that was using it. It's excruciating to wait for Adobe to fix these long-standing issues, as they seem to feel no real urgency to improve the performance and stability of the plugin.

"HTML5" as a group of technologies to replace Flash will no doubt see its share of terribly written uses, but at least the Firefox, Chrome, Safari et al teams can compete to write the most-efficient, least buggy runtimes for those crappy sites to run on.

Sadly, Adobe hasn't seen fit to offer comparable functionality for dealing with a Flash application that goes berserk. But again, I think that comes down to browsers being in strong competition creating a lot of incentive for them to work hard on efficiency and UX, where Adobe is content to let usability stagnate and bugs fester.

  Unresponsive script is different then slow script

[1] Unless your are using webworkers. Those are executed in separate threads.

Edit: It was incredibly easy to locate this on Google, so I am sure a little research could have worked well for your comment and perhaps saved yourself the possible FUD attribution.

Mplayer is roughly twice as fast, and both are using libavcodec for decoding H264.

Or rather, I think it isn't a flattering comment on Flash's efficiency that having it display ads on webpages requires that much processing power.

Flash is a Turing-complete runtime that executes 3rd party content, and the environment that hosts Flash doesn't place any restrictions on how much resources it can use. With such liberties, it's completely expected that some people will produce banner ads that consume 99% of CPU time.

CSS+JavaScript has the same exact problem, so getting rid of Flash wouldn't solve anything. (You may think it does because you're running a Flash blocker, but that's just because the offending content producers haven't migrated to your preferred solution yet.)

I don't have anything but anecdotal data to back this up, which is a huge caveat. Please feel free to knock this down.

But I have to ask: have we seen as much improvement in Flash performance as we have in plain old browser performance? Browsers are improving by leaps and bounds. I'm skeptical that Flash has had a similar performance renaissance.

For one thing, who've they had to compete with until recently? Browser vendors are tripping over one another to improve speed. Until HTML5, you were out of luck for rich content if you didn't want to use Flash.

Now, I agree that eliminating Flash won't solve ads in one stroke of JS. Even so, moving that stuff out of Flash (which browser vendors have little control over) into the browser itself enables vendors to improve whatever performance-troubled cases that HTML5 ads provide.

And, most importantly, improving HTML5 performance, ads or no, is a win across the board, IMO. A faster browser means faster ads AND apps.

Simple fact is, Flash is not as good as we need it to be.

If you don't like Flash, fine. Just stop selling this fallacy that Flash has some universal special power to drain battery power, or has some special ability to empower the worst ads. It's patently absurd.

Amusing of course, but not even close to being accurate. Take a look at this for example:

http://www.unitzeroone.com/labs/alchemyPushingPixels/

That's rendering about 300,000 particles in 3D, in realtime. On my four-year-old macbook pro, the cpu usage is barely noticeable.

I don't know why our numbers are so different. But I do know that on both my G4 iBook and G4 mac mini, any flash meant that I was maxing out. Since it was a G4, I wasn't surprised. What I was surprised about is that when I got my intel iMac (CPU as above) flash wasn't slow but used most of my CPU power.

Edit: removed typo

Flash ads used to lock up my old G4 frequently.

Perhaps if Flash only ran in your active tab - or rather the one you were viewing - it wouldn't be so bad. It's hardly energy efficient - if I was to leave my computer for 20 minutes it would just keep consuming, whereas you'd hope it would throttle power use.

There's nothing that prevents somebody from writing ads in javascript/canvas and using your browser to fold proteins.

Browsing the modern web is an incredibly complex activity.

Many of those Flash ads feature high bitrate videos, sound streams, and complex interactive elements. Of course, maybe advertisers shouldn't be building such overbearing creations to try to grab your attention, but don't blame Flash for their excess.

We are talking about Flash - not ads per se.

JavaScript, on the other hand, has seen a huge emphasis on performance, with Google's work on V8 and the stuff Apple has been doing with Webkit. I strongly suspect it'll be better performance than Flash.

Not that I like Flash, but that's for different reasons.

Except that using a cpu to emulate things gpu do natively requires far more power. A gpu is a specialized processor so the tradeoff isn't going to be 1 to 1.

There is absolutely no empirical basis for assuming this. In actual comparisons between the two -- at least the tests that I've seen -- Flash take the lead.

Removing Flash and being saved the overhead of endless and overbearing ads is good, but as has been said the advertisers will move to HTML5 (they already are), and they're going to do the same full motion video, moving dynamic multimedia, etc, that causes Flash to be such a beast. Worse, it won't be as easily segregatable because to the browser it will be no different than the rest of the web application.

On the other point, any website that lets advertisers take over their content or more space than it should because there are no boundaries (as opposed to Flash) is a website I won't visit anymore, and I suspect a great amount of people think the same.

We have great advertisement providers as Fusion and Google are which are non intrusive. If you wish to add banners and the such you as a content provider should very well be on top of your ad space and avoid shady advertisement companies.

  > Worse, it won't be as easily segregatable because to
  > the browser it will be no different than the rest of
  > the web application.

There are no mechanisms that I know of in popular browsers to disable certain html5 features like canvas, video, or audio elements.

So while its possible right now to disable Flash by not installing it or using certain browser extensions, if an ad provider loads an ad that uses the video or audio element you really have no way to disable them. Disabling javascript should prevent canvas-based ads from running, but what's to stop video and audio playing if your browser supports autoplay?

not sure if you meant it, but that comes off as pretty rude.

loops and EDA's are different things, and there is value in comparing and considering them. also, the Flash API's may have first-class support for the notion of events, but that does not mean that every glorified loop involves events, or vice versa. in a pure EDA, no task is performed unless an event of interest occurs. mindless polling and housekeeping loops are one anti-pattern contributing to unnecessary CPU use.

also, while we're being pedantic, technically not all games require loops. I've built plenty myself that had no loops in the application code.