Technical Reasons: Because Flash is more than an animation platform. Entire applications have been developed in ActionScript (the platform's main language), significant piping was deployed (mainly in the early 2000s) in Adobe/Macromedia-based solutions where Flash played a key role as a connector/target/control interface.
In other words, for many important websites, Flash was the JavaScript of today (far reaching, with critical appearances in both the back and front-end).
Business Reasons: Adobe has had a rough decade. The Macromedia acquisition was a red pill (IMHO) for many at the company. The company has been dramatically slow in adapting to a new Web. Several major projects have failed or under-performed. All and all, Adobe has bigger fish to fry than to procure their developer base of a free/low-cost migration solution.
Other Reasons: 1)The nature of proprietary software - a lot has been written about this so feel free to look it up on the Web but basically its hard to just discontinue software without facing several non-trivial legal challenges. 2) The Steve Jobs Effect - or the curse of having a major figure accelerate the demise of a product that should have evolved into an open standard. 3) The Adobe Coldfusion Effect - Macromedia/Adobe has a product called ColdFusion Server that used Flash technology A LOT to differentiate itself, however the transition strategy adopted by Adobe didn't immediately discontinue Flash support for ColdFusion generated reports (for example) and such a direction made developers less likely to invest in a quicker migration to HTML5.
I feel your pain and, at this point, would also like to see Adobe pull the plug once and for all. But we live in a complicated world, for better or worse.
Really, I always assumed that Adobe successfully mitigated all the revenue risk by selling recurring Creative Studio/Cloud licenses, and that Flash was not a big chunk of revenue anymore. I remember Steve Jobs planning to kill Adobe or at least news blog reporting such intentions.[0]
Adobe stock has done pretty well over last half a decade even when compared with Google.[1]
I don't have the feeling that google finance is live and kicking. I think it's one of those product that will disappear soon. There are lots of broken feeds like:
I actually went to google finance where I could get live price feed when yahoo and my bloomberg terminal had 15min delays. Now even yahoo has live feeds too.
1. It's because Google finance is old and probably forgotten. Really answers the OP question why it's not a good idea to kill flash right now.
2. Have been trading for a while and can tell that the performance of that chart beat the hell out of any JavaScript charting tool out there. It's interesting that JS/HTML 5 is all the hype now but it's still lagging behind a 10 year old technology.
Yeah, i do find it odd that Google finance (which is used quite a bit i believe) hasn't had any life breathed into it. I'm sure its had the same design for the last decade now
While they seemed to have abandoned Google Finance and left it in flash limbo, they do seem to be using HTML5 for stock charting whey you query google for: "company name" quote
The last version before subscriptions came in, it was cheaper to fly return Australia -> US and purchase a copy of Photoshop, than it was to just purchase one locally here in Aus.
Adobe can stand to have a rougher time of it, IMO...
Not true at all - their share price has more than tripled in the last decade [0]. Web development was never a big part of Adobe's business. They were trying, because it's similar to their other product areas, but they never got a big foothold, except Flash.
They still make a ton of popular software (Photoshop/Lightroom, Premiere, Acrobat, Illustator, After Effects, ...), and most of it is selling better than ever.
"The red pill and its opposite, the blue pill, are popular culture symbols representing the choice between embracing the sometimes painful truth of reality (red pill) and the blissful ignorance of illusion (blue pill). The terms, popularized in science fiction culture, are derived from the 1999 film The Matrix."
>or the curse of having a major figure accelerate the demise of a product that should have evolved into an open standard.
Well, they always had the option. It's not like they were working on open-sourcing it. It's an Open standard like Windows API EXEs are, you get half-support from Wine, but no guarantees.
I don't get it, aren't there free (and open source) Flash players besides Adobe's?
Google Chrome doesn't use Adobe's Flash player, for instance, but a player called PepperFlash.
Adobe could very well discontinue developing their player, and just tell people to use an open source version. They could make it a marketing stunt by open sourcing their player for user freedom or some stuff like that.
PepperFlash is made by Adobe, and is closed source, it's called "PepperFlash" because it uses a different set of APIs, "PPAPI" vs "NPAPI". It's available to download from their "other versions" download page, so I'm wondering what your point is?
There are only two open source players AFAIK; Shumway, which has been discontinued, and GNU Gnash, which despite the heroic efforts still doesn't support all features.
Lots of interesting and useful comments in this thread. It looks to me like Flash will remain a nightmare for Adobe until the company gives in and releases their source code to the public. Once that happens, their developers can get involved in supporting it and keeping it secure.
Note that "kill" is just a less ugly way of saying "stop providing security updates for." It's not a SAAS, they can't just snap their fingers, shut down the servers, and have flash actually go away. Even if Adobe actively tried to murder Flash Player, people would still end up pirating copies of the installer from shady sites for their legacy needs.
If no browsers had support out of the box and even plugins were hard to come by (browsers could actively prevent running anything it thinks is a flash plugin..) the problem might go away.
This was the original state of Flash and Java. This is when they grew. Trust me when I say: This would not be a problem.
> and even plugins were hard to come by (browsers could actively prevent running anything it thinks is a flash plugin..)
This is no longer Adobe 'kill'ing Flash Player, and also how you get a bunch of pissed users switching browsers or sticking to legacy versions. This shit right here is how you get IT departments sticking to IE 6.
Although, this is perhaps a golden age of open source. Maybe we'd see hostile forks instead!
And, of course, iOS Safari has already 'kill'ed Flash in this sense. On the one hand, it's added some pressure to transition to new tech stacks. On the other, since we're still asking questions about how to kill Flash Player, it clearly didn't do the job ;)
I think the current pace of the death of flash is good enough. It also seems entirely fine if corporations or some individuals have to bend over backwards to keep their legacy apps running - that's how XP mode on windows still ran 16bit apps for years after ms stopped shipping a Windows version with native support for 16bit apps.
The problem with flash is that the people who get in trouble through exploits had no intention to run flash at all.
Browsers could start by disabling it by default and only enabling after modifying well hidden settings that would be no problem for a legacy intranet or kiosk scenario, but would serve my mother in law well.
No. Kill is to _only_ add bugfixes for X years and then commit to shutting it down, while creating a migration path (shumway, whatever) for existing code.
No way. My employer finished upgrading 250k devices to Windows 7 early last year.
Thanks to the epic fuckup with Windows 8, there's no way that transition to 10 will complete in 2020. My guess is that most large commercial customers will have 20% of users running Windows 7 through at least 2023. VDI or other similar mechanisms will be used to isolate it.
> No. Kill is to _only_ add bugfixes for X years and then commit to shutting it down, while creating a migration path (shumway, whatever) for existing code.
Shumway is dead. There is no migration path for existing code. The closest thing that exists is Haxe and OpenFL but it doesn't directly support ActionScript or SWF files. What they need to do is opensource the player.
I doubt they will open-source the player, for one primary reason: We already know that Flash is hilariously broken wrt security (see for example [1]), and exposing the source code will lead to dozens and dozens of horrible exploits within a few days, thus prompting browser vendors to forcefully lock out Flash in a cloak-and-dagger operation to protect their customers. (Either this, or Adobe will face a shitstorm of unprecedented proportions.)
I work appsec for a company that provides a (primarily) flash-based web platform - Apache Flex, specifically. What people don't realize is the extreme cost of porting things like this to HTML5. We have nearly 1M lines of ActionScript. The browser makers and Adobe are aware of deployments like us, and that's why they can't just pull the plug. We don't need a few months to fix this problem, we need years.
Why would Adobe keep investing money in your problem? When there no longer is a revenue stream that funds updates there will be no more updates.
If you need years to transition off Flash you should have started years ago and if you haven't yet, you have a very big problem on your hands. And if you think Adobe cares about that you are mistaken. They don't care unless they can make money out of it. They are not a charity.
At least in part because you sacrifice some good will with those customers and others around them. Look at the response on HN when Google announce a new product, and people are skeptical that they will keep it alive long enough to build around.
To echo the answers of others: It's bad for their reputation and it impacts the business of the future.
I'm currently involved with a business transitioning their content from Flash to HTML5 and they are adamant about completely removing any Adobe software from the stack.
This means that they won't be using the HTML5 backend of Adobe Animate (formerly Adobe Flash Pro) out of principle, even though in this case it would be acceptable to keep it around as an authoring tool.
By the way, the same is true for any Google software, they won't be using (for instance) Google Web Designer because of Google's extremely poor track record of supporting software in the long run.
Which is precisely what Microsoft did with a raft of technologies that were actually quite good. WPF, SilverLight and WCF all come to mind, and are all reasons why I won't adopt a new Microsoft framework in future.
Is your company actively working on a replacement? I've felt like Flash has been "on it's way out" for the better part of three years. It seems to me that your company has had the years it needs to make the change and has chosen not to do so.
THREE years? I feel like it's been at least ten. The sad thing is I have friends who know the risk of using Flash, but- but there's that ONE (sports-related, in this case) site they need to use... so they won't dump it.
Same for me. I removed the Flash Player from my work notebook in an attempt to increase security, but then noticed that our online meetings are powered by Adobe Connect. Guess what UI technology it uses.
Yes, and we have been for a while. But as you can imagine, you can't stop adding features to your existing product and expect to survive. 1M lines of code isn't something you can port quickly.
Is there some sort of process in place for mitigating the potential "1 step forward, 2 steps back" path of adding features in ActionScript and then having to eventually port them?
Where we could, we certainly tried to avoid it. The bigger problem is just the opportunity cost with regards to resources involved with the transition.
Which is a large cost no question. Especially with the size of the codebase you mentioned. What I'm interested in is how, if at all, the transition process is managed. YouTube's transition from Flash might be an example of this. They managed it by creating an opt in sort of beta experience that they tested for a long time before making it the default.
Another thing I'd be curious about is the line at which the opportunity cost of not making the transition surpasses the cost of not developing new Flash features.
On the other hand, Google has the advantage that it's a web/programming/tech company at heart. So when a CEO hears that Steve Jobs is not allowing Flash on the iPhone (and when a branch of the company helps develop HTML5), he sees the writing on the wall and is willing to work on migrating to HTML5.
When a bank CEO, who has no idea about anything except "Well Adobe is a big company and I've never heard anything about this W3C, and how long will it take? How much will I make off it right now?" hears (if he even does) that Apple doesn't like flash, he won't care.
This. This 1000x. I have a client who is a mid-sized enterprise SaaS provider, and their moneymaker is a large flex app that talks to a legacy backend.
We are currently shoring up this old app while simultaneously building a new, modern in from scratch.
It is a constant battle of bug fixes on the old and implementation and new features in both platforms as we try to transition customers off.
I do wish the actionscript and flex ecosystems were still thriving because we could use the help. I imagine other enterprises are in the same place.
These kind of scenarios are key. People forget that companies have invested millions of dollars into systems based on this technology.
In the early 2000's I worked for an e-learning company. All of their courses were interactive, popular with large corporations and trained employees from fire safety, to compliance to business processes. It had user testing built in and in order to deliver the interactivity and keep it interesting, Flash was the perfect tool. It has great hooks that you could use JavaScript to get data and out, and interface with backbend databases/scripts and of the shelf e-learning management systems.
Much of those e-learning courses are still being used today. Most of the content is still relevant today. It makes no sense to throw it away.
It is companies like these and those of the parent poster, that are the key reason why Adobe cannot simply pull the kill switch
It is the same story with Java Swing apps. Sure they are hideous and can be slow if poorly coded but man once they worked they worked reliable well and porting becomes this sunken cost that you never finish and just abandon.
The real story for Java and Flash is not having to worry about browser compatibility something I think many think has gone away with webkit but the reality is it is still here and worse than ever (mobile, firefox, ms edge).
Well, the codebase existed long before HTML5 was supported by pretty much any major browser (remember, HTML5 didn't really stabilize to the point an enterprise could use it until 2012). So you have to continue adding to it while you wait for HTML5, and its popular frameworks and libraries, to come to fruition. Oh, and we're an enterprise SaaS app, so all of our customers run on whatever version of IE was released 4 years ago.
If all your customers are enterprise and running from within that environment only, would they not be able to enforce a group policy where flash can only run for specific domain names?
Someone always signals there will be a price to pay. The thing is, the price is not high enough when compared to the profit you gain by continuing down the road you are on now.
Further to this, a lot of enterprise-type companies I've worked at who have web applications, but their primary business isn't tech, just don't seem to understand software maintanence, and as such won't put a budget towards it. Instead they'll just completely replace it X years later for Y times more than the maintenance would have cost.
They tried, on a smaller scale, with dropping the Linux NPAPI plugin.
Unfortunately, they were unable to manage even that, and ended up resuming updates to it after several years, since so many security vulns kept popping up in it.
The major browsers are trying to leverage their forced-upgrade strategems to increasingly isolate Flash content (click-to-play, locking it in increasingly-harsh sandboxes and throwing away the keys...), because the problem was never convincing _Adobe_ to kill Flash.
It was, is, and will remain convincing users who have run sites with it forever to migrate off.
There are enterprise device web interfaces written in Java applets or Flash (or, on rare occasion, both), that are past EOL but still in use in a great number of locations. There are many "applications" that are just embedded web browsers doing the above dance.
Flash has been around 20 years - it'll probably take at least another 10 after Adobe absolutely stops any updates (which, I think, would take either a transparent migration tool or a bankruptcy), if not more, before seeing Flash becomes an abnormality.
Yup. I have HP Microserver at my home and it has remote KVM feature powered by Java webstart application. I expect this server to last for many years, so I need access to Java. I'm Java developer myself, so I figured out how to start it without installing Java plugin, but I don't think that there are many people who would do that. So probably Flash or Java will exist for many years, may be behind some obscure flags.
AFAICS every major vendor's KVM plugin is either the same stack with different brandings or just multiple implementations of the same VNC+[secret sauce]+[custom auth] concept in Java - Dell, HP, and Supermicro all do this, at a minimum, as well as probably anyone (else) with an ASTxxxx-based BMC.
I'm hoping OpenBMC wins the day here, at least, so that's one less place with Java or Flash.
Rainbow Dash is in flash ;) (or to put it another way: the wildly popular gen 4 of My Little Pony, with a substantial adult audience, began as a TV series authored in Flash for its animation, and AFAIK still authors most shots in it)
Vectors are scalable, you see… if you're good with an art style using puppeted animation in vector graphics (which can be much quicker and still look good and move well!) then Flash is right there, able to be used, flexible to any screen size you like. Lines made with Bezier curves are appealing to the eye, and the rendering is super clean (when it's not glitching out, see the MLP cyclops horse glitch)
I've spent hours poking around on the web seeing if there were ways to render Flash clips to, say, SVG: simply because I know Natron exists, is a WAY more powerful compositor but much like Shake (and presumably Nuke, out of my pay grade) can composite numbered image frames, including SVG. That means you can zoom and scale SVG-based clips infinitely without losing clarity.
(I'm aware of Fusion and just learned of 'free Nuke' doing a lastminute google check on this stuff, but I favor Natron because it's not restricted to noncommercial/hobbyist purposes and as it's a opensource option, it should be possible to keep a working version of it indefinitely so long as there's been at least one working version on your system. The big commercial software projects, I always worry they will forced upgrade you out of what you use)
…and the point is, you can create animations in Flash. It's a pretty damn mature technology, familiar to many, has a whole infrastructure around efficient use of it, and to replicate that in something like Natron from scratch ain't gonna happen.
Even people talking about reimplementing Flash in open form seem to be talking mostly about playback or web, not authoring.
Flash already exists and mostly works. It even exists in non-subscription form and runs on older machines.
We're here also maintaining some big platforms using Adobe Flash.
Even I mostly agree on the need to reduce unnecessary Flash usage on the public web, there are some features Flash provides that can not still be replaced by HTML5, like audio recording on browser which is not available on some still widely used web browsers.
If there is a need of providing support for those features on relatively old browsers in corporate environments then the best (the only?) choice is Flash Player.
I can also argue on the far less number of development and testing hours needed compared with HTML5 equivalent, where you know that content will render perfectly on all browsers that include Flash Player.
IMO, before killing player itself we will should focus in killing all those old browsers versions to provide developers a real alternative for these features.
May be it is just me, but I actually like Flash for a lot of reasons. I hate it as a web tech, but generally it is very good for games and animations.
Rather then killing it, I hope they just open source it.
It is in some ways better then what we have in HTML5, but being closed source and not able to optimize enough for Mobile usage causes its death.
I haven't worked with flash in at least five years, though I had worked on quite a few decent sized projects with it before then. I became quite competent with Actionscript 3 and absolutely enjoyed working with it. I'd always hoped Javascript would lean in that general direction, as was generally assumed early on (not that I dislike ES6).
I especially liked the potential for writing things dynamically and then refactoring toward strictness over time while moving a project beyond the prototype stage.
There sorta is. Checkout Haxe [0] sometime. Technically it's a superset of AS3, but you can take most AS3 and use it as Haxe code. Then there are numerous transpilers for converting Haxe => whatever (one of which being JavaScript).
There are still parts of the internet developed in the 2000's which use Flash. Even the magic of HTML5 will not allow those sites to easily make the transition for free.
As long as there is Flash in this world, Flash will need to be supported to fix the inevitable security vulnerabilities.
Encrypted video playback is/was a big reason as well. The browser wars for HTML5 EME for playback of encrypted content is still crazy, but only very recently been slightly manageable.
Safari - only FairPlay encryption through HLS, but only modern versions of Safari; Chrome - Widevine Dash, IE - Playready Dash (and smooth), but only recent versions, Firefox only after version 52 do they finally support Widevine Dash, otherwise no EME prior to that.
> Firefox only after version 52 do they finally support Widevine Dash, otherwise no EME prior to that.
What's your source for this?
Firefox shipped EME support for Adobe Primetime on Windows in Firefox 38. Firefox shipped EME support for Widevine on Windows and Mac in 47 and on Linux in 49.
There are a surprising amount of applications built on Flash and still running. I'd rather they open the source or donate the source to the community than simply abandon it. The web ecosystem potentially could have ended up drastically different if that was done back when Flash was ubiquitous. Who knows, canvas and svg might not have had as much enthusiasm.
This is the sad issue with Web based tech. On desktop, you can run most software from Windows 95 on natively on your modern Windows 10 computer.
Think about it.
That means that I wrote a small utility in 1996, you bought it in 1997, I went out of business in 1998, and you can run it in 2017 (that's 20 years later).
How much of Websites/games/utilities from the 90s/2000(!)s are dead because the #1 open language was found to have too many security holes (or more precisely, couldn't update properly) and no ones around to re-write them in HTML5.
----
How much of current HTML5 javascript will be "turned off" in a few years?
What if browsers (read - Google) decide that "eval is evil" and ban it in JS?
I don't see this as desktop vs web. Running a Flash-based site from 1995 still works in IE, Chrome or Firefox, while running a Mac desktop application from 1995 doesn't.
Because DRM, HLS, HW acceleration, H.264+MP3 (which is funny cause HTML5 can play H.264 and MP3 separately, but not them together in any container), that's what I can think of.
There's still a killer feature which is only just now (autumn 2016) being slowly supported by HTML5, and this only for some browsers: Client side video recording and streaming to server. Another one is peer-to-peer. WebRTC is more complicated than RTMFP and still not implemented for all browsers.
We have started to develop a replacement for our Flash app and are fighting a lot with specified but not yet implemented features. Especially configuring the webcam (resolution, frame rate) is still in a very sad state of implementation.
Ah, I hadn't heard about that API. But audio/video encoding and streaming was a basic use case from launch. I guess the new API lets you handle the encoded data yourself, and not necessarily send it out over WebRTC.
MediaRecorder is essential for video encoding. A friend of me had to implement video encoding in JavaScript when he tried out uploading videos to the server. He did something like this: write a video frame to a canvas element, then encode it in JPG and upload that JPG to the server and then make a video out of the JPG frames. Absolutely ludicrous.
Removal of the plugin may be increasingly common among technical users, but I don't think many average users are removing it. The thing that is really killing it is deprecation by browsers (click-to-play initially).
I almost liked it better when we needed Flash for video and audio, because now with HTML5, I continuously run into website abusing the feature for advertising. (Whoever decided to use autoplay video and audio for web advertising should be killed.)
On Firefox, you can flip media.autoplay.enabled = false in about:config, though this may confuse some JavaScript media players that think the video is playing when it's not.
I spent some time trying to figure out what happened to Shumway, a while ago. As far as I can make out, Mozilla figured out that with the amount of resources they could afford to put into Shumway, by the time it reached the point where it could generally play most Flash content, nobody would be making Flash content anymore so it wouldn't be a notable feature for Firefox.
There's definitely still value in something like Shumway for viewing legacy, historical content, just like there's legacy in browsers being able to view old Geocities pages. But it's never going to be a feature of significant commercial value.
It's possible archive.org might be interested in acting as patron for that/a similar project. Seems to me it's more relevant to their mission than most other groups'.
It would be interesting to see the Flex and Flash libraries ported to run directly in the browser. Syntactically, ActionScript is almost identical to TypeScript, so transpiling should be practical.
There is a good amount of existing Flash content on the web. Adobe has de-emphasized the production of new Flash content several years ago, and pivoted its products (and customers) towards HTML5.
Killing Flash outright would do next to no good to Adobe. Google (and on their heels, Mozilla) are well on their way in making accessing existing Flash content more and more difficult [1], which probably appeals to people who think Flash needs to be banished, but most likely frustrates people who want continued to access to that content.
But that being said, in all likelihood, Adobe will eventually stop issuing even security fixes to Flash Player, especially once Chrome and other browsers have put that content behind click-to-plays, warnings, etc., or if Chrome and Microsoft stop their bundling of updates.
In terms of installed user base that isn't going anywhere, Computer Based Training (CBT) embraced Flash deployment and as a result has tons of conversion resistant legacy content.
I'm curious how the ongoing support of Flash applications on the web compares to the support of Java applets on the web. I don't know much about the latter, but if anyone here is engaged in supporting a legacy Java applet I'd be genuinely curious to hear about it.
Windows API is open (you can get documentation for it) but it's known that "in the real world" the API doesn't follow documentation, which causes problems for Wine.
In other words, for many important websites, Flash was the JavaScript of today (far reaching, with critical appearances in both the back and front-end).
Business Reasons: Adobe has had a rough decade. The Macromedia acquisition was a red pill (IMHO) for many at the company. The company has been dramatically slow in adapting to a new Web. Several major projects have failed or under-performed. All and all, Adobe has bigger fish to fry than to procure their developer base of a free/low-cost migration solution.
Other Reasons: 1)The nature of proprietary software - a lot has been written about this so feel free to look it up on the Web but basically its hard to just discontinue software without facing several non-trivial legal challenges. 2) The Steve Jobs Effect - or the curse of having a major figure accelerate the demise of a product that should have evolved into an open standard. 3) The Adobe Coldfusion Effect - Macromedia/Adobe has a product called ColdFusion Server that used Flash technology A LOT to differentiate itself, however the transition strategy adopted by Adobe didn't immediately discontinue Flash support for ColdFusion generated reports (for example) and such a direction made developers less likely to invest in a quicker migration to HTML5.
I feel your pain and, at this point, would also like to see Adobe pull the plug once and for all. But we live in a complicated world, for better or worse.