Slashdot Mirror
How Adobe Flash Lost Its Way
snydeq writes "Despite early successes on the Web, the latter years of Flash have been a tale of missed opportunities, writes Fatal Exception's Neil McAllister. 'The bigger picture — which I've touched on before — is that major platform vendors are increasingly encouraging developers to create rich applications not to be delivered via the browser, but as native, platform-based apps. That's long been the case on iOS and other smartphone platforms, and now it's starting to be the norm on Windows. Each step of the way, Adobe is getting left behind,' McAllister writes. 'Perhaps Adobe's biggest problem, however, is that it's something of a relic as developer-oriented vendors go. How many people have access to the Flash runtime is almost a moot point, because Adobe doesn't make any money from the runtime directly; it gives it away for free. Adobe makes its money from selling developer tools. Given the rich supply of free, open source developer tools available today, vendors like that are few and far between. Remember Borland? Or Watcom?'"
Closed, proprietary, full of security holes, resource hungry, used by marketers to deliver enhanced annoyance to users.
The Internet was waiting for a replacement to come along.
Flash was living on borrowed time because of those who had an opinion most saw it as a necessary evil instead of a wonderful platform.
Flash failed because it was proprietary. End of story. The web is no place for closed technologies.
Aside from discussions on workstation software, the term "native app" has now become moron speak for "embeded webkit".
Any replacement(s) will be shitty, too. It won't matter who creates them, or how they're implemented. They will be shitty. That's just the nature of any attempt to have the browser host remotely complex applications. The browser is merely a document viewer and navigator; it is not an operating system of some sort. It will always fail as an operating system or an application host.
Go back to when this idea of having the browser host applications first took off. JavaScript is one of the biggest blunders of all time. It wasn't just shitty when it was introduced in the mid-1990s, it was seen as absolutely abysmal and unacceptable by basically all developers at the time. These were developers who had used real languages like C, C++, Smalltalk, and Perl. They knew shitty when they saw it, and they refused to use it. That's why JavaScript went basically untouched for a decade, until those developers had retired or moved on to other endeavors. It's only been deemed "acceptable" by a much younger and more inexperienced generation of programmers, many of which haven't used any other programming language (with the exception of perhaps PHP, the next worst language ever implemented and widely used), and thus don't realize how horrible JavaScript is.
The other technologies that followed the initial JavaScript attempt have been shitty, too. Java applets, ActiveX controls, Flash, and now JavaScript again with the latest and ever-changing-not-to-be-standardized-until-2022-or-later HTML5 nonsense, have all offered horrible experiences and nothing but problems for users, system administrators and network administrators alike. Google's Native Client effort will likely be just as horrid in the long run, although their work does seem marginally more competent than, say, all of the JavaScript work ever done.
The end result is that the browser should not be used for anything more than displaying and linking documents. Real functionality should be implemented via a native application. If more than one platform needs to be targeted, use a truly portable programming language like Python, or do the right thing and create separate implementations for each platform.
IIRC Apple explicitly didn't want native apps when it released the iPhone. Their original idea was to have everything web based and accessed through Safari. A lot of time and effort was put into making this work. Native apps, and the app store, only surfaced with the 2nd revision of iOS and after people had been jail-breaking their phones to be able to install native apps. Android had to allow native apps because iOS did. This drive to native apps was from the users not from the manufacturers. The whole summary is a massive rewrite of history to fit the author's viewpoint.
You may think me a tired, old, cynic. I'd have to disagree about the tired bit.
There will be a very big opportunity for something that ties all these platforms together in the near future.
My iPhone has its own development platform
My wife's Android phone the same
My LG TV has its own App API
My Philips Blue ray player has its own App API
Samsung just announced its going to develop yet another OS for mobile phones...
The market is fragmenting so fast its with all these "App" platforms, that there will be a great incentive for the first to create the "write once" , "run everywhere" tool chain. This will of course take a few years, but so many different platforms cannot be sustained.
In modern browsers, any web site can cache application data and logic on a device so no internet access is needed. Google does this for their mobile gmail site and it works quite well.
This is insightful, but I don't think that including movie playback was where Flash lost its way. I think it was when they tried to make Flash into a "platform".
As you say, Flash started out as an animation plugin for vector graphics, and it was good at that. It became used more and more for advertising, which was annoying and often overkill; advertisers used Flash for things that would sometimes be handled more efficiently by a simple animated GIF. Today, it is generally good for 2 things: playing video and making casual games.
However, somewhere along the line, Adobe decided that it wasn't enough to handle content-creation, but they had to own a "platform". PDF stopped being a print-layout format, and suddenly you could build a whole little program into your PDF. Similarly, Flash stopped being an animation plugin and became something more of a development toolkit. When you look at Adobe Air, it becomes clear that Adobe wants you to build whole applications in Flash. Someone at Adobe is hoping that the future will see developers abandon other languages and development tools, and only Adobe will control the software industry.
Still, Flash as a vector animation plugin was doomed to obsolescence sooner or later. It's too simple a function for the world to be depending on a proprietary plugin.
It's not a glibc bug, it's a bug in Flash.
Flash was using memcpy(3) incorrectly. It happened to work on older versions of glibc/x86 by chance. There was never any guarantee that it would work on later version of glibc/x86, or on non-x86 versions of glibc, or non-glibc libcs (e.g. BSD libc), or basically any other Unix/POSIX/C-based system.
The whole bloody reason for API documentation, standards and the like is so that bad or non-optimal implementation details need not be fixed in stone forever! You should be able to re-implement an API any way you like "under the hood", and providing the implementation meets the API spec, you're good to go. Anyone relying on undocumented side effects of a particular implementation is doomed to pain. That's how APIs work. That's how the POSIX and the C standard work, and that's how memcpy(3) works, and that's the reason for memmove(3)'s existence.
Yes, all developers make mistakes. Sometimes we do make the wrong API call, or pass a NULL where we shouldn't, but the code accidentally works on one implementation of the API for a while. When we become aware of it, the correct response is to FIX THE BUG IN OUR USE OF THE API on all current branches and release a "point" update ASAFP. "Months" should not be an acceptable timescale for that sort of thing. Especially for something as simple as replacing calls to memcpy(3) with calls to memmove(3).
Why doesn't the gene pool have a life guard?
That's fine, but why do you hang out on a technology web site?
Apple strongly supports HTML5 (and HTML5 is quickly acquiring all of Flash's capabilities) as a means of writing un-curated apps for iOS devices. There is no regression back to anything. All Apple wants is that the Apps which run on their platform won't destroy battery life, steal data, crash, or otherwise annoy their customers. This can be done by writing curated native apps or by working within industry standard protocols for uncurated web apps. Seems pretty simple to me. But then again, I understand how computers work and you don't.