Flash vs HTML? What is wrong with you people??

And I’m dead serious.

One can't live without the other

Let me start by saying that I am a passionate Actionscript Creative (if someday I might grow up, you can call me a Flash developer but not just yet) and I absolute love the web as it exists today. I love HTML and CSS. I even like Javascript (a bit) (it’s not my favorite, but we get along pretty good). So don’t go off thinking I’m taking sides.

What are we talking about today?

Earlier this week, Serge Jespers wrote about Adobe vs the open web, which kinda looked like a Flash vs HTML5 article from a distance (because let’s face it: The Adobe platform on the web is mainly the Flash platform). I had a lot of conversations about that in the past and the one thing I have come to conclude is that you can’t actually compare those to each other.
Not even remotely.

So to what should we compare it then?

People keep referring to the features that the Flash Player offers and which the developer might want to use. And then their statement goes on with ‘You can’t do that with HTML!
Of course you can’t! There are thousands of things you can do with Flash, which you just can’t pull of with HTML, CSS or Javascript. But if you really want to compare Flash and HTML, you gotta do it right:

Flash Player vs FireFox ( or IE or Safari or Opera or any other browser)
Timeline and Actionscript vs HTML and Javascript (and CSS if you really want)

(Please, stop throwing those vegetables at me… Thank you.)

Comparing the Comparables

So now you’re looking at me, thinking I am completely nuts… So let me clarify…

The Web Browser

A piece of software that allows you to browse the web and renders HTML and CSS into a beautiful layout (depending on the website that is) for your viewing pleasure.

The Flash Player

A browser plugin that allows you to view .SWF files and render them as described in the bytecode (or wherever) into a vector based movie.

This is a very brief description, and despite that I think you could already conclude their first difference (and what they got in common).
Both the Flash Player and the browser are built to display content, and render that content using a specific set of rules. They are both the same on a different level.

W3C and ‘Web standards’

I really like how ‘Web standards‘ is such an often used term (which sounds so professional and simple at the same time), and yet I am unable to describe exactly what it means (even after reading the Wikipedia explanation, I understand but don’t quite know it…). But I bet you, you already know where I’m heading… Exactly. There are rules being written, just to make sure everybody is writing valid code, and every browser displays it the same. Silly to say: Not everyone is writing valid code and nearly no browser displays exactly the same. I’m not bashing the W3C people here (although this might really look like it). In fact, I admire them for their effort. But in spite of that: The problem is there. Everybody is building browsers; websites look different on each and every one of them – even if the HTML/CSS you wrote is 100% valid.

Adobe and the Flash Player

Adobe is (mainly) the only instance developing, evolving, releasing and publishing the Flash Player (mobile devices and such left out). A lot of people think that this is a bad thing. Only one company in charge of whatever is going to happen with our beloved browser plugin? Hell yea!!
I can see how open-sourcing the Flash Player might help evolving the capabilities (features AND efficiency) but the payoff would be ‘Crossplayer compatibility issues’.
Imagine how you would publish your SWF, upload it to the server, and then test it in different Flash Players. (This is actually where my previous point of ‘Browser vs Player’ should start making sense)

So there’s our second conclusion. Browsers can be built and released by about anybody whereas the Flash Player is developed and maintained only by Adobe. Both do have ground rules to which you better stick when creating content but seen as only 1 company is creating the Flash Player and a lot of people are creating browsers, the browser implementation of those rules differs and results (may) vary. (Flash content which is not perfectly ‘valid’ will just result in a ‘movie not loaded’ message…)


Comparing ‘Flash’ to ‘HTML’ is wrong. The Flash Player is more like a browser, but on a different level (it runs as a plugin inside the browser). Comparing them is just plain senseless.

Okay… Still… SWF kicks HTML’s ass!

That’s a plausible one… but I don’t know any self-respecting webdeveloper that would agree (same goes for the opposite). If you’re on the same page as I am you’ll agree that it’s a situation depended statement.

If you want to build a game, Flash is the right choice.
If you want to create an experience to promote your latest product, Flash might be the right choice.
If you want to build a message board, Flash is undoubtedly the wrong choice.

Back to basics

In it’s early years Flash was meant to be used as ‘animated vector graphic’. For the sake of simplicity let’s just say: ‘the enhanced version of an image’. Of course today the capabilities and the use-cases of Flash have long exceeded this basic idea.

