

Five Myths of HTML5 (vs. Adobe Flash) - radley
http://radleymarx.com/2010/02/five-myths-of-html5-vs-adobe-flash/

======
jeff18
While I'm always glad to see articles created by non-famous people on Hacker
News, it sucks when the article turns out to be utterly worthless and riddled
with inaccuracies. Seriously, a random Slashdot post is more worthwhile than
this, yet it is the #1 story. This also pretty much proves that either the
Hacker News voting system is flawed, the author is gaming it, or the community
is no longer as tech savvy, or doesn't read the content. Any of those
possibilities is sad.

Myth 1: the video tag will replace Flash video

The video tag won't replace Flash video? Has he missed the memo that YouTube,
Vimeo, and DailyMotion have already rolled out HTML5 support? It is not
perfect, but it is clearly going to happen. Whether this hurts Flash, is
another story: but HTML 5 video is already here and has replaced Flash for
many people.

I'd like to see a good analysis arguing why this trend might not continue --
not an apologist stick his head in the sand.

Myth 2: HTML5 is here, Flash is dead

Flash obviously is not dead. However, HTML 5 is here. See WebKit, Firefox, the
iPOS platform (his invention), Google Chrome OS, etc.

Myth 3: Canvas is good for artists

He doesn't really expand on this point except to give a few minute examples of
things he doesn't like about it. For example, you can't use fonts that didn't
come with the browser. Pardon? Has he totally missed the web font module of
HTML5?

Canvas doesn't provide interactivity and it is impossible to make a game with
it? What? I have personally played Contra with an HTML 5 Canvas NES emulator.
<http://benfirshman.com/projects/jsnes/>

Myth 4: HTML5 will solve all the problems associated with Flash

He goes on to argue that most of the problems with Flash (splash pages, high
cpu usage, etc.) will continue with HTML 5. This is true, and his only good
point, although I have never heard anyone actually say this...

However, HTML 5 will provide a much better, open sandbox for these problems.
E.g. you can modify the DOM to block an ad, or detect a script that has gone
into an infinite loop, etc. See Google Chrome or various ad block or
Greasemonkey scripts for some creative uses of this fact.

With Flash, at best, you can simply kill the plugin.

Myth 5: Adobe is not scared of HTML 5. In fact, Adobe is pushing HTML 5
forward even harder than Apple?

I was about to write up an angry rebuttal to this, but seriously, it's not
even worth responding to. After reading this last one, I kind of feel like
I've just been trolled hard.

~~~
brg
One important use of flash video is in ads. Many users feel these ads are too
intrusive, but the industry demands them and they have near universal
adoption. Penny-arcade had a strict policy against such ads, but when 99% of
ads requests became flash based even they changed their tune.

That short-content, user generated video hosting sites have experiments with
the video tag does not signal imminent shift in the platform.

~~~
Lazlo_Nibble
_One important use of flash video is in ads. Many users feel these ads are too
intrusive, but the industry demands them and they have near universal
adoption._

Near-universal adoption on the supply side is irrelevant if there's no demand
on the consumption side.

~~~
abstractbill
Users don't "demand" ads of any sort, let alone Flash ones.

Advertisers demand Flash-based ads, because they can do stuff like animation
and sound, but more importantly because they can use Flash's full tcp/ip
sockets to send arbitrary tracking information home (e.g. how long was the ad
displayed for, any mouse-over events, browser and os information, etc).

~~~
blasdel
You can do the same with an embedded <iframe> sourced from your own adserver

------
lambda
_Myth 1: the video tag will replace Flash video_

The format issues over graphics formats in the 90's ended up working
themselves out in the end; even though there were patent concerns, everyone
wound up supporting GIF, PNG, and JPEG due to market pressures (though PNG
support in IE took a while to actually work correctly). It's not going to be
easy, and it may take another couple of years of wrangling to get something
fully settled, but it will happen.

Of note, Google, one of the biggest and most powerful proponents of web
standards, the largest provider of video content on the internet, the author
of the third most popular web browser, and the main financial support for the
second most popular web browser, has bought On2, the company that produced the
original codec that became Theora, and which has much more advanced codecs
that are currently available in Flash only. Now, Google is still in the
process of going through all of the regulatory hurdles of purchasing On2, and
so has not yet said what they plan with it, but given that information, I
think that there's a fairly sizable chance that we'll see some movement on the
codec front within the next six months or so.

 _Myth 2: HTML5 is here, Flash is dead_

