Lady, EVOLVED 
« As browsers have become more powerful, plugins have become less useful. » is that why
@Lady Besides "browsers not supporting them" (which is sometimes an issue!), browsers now expose much of the same stuff you could do from Flash, Silverlight, or Java, with arguably better accessibility (though as ever, that's largely up to the developers). Chrome's WebUSB/Serial/Bluetooth also obviates "install our plugin to access your hardware device", even if FF devs - perhaps correctly - don't like the trade. Doesn't make plugins less useful per se, but there's less of a reason to use them.
@aschmitz i think this is reversing history though; there was an alternate timeline where browsers leaned hard into XML and relied heavily on plugins for supporting namespaces and elements which they didn’t straight out of the box. Opera/Mozilla/Apple didn’t like this future because it reduced their power as The Browser Manufacturers and consequently shut down not only plugins but also technologies like XForms in favour of doing everything in plain HTML and Javascript. Apple refused to support plugins in iOS Safari, forcing adoption of HTML5, and the refusal of browser manufacturers to invest in good extensibility mechanisms led to HTML always being the winning solution, especially after the removal of legacy browser extensions in Mozilla (which were a kind of plugin in their own right).
@aschmitz i think it’s not that “web browsers just got so good that nobody would ever want to write a plugin”; PDF rendering in browsers basically began as a kind of plugin; there has been persistent interest from users in native support for things like EPUB; people are writing entire games and applications in WebAssembly and shipping them to browsers and i’m sure that things like a PICO‐8 plugin would have interest in a different world where browsers were differently architectured. i don’t think the reason why we don’t have that world is because web browsers got too powerful, but because they made web browsers just powerful enough that they could get away with killing it
@Lady I don't know, I think it has to be both. Back in the day, sure, the browsers were full of bugs, but Flash (and to an extent, the others) were even worse, both in terms of hilariously bad security vulnerabilities and just UX / stability issues, either of which could crash the browser or make users unhappy with the browser without blaming the plugin itself. Feels like that's where Native Client (which spiritually became Web Assembly) came from, as browsers wanted sandboxing and portability.
@Lady That's not to mention the mobile landscape, where most vendors wouldn't let anyone run code for various proprietary reasons, and to the extent they did it was just mobile Flash, which was a bit of a joke in terms of parity with the real thing. JS engines were at least ported by browser manufacturers fairly quickly, but most plugins didn't get usable versions even if they were allowed to try. (Performance optimization was also important on mobile, and plugins weren't exactly known for it.)
@Lady That's not to say that plugins can't be good, or some wouldn't be good if they existed (outside of extensions and associated applications), but I don't think it was just "browsers wanted all of the control for themselves just to push everyone else out".
@aschmitz i’m not trying to argue plugins were stellar, but i am trying to make an argument about where labour was being allocated. part of the reason why plugins were buggy / inaccessible / etc was certainly that the Netscape Plugin API was, or soon became, legacy unmaintained code, and there was no interest in improving it or replacing it with something better. some responsibility lies with Adobe and other plugin authors too, definitely, but browser manufacturers also failed to work with them to improve the situation and instead decided to work among themselves to make the situation obsolete.
i like WebAssembly, think it opens a lot of doors, and am not saying we should go back. but there was a pretty long period between when iOS Safari shipped and when WebAssembly became reasonably capable of running entire applications in-browser. and we’re still working on solving some of the same accessibility issues there.
i do think things could have taken a different path if the interest wasn’t so strongly in keeping the internet in the hands of standards bodies that browser developers controlled.
