Since the advent of smartphones and tablets that can't display Flash content, sites that do this have started to die out in favour of a combination of native applications and true HTML implementations. If the experience they're going for calls for a video or canvas element (3D or otherwise) then great, go for it. But the scope of that part of the experience is implicitly reduced, and so it doesn't result in a sub-par experience across the board (I might not be able to see your fancy WebGL 3D canvas effects, but the links to your ‘contact us’ page still work).
What I'm worried about is that by providing a compatibility path, Flash's imminent demise will be put on hold, and the sub-optimal experiences I described above see a resurgence. And that's not a good thing.
But if it's rendered as part of the page instead of in a black-box plugin, doesn't that whole problem go away?
For me the best trade-off is still to use a flash-block and grant the flash running time when I choose to do so.
This same argument is true for Canvas, SVG, WebGL etc.
But where these technologies differ is that Flash was marketed as a one-size-fits-all solution, that allowed designers and developers to work inside of a single framework. The barrier to entry is also very low: you can achieve a lot (relatively speaking) without much technical expertise — certainly when compared to how much effort it might be to do things the right way with native tech.
I don't ever see this happening with the likes of asm.js or WebGL because they're much more narrow in focus, plus they require very different (and non-trivial) skillsets to those of designers. As soon as an endeavour like this requires multiple developers and designers, it no longer appeals to your common or garden ‘chuck it over the wall’ marketing agency; the only ones that can afford to invest in this are the ones using the tools appropriately (or at least, most of them will be).
People have always abandoned the pure, semantic HTML way as soon as the power has been there to do so. Sometimes this has been for good, sometimes for evil. You need to either turn it into a general purpose computing platform (Mozilla have been fighting this for a long time and finally lost) or leave it as a pure document browser (in other words, an application rather than a platform). But since people always want cooler, shinier things delivered faster, and the web provides fast, sort-of-safe delivery, there will be pressure from many places to start trying to eat up some of the native pie, which is how we got here in the first place.
The web people got everything wrong. They pushed a ton of waffly high-level rubbish trying to hang onto a restricted, comprehensible model, but in the end they had to cave and stick all the powerful stuff in anyway, and on a C-machine that means something like C (hence asm.js, which is a C compile target). And what we've ended up with is, frankly, pretty shit. The whole idea of nice, semantic HTML only works as a restricted application with no client-side programming facilities. Maybe in 30 years someone will have the sense to lift it out into the "user land" of the browser where it belongs.
You misunderstand.
My beef is with NaCl, objects, Applets and ActiveX etc as well, mainly because they run outside of the browser's engine, sandbox, security model and conceptual model. you also have to ship them externally to the browser.
Canvas, video, webgl fine.
"Shumway is an HTML5 technology experiment that explores
building a faithful and efficient renderer for the SWF file
format without native code assistance."
But one security model is better than having two security models.
That's why e.g. the Unity3d plugin is so great. A complete 3D engine (with state of the art graphics, the ability to load almost any 3d format on earth, ...) does not belong into the browser. I don't want that code on my work PC.
OTOH, its great to have the ability to run games in the browser. The performance is much better than WebGL (because it contains compiled code, and because it is a complete, tuned, engine and not just an opengl implementation). And it's fairly safe, since it's built with Mono/.NET, you don't have problems with shellcode injection etc..
That would be my stance. "Creativity" mostly translates to flashy adds, and while there are numerous examples of fun, engaging and useful Flash animations, they are vastly outnumbered by Flash banners, and the math is really simple: Blocking Flash is a huge net positive.
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.
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.
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.
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...