Vivaldi-Gründer: "Ein Mobilbrowser ist auf unserer Liste"

Inhaltsverzeichnis

Jon von Tetzchner gründete Mitte der 90er-Jahre Opera und leitete das Unternehmen viele Jahre lang. Nach seinem Ausscheiden gründete er in seiner isländischen Heimat das Unternehmen Vivaldi, das den gleichnamigen Browser herausbringt. Zwei Tage nach Veröffentlichung der ersten Beta-Version von Vivaldi traf c't Jon von Tetzchner.

c't: Wie viele Downloads haben Sie bisher für Vivaldi verzeichnet?

Jon von Tetzchner: Zwischen zwei und zweieinhalb Millionen, aber das schließt nur die Technical Previews ein. Wir sind damit sehr zufrieden. Für die Beta habe ich noch keine Zahlen.

c't: Wo kommen Ihre Nutzer her? Sind das die alten Opera-Schwerpunkte wie Skandinavien, Deutschland, Polen ...

JvT: Ja, nicht zu vergessen Russland und Ukraine, wo Opera immer sehr populär war. Prozentual hat Vivaldi aber in den USA, Frankreich und Großbritannien höhere Anteile als damals Opera. Auch in Japan haben wir Nutzer, die sehr Technik-affin sind, und in Indien.

c't: Wie sehen Sie diese Beta – eher als vorläufige Version zum Ausprobieren oder als ein im Wesentlichen fertiges Produkt, das sich für den täglichen Einsatz eignet?

JvT: Die Beta hat die meisten Funktionen, die wir für die finale Version geplant haben. Viel mehr werden wir kaum schaffen; es gibt noch eine riesige Liste mit Features, die wir gerne hätten.

Bei der Synchronisation wissen wir es noch nicht. Wir sind damit fast fertig, aber noch nicht ganz. Aber da wollen wir uns erst sicher sein, denn wenn Synchronisation schiefläuft, ist das ziemlich schlecht. Der Mail-Client ist in den Versionen enthalten, die ich benutze. Aber ich habe nicht das Gefühl, dass er schon reif für die Veröffentlichung ist. Er hat noch zu viele Bugs und die Oberfläche muss noch überarbeitet werden.

Mail-Client und Funktionen

c't: Wird der Mail-Client so ähnlich aussehen wie Operas M2?

JvT: Es gibt Ähnlichkeiten im Konzept: Wie M2 läuft M3 auf einer Datenbank und kann mit mehreren Accounts umgehen ... Aber wir wollen nicht nachahmen, was wir bei Opera gemacht haben, sondern wir wollen es besser machen. Wir müssen den Code sowieso komplett neu schreiben.

c't: Wie laufen die internen Prozesse bei Vivaldi? Haben Sie mit Ihrer langen Erfahrung beim Browser-Entwickeln den Master-Plan oder bringt jeder aus dem Team seine eigenen Ideen ein?

JvT: Eher Letzteres. Ich glaube, dass mehrere Köpfe besser denken als einer. Wir haben verschiedene Meinungen; etliche Mitarbeiter bringen viel Erfahrung auf diesem Gebiet ein, andere nicht. Wenn es unterschiedliche Meinungen gibt, lautet die Frage: Gibt es einen sinnvollen Grund dafür? Sollen wir dem Benutzer mehrere Optionen zur Auswahl stellen? Wenn es intern oder durch externes Feedback zu verschiedenen Meinungen kommt, die nicht miteinander kompatibel sind, machen wir das konfigurierbar und setzen das als Default, was vermutlich bei den Benutzern besser ankommen wird.

c't: So kommen also beispielsweise Features zustande wie der neue visuelle Tabwechsler, den man auch abstellen kann.

JvT: Ähnlich ist es mit der Reihenfolge der Tabs. Ich persönlich mag es, diese in chronologischer Reihenfolge durchzublättern. Das Betriebssystem macht es bei den Programmen ja ähnlich. Google dagegen orientiert sich an der visuellen Platzierung des Browser-Tabs. Auch das hat eine gewisse Logik, und einige Leute möchten das so, deshalb ist es eine Option. Mit Tastaturkürzeln kann man beides nutzen.

c't: Die Anpassbarkeit von Vivaldi spiegelt also die demokratischen Prozesse innerhalb des Unternehmens wider?

