CSS: Mit planvollem Vorgehen braucht es kein Framework

Sollte man für die CSS-Gestaltung auf ein Framework setzen oder lieber alles von Hand schreiben?

Peter Kröner: Anders als bei JavaScript scheint mir das eine falsche Dichotomie zu sein. Eine fluffige Single-Page-JS-App ist ohne Framework nicht mit vertretbarem Aufwand zu bauen, aber bei CSS ist das anders. Mit modernen Standards wie Grid könnte jeder, der nur ein klein wenig CSS-Wissen hat, große Teile vieler Layout-Frameworks ersetzen. Mit etwas HTML-Kenntnis und planvollem Vorgehen lassen sich auch ganze UI-Elemente bauen – nicht jeder Button muss von Grund auf neu aus Divs zusammengeschraubt werden. So lange sich aber Frontend-Entwickler weigern, Dinge wie „planvolles Vorgehen“ neben JS auch auf CSS anzuwenden, wird der Siegeszug der CSS-Frameworks und Buttons-Aus-Divs-Reimplementierern weitergehen.

Erst vor kurzem wurde über „CSS X“ diskutiert, also darüber, dass es problematisch ist, CSS in seinem derzeitigen modularisierten Zustand in Versionen zu fassen, so wie es in der Vergangenheit gehandhabt wurde. Wie ist deine Meinung dazu: Braucht es ein definiertes CSS4 für die Weiterentwicklung des Standards oder sollte es bei der bisherigen Vorgehensweise bleiben, dass der Fokus auf einzelnen Modulen liegt?

Kröner: Bei komplexen Webstandards gibt es in meinen Augen genau zwei Möglichkeiten, Spezifikationen so zu pflegen, dass sie mit der Realität Schritt halten. Möglichkeit 1 ist eine große Spezifikation für alles, die dann aber entweder offiziell unversioniert ist wie WHATWG HTML, oder wie ECMAScript so mikroskopisch kleine Updates publiziert, dass sie de facto unversioniert ist. Oder ein komplexer Webstandard wie CSS wird modularisiert und die einzelnen Module werden als einzelne, versionierte Standards publiziert. Einen dritten Weg gibt es nicht; eine große Spec ist ein zu schwerfälliges Dickschiff, als dass sie versioniert werden könnte.

Eine große Spec ist ein zu schwerfälliges Dickschiff, als dass sie versioniert werden könnte.

Immer, wenn das in der Vergangenheit versucht wurde, hat das Ergebnis entweder niemanden interessiert (W3C HTML5) oder es kam gar nicht erst zu einem Ergebnis (CSS 2, ECMAScript 4). Es wäre sicher denkbar, den CSS-Arbeitsprozess vom Modulsystem auf eine Riesen-Spec namens CSS4 umzustellen, aber dann wird die Zahl im Namen, genau wie bei HTML5, nicht oder zumindest nicht lange eine Versionsnummer sein. Webtechnologien sind so komplex, dass wir die Wahl zwischen klaren, verabschiedeten Versionsnummern oder einheitlich-monolithischen Specs haben, aber beides auf einmal hat es bisher nie gegeben. Und mir fehlt die Phantasie, um mir auszumalen, warum das heute anders sein soll. Zumal es ja kein echtes Problem gibt, an neuen Features in JS, HTML und CSS herrscht kein Mangel. Jede Webtechnologie kann nach ihrer eigenen Façon spezifiziert werden.

Angular: Ivy – eine große Neuerung ohne Breaking Changes

Die fertige Fassung von Ivy ist jetzt bereits in der 2. Major-Version von Angular enthalten. Welche Praxiserfahrungen gibt es inzwischen mit dem neuen Compiler?

Christian Liebel: In den Projekten, die ich betreut habe, hat man vom Ivy-Umstieg relativ wenig gemerkt. Es gab weder größere Probleme noch wird auf eines der Ivy-Features gewartet. Insofern gestaltete sich dies bei mir sehr transparent.

Manfred Steyer: In erster Linie merkt man nur, dass die Bundles kleiner werden. Gerade sehr kleine und sehr große Projekte profitieren davon am meisten. Daneben kann man die entryComponents nun weglassen und Komponenten per Lazy Loading laden (früher konnte man nur ganze Module Lazy laden).

Ansonsten merkt man wenig von Ivy, weil es sich noch nicht bis zum öffentlichen API von Angular durchschlägt. Das war ja das große Ziel von Angular 9: Die Einführung von Ivy sollte zu keinen Breaking Changes führen. Da Aufräumen im Fokus von Angular 10 stand, hat sich in Sachen öffentlichem API auch nichts getan. Ich habe da große Hoffnungen für Version 11 und danach, weil das Potential von Ivy doch groß ist und mit einigen Ideen im Hinterkopf konzipiert wurde.

