Hacker News new | past | comments | ask | show | jobs | submit login

A video element is a video. It's as well or poorly handled as, say, an image. (The QuickTime / MP4 container actually allows standardized text tracks etc. so it's capable of being more semantically tractable than most other media formats in the long run.)

The other options are all, as you say, semantically impenetrable, but that's not all there is to it.

WebGL has the advantage of delivering very lightweight and efficient graphic effects, whereas even native Flash was horribly inefficient at doing what it did. NaCl likewise is intended to deliver near native performance to embedded functionality and isn't designed for a proprietary production front-end, better than Flash on both counts.

Canvas affords JavaScript the ability to natively generate graphics that would otherwise be impossible or very difficult. Flash is pretty horrible to talk to with Javascript.

So yes, other things are impenetrable, but Flash is impenetrable and lacks the virtues of those other things.




> WebGL has the advantage of delivering very lightweight and efficient graphic effects, whereas even native Flash was horribly inefficient at doing what it did.

Fundamentally incorrect. Flash is actually an incredibly efficient file format for rich media, especially at vector animation. Look it up, you can fit amazing animations into just a few kb. Nothing can beat it on the web today for that purpose, and the Flash IDE environment is unsurpassed as a toolchain for the creation of that sort of content. Of course you can abuse it, like any other tech, and pump too many large images, videos, sounds or whatever into a SWF.


Flash's file format is fine w.r.t. compression. (It's beastly to parse, but that's a consequence of history.)

It does a terrible job of rendering graphics though (probably because the guys who wrote the lowest level parts of the engine did so a long time ago and have moved on). When Steve Jobs wrote his letter about Flash a big part of the deal was Flash's impact on battery life because it was so inefficient -- and Adobe struggled to fix this for years and then gave up.

I remember back when some Adobe blogger published a comparison of Flash to canvas animations showing Flash to be significantly faster. I, and several others, posted trivially optimized versions of the canvas code that crushed Flash like a bug, and this was Flash at the end of a long period of optimization where it carefully draws only the regions of the screen that changed, versus a pretty naive canvas implementation pretty much double-buffering its animation.

http://loewald.com/blog/?p=3362


A single bouncing circle on a rectangle doesn't count as a benchmark in my opinion. Flash can be written in a performant manner, it used to be faster than HTML for almost everything, but that gap has narrowed for some specific things.

Most of all though, in my experience, Flash is usually more consistent across browsers and operating systems. Even if it's slower than the fastest browser, it's at least consistently slower.

When dealing with the desktop and/or applications on mobile devices that support AIR (i.e. supported runtimes), graphics rendering isn't an issue anymore. If you are really stuck with poor graphics performance using the traditional methods, you can just leverage Stage3D, which is just like WebGL, except it has a compatibility layer and is constrained in some ways, which can potentially make it more compatible with different underlying architectures and across more GPUs.

Going back to benchmarks though, I believe that 95% (pulled out of my behindus) of benchmarks have poorly written code / code that could be optimized to run an order of magnitude faster, so I won't engage in a benchmark fling-fest. I can at least link a few minor tests I made a while ago where I encountered the above mentioned inconsistency issues:

https://docs.google.com/spreadsheet/ccc?key=0Av4YDog3VfA-dHI...


My favorite example of a Flash website was Adobe's store, which was 100% Flash for quite some time and virtually unusable (in different ways!) on every platform.


Fun unsubstantiated anecdote; when working for Symbian we unofficially optimised their then-new renderer for generic 2x speedups. But this was just weeks before the death of UIQ and that went nowhere...




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: