Tim Sneath: „Flutter ist für Apps wie Unity für Spiele“

Vorwort

Wir haben mit Tim Sneath, Googles Produktmanager für Flutter und Dart, darüber gesprochen, wie sich sowohl die Sprache als auch das Framework in den letzten zwei Jahren entwickelt haben, wie sie heute verwendet werden und wohin sie sich entwickeln werden.

Das Interview

Evrone: Ihre Berufsbezeichnung lautet „Produktmanager für Flutter und Dart“. Was braucht man, um Produktmanager eines Frameworks und einer Programmiersprache zu sein?

Tim: Ich war noch nie Produktmanager für ein Verbraucherprodukt, also kenne ich nur die Seite der Softwareentwicklung! Aber im Allgemeinen geht es bei der Tätigkeit als Produktmanager darum, Geschäftsstrategien, Kundenfeedback, technische Ressourcen und ein gewisses Maß an vorausschauender Intuition zu kombinieren, um ein Produkt zu schaffen, das von seiner Zielgruppe hoffentlich geliebt wird.

Die Nutzung von Flutter hat in den letzten Jahren enorm zugenommen, und viele der Herausforderungen, die mich beschäftigen, beziehen sich auf den Umgang mit den Kompromissen, die mit diesem Wachstum verbunden sind: Wie viel unserer Ressourcen widmen wir dem Bau neuer Features im Vergleich zum Aufpolieren bestehender? Wie teilen wir unsere Aufmerksamkeit auf interne Nutzer, Unternehmen und Start-ups auf? Wie können wir neue Formfaktoren wie Foldables und Plattformen wie Windows und MacOS unterstützen, ohne dass wir etwas vernachlässigen?

Evrone: Es scheint im Moment eine Art Renaissance für Frameworks zu geben, die UI mit Code erstellen. In den letzten Jahren wurden Flutter, Swift UI und Jetpack Compose angekündigt oder veröffentlicht. Sie sprechen im Zusammenhang mit Flutter auch viel über „Hot Reload“. Welche Trends beobachten Sie hier?

Tim: Ich glaube, die Produktivität der Entwickler wird seit einigen Jahren auf dem Altar der Innovation geopfert. Ich war an der Universität, als Visual Basic 1.0 herauskam, und das war in vielerlei Hinsicht eine gute Voraussetzung für die einfache Entwicklung von Benutzeroberflächen. Vor VB erforderte das Programmieren einer Windows-Anwendung Hunderte von Zeilen in C, einen DOS-Editor und Befehlszeilen-Compiler sowie eine mühsame Editier-/Kompilier-/Debug-Schleife, um sie zum Laufen zu bringen. Visual Basic hat Hobby-Entwicklern die Möglichkeit geboten, ihr UI-Design direkt auf den Bildschirm zu malen, zusammen mit „Edit and Continue“ – der Möglichkeit, eine Anwendung anzuhalten, Änderungen vorzunehmen und dann ohne Neukompilierung fortzufahren.

In den letzten paar Jahrzehnten ist es eher schwieriger als einfacher geworden. Wir haben sehr viele Ebenen der Komplexität zu den damals einfachen Operationen hinzugefügt: Präprozessoren und Transpiler, tief verschachtelte Modulhierarchien mit unklaren transitiven Abhängigkeiten sowie Stacks, die sich so schnell verschieben, dass die Anwendung veraltet ist, bevor sie fertig ist.

Wir haben noch einen langen Weg vor uns, aber „Stateful Hot Reload“ ist ein Schritt nach vorn, um die „Edit and Continue“-Bequemlichkeit der UI-Entwicklung wieder herzustellen. Ich hoffe, dass wir die kognitive Last der Realisierung einer App mit Flutter weiter verringern können, so dass sich die Entwickler mehr auf das konzentrieren können, was sie bauen wollen, und weniger darauf, wie sie dies im Code ausdrücken können.

Evrone: Der Krieg zwischen „Nativen OS-Widgets“ vs. „Pixel-gezeichneten eigenen Widgets“ dauert Jahrzehnte an, beginnend mit den ersten Qt-Versionen. Angesichts Ihrer Erfahrung mit vielen großen Unternehmen, die mobile Apps entwickeln, wie ist die aktuelle Situation?