But doesn’t it feel strange to deliver information using a technology that was meant to be used as an ‘entertaining addition’?
Google doesn’t present its search results using an image or a Flash movie, right?
I can hear you go “Yea duh! That’s because Flash isn’t intended to be used for that kind of application“. Exactly…

‘The problem is choice’

Taking the red pill

It’s not about what you like most… It’s not about what is ‘the best’. It’s about what is ‘better in this case’. Right now, if somebody asks you to put a video on their HTML site, you’ll use a Flash Videoplayer (because right now Flash is the best choice to deliver video on the web: Everybody (about 99%, Adobe?) has a Flash Player installed, no (additional) codecs are needed, and not everyone is able to view HTML5 in their browser yet). That’s a no-brainer. You could go for Windows Media/Quicktime plugins but Flash would be the better choice in this case.

But if people are being asked to build a datadriven application, they’ll have a different idea about what to use. Some keep it simple and stick to basic HTML tables. Some others go nuts using jQuery and other Javascript libraries to enhance the dataviewing experience and useability of those tables. Others push it even further and choose a Flex based solution. All 3 of them will get the job done, that’s for sure, but what is the better choice in this case ? (Personally I’d go with the jQuery enhanced version)

The use of Flash or HTML each come with their own pro’s and con’s. And this is where people start arguing…

Pro’s and Con’s

Google can’t index Flash sites

Bad implementation of Alternate Content
Bad implementation of 'Alternate Content'

That’s true, although they’re working on it, it’s for from being ready (Google apparently has a special Flash Player that indexes Flash Movies. The only thing I can say about that: I don’t know about any of my previous Flash sites being indexed by Google yet…) . You could make use of the alternate content feature when embedding your Flash movie in the website. That way Google can actually index the content of the website, and bring the user to your website (where he/she can then view the Flash based version). But you have to implement the alternate content. And: No. ‘You need Adobe Flash Player to view this site‘ is no alternate content (read: Bad Alternate Content). And talking about alternate content: I haven’t seen many Flash sites being built to be able to ‘gracefully degrade‘. What if you users just don’t have the requested Flash version (company computer networks often disallow installation of new software). How do you enable them to use your website/webapplication? Right: Progressive enhancement. But building a Flash website, and not providing decent alternate content (read: alternate HTML/JS version of the Flash application) is not it!

People with accessibility issues can’t rely on screenreaders and such on a Flash based website.

As far as I know, today it is possible to help screenreaders understand what Flash is doing, and what the user can do. However: You have to implement this in your website.

You can now manage the browser history in a Flash site

Sure, and by all means: SWFAddress is great! But you have to manage it and that’s where it boils down to: It’s standard browser behaviour! You shouldn’t have to manage that.

Let’s face it: Flash breaks the regular web. So choosing Flash because it’s prettier isn’t the right choice. Choosing Flash should ALWAYS be a result of weighing the pro’s and con’s; not a result of you (or your client) liking Flash sites better than standard HTML sites…

Grand conclusion

(I’ll start this one with a disclaimer. Unlike Serge Jespers, I’m not paid by Adobe so this is really my opinion and not the one of my employee 😛 )

For now (and even for the HTML5-era): Flash will always offer a bigger and probably faster featureset than HTML (video, audio, audio analyzing, drawing, shape morphing, complex animations, special effects, levels of interaction perharps, etc…) but as long as you don’t really have to rely on Flash’s special features, stick to plain old HTML and CSS.

Flash and HTML are no opponents. They should be seen as couple that complement each other. Both should be used for what they’re best at. There is no winner, there’s no best. There’s only ‘better in this case‘.


view all posts

Ronny is a freelance frontend developer with a wild passion for creativity and a relentless hate against flat design. Ronny spent years as a Flash developer before moving to HTML5 and rediscovering fun and happiness.

3 Comments Join the Conversation →

  1. Jonas De Smet

    Nice post. I agree in most of them. It should be well considered to choose Flash, HTML or both… Everything has his special needs and capabilities…

    I only have on question, you say you love “webstandards”, but why isn’t this blog valid? 🙂

  2. Ronny

    Touché 😉

  3. Dieter H

    Nice arguments, nice post!


Leave a Reply

Your email address will not be published. Required fields are marked *