This is correct. Most of the new features introduced in HTML5 (and other
modern standards, such as CSS3, SVG, and the like) are not done yet, or are at
a "public preview" level in terms of compatibility and completeness. Canvas
has been around for a while, and is fairly well supported portably, including
a compatibility mode for IE, so it's pretty much ready to use, but some other
features are not.

Right now, it's time for geeks to start playing with HTML5, building tools to
make authoring with HTML5 easier, pushing it to its limits to discover where
they are and fix them before everything gets set in stone by backwards
compatibility limitations and inertia in the standards process. If you need to
deliver interactive multimedia content to a broad audience in a month, or in
six months, it's not yet time to switch from Flash to HTML5.

 _The leading HTML5 browsers, Safari and Chrome, make up less than 20% of the
desktop market._

Er, I'd consider Firefox to be a leading HTML5 browser as well, and it
commands ~25% of the market.

* Moving on, the Flash Platform today provides a far more complex level of interactivity that the HTML5 digerati can imagine, including skinnable components, embeddable swfs, movieclips, native apps w/ native processes, video and microphone input, peer-to-peer communication and file transfer, the Text Layout Framework, shared whiteboarding, and multiplayer games …and that’s just the off-the-top-of-my-head stuff.*

Some of this is bogus (skinnable components? How about CSS?), and some of this
stuff that belongs not in the browser itself but in a library on top of it,
using lower-level functionality (shared whiteboarding, multiplayer games), and
some of this represents genuine limitations that HTML5 does not address (video
and microphone input).

But the excitement about HTML5 is not simply about what HTML5 itself provides.
It's that standards based web development is actually moving forward again;
standards that meet real needs are being written, and implemented, by browser
vendors. There was a long dead period in browser development; from about
Netscape 4 until the release of Firefox 1 and Safari 1, when Microsoft had so
much market share it was inevitable and Microsoft had actually ceased browser
development altogether, and when the standards bodies went off the deep end
with crappy XHTML based standards that no one really cared about. And until
around version 3 of Firefox and Safari, and the release of Chrome, they were
still to small in market share to make much of a difference. But now advanced
browsers, with much faster JavaScript, support for SVG and canvas and Web
Fonts in an open format and, support for video and audio and more are reaching
30% market share, and it's now becoming a serious platform.

 _Myth 3: Canvas is great for artists_

Some parts not true (all major browsers support some form of Web Fonts by now,
and technologies like Cufon can convert fonts into paths that can be rendered
on a canvas even without native web font support).

The tools are still not here yet, this is true. As I mentioned above, HTML5 is
now at the stage for hackers and geeks to play with it, push the boundaries,
and start writing those tools that will allow artists to do great things with
HTML5.

 _Myth 4: HTML5 will solve all the problems associated with Flash_

Well, this is a pretty uncontroversial statement. There are never any silver
bullets, that will solve all of your problems. However, HTML5 does offer the
ability to solve many of the listed problems.

 _1) CPU hogging – yes, Flash pushes CPUs. But so does HTML5, even with really
simple apps._ _4) Crashes – this one is harder to clearly refute except to say
that Flash Player 10.1 is far less resource intensive than the current version
because it’s meant to work on mobile devices, which is no small effort. In
contrast, HTML5 is brand new and therefore untested. As people start to
experiment with complex canvases, we’re going to see CPUs pushed just as much
as Flash, if not more._

The advantage HTML5 provides is that browsers can compete on performance and
stability; as no content is locked in to a single vendor's proprietary
rendering engine, there is actually opportunity to provide something better
than one Flash can provide.

 _2) Banner ads – HTML5 won’t kill Flash banner ads – they’ll just be done in
HTML5, but now you can’t ignore them with a Flash-blocker (note to HTML5
developers – you can have the banner market. Please. Take it.)_ _3) Splash
pages – we finally defeated Flash-based splash intros, only to see them
reintroduced for HTML5_

