Reader Q&A: Flash Redux

David Braun asked:

@Tom @Herb: What’s so wrong with flash that it should be boycotted? Have I been being abused by it in some way I’m not aware of? Also,does HTML5 have any bearing on the subject?

I’m not saying it should be boycotted, only that I avoid it. Here’s what I wrote two years ago: “Flash In the Pan”.  Besides security issues and crashing a lot, Flash is a headache for servicing and seems to be architecturally unsuited for lower-power environments.

Since then, two more major developments:

1. Even Adobe has given ground (if not given up).

Adobe subsequently abandoned Flash for mobile browsers and started shipping straight-to-HTML5 tools.

Granted, Adobe says it’s abandoning Flash ‘only for new mobile device browsers while still supporting it for PC browsers.’ This is still a painful statement because:

  • it’s obvious that ceding such high-profile and hard-fought ground sends a message about overall direction; and
  • the distinction between mobile devices and PCs is quickly disappearing as of this year as PCs are becoming fully mobilized (more on this in my next blog post).

2. We’re moving toward plugin-avoiding browsing.

Browsers are increasingly moving to reduce plugins, or eliminate them outright, for security/reliability/servicing reasons. Moving in that direction crease pressure or necessity to either:

I’m not saying Flash will die off immediately or necessarily even die off entirely at all; there’s a lot of inertia, it’s still useful in many kinds of devices, and it may well hang on for some time. But its architectural problems and current trajectory are fairly clear, and it’s been months since I’ve heard someone complain that certain people were just being unfair – Jobs’ technical points are on the right side of history.

5 thoughts on “Reader Q&A: Flash Redux

  1. Plugin Free? It really depends on how you define that, and yes, I know the current definition.

    Are smart phones/tablets plugin free? IMO, the direction is that of being a container that allows plugins(Apps) to render themselves based on a set of rules defined by the phone/tablet maker.

    The browser should be the same, not a different method of information delivery. In other words, the standards should be focused on a standard container for app delivery, not a standard based on content rendering.

    Unfortunately, this is not the case today.

  2. @ Johan
    “There’s a nasty bug lurking in the memcmp() implementation of operator==(). The layout of a struct, due to alignment, can have ‘holes’ in it. C++ does not guarantee those holes are assigned any values, and so two different struct instances can have the same value for each member, but compare different because the holes contain different garbage. ”

  3. Herb is there a chance we might get easy way to compare structs in C++17?
    like bool MyClass::operator==(const MyClass &other) =memberwise/*or “default”*/ ;

Comments are closed.