5 ms·

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, become

by kapowaz 13y ago

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.

sp332 13y ago
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 13y ago
  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.
Recoil42 13y ago
>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 13y ago
  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 13y ago
    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 13y ago
      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).

by kapowaz 13y ago

sp332 13y ago

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 13y ago
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.

Recoil42 13y ago

>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 13y ago
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 13y ago
  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 13y ago
    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).