Die Qual der Wahl - Frontend-Technologien in 2017
Alle Jahre wieder wird man gefragt oder muss die Frage für eigene Projekte beantworten, welches denn aktuelle die Frontend-Technologie der Wahl ist. Schon lange wollte ich das einmal aufschreiben, damit ich nur noch Links versenden muss und eine Grundlage für zukünftige Antworten habe.
Natürlich ist dies nur eine von vielen subjektiven Meinungen, und ich erhebe keinen Anspruch auf Vollständigkeit oder Richtigkeit, freue mich aber auch über eine kritische Diskussion. Obwohl ich in vielen Projekten vermehrt mit Backend-Schwerpunkt arbeite, ist mein Background sehr stark Frontend-lastig. Mit Web-Technologien arbeite ich seit 1994 (hauptberuflich seit 2000), habe schon vieles selbst verwendet (Perl, PHP, Ruby, JavaScript, HTML, CSS usw.), und für unsere eigenen Lösungen bin ich auch immer noch oft selbst an den Tasten aktiv.
Werkzeugauswahl
Grundsätzlich bin ich der Ansicht, dass man sich immer die besten Werkzeuge (und damit meine ich Technologien, Frameworks, Bibliothken oder Produkte) für das jeweilige Ziel unter den gegebenen Rahmenbedingungen (vorhandene Skills, kleines/großes Projekt/Team, Budget, Laufzeit, Internet-/Intranet-Anwendung, verwendete Backend-Technologie etc.) aussuchen sollte. Daher ist die Betrachtung “was ist am besten geeignet” keine einfache Frage und nicht immer eindeutig zu beantworten, sondern muss differenziert betrachtet werden.
Insbesondere im Bereich Frontend-Technologien herrscht eine große Dynamik vor, und alle paar Monate tauchen neue Frameworks und Technologien auf. Die unübersichtliche, mitunter chaotische Situation, die diese Vielfalt und Auswahl mit sich bringt, macht es fast unmöglich, diese alle selbst ausreichend auszuprobieren, inbesondere nicht unter verschiedenen Rahmenbedingungen. Daher ist man auf Meinungen zahlreicher Personen angewiesen und sollte diese immer in dem Kontext der jeweiligen Verwendung interpretieren. Neben eigener praktischer Erfahrung, kommt so auch meine Meinungsbildung zustande.
Dies vorweggeschickt, haben wir im Team in letzter Zeit einiges angewendet und getestet und noch viel mehr gelesen. Gerade im Internet gibt zu jeder Pro-Meinung auch mindestens eine Kontra-Meinung und kaum neutrale Bewertungen. Was einer solchen am nächsten kommt, ist z.Z. https://stateofjs.com/ (1), ganz frisch mit den aktuellen Umfrage-Ergebnissen für 2017 aus > 20.000 Teilnehmern. Diese Übersicht soll hier als Grundlage für die Vorauswahl von Frameworks und Technologie dienen, was Exoten und ganz neue Frameworks ausschließt.
Browser sind die Laufzeit-Umgebungen für Web-Anwendungen
Web-Anwendungen, also im Browser angezeigte Seiten mit dynamischen und interaktiven Elementen, sind State-of-the-Art und werden es auch bleiben. Ansätze mit proprietärer App-Technologie als besserer Ersatz sind nur in begrenzten, geschlossenen Ökosystemen wie z.B. in mobilen Betriebssystemen erfolgreich. Die Offenheit und Vielfalt des Internet sorgt auch für eine ständige Evolution der Technologien.
Da die eigentliche Laufzeit-Umgebung für Web-Anwendungen die Browser sind, ist es immer interessant und wichtig, die Entwicklung der Browser-Engines zu betrachten. Historisch gesehen war es oft so, dass die Entwicklung der Funktionsunterstütztung der Browser immer der Fantasie und Schaffenskraft der Web-Entwickler hinterherhinkte, da entweder Quasi-Monopole (Microsoft IE) oder ein langsamer Standardisierungsprozess (W3C) die Browser-Entwickler ausbremste. Dies ist durch die größere Vielfalt der Browser-Hersteller und -Engines und die geänderte Strategie von Microsoft (Edge!) aber in den letzten ca. fünf Jahren schon deutlich besser geworden.
JavaScript-Frameworks im Speziellen
Der zuvorgenannte Punkt ist wichtig, um zu verstehen, warum es überhaupt JavaScript-Frameworks gibt. Grob betrachtet, erfüllen diese zwei Aufgaben: Zum einen erleichtern sie häufig verwendete Methoden, die mit den Bord-Mitteln älterer Browser nur sehr umständlich und vor allem in verschiedenen Browsern auf unterschiedliche Weise zu implementieren wären. Dies spart immens Zeit und erleichtert die Wartbarkeit, da es einem viel eigene Implementierung erspart und durch die Abstraktionsschicht unabhängig von den Browser-Engines und deren Unterschiede macht.
Zum anderen erweitern sie die eingebaute Funktionalität um Mittel zur Gestaltung von echten Web-Anwendungen z.B. durch Unterstützung von Templates und erleichtertes Data Binding, also die Erzeugung dynamischer Anwendungselemente durch Zusammenführung von Template-Elementen und benutzerspezifischen Daten aus einem Datenbank-Backend.
Oft steckt ein großer Hersteller hinter den in der öffentlichen Diskussion oft dominanten Frameworks, Bibliotheken und Sprachen, wie z.B. AngularJS, Angular (2, 3, 4, 5) (Google), React (Facebook), TypeScript (Microsoft) etc.. Die Vorteile sind, dass sie einen großen Funktionsumfang (“Full-Stack-Framework”) haben, ausgereift und gut dokumentiert sind und von vielen Entwicklern weltweit beherrscht werden. Allerdings muss man auch wissen, dass sie auch für ihre jeweiligen Hersteller optimiert entwickelt wurden, und mit dem großen Funktionsumfang auch oft eine Komplexität einhergeht, die einen höheren Einarbeitungsaufwand bedeutet. Dies bindet Entwickler mitunter langfristig an eine Technologie, und im “War for Talent” im Silicon Valley ist eine gewisse Abhängigkeit von einem Framework durchaus ein für die großen Hersteller angenehmer Nebeneffekt, denn wer z.B. fit ist in React findet bei Facebook schnell Anschluss.
Schaut man sich die am häufigsten verwendeten Client-JavaScript-Frameworks an, kann man - wie ich - zu folgender Einschätzung kommen:
AngularJS/Angular
AngularJS (Angular 1) ist 2017 weitgehend obsolet, denn Google hat bereits neue Folgeversionen (Angular 2, 4, 5) entwickelt, die Verbesserungen mitbringen, aber inkompatibel sind. U.a. nutzt Angular TypeScript, hat weitgehende Ansätze der Objektorientierung und Dependency Injection, zwingt Frontend-Entwickler aber damit, eine neue Sprache und neue Konzepte zu lernen. Angular ist geeignet, wenn man komplexe Enterprise-Projekte als SPA-Frontend-Anwendungen umsetzen will und die entsprechende Basis an Entwicklern dafür hat. Also ideal für Google selbst. Weist ein paar technische Merkwürdigkeiten auf wie z.B. ungültiges HTML in Templates, un-intuitive Begriffe wie Components, Scope, Directive, Providers, Host Elements. Erfordert Build-Pipeline.
React
Eher eine Bibliothek als ein Framework; implementiert ein komponentenbasiertes View-Modell mit One-Way-Binding (im Gegensatz zu Two-Way-Binding wie bei Angular oder Vue). Wird meist mit Redux (früher: Flux) oder MobX als Controller/Data Binding-Framework zu einem Full-Stack kombiniert. Recht schnell (aber es gibt schnellere inzwischen, siehe Preact oder Inferno); war das erste, das Virtual DOM unterstützt. Gut geeignet für Komponenten und Fragmente, die auf mehreren Seiten eingesetzt werden, also nicht zwingend nur für Single Page Applications (SPA). Erfordert eher viel JavaScript-Coding (ES6), um alles miteinander zu verbinden, was die Entwickler als positiv empfinden. Führt mit JSX einen HTML-Präprozessor und damit alternativen Templating-Ansatz ein, der HTML-ählichen Code und JavaScript mischt, was die Entwicklung erleichtert, aber von vielen als unsauber angesehen wird.
Vue.js/Vue2.js
Auch eher Bibliothek; schlank, schmal, schnell, verbreitet in China (Schöpfer ist der Ex-Googler chinesischer Abstammung Evan You) und in der PHP-Community gern verwendet als Ergänzung zum Backend-Framework Laravel. Das erklärt sich die gute Eignung für Backend-lastige Anwendungen (“backend first”), d.h. für existierende Backends, die die Frontend-Views vorgeben. Passt sehr gut zum ROCA-Ansatz, gut geeignet für kleinere Projekte/Teams mit wenig Frontend-Logik. Kompatibel mit ES5 (JavaScript auch für ältere Browser) und ES6 (aktueller Standard), erzeugt sauberen Code
Alle anderen
Viele weitere Frameworks wie z.B. Backbone, Ember.js, Meteor, Polymer oder Aurelia sind entweder Full-Stack-Frameworks oder beschränken sich auf einige zentrale Aspekte, so dass sie manchmal sogar sinnvoll miteinander kombinierbar sind (z.B. Meteor/React oder Angular/TypeScript). Einige behaupten, leichtgewichtiger/kleiner, leistungsfähiger oder schneller als andere zu sein. Da sich dies mit jedem neuen Framework oder Version ändern kann, und sich die grundsätzlichen Konzepte (s.o.) eigentlich nicht stark unterscheiden, wenn man mal von etwas weiter weg darauf schaut, sei hier die Grenze gezogen. Denn jedes weitere Framework lässt sich durch seine Gemeinsamkeiten bzw. Unterschiede zu einem der o.g. aktuell beliebten Systeme ausreichend gut beschreiben, und man findet diese “X vs. Y”-Betrachtungen zahlreich im Internet.
Die Sprachen
Ein Wort sei noch zu den verschiedenen Sprachen erlaubt, die für die Frontend-Entwicklung relevant sind. Neben dem “Good-old” JavaScript (damit ist i.d.R. alles einschließlich ECMAScript 5 gemeint), das nativ auch in älteren Browsern läuft, gibt es Sprachen, die zu ECMAScript kompilieren wie z.B. TypeScript, ClojureScript, CoffeScript, und der sich durch kontinuierliche Weiterentwicklung des ECMAScript (ES)-Standards immer weiter verbessernde Sprachumfang der Browser-JavaScript-Engines (siehe 3, 4).
Nach > 20 Jahren Erfahrung in der Software-Entwicklung bin ich hier zu der Erkenntnis gekommen, dass es schon sehr profunde Gründe geben muss, eine zusätzliche Schicht in der Architektur einzuführen, die die Komplexität erhöht und die Performance verschlechtert. Eine Sprache zu verwenden, die in eine andere, native Sprache kompiliert, nur um ein paar Prozent kleineren Source-Code, Zeilenumbrüche oder Tabs statt Klammern oder sonstigen “Syntactical Sugar” zu erhalten, ist Geschmackssache, und ich bin kein Fan davon.
Auch wenn TypeScript mit einem statischen Typ-System interessante Spracheelemente mitbringt, glaube ich, dass mit ES6 ein ausreichend reifer, leistungsfähiger und zudem nativer Sprachstandard vorhanden ist, der ältere Sprachvarianten verdrängen und zunehmend auch ganz oder teilweise auch die Aufgaben von Frameworks übernehmen wird.
Zusammenfassung
Abschließend lautet meine Bewertung, dass umfängliche Full-Stack-Frameworks wie Angular nur dort Sinn machen, wo man komplexe Anforderungen rein frontend-seitig als Single-Page-Applications umsetzen und in einer heterogenen Umgebung von Backend-Systemen arbeiten muss, auf die man wenig Einfluss hat.
React und ähnliche Bibliotheken bzw. Stacks geben einem mehr Freiheiten und sind auch für mehrseitige Anwendungen geeignet, bei denen der Schwerpunkt eher auf einer guten Komponenten-Bibliothek liegt. Die wachsende Beliebtheit von React etc. sorgt auch für eine gute Verfügbarkeit von Dokumentation und Entwicklern, was für eher langfristig angesetze Projekte wichtig ist.
Hat man dagegen eine gut durchdachte Architektur mit Backend-Services, die sich flexibel auch auf GUI-Bedürfnisse zuschneiden lassen, so macht es Sinn, die Geschäftslogik nur einmal und daher weitgehend Backend-seitig zu implementieren. Dann sind leichtgewichtige Frameworks wie Vue.js bzw. das neuere und schnellere Vue2.js ideal geeignet. Hier sollte man auch einmal den Blick auf das serverseitige Rendering von HTML setzen, das zu Unrecht verpönt ist.
Möchte man optimale Geschwindigkeit und Unabhängigkeit von Frameworks, dann ist man am besten ohne Framework bedient, denn alle Frameworks haben irgendwelche Nachteile (6). Der Ansatz, heute gleichbedeutend mit der Verwendung von ES6, manchmal auch Vanilla-JS genannt, ist keineswegs mehr nur etwas für Puristen und Performance-Junkies, sondern die Zukunft der Web-Frontend-Entwicklung und schon heute einsetzbar dank guter Polyfills für ältere Browser wie Babel (7). Und nichts spricht dagegen, sich für einzelne Aufgaben durch den Einsatz kleiner ES6-Erweiterungen das Leben einfacher zu machen.
Quellen und weiterführende Links:
2 https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176
3 https://kangax.github.io/compat-table/es6/
6 https://medium.com/@mattburgess/all-javascript-frameworks-are-terrible-e68d8865183e