Wenn du einen Wunsch frei hättest, was würdest du dir für die künftige Entwicklung von Angular wünschen?

Liebel: Ich wünsche mir, dass das Tooling aus dem CLI-Umfang wieder etwas aufgefrischt wird: Protractor ist beispielsweise zwischenzeitlich etwas angestaubt und ESLint müsste eingeführt werden.

Steyer: Ich würde gerne über das öffentliche API jene Dinge, die Ivy bereits heute unter der Motorhaube kann, nutzen können. Dazu zählen Standalone-Komponenten, also Komponenten, die ohne Angular-Module auskommen, aber auch dynamische Komponenten und Komponenten höherer Ordnung. Auch ein (sinnvolles) Arbeiten ohne zone.js wäre interessant und könnte sich positiv auf die Performance auswirken. Daneben wäre es cool, wenn Angular Elements noch kleinere Web-Component-Bundles erzeugen würde. Ivy würde das prinzipiell erlauben, wie erste Experimente zeigen.

Ich würde gerne über das öffentliche API jene Dinge, die Ivy bereits heute unter der Motorhaube kann, nutzen können.

Fullstack: Drei Meilensteine auf dem Weg von JavaScript

JavaScript war ja nicht „von Anfang an“ als Sprache gedacht, mit der man in die komplexen Bereiche vorstoßen kann, die heute als Fullstack Development bezeichnet werden. Was war die wichtigste Veränderung an der Sprache, die dazu führte, dass das heute möglich ist?

Thorsten Hans: Betrachte ich den Siegeszug von JavaScript, so kristallisieren sich für mich persönlich drei wichtige Meilensteine heraus. Als ersten Meilenstein sehe ich Apples Entscheidung, keine Plug-ins wie Adobe Flash oder Microsoft Silverlight auf iPhones und iPads zuzulassen. Viele Softwareunternehmen mussten neue Wege finden, um ihre Dienste und Anwendungen auf mobile Plattformen bereitzustellen. Native Anwendungen zu implementieren ist zwar naheliegend gewesen, allerdings erlaubte lediglich JavaScript den Betrieb einer Anwendung (mit homogener Codebasis) auf allen mobilen Betriebssystemen und im Web-Browser.

Als zweiten Meilenstein gilt es ganz klar Node.js hervorzuheben. Node.js hat JavaScript den Weg auf die Server geebnet. Viele Teams, die JavaScript zuvor nur belächelt hatten, beschäftigten sich auf einmal mit der Sprache und der Möglichkeit, effiziente Backend-Dienste mit JavaScript auf Basis von Node.js zu realisieren. Das Ökosystem rund um Node.js wuchs rasant, Teams konnten bereits früh aus vielen öffentlichen Paketen wählen und hatten dank npm eine zentrale Anlaufstelle.

Erst mit der Verfügbarkeit von SPA-Frameworks wurde der professionelle Einsatz von JavaScript im Frontend für viele Teams interessant.

Den dritten Meilenstein bilden Single Page Application (SPA) Frameworks wie Angular, React, und Vue.js. Sie erlauben es, komplexe Anwendungen im Browser zu realisieren und Rechenkapazitäten der Clients zu nutzen. Erst mit der Verfügbarkeit von SPA-Frameworks wurde der professionelle Einsatz von JavaScript im Frontend für viele Teams interessant. Insbesondere im direkten Vergleich zu einer Herangehensweise mit purem JavaScript bestechen die Frameworks indem sie viele Fragen des alltäglichen Gebrauches beantworten. Framework-Anbieter liefern in der Regel ein eigenes Command Line Interface (CLI), das viele komplexe Workflows für den Anwender vereinfacht. Jedes der populären SPA-Frameworks verfügt über sehr gute Dokumentation – sowohl für Neueinsteiger als auch für Profis. SPA-Frameworks bieten darüber hinaus einfache Lösungsansätze für wiederkehrende Problemstellungen unter Verwendung etablierter Patterns der Softwareentwicklung.

Und wo liegt heute die größte Hürde, wenn man JavaScript in einen Kontext einbinden möchte, der klassisch eher von anderen Sprachen geprägt ist?

Hans: Basierend auf meinen Projekterfahrungen ist die größte Hürde das offene JavaScript-Paket-Universum rund um npm. Viele Unternehmen müssen wissen, welche Abhängigkeiten in ihren Softwareprojekten verwendet werden, um deren Lizenzen zu validieren und den Drittanbieter-Code einer kontinuierlichen Sicherheitsprüfung zu unterziehen. Natürlich gibt es bereits professionelle Dienste, die Abhängigkeiten überwachen, scannen und validieren können, allerdings ist dies – meiner Meinung nach – immer noch eine der größten Hürden, wenn es darum geht mit JavaScript neue Umgebungen, insbesondere im Enterprise-Kontext, zu adressieren.

