[kapowaz]

There may not be any conceptual difference, but there is a very significant difference in how these things you describe are used. Flash, when used badly, becomes a self-contained sandbox for the entire experience of a website. Besides security concerns, this approach is damaging to the overall experience of that site, since developers end up needing to re-implement native controls and functionality (scrollbars, form elements and keyboard navigation to name a few) in order to provide users with affordances they would otherwise take for granted. More often than not, the developer doesn't re-implement these features and so users are left with a sub-optimal experience (even if it is more ‘on brand’, or replete with gratuitous effects and animations). This is to say nothing for the accessibility implications.

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.

[Recoil42]

>Flash, when used badly, becomes a self-contained sandbox for the entire experience of a website.

This same argument is true for Canvas, SVG, WebGL etc.

[kapowaz]

This is true, but because of completely different toolchains it's very rarely the case that this happens. Flash, at its height, was being used with tools like Flex to build full applications. Adobe provided interface libraries for you to substitute native controls for its own (inferior) versions. Nothing like this exists yet for the tools you mention, and hopefully never will..

[roarroar]

And you think asm.js/WebGL will be any different? The more powerful the browser gets the more open to this kind of abuse it will be. Live with it.

[kapowaz]

Being open to abuse and being something that is commercially viable and desirable are totally different things. Yes, you can do all manner of nefarious things with native web technologies — as I understand it, this was one of the reasons it took so long for a native JS fullscreen API to be implemented, as it would open the door to spoofing the operating system's interface chrome.

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).

[roarroar]

To say that asm.js and WebGL are "narrow in focus" is like saying x86 is "narrow in focus". They're general-purpose primitives that can be used for a wide variety of purposes. UDK, Unity, Gamemaker, Construct all export to HTML5. Flash has achieved a huge degree of success, so if it goes away maybe the next contender will be less damaging, but the mistake can be remade at any point, and with the power of asm.js/WebGL almost any framework can be ported.

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.

[sp332]

Flash, when used badly, becomes a self-contained sandbox for the entire experience of a website.

But if it's rendered as part of the page instead of in a black-box plugin, doesn't that whole problem go away?

[Yaa101]

No, It's about what is inside the Flash that defines your experience with it.

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.