Certainly no plugin has ever turned into a full-fledged browser feature.

I'm not saying that Plugins are great, or even desired, but sometimes they're necessary to fill a gap.

I know HTML5 has the video tag, but it doesn't support streaming video, only video files for progressive download. So the alternative is?

“There is no job that plugins are the right tool for.”

- Firebug or Developer Tools for debugging javascript on a live site.

- Delicious's browser plugins do to keep track of bookmarks and sync them between computers.

@MattL

Those are extensions, not plugins. Extensions modify the browser in some way (adding Firebug's console, syncing bookmarks with Delicious). Plugins load non-standard content in the web page itself (a flash "movie", a java applet).

I second Brad's comment. Plug-ins are generally difficult for accessibility tools in general.

Watching DRM video that content providers wouldn't allow otherwise...

Doing almost anything on old browsers.

Viewing HTML5 content in IE7- (Chrome frame)

Webcams

P2P connections

There are lots of things...

@Rick (#4)

You are incorrect. While some plug-ins serve to load external content into the page, not all of them do so.

A plug-in is just a program that extends the browser functionality. Traditionally, this was done using a programming interface (API) designed originally by Netscape (remember them?), but even this is really not a hard-rule. Each browser may have their own API and access controls for plug-ins, and indeed some do.

This programming interface gives the plug-in access to parts of the content of the page and to some of the capabilities of the browser.

Firefox extensions serve the same purpose as plug-ins did before, but offer a different interface with a different security model. They were intended originally to *extend* the chrome of the browser (the functionality and presentation of the user interface), but now can do much more.

From your list and your comment, it seems that what you object to are *specifically* plug-ins such as Flash, that provide a non-standard container with content that does not integrate well with the rest of the browser. That's the programmer's fault.

Not being able to print, or access cookies, or drag and drop from a plug-in is not necessarily the fault of "plug-ins," but of the crappy plug-in itself. The browser may offer access to those capabilities, but the programmer needs to write his own code on how to handle it within his plug-in.

-dZ.

Why does an end user care about most of that list?

Browser bookmarking works perfectly well with Flash applications using the same technique that JavaScript libraries like jQuery use today in browsers that do not natively support the HTML5 history pushstate API. Just as with JavaScript-based applications, the app developer has to do a bit of work, but it's perfectly functional.

Most of what you wrote is true of Flash in general, but it doesn't have to be that way. Adobe could have given the plugin better integration with the host environment, better support for accessibility, better support for OS conventions like Cmd-click or drag-and-drop. The fact that Adobe did not does not mean that all plugins for the rest of all time will always be as bad.

There is no call for sweeping generalizations about the value of a given technology. Saying that plugins 'have no place' is ignorant and complacent, and stifles technological innovation.

Writing "Saying that plugins ‘have their place’ is ignorant and complacent." is ignorant and complacent, dramatic but factually incorrect. However, it did get my attention in the same way those irrelevant tests of the emergency broadcast system do when I'm watching something interesting on TV. Good job.

How about consistency? Your simple article renders differently in the two browsers I used to test it (IE 9 and Chrome 15).

What about just playing a game? When you play a game in your OS, do you have to print, save passwords, or do anything on that list? So why would this same behavior not be acceptable in a Flash game?

But I can agree, for the mostpart with the limitations of plugins, however, there are exceptions to every rule.

Wow! The post shows a complete disregard for WHY browsers plugins were made in the first place. It's wrong on so many levels it's silly. Before html5 canvas you COULD NOT have anything like a desktop experience delivered over http on your computer. Plugins allowed access to a lot of the great stuff already in your machine that was hidden by your browser and HTML.

Plugins are a bridge between the basic document model of HTML and the full state full do whatever model of the desktop. You don't have a view source button on a desktop app so why would you have one on what is basically a desktop app running in your browser?

HTML pages are dead by definition. Desktop apps are always running and so are stateful. So why would you need to bookmark a page in a stateful desktop app?

I'm tired of these new web people talking rubbish about how amazing HTML is for apps. HTML is and always will be a fudge if your using it for applications. It's not designed for applications , end of story. It's a document displaying framework (for which it excels at) but for apps its a hack. Whatever amazing things are produced in HTML/js will never get away from the fact it's a hack.

@kroc
What I'm getting at is that a lot of the things that you listed as functions that plugins break are options that are useful for displaying documents. The very essence of what html is, a document displaying model.

Plugins had traditionally offered desktop style functionality which is why a lot of these options are irrelevant for plugins. In my mind there are "websites" and "web apps". Websites are like dynamic newspapers or magazines. I think HTML is fine for that and there is no need to use any plugins going forward. We have everything we need to animate, show video, sound etc.. With html5 now.

Apps on the other hand have different issues entirely. Users want desktop style apps delivered in a easy way (I.e.the browser). But the pain in getting that to work well in HTML/js is massive compared to doing the equivalent in silverlight or flash. The user is NOT getting the best web app they could get in HTML 5 compared to flex or silverlight.

What html 5 will do for the industry is deliver apps that will conform to the lowest common denominator. As technology develops you will find that the native apps on iOS, win8 etc.. Will utterly destroy the capabilities of anything on html5. Html5 apps will be harder to maintain and develop because the architecture involved is so "anti" modern software development it's not true. Apple and MS will be the winners and in 5 years time we will looking for ways to bring more power and parity to the DOM again versus desktop apps.

Which is exactly the scenario Macromedia solved when they made flash and director in the first place! It's amazing how we never learn from history...

All of those things are also true of native applications. Would you say that native applications running on your operating system do not have any place?