Browser Extensions Considered Harmful
Friday, January 20th 2006 | Ismael Ghalimi
Browser extensions such as plugins and toolbars can improve one’s browsing experience, but they also create a dependency on one particular browser setup that goes against the principles of Office 2.0. For this reason, I have decided to use them in very rare occasions only.
One of the most useful extensions is the Google Toolbar, especially for the Google Search interface. Nevertheless, the later comes standard with Firefox and Safari, and therefore has to be installed only with Microsoft Internet Explorer, which I use only for accessing Cingular’s BlackBerry web client. Request to RIM: please make it work with Firefox.
An other extension I used at some point is Grease Monkey, especially for the user script that created a Gmail Delete Button. Unfortunately, moving from a browser sporting this extension to one that did not created significant mental confusion that led me to use the ‘Delete’ button instead of the Archive one in way too many occasions — hardly a productivity improvement… The Gmail team must have been aware of this problem and recently added the most-desired ‘Delete’ button, right to the ‘Report Spam’ one, which is a better option than Grease Monkey’s, which appeared to the left of the ‘Archive’ one. Since then, I have uninstalled Grease Monkey.
The last functional area that heavily relies on browser extensions is social bookmarking. For it, I only use tools that can both work with and without browser extension, such as Simpy or del.icio.us. Activeweave or Diigo offer interesting annotation capabilities, but both require the installation of a plugin, therefore I am not using them and remain convinced that they could have been implemented using AJAX only.
Entry filed under: Office 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[…] I liked del.icio.us a lot, but two features convinced me to upgrade to Simpy: first, Simpy allows you to create private bookmarks; second, it provides a REST API that I intend to use to synchronize my bookmarks with the various links I store into Salesforce.com. Obviously, I must not be the first one to upgrade from del.ico.us, and the Simpy team developed a del.icio.us import tool that made the upgrade a snap: just enter your user name and password, wait for an hour or two, and you’re ready to uninstall the del.icio.us plugin and install the Simpy one, keeping in mind that browser extensions should be used with care. Much like with del.icio.us, I am sharing my bookmarks, and among them my office 2.0 setup, the candidate services that might eventually make their way into the later, and the technologies that I am currently investigating in order to connect all these pieces together. Among them, I have just discovered Feed Digest and must say that I am quite impressed. More on this later. […]
[…] No browser extension or pluginFor reasons explained in a previous article, browser extensions and other plugins should be avoided at all cost. If two services offer the same functionality, but one requires an extension and the other does not, I will always go for the later one, even if that means that I have to lose a couple of features along the way. […]
You say “Browser extensions such as plugins and toolbars…” but you don’t really talk about plugins such as Java and Flash. Office 2.0 sites as ThinkFree and Gliffy make heavy use of these plugins. Do you consider Java and Flash so ubiquitous that a dependency on them is not an issue? Or do you lump them into the browser extension category and avoid them? -Chris
Chris,
Very good question. I view them as ubiquitous, yet I tend to prefer solutions that do not rely on them. AJAX is not yet as powerful as Java or Flash, but it’s a lot more Web-friendly.
Hi,
I can’t disagree more strenuously. While plugins and extensions have gotten a bad name for security reasons, to blame the concept is wrong. Extensions to applications often are what moves functionality forward. What would the web be today without Flash?
My own company’s situation and product, MathPlayer, is an excellent example here. It is a plugin that provides MathML support within Microsoft’s Internet Explorer. Mozilla/Firefox, on the other hand, has MathML built in.
All other things being equal, one might easily conclude that Firefox’s built-in MathML support is better than IE’s add-on support via MathPlayer. However, MathPlayer’s support of MathML is superior as it supports more of MathML, and it interfaces with screen reader software used by the blind to have web pages read to them using a synthesized voice. MathPlayer has a number of other features that Mozilla’s MathML lacks.
I mention this not to toot my company’s own horn, but to indicate how important and beneficial the marketing dynamics gained from a plugin architecture are. On one hand, Mozilla’s MathML support was added mostly by the herculean efforts of one person who gave up their own time, unpaid as far as I know. On the other hand, my company builds products that are based on MathML technology. While MathML is an open standard, my company profits from it. It allows us to invest in providing the free MathPlayer plugin that would be hard to duplicate otherwise.
In conclusion, plugins and extensions are a very good thing. They allow new functionality to be explored in an efficient way, and exploit market dynamics to supply solutions that would otherwise not occur.
Paul Topping
Paul,
I agree with the business benefits offered by plugins, but I do not like their technical implementation, for they prevent mobility. Now, this is very much a matter of personal preference. Plugins are needed in many instances, and I am not saying that they should not be used in such instances. Instead, I am just recommending that application developers do not use them when alternative approaches are available. In your particular example, I cannot think of any working alternative, hence plugins are the only option available, and should be used as such.
I totally agree that plugin mechanisms have technical problems. As they represent executable code, security is a big issue. Also, many extension mechanisms are proprietary and cause undue product or platform lock-in. I do believe that these problems are surmountable, however. The root of the problem is that most extension mechanism have been implemented in a kind of back-door, application-specific way. If an extension mechanism is based on robust, public standards, these problems can be solved. -Paul
gbwcpfqs… gbwcpfqs…
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment