It's still unclear whether having Flash is better than not having Flash. | Hacker News Reader

It's still unclear whether having Flash is better than not having Flash.

technologizer.com

30 pointstechnologizer38 comments

Click to Flash is the ideal middle ground for mobile devices. Only play the Flash when the user explicitly requests. 90% of the time, the user won't notice the Flash missing, the other 10% it is available on request. That solves the battery issues and the annoying advertisement issues.

Well, it might help the battery issue, but it couldn't solve it unless the video playback was just as efficiently hardware-accelerated as the native implementation. You're also introducing a user experience cost of N additional taps for an afternoon watching N flash videos.

The ideal sweet spot is for proprietary plugins to vacate all browsers post haste.

Take a good look at the number of plugins you are already running. If you are using Chrome type in about:plugins in the URL. I think you might be surprised.

I see many people have this hate towards Flash because it is a plug-in, but what about QuickTime, Silverlight, and Java? Plug-ins exist to extend the functionality of our browsers and let's face it, HTML does not do everything.

In most cases, those plugins are there because some other app put them there, not because they're actually used. The most notable exception is probably Silverlight for Netflix.

I don't think Click to Flash is the optimal solution. On the PC side it still loads Flash objects, they just aren't displayed. It also skews feedback. If developers think that flash is being represented in mobile devices when its not that only causes them to divert resources from creating mobile HTML versions of sites.

There could be a ClickToFlash version not loading Flash objects at all until requested couldn't there? Of course it would probably be for all <embed> and <object>, but...

That's the core functionality of NoScript: don't allow anything more complicated than HTML+CSS until authorized by the user. It blocks objects but by default leaves behind a rectangle you can click to download and run the object.

In Safari with the ClickToFlash extension, flash objects are not just 'not displayed', they are not loaded at all until the placeholder is clicked. See for yourself: point Safari to http://adobe.com/software/flash/about/ and show the web inspector 'Resources' tab before clicking on a CtF placeholder. Notice that no SWF are loaded, then click on any one of them and see the SWF get fetched, along with the external process being started in your OS process list.

For me, this seems pretty simple: if it is shown that Adobe can create a version of Flash that alleviates problems with poor battery life and terrible performance, obviously it will be "better to have Flash". So long as those problems persist, Flash seems like a lot more of a liability than an asset.

I'd add 'security' in there, too. The situation is already looking worthy of concern on Android and other open mobile OSs. Do we need one more attack vector? Particularly a platform with a history like Flash?

CSS3 is also worthy of concern. It's true that the security concern is different, and it's true that the security concerns are in general cumulative, but it's not like you can decisively say "things that add to the attack surface are bad".

I think it's pretty safe to say that Adobe code bases have more or less earned themselves a special line item in the security concerns list at this point.

You could --- and I'm not just saying this to be argumentative --- say the same thing about parts of Webkit.

I want to be clear that I agree that Flash adds more than a banana-equivalent dose of insecurity. I just worry about the notion that the rest of the system is much better.

You make a good point that I wouldn't want to try to disagree with.

I'd argue the same could be said for the functionality of Flash. Yes, watching video via Flash can start the fans flying, particularly on OS X before Apple allowed them access to the hardware. But, it's not like displaying highly encoded H.264 and allowing people to manipulate the resulting output is easy. The last comparison I saw showed only IE9 convincingly beating Flash in this task, and the big outliers were some of the browsers like Safari on Windows which was abysmal, whereas Flash was solidly good across platforms and browsers. And I'm guessing that performance in other areas is a clearer win for Flash.

I have ideological reasons for not liking Flash, but clearly my brand of ideology isn't as good at mass-mind control and reality-re-defining as the Apple-ideologues. I'll be glad to see it go, I just wish it was because people thought that core web technologies should be open with multiple interoperable implementations, rather than because of a concerted campaign of misinformation and misdirection about performance.

I think you may have accidentally replied to the wrong comment.

Your point appeared to be that Flash is insecure, but that the things proposed to replace it e.g. Webkit, CSS3 implementations suffer from similar issues. My point was that, similarly, its performance problems with video are shared by other browsers when implementing the same functionality.

