The End of Flash as we Know It by

Usually when someone says “the end of” some technology, we can all snicker, knowing that this meme comes up every so often and is usually way off base.  In this case, with Adobe’s recent announcement of the end of Flash on mobile devices, we can reasonably say it is the beginning of the end of Flash as we know it – because, increasingly, sites will be designed without it.  Flash won’t go away in a day or a week, but it is in decline. It seems like a reasonable strategic move for Adobe.  Their engineering team has had more than enough time to figure out how to make it perform for mobile devices – and it hasn’t.  Moreover, iOS was unlikely to support Flash even if it started to perform well. Still, it was a moment full of rich claim chowder.  No surprise, Daring Fireball has the best collection of such links:
  • Everybody Wins – as John points out, it isn’t some competing Apple tech that won, it was HTML5, which is an open specification.
  • And clearly, Steve was Right.
  • Opponents: in this piece, John reminds us that Apple didn’t win this argument from a position of market dominance, they were starting from a position of zero marketshare in 2007.  And one could argue that keeping Flash off the phone improved the experience – and therefore the sales – of the devices.
  • Why Apple is Completely Wrong – one of the more amusing “claim chowder” posts.  JR Raphael’s response is even more amusing, in that he completely ducks the argument he picked in the first place. And of course the first tip-off that he’s lost the argument is that he opens his blog by belittling Daring Fireball and John Gruber, rather than just responding to the points made.
  • Did you know Flash 10.1 was going to kill HTML5?
What’s surprising (to me) is how many people really thought Flash support was a problem, or a marketing gimmick that real people would care about. At least there is one commentator who had the courage to poke fun at his own writing: Dan Frommer, now writing for his own spot, SplatF:
But it was so impractical! Not just the idea of Palm and Adobe banding together — they actually did try to work together on Flash for WebOS devices, and it still failed. But the idea of Flash working well on a mobile/touch device was so far-fetched in 2007, and is still pretty looney today. And that’s a big reason why Adobe is now winding down mobile Flash development. (Though it will continue to try to be a part of the mobile app ecosystem, which is sort of what I was getting at.) Anyway, I think that was the first time John Gruber linked to me from Daring Fireball. I guess I deserved his sarcasm that day: Sure, and maybe they can wave the same magic wand and make chips run faster and cooler and have batteries that last for weeks without recharging.
At least Dan owns it.  I’d love to see something similar from Fred Wilson’s blog – a re-examining of the basic truths as he saw them in 2007-8.
  • http://twitter.com/philgilbertsr Phil Gilbert

    Scott… nice wrap up.  But there’s a lesson to be learned here that goes beyond who was right and wrong about Flash.  It goes, I think,  to the curiosity and intellectual honesty of engineers, and the political courage of business management to protect those precious traits.

    In 2006 or 2007 when we (at Lombardi) were initially prototyping what would become Blueprint, we tried many technologies as the foundation for the user interface advances we wanted to make with that product.  One of the earliest prototypes was (not surprisingly) based on Flash, which we assumed would be the long-term basis for Blueprint’s advanced interface.  We wanted the interactivity that Flash promised, we thought the browser-independence would give us cross-platform leverage and it had a market share that we felt would give the product technical credibility.

    What we found out was quite different, especially in the area of basic stability.  In a matter of weeks, we discovered every flaw that Steve would write about two years later.  We scuttled Flash and spent 2-3 months (an eternity, at the time, if you were working for me!) looking for a suitable architecture.  Of course, as you know, we ended up with GWT, which turned out to be a great platform for us.

    Over the years, our decision to not use Flash was challenged by a lot of people, almost all of them coding engineers (!) and I always wondered why they were so passionate.  I mean, it’s never taken a lot of work for our engineers to crash Flash.  It seems that some “truths” get so ingrained in our thinking that we become, I don’t know, un-curious… set in our ways.  We assume the market leader is good simply because they are the market leader… we assume that if something is good for one use case, it must be OK for another.  Oddly, many of the people who questioned us had, themselves, built applications that crash Flash… and they acknowledged this!  It’s a head scratcher.

    I think it’s a troubling trend in our industry.  As an old-timer, and fresh off reading Isaacson’s book and reminiscing about Apple, Microsoft and the beginning of personal computing, I do recall when the engineers of the early personal computers and related software accepted nothing as gospel, and certainly challenged everything that existed.  It was a small community, but there was a curiosity, and an intellectual honesty I find lacking today.  Although he ended up very rich, I know exactly what Jobs’ meant when he said he never did anything for the money, just for the product.  

    But back to the lesson:  At the end of the day, to me this isn’t about Flash or Apple… it’s about the quiet acceptance of mediocrity; and about accepting a “standard” simply because it is a “standard” rather than because it is the right thing. 

    So for those of us who are crazy enough to worry and wonder about something like Adobe Flash and why it took a Grand Gesture from Apple to reveal what was patently obvious to many people around the world, let’s also think about the broader issues of curiosity and intellectual honesty, and how we can and should be relentless in our pursuit of these traits in our work, in our products, and in our daily lives.  

    Phil

    • http://www.bp-3.com/blogs sfrancis

      Phil – I remember those early prototypes – and I remember how the issues with Flash drove us to GWT.  And it wasn’t quite as visually appealing at first, but it worked. And it worked all the time.  (I can’t remember blueworks or blueprint ever “crashing” or failing to operate on my browser).  Glad we made that switch!

      And there’s definitely a lesson here for BPM… whether you’re producing a BPM software product, or producing a process in a BPM platform…