Tim: Ich denke, das ist eine falsche Dichotomie. Das Einzige, was zählt, ist Qualität: Kann man ein schönes Erlebnis schaffen, das eines anspruchsvollen Nutzers würdig ist? Und Qualität hat wenig damit zu tun, wie binär ein bestimmtes Pixel auf dem Bildschirm dargestellt wird: Es ist eine Kombination aus Leistung, Liebe zum Detail und technischen Möglichkeiten. Einige der am meisten ausgezeichneten Spiele da draußen werden mit der Unity-Spiele-Engine gebaut, aber niemand kümmert sich darum, ob Monument Valley „native OS-Widgets“ verwendet oder nicht. Wir glauben, dass Flutter für Apps wie Unity für Spiele ist: Es bringt Apps eine native Leistung und visuelle Finesse, unabhängig von ihrer Zielplattform.

Wir glauben, dass Flutter für Apps wie Unity für Spiele ist: Es bringt Apps eine native Leistung und visuelle Finesse, unabhängig von ihrer Zielplattform.

Evrone: Wie hängt Dart mit dem brandneuen Google-Projekt „Fuchsia“ zusammen? Sie ist neben C++, Rust und Python als eine der „empfohlenen“ Sprachen aufgeführt.

Tim: Fuchsia ist ein experimentelles Open-Source-Betriebssystem, an dem wir seit kurzer Zeit arbeiten. Zu diesem Zeitpunkt haben wir nicht viel dazu zu erzählen, aber der Quellcode ist vollständig öffentlich. Da Flutter das Builden für Fuchsia unterstützt, findet man im Flutter-Quellcode verschiedene Verweise darauf. Und natürlich ist Dart die Sprache von Flutter.

Evrone: Große Unternehmen wie eBay oder BMW nutzen die Dart+Flutter-Kombination für ihre mobilen Projekte. Was sind für sie die wichtigsten Verkaufsargumente?

Tim: Für viele von ihnen ist es schlichtweg die Möglichkeit, ihre App-Entwicklung mit einer einzigen hochwertigen Lösung zu vereinheitlichen. Wenn man darüber nachdenkt, ist es verrückt, dass bei den meisten Consumer Apps mehrere Teams an genau demselben Geschäftsproblem arbeiten, mit denselben Ergebnissen und Zeitplänen, und die alle dieselbe Arbeit machen, nur mit einer anderen Sprache und einem anderen Tool für jeweils iOS, Android und Web. In der Software-Entwicklung gibt es heute nicht wirklich eine Analogie: Kein Unternehmen implementiert freiwillig drei neue, getrennte Gehaltsabrechnungssysteme. Wenn Teams entdecken, dass sie nicht nur ein qualitativ hochwertiges natives Erlebnis für mehrere Plattformen gleichzeitig aufbauen können, sondern dass sie aufgrund von Funktionen wie Stateful Hot Reload produktiver sein können als auf jeder einzelnen Plattform, dann ist der Verkauf garantiert!

Die größten Herausforderungen sind nicht-technischer Natur: Viele Unternehmen haben eine organisatorische Ausrichtung um ihre Zielplattform herum. Das bringt manchmal Widerstand seitens der Teams mit sich, die sich nicht auf einen Haufen werfen lassen wollen. Und natürlich sind wir noch eine junge Plattform, so dass konservativere Unternehmen von Natur aus skeptisch sind. Aber die Zeit wird dieses Problem lösen: unser Ökosystem von Paketen und Plug-ins ist im letzten Jahr um das 5-fache gewachsen, und es gibt Zehntausende von Apps im Store, die zeigen, dass Flutter in der Lage ist, Qualität in großem Maßstab zu liefern.

Evrone: Ist es Ihrer Meinung nach besser, wenn Entwickler getrennte Layouts für Tablets und Mobiltelefone erstellen, oder sind die modernen Technologien bereits leistungsfähig genug, um „adaptive“ Benutzeroberflächen zu erstellen, die perfekt zu verschiedenen Bildschirmgrößen passen?

Tim: Die Herausforderungen beim adaptiven UI-Design liegen sowohl im Framework als auch in der Verwendung von Tools. Das Internet unterstützt seit Jahren „Media Queries“, aber es ist immer noch schwierig, eine App zu schaffen, die gleichmäßig über alle Formfaktoren skaliert. Flutter macht dies möglich, und Matias Duarte hat kürzlich einen Tool-Prototypen vorgeführt, mit dem wir für Flutter experimentieren.

Evrone: Welche IDE bevorzugen Sie im Moment? Android Studio, JetBrains-Produkte, VSCode oder etwas anderes?

