Movement to get rid of Adobe Flash started 3 years ago. Flash is still alive
occupyflash.org
occupyflash.org
It is very possible to get by without flash. In the rare cases where flash is essential to view a video, for example the SpaceX livestream a short while ago, I stick the url into `youtube-dl` and I have yet to experience a situation where it is not supported. In the case of the livestream, You can do:
$ youtube-dl -o- $URL | mplayer -
As a side note, I found this humorous:
> It's a fossil, left over from the era of closed standards and unilateral corporate control of web technology.
Google is your ISP (Fiber), Google makes your hardware (Pixel & Nexus), Google maintains your OS (ChromeOS & Android), Google made your browser (Chrome), Google strong arms web standards (http2), Google Decides what you see (Search), and places ads on it.
To confine `unilateral corporate control of web technology` to the past is laughable.
I also like the "whitey" CLI interface to youtube, which uses youtube-dl to get the video URL and can either download it, or feed it straight into mplayer.
For iplayer, there's also get-iplayer ( http://www.infradead.org/get_iplayer/html/get_iplayer.html ), which is pretty fantastic; except that sometimes they enable some new feature by default, which breaks the old behaviour (eg. automatically transcoding everything to the same format, which is IMHO a waste of time and quality).
Unfortunately the BBC have recently removed the programme feed that get-iplayer uses, so it's no longer possible to list available programmes as text (useful, eg., for grep). Instead you have to actually visit the iPlayer Web site and navigate around to find each programme, which is a pain.
If the worst comes to the worst, it's usually possible to find the URL of a Flash video using a Web inspector tool like Firebug, and perhaps a bit of URL-unescaping. Protip: lots of Web sites don't care about user agents other than (the most popular) Web browsers, so set the user agent of your download tool (wget, cURL, etc.) to match some version of Firefox, to avoid inconsistent behaviour.
Add to that Google strong-arming web-DRM into the standard to have exclusive access to Netflix on their closed-down Chromebooks.
Yeah, but they swore they "wouldn't be evil". /s
Websites use it for slideshows, games, small interactive animations (for example to demonstrate concepts such as waves and Fourier transforms), IRC, chat boxes, and more.
Some of that can (today) be replaced with HTML. It couldn't not that long ago, and not everything can be replaced with HTML even today.
And so all those flash bits are here to stay, possibly forever. That's why there were a lot of people - me included - that were arguing against things like flash, silverlight, binary components and other web-page plug ins because they will sooner or later end up being unsupported. Besides causing gigantic accessibility issues for the handicapped.
So, now we have a mess, and that mess is here to stay. That won't stop large company 'x' from doing this all over again in a few years just because they can but at least there may be a few more voices trying to stop the plug-in madness before it gets out of control.
If it isn't in the html spec: don't use it. Welcome to a web full of non-rendering holes that may or may not be functionality and an archive full of websites that nobody will be able to see without powering up a VM circa 2004.
I'm not aware of any JS-powered flash implementation or how that would solve anything since presumably that would come with all of the drawbacks that the non-JS powered flash implementations of today have (and that we are so keen on getting rid of).
I think it's for mobile first where Flash is no longer available.
Nevertheless, it's still a smaller problem than, for example, broken links.
Firstly, the number of sites relying completely on Flash is relatively small, eg. compared to those which rely on hyperlinks (indexes or reading lists).
Second, there is less urgency to fix Flash sites compared to mitigating link rot: as long as the SWF content is archived, it can be converted/re-implemented at a later date. On the other hand, links are failing all the time, which requires immediate, persistent action (crawling).
Thirdly, there is a subjective argument about whether Flash sites are part of the Web or not, and hence whether this is much of a problem. At some point, an archive must draw a line and say "this is not Web content"; for example, archiving videos, or FTP sites, or Linux ISOs, or the content referred to by torrents or magnet links, or Windows EXEs, etc. It's an arguable choice to ignore Flash content completely. It's also an arguable choice to archive the Flash content but not care whether it runs. Of course it's also legitimate to want Flash to work seamlessly in the browser, but that's not the only position.
> I'm not aware of any JS-powered flash implementation
There are a few. A quick Google search reveals https://github.com/tobytailor/gordon/wiki and http://mozilla.github.io/shumway/ . At a stretch, Free Software, non-JS players like https://www.gnu.org/software/gnash/ , http://lightspark.github.io/ and http://swfdec.freedesktop.org/wiki/ could be ported to emscripten.
> or how that would solve anything since presumably that would come with all of the drawbacks that the non-JS powered flash implementations of today have (and that we are so keen on getting rid of).
Of course they have all the same problems (and more, since they're not fully compatible); but that's irrelevant. Backwards compatibility only requires that the stuff we used to do is still possible. If we send an un-screen-readable, un-keyboard-navigable mess of a Flash site to a perfectly compatible JS-based Flash implementation, we should hope to get an un-screen-readable, un-keyboard-navigable mess as well. As an analogy, it's a good idea to write an emulator for the Sinclair Spectrum, so that Spectrum games remain playable on new hardware. This does not mean that a) emulating a Spectrum game must produce modern-looking 3D, immersive, high-def, 24-bit colour graphics with surround sound; or b) that the existence of a Spectrum emulator should make the Spectrum a valid target platform for new commercial game development.
It's a shame that website doesn't have graphs from the time that Android and iOS announced they wouldn't support flash - it would be interesting to see if there was a noticeable bump.
I will say that Flash isn't usually required for most of these uses; just like Javascript it should degrade gracefully to a fallback (eg. a POST form for uploads). Except for web sockets, if they're powering something fundamental (which is the same for JS).
The only time I've added a Flash widget to a page without a fallback has been "copy to clipboard" buttons, which didn't have a decent alternative. In those cases the button just doesn't show at all.
Some games are transitioning to unity player - you can't really call that much better though.
However I believe the games themselves are cross platform so there is hope.
There is an easy to install wine based port of the web player for Linux.
Every other kind of snazzy desktop-like animated experience can be created in js, and if you dread using js you can write them in another language and compile to js. The js runtimes are fast enough these days.
But: video. Especially live broadcast video. What is the best attempt a replacing flash/SL there? The rights for sports events are worth billions, and a single game can sell for $20-50, so an open unencrypted video service just will.not.happen. The rights holders would rather retreat to cable. Whatever the solution is will have to have the same features in terms of DRM and other protection that flash has.
EDIT: just realized the solution is quite simple: just get off the web and let those who want to watch e.g NHL Game Center use a special application, not a web browser.
I was surprised how many sites and embedded video now offers HTML5, obviously Youtube and Vimeo have been working for years, but just video on news sites that use their own video solution work.
The biggest surprise was visiting twitch.tv and seeing the live video stream work in HTML5 (only in Safari, not Chrome).
Sadly, there's still no good way to stream live video across multiple browsers without Flash. Eventually, this will be possible via the Media Source Extensions API, but even then, you'll still probably have the issue of different browsers supporting different containers and codecs - which will lead to people doing crazy things like converting MPEG2-TS to MP4 in JavaScript web workers.
I had to keep a pretty close eye on all of this stuff when I worked at Aereo, and it always bummed me out to think about the fact that it's still not really possible to stream live video in a web browser without plugins.
Killing Flash is like killing the Concorde Airplane, it just means it is too advanced for its time.
Everyone who knows anything about Flash and HTML5 knows that in terms of CPU resources HTML5 is still far far far FAR behind on what the Flash plugin can do... yes, even now.
HTML5: http://themaninblue.com/experiment/AnimationBenchmark/html/
Flash: http://themaninblue.com/experiment/AnimationBenchmark/flash/
what html5 can do is what flash can do long time ago. the motivation for replacing flash must not be technical but perhaps political.
why didn't adobe release flash as opensource to push it as a standard.
Funny , remove the space and it looks a lot more different !
Why would you need Flash to use a VPN? Is it some weird web-login? How do you write a VPN client in Flash? Who thought that requiring Flash for a VPN would be a good idea?
Your comment raises so many questions.
I think the problem is rather that flash, java and javascript are all enabled by default, allowing any site and all the associated advertisement websites to execute code without the user consenting or being aware. This is a major security and privacy problem.
The model should rather be per-website opt-in of javascript if required (and most websites don't need it). And even in that scenario enforcing a same source policy, ie only javascript hosted on the domain visited would be enabled, not third party javascript.
To me the current model is like windows XP's autorun. It is just designed to be a perpetual source of security and privacy breaches until someone finally takes the decision to kill it.
If you want to disable javascript yourself, fine, but don't degrade the experience of the web for everyone.
If a user ends up on a webmail or an online gaming website, I don't think he will be surprised if he is asked whether he would like to allow this website (not third parties) to execute javascript (and to keep that setting). If that same user goes on any blog, forum, news or ecommerce website, there is really no good reason to execute client side code.
Auto completion in a text box (or server validation by input without a full POST) should have been embedded in html a long time ago. And it took 20 years before they finally agreed to add a datepicker tag, not exactly a new problem. Because of the glacial pace of evolution of html, we became used to javascript tricks to make up for what html doesn't do. And flash is mostly used for the same reason.
That doesn't mean that flash and javascript don't have any use.
The more complicated HTML/CSS gets the less efficient it will be and the harder it will be to get all the browsers to maintain compatibility with each other.
In a way the current scenario where a lighter, shallower HTML and CSS are enhanced by custom code in the form of JS is better for the ecosystem because it allows creative freedom in development without overloading the core engine with cruft.
If you choose to do so you can create a bloated abomination of an HTML page powered by tens of thousands of lines of JS, but since the core engine itself is very light it is also possible to make a clean and simple page that is extremely light and which uses no JS at all.
On the other hand baking lots of functionality into the core engine would force everyone to experience the bloat and cruft, even if you were trying to make a clean and simple website.
Say you add to the input tag a validation attribute with an URL and the browser posts the content of the input box in the background for validation, and give feedback to the user in a standard but customizable way.
For auto-completion, same thing, just adding one attribute with a url and a standard feedback.
Also an attribute to allocate a change to a css property when clicking on an element, to enable css pop ups.
There are probably a dozen more attributes like that and that would pretty much make javascript redundant on 99% of the website without making the HTML syntax much heavier (and overall your page would be lighter, because you don't have to write the plumbing every time). And you save having to interpret javascript so it has to be more efficient in term of performance too.
One counter example is something like bootstrap, where javascript is used to adapt the formatting to the form factor. But this is a good example of a horrible use of javascript, having to use javascript for presentation. It is just a case of html not being fit for purpose (since its purpose has evolved).
The more complicated HTML/CSS gets the less efficient it will be and the harder it will be to get all the browsers to maintain compatibility with each other.
In a way the current scenario where a lighter, shallower HTML and CSS are enhanced by custom code in the form of JS is better for the ecosystem because it allows creative freedom in development without overloading the core engine with cruft.
If you choose to do so you can create a bloated abomination of an HTML page powered by tens of thousands of lines of JS, but since the core engine itself is very light it is also possible to make a clean and simple page that is extremely light and which uses no JS at all.
On the other hand baking lots of functionality into the core engine would force everyone to experience the bloat and cruft, even if you were trying to make a clean and simple website.
The more complicated HTML/CSS gets the less efficient it will be and the harder it will be to get all the browsers to maintain compatibility with each other.
In a way the current scenario where a lighter, shallower HTML and CSS are enhanced by custom code in the form of JS is better for the ecosystem because it allows creative freedom in development without overloading the core engine with cruft.
If you choose to do so you can create a bloated abomination of an HTML page powered by tens of thousands of lines of JS, but since the core engine itself is very light it is also possible to make a clean and simple page that is extremely light and which uses no JS at all.
On the other hand baking lots of functionality into the core engine would force everyone to experience the bloat and cruft, even if you were trying to make a clean and simple website.
The more complicated HTML/CSS gets the less efficient it will be and the harder it will be to get all the browsers to maintain compatibility with each other.
In a way the current scenario where a lighter, shallower HTML and CSS are enhanced by custom code in the form of JS is better for the ecosystem because it allows creative freedom in development without overloading the core engine with cruft.
If you choose to do so you can create a bloated abomination of an HTML page powered by tens of thousands of lines of JS, but since the core engine itself is very light it is also possible to make a clean and simple page that is extremely light and which uses no JS at all.
On the other hand baking lots of functionality into the core engine would force everyone to experience the bloat and cruft, even if you were trying to make a clean and simple website.
The more complicated HTML/CSS gets the less efficient it will be and the harder it will be to get all the browsers to maintain compatibility with each other.
In a way the current scenario where a lighter, shallower HTML and CSS are enhanced by custom code in the form of JS is better for the ecosystem because it allows creative freedom in development without overloading the core engine with cruft.
If you choose to do so you can create a bloated abomination of an HTML page powered by tens of thousands of lines of JS, but since the core engine itself is very light it is also possible to make a clean and simple page that is extremely light and which uses no JS at all.
On the other hand baking lots of functionality into the core engine would force everyone to experience the bloat and cruft, even if you were trying to make a clean and simple website.
The more complicated HTML/CSS gets the less efficient it will be and the harder it will be to get all the browsers to maintain compatibility with each other.
In a way the current scenario where a lighter, shallower HTML and CSS are enhanced by custom code in the form of JS is better for the ecosystem because it allows creative freedom in development without overloading the core engine with cruft.
If you choose to do so you can create a bloated abomination of an HTML page powered by tens of thousands of lines of JS, but since the core engine itself is very light it is also possible to make a clean and simple page that is extremely light and which uses no JS at all.
On the other hand baking lots of functionality into the core engine would force everyone to experience the bloat and cruft, even if you were trying to make a clean and simple website.
Most people who are not in "enterprise" IT (that includes many web developers) only think of applets when they hear Java.
Sad, but true.