Hacker News new | ask | show | jobs
by simonsarris 4224 days ago
I hate to shit on people's work[1] on HN because everyone else does it but I earnestly think this will get filed in the same bin as XHTML, aka "no web developer actually cares about this so no one will write it and it will die an awkward, forgotten death."

HTML5 did some very important things. Mainly it wrestled back the web from plugins.

Hey, remember Flash?

Isn't that great! That in 2014 I can say "Remember Flash?" Flash had such an insane grip on the web and now it's nearly gone! Not nearly, you might argue, but there are extremely few serious pages left that depend on flash. We've come a huge way since 2009.

It's crazy to think back, honestly. I'm amazed at how the grip of flash has receded. I would not have guessed in 2008 that this was where we'd be. I am a happy web developer.

This just doesn't solve the same scope of problems. It might be useful to some people, just like XHTML, but it's not worth building a new buzzword paradigm over.

[1] Everyone who writes a post like this deserves to be commended. Putting your own opinions out there is hard, so kudos to the author.

3 comments

I don't think it's shitting on work to criticize this proposal. It has too many flaws to just be nice, smile and go on - it is the direction I don't want HTML to take, and the direction that already failed.

It's missing the lesson of XHTML. Namespaces and XML-correctness failed, what is wanted is easy to write HTML that is readable and rescueable by the browser if it is invalid. Namespaces are a clusterfuck when you just want to get a html-element with a parser, and they make writing code so much more complicated.

Also, the whole idea of elements that have no meaning for the browser misses the niceness of HTML5. Yes, we have now some elements that have only semantic meaning like the header element, but there is at least the option for browser to help with them. It is a standard set to build readable code, not fully customizable XML with no anchor in the browser. Really appreciated are the elements that use the browser, like audio and video, as you mentioned. That is missing here.

Maybe things like the media element are a good idea. Or maybe not, since it does not hurt to be explicit what you are specifying here, a video or an audio file - talking about semantic.

>extremely few serious pages left that depend on flash. //

I'll bet of the pages served the [vast] majority depend on flash for display of content and/or advertising.

On the other hand many _sites_ no longer rely on flash in that they offer an alternative HTML5 implementation. But, of the pages served I'd imagine that version is far less commonly presented to the site visitor. I'm thinking YouTube as an example.

http://httparchive.org/trends.php?s=Top1000&minlabel=Nov+15+... shows that in the Top 1000 (however they're judging that) the instances of flash use are down on average from 52 to 34% over the last 4 years. However the average flash amount of flash transferred and the average number of flash items on a page don't show any downward trend.

http://trends.builtwith.com/framework/Shockwave-Flash-Embed shows a different story - look at the whole internet version and they show a precipitous drop around April 2014, what caused that?

HTML5 may have enabled some of that, but I think the thing that actually "wrestled the web back from plugins" is the iPhone, or more generally, the smartphone. Popular devices that people wanted to target, without support for plugins (sure, Android had Flash for a while, as a second-class citizen, but it never had support for arbitrary plug-ins).