JvT: Ja. Nicht verhandelbar ist nur, dass wir diese Optionen haben. Wir nehmen dafür auch zusätzliche Arbeit und zusätzliche Komplexität auf uns. Es hat schon Gründe, warum andere das nicht machen: Dinge dürfen nicht zu kompliziert werden, und vielfältige Einstellungsmöglichkeiten eröffnen Bugs mehr Raum. Wir haben diese Herausforderung angenommen, weil wir glauben, dass dies dem Benutzer großen Mehrwert bringt.

c't: Sie glauben also, die Vivaldi-Nutzer sind genug Experten, um mit diesen Optionen zurechtzukommen.

JvT: Die Nutzer, die wir im Blick haben: ja. Aber wir geben uns Mühe, dass die Konfigurierbarkeit nicht im Weg steht, und statten den Browser mit guten Default-Einstellungen aus.

Desktop first

c't: Wir sprachen ja über die angekündigte Synchronisation. Da liegt die Frage nach einer Mobilversion nahe ...

JvT: Eine Mobilversion ist auf unserer Liste. Wir haben uns schon mal angesehen, wie man das über Plattformen hinweg umsetzen kann und wie das mit den Bibliotheken und der Code-Basis klappen könnte. Wir werden das machen, aber erst einmal konzentrieren wir uns auf den Desktop. Bis dahin achten wir darauf, dass wir nichts einbauen, was einer mobilen Version im Weg stehen würde.

c't: Eine Sache, die Opera groß gemacht hat, war die serverseitige Datenkomprimierung. Wird es das in Vivaldi auch geben?

JvT: Wir werden das prüfen. Wahrscheinlich werden wir aber nicht eine Art Opera Mini bauen. Datenkomprimierung steht nicht weit oben auf unserer Liste, denn man braucht massive Infrastruktur dafür.

Chromium und Versionssprünge

c't: Chrome und Firefox haben einen ziemlich kurzen Release-Zyklus von ungefähr sechs Wochen. Wie ist das für Vivaldi geplant?

JvT: Wir müssen sicherstellen, dass wir Vivaldi mit aktuellem Chromium-Unterbau ausliefern. Wir werden aber nicht alle sechs Wochen eine neue Versionsnummer vergeben. Wir glauben, das ist nicht richtig. Von einer Version 2.0 erwarte ich mehr als von einer 1.1. Das ist vielleicht ein bisschen konservativ, aber wir wollen mit den Versionsnummern mehr aussagen. Können Sie mir sagen, was der Unterschied zwischen Chrome 30 und Chrome 35 ist? Es gibt vielleicht wichtige Features, aber sie sind nicht wirklich sichtbar. Wir konzentrieren uns auf die Bedienoberfläche, und dafür halten wir eine etwas konservativere Versionsnummer für sinnvoll.

c't: Aber Sie wollen die Chromium-Updates einbauen, so schnell es geht?

JvT: Ja. Wir dürfen da nicht weit zurückliegen, vor allem, wenn es um Sicherheits-Updates geht. Das machen wir mit den Unterversionen.

c't: Ist es ein Problem, Chromium zu aktualisieren? Geht da was kaputt?

JvT: Manchmal, ja. Wir arbeiten mit Code, der sich ständig ändert. Bei Opera hatten wir Kontrolle über alles. Jetzt arbeiten wir mit dem Code dieses Riesenunternehmens. Dabei müssen wir sicherstellen, dass deren Änderungen mit unseren harmonieren, denn unsere Updates schaffen es meistens nicht in ihre Code-Basis.

c't: Chromium hat also kein robustes API, sondern ist eine bewegliche Plattform.

JvT: Sie schreiben immer wieder alles um. Wir kriegen ein Update, alles ist kaputt und wir brauchen eine Woche, um es wieder in Ordnung zu bekommen; manchmal sogar länger. Aber Chromium ist für uns keine Blackbox, und manchmal müssen wir an den Code. Sie arbeiten eben für sich selbst. Manchmal nutzen wir ein Stück Code und sie ändern oder entfernen es.

c't: Sind Sie in Kontakt mit den Chromium-Entwicklern?

JvT: Sie wissen, dass es uns gibt. Wir haben auch Bugs gemeldet und Fixes gemacht. Wir haben eine gute Arbeitsbeziehung, aber sie haben ihren eigenen Fokus. Ein Grund, warum sich Chromium von Apple getrennt hat, war, dass sie von niemand anderen abhängen wollten. Ich verstehe diese Sichtweise. Wir müssen damit zurechtkommen, dass wir von ihnen abhängen.