Sure, and banner ads and splash pages existed before Flash, too, and are still
done with Flash today (when did anyone defeat Flash-based splash intros? I
still see them all the time). Advertisers will annoy users with whatever
technologies they have available; but having it all in one format that is
standardized easily navigable by DOM will make it easier for the authors of ad
blockers to selectively block content.

 _Myth 5: Adobe is afraid of HTML5_ _The fact: nobody is doing more to support
HTML5 than Adobe (not even Apple)._

Wow, this is a bold statement. Apple, Google, Mozilla, and Opera have
dedicated many engineer years to implementing HTML5 in the browsers. They
founded the WHATWG, the group that originally wrote the HTML5 spec (later
adopted by the W3C after it realized what a failure XHTML 2 was).

 _Adobe pushed for SVG integration but was ultimately won over by the
flexibility of Flash._

Beyond the fact that SVG is not HTML5 (yes, I realize that people use HTML5 as
an umbrella term for all modern web standards), it's true, Adobe was one of
the early supporters of SVG. They did a crap job of implementing SVG as a
plugin, though, and ended up simply buying Macromedia with its much better
Flash plugin instead, and abandoned SVG. They haven't really shown much of a
commitment to SVG, HTML5, or any other modern web standards since then,
though, devoting the majority of their effort to promoting Flash and Flash
based platforms like Flex and Air.

So yes, Flash had many years to pull ahead. It will take some time for the
browsers to catch up, and become ubiquitous enough to depend upon. It will
also take some time for tool vendors to produce tools that can compete with
Flash. The disadvantage of it being done in standards is that the process is a
bit slower, and it can take longer to wait for the stragglers to catch up
(beyond the long head start Flash got due to the implosion of the browser
market and standards process). The advantage is that the browsers can compete
on stability, performance, and all of those issues that Flash is notorious for
not addressing; by using open standards, your content is not locked into an
engine provided by one vendor only.

~~~
psyklic
Regarding "CPU hogging," there is nothing wrong with a graphics-intensive
program using the CPU -- in fact, this is necessary to continually refresh the
screen.

It only gets out of hand if the software does not give time to other
applications who request it. In Chrome, if you minimize the window or switch
tabs, then the CPU usage returns to normal. So, I do not classify this as
"hogging." It would be interesting to see what happens if a second CPU-
intensive task is running simultaneously, but note that here different users
will have different preferences on priority.

------
dbz
_"Bottom line (and greatest irony): the only company we can actually count on
to make HTML5 successful will be Adobe."_

Uhm. No? Where did you get that idea? Microsoft has the majority of the
market. If Microsoft suddenly forced an update to all browsers which supports
html5- well gosh. html5 would instantly be a huge success just because almost
everyone is forced to use it! I'm not going to go into other examples where
other companies could also make html5 a success because I already disproved
your point; however, I will say that I don't believe the success of html5 is
up to adobe.

------
endtwist
I could write and write about all the problems with Marx's arguments, because
there are many, but it's just not worthwhile.

 _To those less informed on the whole situation:_ The simple fact is that
Flash isn't going anywhere for a long time, but at the same time,
implementation of HTML 5's features is quickly going to become far more
pervasive (we're already starting to see this). You, of course, have people
from both extremes arguing both sides ("Flash is dead!"; "HTML5 will never get
anywhere!"), but if you're really listening to just these opinions, you're
only going to get a very polarized view of the situation.

Sit down, read the HTML 5 specs, keep up with the latest HTML 5, Flash, and
major browser updates, and you'll get a better picture of the situation.
Listening to people like this Radley Marx really does not give you an informed
or balanced view of the whole situation.

------
gnubardt
_The problem solved by Flash video wasn’t can I show a video? Instead, Flash
solved can everyone watch my video? HTML5 video doesn’t provide this solution;
it just adds another approach to the incompatibility pile._

Isn't support for codecs built into browsers that support the video tag
(rather than requiring external software to be installed, when embedding)?

~~~
yumraj
Why are you forgetting that codec's themselves are "external software", the
only difference would be that the browsers themselves would be shipping them.

One could kind of argue the Ogg Theora would not be "external" just because
it's open source, but in reality all codecs are external, especially the
proprietary ones like H.264.

------
chipsy
I posted a much more comprehensive and correct summary here:
<http://news.ycombinator.com/item?id=1101588>

