I don't have strong feelings on browser plugins vs no browser plugins, but I can say that I can now watch streaming video from the major services and play browser games on Linux now, and that wasn't possible a couple of years (or maybe a little more) ago. I welcome the end of Silverlight, Flash, Java applets, because it means I can use any modern browser to do anything I want on any platform I want (kinda, but it keeps getting more true over time).

Plugins aren't inherently Linux-incompatible it's just that for most of them Linux support was an afterthought or actively avoided for competitive reasons (in the case of Silverlight, I would guess). I don't miss fighting to make Flash work in a 64-bit browser, or having to set my user agent to claim I'm on Windows, to make something work (and have it break periodically for whatever reason).

The issue with a plugin architecture is that it makes it difficult to compete. There essentially will come a pool of plugins which are expected to be installed on every user's machine, & without standardization or open source implementations you'll end up with 1 plugin being used on any base browser as opposed to different versions on each browser

In theory we could create a basic browser with various HTML/JS/CSS spec features created as a plugin

Speaking as a clueless user; closed source plugins, sooner or later, go away. Which is pretty painful. In the interim, the big grief-causers are usually closed source plugins that crash the host.

Open source plugins cause a lot less grief. Typically they don't have a feature I want. Often for legal reasons and not technical, or because a proprietary vendor is fighting back (eg; video patents the first case, Skype protocol the second).

The linux kernel is an example how an open-source-only plugin system works technical wonders. A very interesting case study was graphics drivers circa 2005. The closed source drivers (essentially plugins) tethered the linux community to the technically obsolete X server; and would have crippled the kernel in a similar way if the kernel devs had accepted closed source plugins.

Apple did wonders driving open standards on the web with the explicit acknowledgement that popular closed source plugins were too dangerous for their platform to implement [1].

The issue here is the one Stallman has been harping on since the dawn of time - closed source is unmaintainable in an extremely profound way.

[1] https://www.apple.com/hotnews/thoughts-on-flash/

You could also argue in the opposite direction: Without a plugin architecture, you are at the mercy of the browser developers to implement a certain functionality.

If you need some native feature, browser vendors can force you to use a native app and thus go through their app store (think Safari on iOS). There is a large category of apps that you cannot make in HTML, for example anything truly P2P (not WebRTC, but based on real sockets). You can't make an IMAP client. You can't make a friend-to-friend file sharing tool, without a central server, that uses your Facebook and Google contacts to find peers (I've tried). You can't make the browser window partially-transparent or use native looking widgets. You can't burn a DVD. And if someone invents free-floating holograms, you can't add them to your page.

Granted, these examples are silly. The web is now a very capable platform. But vendors have always been steering what you can and cannot do based on business and other interests. It would be great to be able to break out of that, by having a kind of "C foreign function" interface for the web.

In addition to this. Many of the new Web features came from people going "Flash does it". Plugins allow capability that can be used by people now. Those instances can then be shown to people who say one of my most hated phrases, "What's the use case?"

Ugh, that phrase is used to kill anything vaguely creative fun or artistic.

It is probably why we all have flat windows 3 inspired UIs now.

Plugin has advantages though, consider I don't need the built in pdf in browser, if the pdf reader was a third party plugin I could decide to not install or remove it, less code that I do not use is better. Also we could have a few prf reader plugins choices instead of having the one Google/Mozilla chose. Anyway the people wanting Flash to be preserved do not intend to built Flash apps but conserve the existing ones, most of them could be run in the standalone player(I think a few try to hook into the browser to get the url or similar ,so those would fail as standalone)

> An open source flash player will most likely be used standalone, and not in a browser.

It'll most likely be modified to run in browsers, too, e.g., via compilation to WebAssembly and suitable web-platform replacements for the low-level IO, etc., implementations.

There is Mozilla Shumway which is an open source Flash runtime in JS.

The jit won't port to current wasm, so it would be slow.

There are some noteworthy security problems with Flash in principle.

If website.com embeds a flash file from flash.example, it will run in the context of flash.example, the embedee. If website.com embeds JavaScript from js.example, the code will run in the context of website.com, the embedder.

This will and has caused problems with interoperability in so far, as I'd call it an ugly and dangerous wart.

See web security literature like "The Tangled Web" (or https://code.google.com/archive/p/browsersec/wikis/Part2.wik...) for more.

The only way to solve that implementation problem is to create competition, just like you have with HTML.

So the W3C would have to define "standard Flash specification" and then everyone would have to implement their own "Flash player". But ain't nobody got time for that.

If the "Flash player" had been a specification rather than a piece of standalone software from day one, I believe the overall security of the Flash players would have been way better.