Node und Deno: Eine ideale Mischung?

Deno liegt jetzt in v1.0 vor und hat somit erstmalig produktionsreife erreicht. Deno könnte zum Disruptor im Bereich des serverseitigen JavaScript werden – oder auch nicht: Was ist deine Prognose?

Golo Roden: Den Grundstein für Deno hat Ryan Dahl, der auch Node.js ursprünglich entwickelt hat, in seinem Vortrag 10 Things I Regret About Node.js auf der JSConf EU 2018 gelegt. Einige seiner Kritikpunkte haben sich überlebt, so sind beispielsweise Promises unter Node.js heutzutage überhaupt kein Problem mehr. Gut gefällt mir an Deno allerdings die Idee, die Sandbox von V8 auch auf den Server zu übernehmen, so dass Code nicht mehr ungefragt auf das ganze System zugreifen darf. Auch schön ist, dass Deno zahlreiche Werkzeuge bereits integriert enthält, beispielsweise zum Formatieren und Analysieren von Code. Ob das ausreicht, um eine signifikante Delle in das Node.js-Universum zu schlagen, wage ich allerdings zu bezweifeln – zumal Node.js ja auch stetig weiterentwickelt wird. Dennoch ist Deno ein spannendes Projekt, das man im Blick behalten sollte.

Wenn du dir was aussuchen könntest, welches Feature sollte in Node möglichst bald verfügbar sein?

Roden:Tatsächlich würde ich mir eine Mischung aus Node.js und Deno wünschen: Die Sandbox, die integrierten Werkzeuge für Codeformatierung und -analyse, und native Unterstützung für TypeScript wären hier meine Favoriten. Wobei die Unterstützung für TypeScript eigentlich bei V8 ansetzen müsste, denn auch Deno kompiliert unter der Haube nach JavaScript. Worauf ich bei Deno hingegen gut verzichten kann, ist der Ansatz, wie Module gehandhabt werden – dass dort verwendete Modell des Vendorings mochte ich schon in Go nicht, und auch wenn ich die Beweggründe für eine Entkopplung von npm verstehen kann, ist das für mich keine gangbare Option. Wie gesagt, letztlich wäre eine Mischung aus beidem ideal.

Ich würde mir eine Mischung aus Node.js und Deno wünschen: Die Sandbox, die integrierten Werkzeuge für Codeformatierung und -analyse, und native Unterstützung für TypeScript wären hier meine Favoriten.

React: Weniger Wartezeiten für den Anwender

Das React-Team arbeitet derzeit am Concurrent Mode und Suspense. Das dürften zwei der größten kommenden Neuerungen werden. Worum geht es da?

Sebastian Springer: Der Concurrent Mode greift in den Rendering-Prozess von React ein und macht es möglich, den Benutzern ein noch besseres Erlebnis zu präsentieren. So können beispielsweise Informationen direkt dargestellt werden, ohne dass ein aufwändiger Renderprozess erst abgeschlossen werden muss. Oder die Übergänge zwischen zwei Sichten in einer Applikation können so gestaltet werden, dass die neue Sicht erst dargestellt wird, wenn alle Daten vorhanden sind.

Sowohl Suspense als auch der Concurrent Mode zielen darauf ab, dem Benutzer eine möglichst schnelle Rückmeldung zu geben.

Das Suspense-Feature gliedert sich in zwei Teile: Das ältere Suspense for Code Splitting dient dazu, Komponenten nachzuladen und in der Zwischenzeit einen Platzhalter zu rendern. Suspense for Data Fetching geht noch einen Schritt weiter und kann diese Platzhalter auch beim Laden von Daten anzeigen. Sowohl Suspense als auch der Concurrent Mode zielen darauf ab, dem Benutzer eine möglichst schnelle Rückmeldung zu geben und die Zeiten, in denen nichts von der Applikation zu sehen ist, weil React gerade rendert, auf ein absolutes Minimum zu reduzieren.

Was ist der wichtigste Tipp, den du Einsteigern in die Arbeit mit React an die Hand geben möchtest?

Springer: Schafft euch das, was React nicht bietet, also eine konsistente Struktur für eure Applikation, selbst. React ist dynamisch und flexibel und lässt einem Entwickler sehr viele Freiheiten. Wird eine Applikation größer, kann sich das allerdings rächen. Deshalb sollte man schon zu Beginn der Entwicklung einen groben Plan haben. Das betrifft sowohl die Gestaltung von Komponenten als auch den Einsatz von Entwurfsmustern und geht bis hin zur Benennung von Dateien und deren Platzierung in Verzeichnissen.

Ansonsten bleibt nur: Offen bleiben und viel ausprobieren.

Vielen Dank für eure Antworten!

Die Fragen stellte Ann-Cathrin Klose.