Stories
Slash Boxes
Comments

SoylentNews is people

Flash Used on 5% of All Websites, Down From 28.5% Seven Years Ago

posted by chromas on Saturday April 21 2018, @02:34AM   Printer-friendly
from the made-with-macromedia dept.

MrPlow writes:

Submitted via IRC for TheMightyBuzzard

Only 4.9 percent of today's websites utilize Flash code, a number that has plummeted from a 28.5 percent market share recorded at the start of 2011.

The number, courtesy of web technology survey site W3Techs, confirms Flash's decline, and a reason why Adobe has decided to retire the technology at the end of 2020.

[...] On the client side, browser makers are expected to remove Flash support from their products altogether by the end of 2020 —Flash's end-of-life date.

2020 can't come soon enough.

Source: https://www.bleepingcomputer.com/news/software/flash-used-on-5-percent-of-all-websites-down-from-285-percent-seven-years-ago/

Original Submission

 
This discussion has been archived. No new comments can be posted.
Flash Used on 5% of All Websites, Down From 28.5% Seven Years Ago | Log In/Create an Account | Top | 58 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by Justin Case on Sunday April 22 2018, @08:54PM (3 children)

    by Justin Case (4239) on Sunday April 22 2018, @08:54PM (#670477) Journal

    What's better: a script delivered over HTTP or a native application delivered over HTTP?
    What's better: a script that you can't run because you have disabled script in the browser or a native application that you can't run because it is compiled for a different operating system?

    What's better: being shot in the head with a rifle or a pistol?
    I'll take neither for $1000, Alex.

    Try to remember that HTML is a document specification language with optional formatting suggestions that users are free to ignore if, for example, they are blind.

    Trying to shovel shit into a soda straw is probably a fundamentally broken plan.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 2) by Pino P on Monday April 23 2018, @12:35AM (2 children)

    by Pino P (4721) on Monday April 23 2018, @12:35AM (#670546) Journal

    For the purpose of argument, let us assume that HTML is a document specification language. Thus if a work is a computer program, not just a document, the program ought not to be delivered in a form contained by HTML. Given the preceding, in what not-HTML form should the program instead be delivered so that less-technical users of Windows, macOS, X11/Linux, iOS, Android, and Chrome OS can execute it?

    • (Score: 2) by Justin Case on Monday April 23 2018, @02:18AM (1 child)

      by Justin Case (4239) on Monday April 23 2018, @02:18AM (#670576) Journal

      First of all, accepting executable code from strangers is dangerous. It should be done rarely, and it should not be easy.

      Now, then, the appropriate place to get executable code, on the rare occasions when that is necessary, is from repositories you trust. Various linux distros have things like "apt-get" or "yum update". These cryptographically verify the publisher using previously accepted identities. MacOS has something similar. Windows is a lost cause.

      • (Score: 2) by Pino P on Tuesday April 24 2018, @12:41AM

        by Pino P (4721) on Tuesday April 24 2018, @12:41AM (#670957) Journal

        Now, then, the appropriate place to get executable code, on the rare occasions when that is necessary

        I disagree with your claim that desire to use applications not shipped with an operating system is (with emphasis) rare. Say someone wants to use a whiteboard application to draw-chat with other people over the Internet. What is the standard protocol for an Internet whiteboard that allows users of different native whiteboard clients to send strokes to one another for draw-chat, much as people use different native IRC clients to send lines of text to one another for text-chat?

        [Package managers on GNU/Linux] cryptographically verify the publisher using previously accepted identities.

        One might consider relying on the publisher of the distribution to also publish the application. But in general, distributions' policies allow this only for applications distributed as free software, and for some fields of use, a business model based on free software licensing has not yet been demonstrated. Such fields of use include at least nontrivial video games, playback of rented movies, and tax return preparation [pineight.com]. In such a situation, what should the publisher of a computer program do to make his identity worthy of acceptance?

        MacOS has something similar.

        Which requires the publisher to have the time and money to port the application to macOS. Even if the application is distributed as free software in source code form, source code relying on Win32 or X11 headers for compilation and Win32 or X11 libraries for linking will not build and run in a stock installation of macOS. Would you find it fair to make a web application available without charge but put the corresponding native application behind a paywall to cover the cost of porting it to macOS and distributing it through Mac App Store?

        Windows is a lost cause.

        What steps should a publisher of an application take to work around this "lost cause"?