Tim: Ich persönlich bin VSCode gewöhnt, da ich vom Visual Studio-Team zu Google gekommen bin und es eine Produktsuite ist, mit der ich über die Jahre viel Zeit verbracht habe. Und ich war begeistert von der Arbeit, die Danny Tuppeny beim Aufbau der Flutter- und Dart-Erweiterungen geleistet hat. Es war großartig zu sehen, wie Flutter von VSCode aus zu einer nahtlosen Benutzererfahrung wurde. Als Team kümmert es uns natürlich nicht wirklich, welche Programmierwerkzeuge man verwendet, ob Android Studio, IntelliJ, VSCode, Vim oder Emacs!

Ein Projekt, das mich sehr interessiert, ist das Language Server Protocol-Projekt Es versucht, die Kluft zwischen Editoren und Sprachen mit einem gemeinsamen Protokoll zu überbrücken. Neben einem ähnlichen Projekt für Debug-Adapter, hoffen wir, dass dies den Entwicklern nach und nach ermöglicht, Tools auszuwählen, die ihren Bedürfnissen entsprechen, ohne dass die Autoren der Sprachen ihre Arbeit für jedes dieser Tools duplizieren müssen.

Evrone: Es gibt Gerüchte, dass Dart JavaScript in Webbrowsern ersetzen sollte, jetzt aber Flutter unterstützen wird. Stimmt das? Und wo wird Dart abseits der App-Entwicklung eingesetzt?

Tim: Es stimmt, dass die Entstehungsgeschichte von Dart als Auswuchs des V8-Teams begann, das neue Ansätze für die Entwicklung von Apps erprobte. Aber dieses Dart hat wenig Ähnlichkeit mit der heutigen Sprache, die vor einigen Jahren mit der Einführung von Dart 2.0 als kundenoptimierte Sprache wiedergeboren wurde. Das heutige Dart konzentriert sich auf einen bestimmten technischen Bereich: Plattformportabilität im Web, auf mobilen Geräten und auf dem Desktop; schnelle Objekterstellung und Garbage Collection; VM-Code-Injektion während der Entwicklung mit nativer Kompilierung zur Laufzeit. Dadurch eignet es sich besonders für Kundenszenarien, egal ob Flutter, CLI oder Geschäftslogik.

Evrone: Was ist Ihre persönliche Meinung zum „Full-Stack“-Ansatz? Ist es für moderne Entwickler machbar, mit Sprachen wie Dart, die sowohl im Front- als auch im Backend gut funktionieren, alle Teile der Anwendung zu schreiben?

Tim: Ich weiß nicht, wie es anderen geht, aber ich finde es schon herausfordernd, alleine mit den Client-Technologien Schritt zu halten! Es ist toll, eine Sprache zu haben, die so flexibel ist, dass sie auf Mobilgeräten, im Web, auf Servern und in der Cloud eingesetzt werden kann. Wir sehen auch, dass verschiedene Leute Dart effektiv auf dem Server einsetzen, um beispielsweise vorhandene Geschäftslogik, die sie bereits für den Kunden geschrieben haben, zu teilen. Ich denke, dass es machbar ist, Full-Stack-Entwickler zu sein. Es gibt viele Menschen, die genau das bereits sind. Spezialisierungen werden allerdings immer notwendiger, da die Anwendungen immer umfangreicher werden. Und ich glaube nicht, dass man bei Google außerhalb von Projekten aus Innovationszentren viele echte Full-Stack-Entwickler findet.

Evrone: Flutter for Web ist jetzt in der Beta-Phase und Flutter for Desktop ist in einer frühen Alpha. Welche Zukunft sehen Sie für sie?

Tim: Beide befinden sich noch in der Entwicklung, aber wir kommen der Sache immer näher und werden bald einige Ankündigungen über die Fortschritte veröffentlichen, die wir an beiden Fronten gemacht haben. Wir haben Flutter nie nur für den mobilen Einsatz konzipiert; es war immer als tragbares UI-Framework gedacht, und iOS und Android waren nur zufällig die ersten beiden Ziele. Anwendungen der Desktop-Klasse stehen vor neuen Herausforderungen: der Formfaktor und die Eingabemethoden unterscheiden sich, und es werden oft unterschiedliche UI-Metaphern verwendet. Die Anwendungen müssen in der Lage sein, Fenstergrößen anzupassen und mehrere Fenster zu handhaben. Hinzu kommt, dass das Web vergänglich ist, im Gegensatz zu einer installierten Desktop- oder mobilen App.

Sowohl Web als auch Desktop sind auf unterschiedliche Weise als Zielplattformen für Flutter spannend. Das Web ist technisch anspruchsvoller, insbesondere wenn man die „Akzeptanzlücke“ älterer Projekte wie Flash und Silverlight vermeiden will. Wir möchten, dass das Web-Erlebnis so nahtlos ist, dass man sich den Quellcode ansehen muss, um sicherzugehen, ob eine Seite Flutter verwendet oder nicht. Auch bezüglich der Leistung machen wir gute Fortschritte: Wir haben vor Kurzem ein CanvasKit backend für das Web fertiggestellt, das enorme Vorteile bietet.

Der Desktop bietet eine faszinierende Reihe von Anwendungsfällen: von der Möglichkeit, Entwicklern einen einfachen Weg zu den mehr als eine Milliarde Windows-, MacOS- und Linux-Rechnern zu ermöglichen, bis hin zu einer deutlichen Vereinfachung der Anwendung von Flutter für neue User. Ich betrachte zunehmend den Desktop als primäres Ziel bei der Arbeit an einer Flutter-App, da man keinen Emulator oder ein angeschlossenes Gerät benötigt, um die Resultate zu sehen.

Noch faszinierender ist die Tatsache, dass die Wahl zwischen Web und Desktop mit Flutter erst relativ spät getroffen werden muss. Wir haben mehrere interne Projekte, die sich in der Entwicklungsphase befinden, bei denen wir noch nicht entschieden haben, ob sie als nativ kompilierte Desktop-Anwendung oder als PWA ausgeliefert werden sollen. Es ist großartig, dieses Maß an Flexibilität bieten zu können.

Evrone: Lässt sich Flutter mit React Native vergleichen? Was sind die Vorteile für einen durchschnittlichen Entwickler, eine neue Programmiersprache zu erlernen und ein vertrautes JavaScript liegen zu lassen?

Tim: Der reaktive Programmierstil hat Flutter in der Anfangszeit sehr inspiriert. Das ist ein enormer Unterschied im Vergleich zu den lange Zeit vorherrschenden Stilen des Nachrichtenaustauschs und des „Retain“-Modells. Es ist allerdings schwierig, diese Frage zu beantworten, ohne ein anderes Framework schlecht zu reden, was ich unter keinen Umständen tun möchte. Jedes von ihnen hat seine Stärken und Grenzen, und man findet überall unterschiedliche Meinungen, auch ohne eine Ergänzung meinerseits!

Evrone: Wenn Sie in der Zeit zurückreisen und irgendein Feature der Dart-Sprache ändern könnten, welches wäre das?

Tim: Ha! Zweifellos war das Feature, mit dem wir in den letzten Jahren die meiste Zeit verbracht haben, der „Strong Mode“: eine statische Typisierung für die Sprache. Das ursprüngliche Konzept von Dart war eine optional typisierte Sprache mit der Möglichkeit, Typen zu Entwicklungszwecken durch Annotationen auszudrücken, aber ohne semantischen Effekt zur Laufzeit. In Dart 1.x war das auch ein Kernprinzip der Sprache, aber im Laufe der Zeit wurden die Limitierungen dieses Ansatzes immer deutlicher, da sich sogar das Web in Richtung Typüberprüfung mit TypeScript bewegt hat.

Eine Änderung dieser Größenordnung an einer aktiven Programmiersprache war keine Kleinigkeit, aber das Entwicklerteam hat diese Arbeit mit Dart 2.0 abgeschlossen und dabei Millionen von Zeilen Dart-Code innerhalb von Googles Monorepo auf einen neuen gemeinsamen Frontend-Compiler migriert. Jetzt bauen wir auf dieser Arbeit auf, um eine solide Nullsicherheit hinzuzufügen, indem wir überprüfbare, nicht-nullbare Typen im gesamten Framework bereitstellen.

Wir haben vielleicht mehr als 50 Jahre damit verbracht, diese beiden Design-Entscheidungen umzukehren, aber das Endergebnis ist eine solide, nullsichere Sprache mit kampferprobten Compilern für JavaScript, Intel- und ARM-Maschinencode aus demselben Quellcode. Das ist meiner Meinung nach einzigartig.

Hier bei Evrone sind wir wirklich begeistert von der kontinuierlichen Weiterentwicklung von Dart und Flutter: je leistungsfähiger sie werden, desto besser sind die mobilen Apps, die wir für unsere Kunden und Partner entwickeln können. Viele dieser Apps haben bereits aus erster Hand von den Vorteilen des Dart-Ökosystems profitiert!