My favorite Quicktime of Ill Repute website, despite promising that it serves up naught but ill-reputed Quicktime, now tells me that I don't have Flash installed.
I find it strange Flash is still around, given that iOS and Android don't support Flash anymore and that YouTube has made a lot of video content available as HTML5. I thought that other sites would have followed suit. Is there evidence of a mass exodus from Flash?
There is way more to Flash than video. You see a lot of Flash silently running invisible in the background to enable modern web app features that aren't yet possible or easily achieved with standard HTML and JS. For example, Flash was used for web sockets before web sockets was a thing. Flash was also used to facilitate uploads.
There's also way more to Flash than websites. Using Adobe AIR, developers can take their content created in Flash, and package it into apps for iOS, Android, and also for Windows and Mac.
This is definitely true, given how often I've had my keyboard become unresponsive, only to find out that some little Flash widget had the focus and completely bypassed the browser, requiring me to use the pointer to click on some (hopefully) empty area of the page.
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.
Thanks for the link, that's more steady than I had expected.
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 never install flash on any computer I own. I don't run any closed source software outside of a VM.
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 -
To stream it yourself. This is how I watch iPlayer.
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.
youtube-dl is great. It has a bunch of functionality, like "-x" to extract audio via ffmpeg (very useful for saving space).
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.
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.
I've not had Flash installed for 2 years and the single barrier I have (streaming video) is replaced with VLC or youtube-dl. Not a problem in sight, though I originally expected there to be.
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.
I think like Flash and Java, javascript should not be removed from the browser. Some websites do have a need for flash (for streaming for example).
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.
But there is an over reliance on javascript to make up for the shortcomings of html and css. Most websites should not need javascript. If you look at your own browsing history, how many of these websites genuinely need to run client side logic?
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.
I'd rather have our current lighter, generic HTML spec that can be enhanced by running code in JS than a heavy HTML spec that tries to do everything in pure HTML/CSS just so that way we can avoid running JS by default.
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.
I'd rather have our current lighter, generic HTML spec that can be enhanced by running code in JS than a heavy HTML spec that tries to do everything in pure HTML/CSS just so that way we can avoid running JS by default.
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.
I'd rather have our current lighter, generic HTML spec that can be enhanced by running code in JS than a heavy HTML spec that tries to do everything in pure HTML/CSS just so that way we can avoid running JS by default.
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.
I'd rather have our current lighter, generic HTML spec that can be enhanced by running code in JS than a heavy HTML spec that tries to do everything in pure HTML/CSS just so that way we can avoid running JS by default.
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.
I'd rather have our current lighter, generic HTML spec that can be enhanced by running code in JS than a heavy HTML spec that tries to do everything in pure HTML/CSS just so that way we can avoid running JS by default.
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.
I'd rather have our current lighter, generic HTML spec that can be enhanced by running code in JS than a heavy HTML spec that tries to do everything in pure HTML/CSS just so that way we can avoid running JS by default.
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.
It's a bit of a subjective debate. But having to run all that interpreted code in the background is probably not making the engine leaner and faster. I am sure it would be much more efficient to declare your intent in html and having the native renderer handling it. And certainly a lot less verbose and subject to bugs.
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).
Flash is not going away. There is too much content using it, for example there are tons of flash games. And not just little toys, there are some very good games. Also MMO's use it extensively.
Some games are transitioning to unity player - you can't really call that much better though.
Of course it is. The thing those 'movements' don't seem to understand is that budgets are limited and that people (and companies) tend to build websites the way they used to make paintings: once. Then maybe, over time they'll update the content but flash is usually not seen as part of that content but as the infrastructure, or 'deliverable' at the time they commissioned the website. So if it worked at delivery time it is presumed to work for eternity.
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.
What you say is correct, but a bit over-the-top. Compared to broken hyperlinks, concerns over missing Flash content is pretty small. It's at least conceivable to automatically load some JS-powered Flash implementation, but if a link's target isn't available in an archive, there's no way to get it back.
Plenty of sites that were archived have their whole UI in flash, so for those sites the pages are pretty much empty pages without flash.
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).
> Plenty of sites that were archived have their whole UI in flash, so for those sites the pages are pretty much empty pages without flash.
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
> 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.
Couldn't agree more. I just want to highlight a minor example of the aforementioned "mess". Today Firefox complained that Flash plugin needed critical security update. So firefox sent me to this link: http://helpx.adobe.com/security/products/flash-player/apsb14...
which is crazy TL;DR. The fix to the security update is on the last page rendered with a font size of 13px.
Agreed. Regarding your first paragraph, you could easily substitute Java, PHP, Python, Ruby, etc and it would still be just as valid. I shudder to think just how many web applications are still out there running severely outdated versions of PHP and whose source code hasn't seen a pair of eyeballs in years. I suppose this is one reason why SQL injections are still so pervasive.
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?
I don't understand the essence of this movement, by all standards it is the mobile lobby who should be to blame.
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.
I don't think those benchmark links are really furthering your argument; in both Chrome and Safari on my Mac I get roughly twice the FPS with the HTML5 version...
This new MacBook I got last month didn't come with Flash and I decided to not install it. I also decided to switch to Safari from Chrome.
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).
I've had a similar experience, for even longer. I haven't had Flash installed on my MacBook since I got it in early 2013, and I primarily use Safari. For a while it was annoying that Netflix didn't work, and I used to run Chrome exclusively for that purpose, but since OS X 10.10 Netflix works natively in Safari, which is nice.
Safari can stream live video because it supports HLS (HTTP Live Streaming), which is Apple's own thing.
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.
The only thing I use Flash for is to allow a user to easily get something to their clipboard. (http://zeroclipboard.org/) - until that is possible, afraid I will still be using it.
The website for Occupy Flash has outbound link to http://ie6funeral.com/. Apparently, some Japanese funeral company has bought the domain. I find that quite funny.
Has there been any serious attempts at creating a flash or a SilverLight killer? Let's face it: flash and SL exist almost exclusively because of video (yes I know there are other uses but most of them like sockets etc can be done in other ways today, I'm talking about why it's still deployed for new sites).
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 earned my bread and butter for well over 15 years with just that: plug-in free video. It's always been a hack and audio is harder than video (though you can hack your way around that as well). So yes, those attempts have been made and it was pretty successful. But, ironically, mass adoption of flash killed it and now that flash is being killed there is nothing left to really replace it (except maybe to revive jpeg-push for live streams but that's also not really an option...).
This Nov. 2013 post from wowza (one of the better streaming platforms available today) is a good read: http://www.wowza.com/blog/a-note-on-html5
DRM extensions for html5-video could help, but at this point I'm actually inclined to say keep html (and the web) clean from that and just use custom applications for DRM video.
I generally don't install Flash on my machines but recently I installed it because a major financial site that my employer uses (I know, WTF!?, right?) required it. I set the plugin to ask for permission every time and, holy cow, nearly every site, particularly news sites, requested it. It's a key part of the Web's advertising infrastructure.
I have a potential client project coming up where they will need to access a user's webcam and record video and audio from it. They'll want this to work in modern desktop browsers (let's say latest Chrome, Firefox, Safari, IE10+). At this point in time I don't believe it's possible to do this with HTML5 technologies alone.
a while ago, I wanted to create a real-time broadcasting website. I explored all sorts of technologies, like webrtc, mediasource ... none seems to be suitable for what I wanted. then, I asked how twitch does it? it's 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.
66 comments
[ 3.6 ms ] story [ 138 ms ] threadI 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.
http://w3techs.com/technologies/details/cp-flash/all/all
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.
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:
To stream it yourself. This is how I watch iPlayer.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.
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.
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
[0] https://livestreamer.readthedocs.org/en/latest/
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.
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.
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).
Most people who are not in "enterprise" IT (that includes many web developers) only think of applets when they hear Java.
Sad, but true.
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.
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.
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.
[1] https://code.google.com/p/swfobject/
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/
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.
Funny , remove the space and it looks a lot more different !
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.
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.