Hacker News Reader

I've heard - and seen - the same argument made with respect to Flash on one side and HTML4 + JavaScript on the other side.

I'm the biggest flash hater there is, I only started using it November last year for one specific feature that we no longer could talk our way around (video+audio) and it is really amusing to see history repeat like this.

Adobe isn't going anywhere, and, unfortunately, neither is flash. 'just' video is not going to suddenly make everybody drop flash.

> While I do think that this is bad user experience for those buying the MacBook Air, it should help foster an overall better user experience for the Internet.

Reducing the user experience for any group does not increase the user experience for the whole.

What it might do is foster standardization in the long run. But don't forget that Apple is not doing this from the good of their heart to help open standards, but simply because flash competes with the App store.

It is no coincidence that flash gets dropped from the MBA at the same time that the app store for the Mac gets launched.

How does Flash compete with the App Store more than HTML5? Since Apple has been promoting HTML5 web apps, especially those targeting Mobile Safari, I find it hard to believe that their hatred of Flash comes from a desire to protect the App Store. I take Apple at their word that it's because of Flash's atrocious performance, which as a Mac user I can attest to.

I don't agree with this decision, though. I think the best way to handle Flash is to build ClickToFlash functionality directly into the browser.

Imagine if they had included Click-to-Flash by default instead.

How does Flash compete with the App Store more than HTML5?

By having a mass market share that makes it competitive. "HTML5" does not (by comparison).

I think that flash competes with App store mainly in small silly games which are free in Flash and probably will cost 0.99 in App store

Except you can STILL go out to the internet and play those silly free flash games.

And Flash Developers can now release their silly flash games on the iPhone/iOS App store.

If either of those facts were not true, you might have a point.

...flash competes with the App store.

I don't think that's at all the case. Flash is mostly used for rich content on web pages. If it competes with anything, it's new browser features like HTML5. One could make the argument that Apple is trying to discourage the use of flash-based competitors to iTunes such as Amazon VOD and Hulu. Though that's a bit of a stretch.

It is no coincidence that flash gets dropped from the MBA at the same time that the app store for the Mac gets launched.

I think the coincidence is more mundane. According to Jobs, Apple made a more realistic battery benchmark for the Air. It now involves browsing 25 popular websites over wifi. Killing flash would almost certainly improve battery life in that benchmark.

...it will only be a matter of time before the percent of Flash enabled browsers falls enough that web developers need to start using more appropriate standards-based techniques.

I agree with your prediction, but I'm not sure it will be a good thing. With the exception of a few popular domains, I'd say 90% of flash content serves to annoy me and waste my computer's resources. I love using clicktoflash because it filters so much. Imagine if band websites started using HTML5 instead of flash. Instead of a big gray box with a "skip intro" link below it, you'd get bombarded with loud noises and stuff flashing on your screen.

I say this half-jokingly: How long until someone makes clicktoHTML5?

Good point.

Although this doesn't solve the issue you raised, one change I would like to see made on the browser side is sandboxed tabs. As far as I know only Chrome is sandboxing tabs at the moment. I'd like to see Firefox and Safari do the same so one bad javascript doesn't kill the browser entirely.

One way those issues could be addressed is by Google page ranking. If certain abusive practices were highlighted as universally obnoxious, I'm sure Google could create filters to reduce the search ranking of those pages using obnoxious HTML5 and JS. My reasoning here is that the same executives and elements of corporate culture responsible for obnoxious uses of Flash and other technologies today are the same ones that push the hardest for SEO. At least at the HTML5 and JS level, Google could parse for obnoxious code, which AFAIK is something they can't do today with Flash. It's a bit of a stretch but certainly a possible solution.

This last comment is exactly right. People are quick to blame Flash, but it's what Flash enables and what runs on Flash that is the problem, which is 90% ads. And that can just as easily become annoying in HTML5/javascript, minus the sandboxing of Flash.

Moving from "click to enable technology that usually contains annoying video and sound" to "click to enable video and/or sound" is a better approach, in my opinion. That way if someone wants videos to play, but require permission to play sound, or wants sounds on one site but no videos, they can do that. We move from an all or none solution to something customizable.

Also embedded audio and gifs aren't covered by flash-blockers, though in some cases there isn't much of a difference between that and a video ad. If we have to filter content by type and/or by html tag instead of "wrapper that normally contains type", we'd get better coverage overall.

For the sIFR thing don't blame the website designers, blame the browsers and HTML group.

And as for 'more appropriate standards-based techniques', the phrase gives me the creeps.

We're living in an age of a range of wonderful languages, fantastic form markup languages, superb IDEs.

Apart from in web applications.

Languages? Javascript. One choice. And a very odd one at that. Markup? HTML. Yuck, no extensibility, barely updated for 10 years, way, way, way behind flash or xaml, it hasn't even got close to what's available to us on desktops yet. Javascript IDEs? None of any note that I've come across.

Wouldn't it be great if Chrome, Safari or Firefox added in python or ruby client-side support. Or all of them, really kill off IE...

It's a dire state of affairs, Microsoft are to blame, but I wouldn't celebrate 'standards-based' techniques. They're frustratingly constricting and old fashioned.

I thought designers had free will. Some choose not to accept the limitations of browsers and use sIFR to get past those limitations.

How can they not bear any responsibility for an implementation choice?

One word: Cufon.

True, but it came long after sIFR.

>Languages? Javascript. One choice. And a very odd one at that. Markup? HTML. Yuck, no extensibility, barely updated for 10 years, way, way, way behind flash or xaml, it hasn't even got close to what's available to us on desktops yet.

Choice is a wonderful thing, but take a look at how different the browsers are at implementing these basic, single languages. Imagine if you had to worry about cross browser support for another language. You might not just have to write your webpage to support IE6, but have to rewrite it in another language. It'd be great if we had multiple web languages, but it'd also be great if we had one single web language that actually worked 100% consistently cross platform.

For the most part, we do have a single web language that is reasonably consistent across platforms... if you keep things simple.

Where things get dicey is when designers demand a high level of control over the cosmetics (i.e., pixel perfection) or developers demand a high level of control over the interactivity (i.e., making rich internet apps, etc.).

I'm not saying there's anything wrong with pixel perfect design or rich internet applications, but it is the desire to make the browser a design/media/application platform that created all these cross-browser issues.

--

On a side note, sometimes I wonder if there would be more fat clients if Windows did not introduce DLL hell. DLL hell and app maintenance contributed to the enterprise market's desire for browser based applications.

If you take iOS for example, you see a lot of apps for site content that are native and richer than a browser, but still rely heavily on http. That model seems to be thriving.