Direkt zum Hauptbereich

Add-ons for Chrome - or - A new architecture for browsers

On September 2nd, on Tuesday, Google released Chrome -- their own web browser. Chrome has a simple, unobtrusive user interface, it's based on WebKit, it's powered by a new JavaScript implementation, it runs a process for each new tab, and it promises a new approach to safe browsing. On this one, Chrome failed. Chrome has some severe security holes Google needs to fix. Nonetheless, I like the new browser.

Some hours after Google had released Chrome, I read a lot of comments about the Chrome experience. Most users seemed to be quite enthusiastic, some few were not. But one sort of comments caught my attention: Some folks argued that Firefox users will stay with Firefox. Why? Because of all these nice add-ons you can extend Firefox with.

My spontaneous reaction was: Who needs add-ons?

Before you laugh at me. I run Firefox with extensions like Firebug, Web Developer, ScrapBook and others. I use them extensively and like them a lot. Who wants to miss Firebug, for instance? Nobody, right?! I wouldn't use a browser without my beloved add-ons. And one is for sure. A browser without extension capabilities won't make it in the long run. (Ok, I'm not sooo sure.)

So what made me think "Who needs add-ons"?

I contemplated some time over my spontaneous reaction. Forgive me, I don't know much about how to write extensions for Firefix. I am an extension user, not an extension programmer. But my gut feeling tells me that the approach to extensions in Firefox is wrong. It's the worst Google could do to copy the extension mechanism of Firefox. I should rephrase my first reaction: "Who needs such an add-on architecture?"

Instead of criticizing Firefox's extension mechanism, of which I don't know much about, let me sketch an alternative approach to extensions.

Assume a "naked" browser: no buttons to click on, no url field, no menu, nothing. Assume that all the browser does after startup is run a JavaScript program. Let's call this program the "Controller". The key point is: You can change the Controller. Don't like the default Controller? Change it. The Controller is under your control!

The default Controller is a JavaScript program that creates buttons to click on and implements a history of web pages visited. It provides the url input field and displays suggestions while you type. It lets you have menus and so on.

Got it? The Controller is a program that creates a user interface that mimics Firefox. Or Chrome. Or IE. Or Opera. Or Safari. Whatever you want.

If you type in a url in the url field and hit enter, it's the Controller, which -- so to speak -- creates an IFrame and loads the given web page into that frame. So the web page remains fully under control of the Controller.

It does not require that much imagination to see that the Controller can easily be extended by -- right, by extensions or add-ons. These extensions are just other JavaScript programs, which are plugged into the Controller.

To oversimplify things, I envision a browser, which consists only of an HTML and CSS rendering engine and a virtual machine running JavaScript. The rest is initiated by an ordinary JavaScript program using web technology. In other words: My favorite browser is fully programmable with web technology.

The idea is simple, isn't it? It thrills me.

The development of such a "naked" browser inevitably raises questions like:

  • How do we guarantee that the Controller doesn't loose control?

  • How do we compose add-ons? How do we avoid interference of add-ons?

  • Do we need a component architecture? Or do we need a service-oriented architecture?

  • How do we ensure safe browsing and secure execution?


It's much about architecture thinking and a JavaScript implementation that supports fundamental notions of modularization, safety and security. These are aspects which should IMHO drive the standardization activities of JavaScript. Implementors of browsers should radically rethink the way browsers are built and function. Google did a first, tiny step in that direction with Chrome. But there's more to strive for.

Beliebte Posts aus diesem Blog

Lidl und der Kassen-Bug

Es gibt Fehler, im Informatiker-Jargon "Bugs", die etwas anrühriges haben. Ich bat den Menschen an der Kasse bei Lidl um einen Moment Geduld und meine Kinder um Ruhe, um nicht den wunderbaren Moment zu verpassen, bei dem es passierte. Der Lidl-Mensch fluchte kurz auf -- und ich war entzückt! "Einen Moment, davon muss ich ein Foto machen!" Und dann machte ich noch eines. Ich bin heute extra für diesen Fehler zu Lidl gepilgert -- ich wollte es mit eigenen Augen sehen. Gestern hat mir ein Student (vielen Dank Herr Breyer) von diesem Fehler in einer EMail berichtet. Ein richtig schöner Fehler, ein Klassiker geradezu. Ein Fehler, den man selten zu Gesicht bekommt, so einer mit Museumswert. Dafür wäre ich sogar noch weiter gereist als bis zum nächsten Lidl. Der Fehler tritt auf, wenn Sie an der Kasse Waren im Wert von 0 Euro (Null Euro) bezahlen. Dann streikt das System. Die kurze Einkaufsliste dazu: Geben Sie zwei Pfandflaschen zurück und Lidl steht mit 50 Cent bei Ihne

Syntax und Semantik

Was ist Syntax, was ist Semantik? Diese zwei Begriffe beschäftigen mich immer wieder, siehe zum Beispiel auch " Uniform Syntax " (23. Feb. 2007). Beide Begriffe spielen eine entscheidende Rolle bei jeder Art von maschinell-verarbeitbarer Sprache. Vom Dritten im Bunde, der Pragmatik, will ich an dieser Stelle ganz absehen. Die Syntax bezieht sich auf die Form und die Struktur von Zeichen in einer Sprache, ohne auf die Bedeutung der verwendeten Zeichen in den Formen und Strukturen einzugehen. Syntaktisch korrekte Ausdrücke werden auch als "wohlgeformt" ( well-formed ) bezeichnet. Die Semantik befasst sich mit der Bedeutung syntaktisch korrekter Zeichenfolgen einer Sprache. Im Zusammenhang mit Programmiersprachen bedeutet Semantik die Beschreibung des Verhaltens, das mit einer Interpretation (Auslegung) eines syntaktisch korrekten Ausdrucks verbunden ist. [Die obigen Begriffserläuterungen sind angelehnt an das Buch von Kenneth Slonneger und Barry L. Kurtz: Formal Syn

Mit Prof. Handke im Gespräch: Vom Workbook zum Inverted Classroom

Aus dem Netz in Handkes Büro Es gibt diese schönen Momente, da führen soziale Medien zu sozialen Begegnungen im echten Leben. Ich twittere im Nachgang zur #BiDiWe16, ein Dialog mit Jürgen Handke ergibt sich, er schickt mir seine Telefonnummer, ich rufe sofort durch, wir verabreden uns. Drei Tage nach der #BiDiWe16 sitze ich bei Handke im Büro, das gleichzeitig sein beachtlich ausgestattetes Aufnahmestudio beherbergt. Es ist Freitagmorgen, 9. September 2016. Jürgen Handke ist mir kein Fremder. Ich habe zwei seiner ICM-Konferenzen besucht, auf der #BiDiWe16 in Berlin hielt er die Keynote. Er hat für seine Lehre Preise erhalten, zuletzt 2015 den Ars Legendi-Preis für exzellente Hochschullehre. Zugegeben, ich hadere mit dem Konzept des Inverted Classroom -- auch Flipped Classroom genannt. Meine Erfahrungen mit der Programmierausbildung von Informatik-Studierenden des 1. und 2. Semesters lassen mich zweifeln. Videos habe ich auch schon produziert, aber vor allem das selbstgesteuerte