Nativ vs. Webtechnik

c't: War von Anfang an klar, dass Sie die Oberfläche mit Webtechniken bauen, oder stand auch nativer Code zur Debatte?

JvT: Wir haben darüber diskutiert. Es gibt da eine lange Vorgeschichte. Am Anfang haben wir bei Opera alles nativ gemacht. Nach und nach haben wir unseren eigenen Layer gebaut, Quick, damit wir auf Windows, Mac und Linux ausliefern konnten. Web-basierende Lösungen haben wir nur auf Mobilgeräten und anderen Geräten ausprobiert, nicht auf dem PC. Ein Problem war dabei, dass Opera in einem Thread läuft – wie priorisiert man da? Es kann passieren, dass die Oberfläche sich nicht aktualisiert, weil die Webseite beschäftigt ist und so weiter.

Opera hat seit dem Sprung auf Version 15 eine native Oberfläche. Ich weiß nicht, ob das eine gute Wahl war, denn es ist aufwendiger und man braucht unterschiedliche Teams. Indem wir mit dem Web als Layer arbeiten, können wir dagegen effizient arbeiten. Dadurch können sich auch die Designer besser einbringen und Sachen ausprobieren. Viele Leute können am Code arbeiten, ohne ihn kompilieren zu müssen – dadurch entwickelt man viel schneller.

Es ist auch kein Zufall, dass viele Webseiten besser aussehen als native Anwendungen -- das Entwickeln ist weniger aufwendig. Klar, aus einer technischen Perspektive ist nativ besser: Der Code läuft schneller. Aber so können wir schneller entwickeln.

c't: Kann man mit Webtechniken ausreichende Geschwindigkeit erreichen?

JvT: Ja. Heutige Rechner sind sehr schnell. Wenn wir das Gefühl haben, dass etwas mit Webtechnologien nicht schnell genug ist, haben wir immer noch die Wahl, es nativ zu programmieren. Langsam sind typischerweise die Dinge, die zwischen Web und nativ passieren, zum Beispiel die Lesezeichen. Wir haben lange daran gearbeitet und mussten entscheiden, was wir nativ und was mit Webtechnologien umsetzen.

Performance

c't: Warum haben Sie sich für das von Facebook entwickelte JavaScript-Framework React entschieden?

JvT: Wir haben einiges ausprobiert und sogar versucht, unser eigenes Framework zu schreiben. React war für uns die Lösung, mit der wir am effektivsten arbeiten konnten. Als wir anfingen, gab es das noch gar nicht. Wir fanden es interessant, probierten es aus, evaluierten es – das ist unser Prozess. Wir haben einen Rapid-Prototyping-Arbeitsstil und machen die Dinge interaktiv.

c't: Und Sie sind zufrieden mit der Performance?

JvT: Es funktioniert gut, aber wir arbeiten ständig daran. Manchmal baut man hübsche Animationen ein und wirft sie raus, weil sie nicht schnell genug sind, dann findet man doch eine Lösung und nimmt sie wieder hinein, dann wirft man sie erneut hinaus oder macht eine Option daraus ... Man muss auf verschiedenen Systemen testen.

Die Entscheidung für React war schwierig und wir haben uns viel Zeit dafür genommen. Wir arbeiten mit Chromium, das ein bewegliches Ziel ist, und mit diversen Bibliotheken, die bewegliche Ziele sind. Wir haben versucht, die Zahl der Bibliotheken so weit wie möglich zu reduzieren, auch wenn sie verführerisch sind, und mehr eigenen Code einzusetzen, um die Auswirkungen auf Größe und Geschwindigkeit zu verringern.

c't: Die Versionen für die unterschiedlichen Betriebssysteme sind alle auf dem gleichen Niveau?

JvT: Sie laufen alle mit dem gleichen Code, aber es gibt ein paar spezifische Anpassungen. Zum Beispiel sind die Menüs auf dem Mac anders. Auf Linux ist es ziemlich kompliziert, weil die Fenster-Bedienelemente unterschiedlich platziert sind.

c't: Gibt es eigentlich Neues in Sachen Monetarisierung?

JvT: Wir haben ein paar Suchmaschinenverträge. Wir versuchen, nur Suchmaschinen und Lesezeichen einzubinden, die die Benutzer auch mögen. Unsere Verträge sind provisionsbasierend – es hätte also sowieso keinen Sinn, Schrott anzubieten. Was die Benutzer nicht mögen, können sie natürlich löschen. (dbe)