I kinda like the flashbanner-free world that is my iPad.

They'd also have to alleviate the UX problems with Flash - most notably the fact that it's a development tool for mouse-based UIs, not multitouch UIs.

It's notoriously difficult to design for an environment in which you don't know whether the user can mouseover or not, whether they can use multitouch gestures or not, whether there needs to be scrollbars vs. draggable content, and you don't even know if the pointing device will be a pixel-accurate mouse pointer or an inaccurate finger.

Is the situation in HTML/JS applications any different, though?

I think there are five major points of failure for Flash on tablets.

1. Flash integration into system battery management.

2. Software support for hardware acceleration, both for video, 3D, and 2D.

3. Flash objects' use of network hardware.

4. Flash memory caching / swaps.

5. Android allocation of processor usage for Flash VM.

Implementing a Flash VM that doesn't crush your battery requires addressing all these points. This will be especially hard to support the plurality of hardware and OS varieties.

I really thought I'd miss Flash for certain sites, but it turns out that if it can't be done with html5 then there's usually "an app for that".

I can't stand the middle-ground of things 'sorta working' I would rather have it be either fully functional or non-existant.

I think that the big news with Flash 10.2 is that it does have hardware acceleration for video. http://blogs.adobe.com/flashplayer/2011/02/flash-player-10-2... The article suggests that 10.2 is not hardware accelerated.

10.2 hardware acceleration is actually disabled for mobile.

It's not enabled in the beta, that's all.

I see. I just checked the release notes http://kb2.adobe.com/cps/895/cpsid_89556.html

"Please note that this feature has been turned off for this Beta release, but will be available in the final Flash Player 10.2 release."

"Please note that GPU rendering was turned off for this Beta release."

It will be interesting to see how well it performs when they enable the hardware acceleration in the final 10.2 release.

10.1 had hardware acceleration of decoding. 10.2 has "Stage Video" which lets it take advantage of even more hardware for displaying the video as long as the developer of the Flash code displaying the video doesn't need to do anything fancy with it like put it on the face of a rotating cube. They seem to refer to this as hardware accelerated rendering.

This latter thing seems to be only coming to Honeycomb and up, and isn't fully baked so 10.2 for Froyo is final, while 10.2 for Honeycomb is still a beta.

This is what will determine RIM's fate in a few weeks, if playbook flash is just as bad then they are pretty much done for.

You say that as though the PlayBook actually has a chance of catching on in a big way. Even if it did, it wouldn't hinge solely on Flash support.

RIM has never done a great job targeting the consumer market, and their enterprise customer base is still pretty loyal. Even if the PlayBook fails to change that, RIM will not go bankrupt before they have time to try again.

Reading that article I could almost hear Steve Jobs over my shoulder saying, "I told you so."

I think flash is just a stopgap until something faster and native comes from android. Both MSFT and AAPL are not supporting it on their mobile platform. Android only supports it because they don't have any other options.

Huh? As far as "native" goes, the Android browser is just as fast as, or faster than, the iPhone's. And Adobe has already confirmed Flash for Windows Phone 7.

Would you elaborate on Android not having any other options?

Android already supports Theora, WebM, and H.264 -- what do you feel its native support is lacking?

Manufacturers put Flash on tablets/phones as mindless "differentiation", an extra checkbox to wave in front of consumers. There's no technical reason for Android to support Flash, and (as this article demonstrates) numerous good reasons not to.

Forgetting that there is a ton of popular flash content on the web? Outside the developer community, people don't care about how the content they're interested in is delivered, they just want access. It isn't hard to criticize the implementation of flash on mobiles, but there are obviously strong arguments for including it on a platform. It's clearly a LOT more than an 'extra checkbox'.

Right. Thanks to flash compatibility on my phone, I can watch/listen to a lot of content that cannot be rendered on an iDevice. That's a meaningful differentiator.

Not sure what you mean - what does WM7 or iOS have that Android doesn't? Native apps are just as capable on any platform.

Reply on news.ycombinator.com