Sechs Experten kommentieren aktuelle Entwicklungen im Web - Teil 2

JavaScript Expertencheck: Aktuelle Entwicklungen bei React, Angular, Vue.js
Keine Kommentare

Wir haben sechs Experten nach dem Status Quo der Webentwicklung befragt. Wie stellt sich aktuell die JavaScript-Szene dar? Welche Trends sind wichtig? Welche Herausforderungen gilt es zu meistern?

Im ersten  Teil unseres Expertenchecks ging es um aktuelle Trends und Herausforderungen in der Webentwicklung. In Teil 2 wollen wir uns die Szene der JavaScript Frameworks etwas genauer vornehmen. Außerdem sehen wir uns Techniken des Einsatzes von CSS und Sass an und klären, welchen Nutzen Ansätze wie OOCSS, SMACSS und BEM haben.

React, Angular, Vue.js

Entwickler: Betrachten wir die Szene der JavaScript-Frameworks: Insbesondere sind hier React, Angular und Vue.js momentan gesetzt. Nils, welche aktuellen Entwicklungen gibt es bei React? Momentan stehen wir bei Version 16 – wie geht es bei React 17 weiter?

Nils Hartmann: Die Versionierung von React ist relativ konservativ, und es gibt nur selten Releases, die sich in der Erhöhung der Major-Version widerspiegeln. React 16 ist nun mittlerweile schon fast ein Jahr alt, allerdings sind im Laufe des Jahres die Versionen 16.3 und 16.4 veröffentlicht worden, die einige interessante neue Features enthalten. So wurde mit 16.3 eine nun auch offiziell unterstützte Context-API vorgestellt, und in React 16.4 wurde Support für PointerEvents hinzugefügt. Alles in allem kann man sagen, dass sich React stetig, aber nicht im Eiltempo voran bewegt. Das liegt auch daran, dass neue Features ausreichend Stabilität haben sollen, bevor sie in ein Release aufgenommen werden. Außerdem wird viel Wert auf Abwärtskompatibilität gelegt.

Alles in allem kann man sagen, dass sich React stetig, aber nicht im Eiltempo voran bewegt.

Aktuell wird aber an zwei größeren neuen Features gearbeitet, die in einer Version 17 eventuell gegen Ende des Jahres veröffentlicht werden könnten (die React-Entwickler sind gewöhnlich sehr zurückhaltend, was das Ankündigen von konkreten Release-Nummern und -Erscheinungsdaten angeht). Beide Features zahlen auf eine verbesserte User Experience ein. Zum einen geht es darum, “unwichtige” Updates der UI unterbrechen zu können und “wichtigere” Updates vorzuziehen (“Time Slicing”). So kann zum Beispiel bei begrenzten CPU-Ressourcen verhindert werden, dass die Anwendung beispielsweise beim Darstellen eines Textes in einem Eingabefeld “ruckelt”, weil gerade an anderer Stelle Komponenten aktualisiert werden müssen. React würde in diesem Fall die Eingabe bzw. die Darstellung der Eingabe höher priorisieren und dafür andere Updates hinten anstellen.

Die JavaScript-Experten

 JavaScript Experte Nils Hartmann

Nils Hartmann – Softwarearchitekt bei EOS Technology Solutions

JavaScript-Experte - Jens Grochtdreis

Jens Grochtdreis – Gründer der webkrauts

JavaScript-Experte Karsten Sitterberg

Karsten Sitterberg – Freiberuflicher Angular-Experte, Kolumnist bei JAXenter

JavaScript-Expertin Yara Mayer

Yara Mayer – Expert Consultant bei evia
Tobias Struckmeier – Software Entwickler bei der Adesso AG

JavaScript-Experte Golo Roden

Golo Roden – Gründer und CTO der the native web GmbH

Das zweite Feature, “Suspense” erlaubt es, das Rendern von Komponenten innerhalb einer Hierarchie so lange zu unterbrechen, bis die zur Darstellung erforderlichen Daten (asynchron) geladen wurden. Sobald die Daten geladen sind, setzt React das Rendern ab der unterbrochenen Stelle automatisch fort. Damit wird es zum Beispiel sehr einfach, Nutzern der Anwendung einen Loading Indicator o.ä. einzublenden. Hiermit könnte aus meiner Sicht ein gerade für React-Neulinge schwieriges Thema, das Arbeiten mit asynchronen Daten-Zugriffen, vereinfacht werden.

Entwickler: Golo, auf welche Highlights freust du dich in React? 

Golo Roden: Eines der ganz großen Themen ist das asynchrone Rendern. Bislang blockiert ein Render-Vorgang die gesamte UI, was man bei komplexen Änderungen zu spüren bekommt, da die UI nur noch träge oder gar nicht mehr reagiert. Das asynchrone Rendern blockiert nicht mehr, weshalb die UI auch dann responsiv bleibt, wenn beispielsweise eine umfangreiche Komponente neu gezeichnet werden muss.

Das Feature ist also insbesondere in Hinblick auf die Performance der UI sehr interessant, erfordert aber teilweise neue APIs und zieht daher einige nicht mehr abwärtskompatible Änderungen nach sich. Beispielsweise entfallen einige Funktionen aus dem Lebenszyklus von Komponenten, da dieser zukünftig anders aufgebaut sein wird.

Beachtlich ist dabei aber, dass die Entwickler von React – wie bei bislang jeder Version – dafür sorgen, dass der Bruch nicht schlagartig von einem auf den anderen Tag erfolgt. Stattdessen werden die nicht mehr länger benötigten Funktionen als veraltet gekennzeichnet, so dass die Entwickler von Anwendungen ausreichend Zeit erhalten, um ihren Code anzupassen.

Das finde ich persönlich ein sehr sympathisches Vorgehen, da man nicht einfach nur vor vollendete Tatsachen gestellt wird, sondern sich nach und nach auf die Änderungen einstellen und sie adaptieren kann.

Entwickler: Tobias, was ist für dich gerade das Spannende an React? 

Tobias Struckmeier: Besonders spannend ist momentan das Context API, das demnächst herauskommt, also noch nicht final ist. Den Kontext, den ich schon jetzt in der React-Anwendung habe, kann ich mit diesem API weiter vereinheitlichen. Damit werden Schmerzen, die ich bisher mit dem Kontext hatte, beseitigt. Das wird auch Redux helfen, sich besser an die React-Komponenten zu binden.

Entwickler: Ein JavaScript-Framework, das momentan enormen Zuspruch findet, ist Vue.js. Wo liegen die Unterschiede zu React?

Tobias Struckmeier: Viele Konzepte, die man aus React kennt, findet man auch in Vue.js wieder. Ein großer Unterschied ist die Arbeit mit Templates. Während man bei React mit JSX arbeitet, kann man in Vue auch noch Templates benutzen, um sein HTML mehr von seinem Code zu trennen. So kennt man es ja bereits aus Angular und anderen Templatesprachen. Ich persönlich sehe den Vorteil von JSX, dass ich meinen Code und mein Template an der gleichen Stelle zusammen habe. Das ist natürlich Geschmackssache, aber da ist Vue tatsächlich ein wenig flexibler. Es gibt auch für Vue die Möglichkeit, mit JSX zu arbeiten. Dann sieht das schon sehr stark nach React aus. Ich würde also behaupten, dass ein Entwickler, der mit React klarkommt, auch schnell in Vue reinkommt.

Entwickler: Karsten – du bist Angular-Experte: Wo steht die Entwicklung von Angular gerade? Welche Neuerungen sind in Arbeit? 

Karsten Sitterberg: Vor kurzen wurde Angular Version 6.1 – und damit voraussichtlich die letzte 6-er Minor Version – released. Mit diesem Relese kommen zum Beispiel Unterstützung für die neueste TypeScript Version 2.9. Auch die offizielle Shadow Dom v.1 Spezifikation ist nun implementiert. Die wichtigste Neuerung bei Angular, die mit der nächsten Major-Version released werden soll, ist mit Sicherheit der neue Ivy Renderer. Mit dem Ivy Renderer wird die Art und Weise, wie Angular mit dem Browser interagiert, komplett verändert. Dies wird sich in besseren Tree-Shaking Eigenschaften zeigen, welche dann kleinere und schnellere Apps produzieren werden. Duch diese Verbesserungen wird der Ivy Renderer außerdem die Eigenschaften von Angular Elements – den Angular-Webkomponenten – verbessern, sodass diese unabhängig von äußeren Angular-Anwendungen werden.

Kostenlos: Das iJS React Cheat Sheet

Sie wollen mit React durchstarten?
Unser Cheatsheet zeigt Ihnen alle wichtigen Snippets auf einen Blick.
Jetzt kostenlos herunterladen!

Download for free

 

Angular Kickstart: von 0 auf 100

mit Christian Liebel (Thinktecture AG) und Peter Müller (Freelancer)

JavaScript für Softwareentwickler – für Einsteiger und Umsteiger

mit Yara Mayer (evia) und Sebastian Springer (MaibornWolff)

Webentwicklung mit CSS & Sass

Entwickler: Yara, dein Steckenpferd ist CSS. Leider wird CSS oftmals nicht so ernst genommen. Das sieht man etwa daran, dass CSS mitunter immer noch ans Ende einer aktuellen Datei geschrieben wird. Welche Unarten sind dir in deiner Praxis mit CSS noch so untergekommen?

Yara Mayer: Was ich am häufigsten sehe ist:

  • Klassen, die innerhalb eines Projektes keiner Strategie, keinem Standard oder Gesamtkonzept folgen
  • verkomplizierte Regeln und Abhängigkeiten, vor allem im Zusammenhang mit Responsiveness
  • die ständige Nutzung von fixen Breiten und Höhen
  • die Nicht-Nutzung von Variablen oder, am schlimmsten, wenn welche definiert, aber dann doch nicht immer benutzt werden.

Die Hauptgründe dafür sind fehlende Zeit, Kommunikation und/oder fehlendes Wissen bzw. Erfahrung.

Entwickler: Jens, du plädierst ja dafür CSS modular zu erstellen. Genügt es nicht, CSS als ein zentrales, monolithisches Artefakt zu sehen, das die Module einer Webseite mit einem einheitlichen Look & Feel versieht?

Es liegt im Eigeninteresse, das CSS in einzelnen Häppchen (Modulen) zu erstellen und von Projekt zu Projekt mitzunehmen.

Jens Grochtdreis: Kann man machen. Das genügt sicherlich für viele kleine Projekte und einzelkämpfende Kollegen. Aber ich gehe immer davon aus, dass man als Selbständiger und vor allem als Agentur viele unterschiedliche Projekte hat, die oft mit den gleichen oder ähnlichen Modulen bestritten werden. Wenn man nun also diese Module isoliert und sich so sein eigenes „Bootstrap“ schafft, hat man viel Arbeit und vor allem viel Testingaufwände gespart.

Man kann sie dann immer wieder in neuer Zusammenstellung verwenden. Außerdem fällt so die Arbeit im Team leichter, denn jeder Entwickler ist nur für sein Modul zuständig. Deshalb liegt es im Eigeninteresse, das CSS in einzelnen Häppchen (Modulen) zu erstellen und von Projekt zu Projekt mitzunehmen, wenn sie gebraucht werden. Präprozessoren wie Sass sind da sehr hilfreich, aber nicht notwendig.

Entwickler: À propos Sass. Die Kritik an Sass als Metasprache für CSS lautet ja häufig, dass durch den Einsatz eines Präprozessors der Entwicklungsprozess schwergewichtiger wird. Sind solche Einwände berechtigt?

Jens Grochtdreis: Da man mit Sass in gewissem Umfang programmieren kann, sind Entwickler immer in der Gefahr, zu viel Energie in die „Vereinfachung“ des Entwicklungsprozesses zu stecken. Gerade zu Beginn meiner Beschäftigung mit Sass habe ich diesen Fehler oft genug selber gemacht. Alles musste in ein Mixin, das auch schon mal zehn Parameter hatte. Das war nicht handhabbar. Aber die Erstellung machte Spaß. Doch das war ja eigentlich nicht Ziel der Übung.

Ich kenne ein Projekt, bei dem ich den Aufbau der Sass-Files definitiv nicht verstehe. Da wird u.a. mit JSON gearbeitet und sehr viel in Mixins ausgelagert, die manchmal nur eine einzige Verwendung finden, aber genutzt werden, um einen einfachen Bezug zu Breakpoints zu bekommen. Solche Sass-Projekte sind am Ende von Quereinsteigern nicht einfach und nur unter großem Zeitaufwand zu verstehen. Ich habe den Eindruck, dass man sich damit weniger die Arbeit vereinfacht, als das eigene Ego streichelt.

In dieser Form finde ich Sass nur bedingt hilfreich. Aber ich möchte trotz allem nicht mehr auf Sass verzichten. Ich habe vor zwei Jahren einmal eine kleine Applikation – einen Adventskalender – ohne Sass erstellt. Es fühlte sich falsch und umständlich an.

Yara Mayer: Ich würde eher sagen, dass es nicht schadet, es sei denn, man hat aus irgendeinem Grund nicht die Möglichkeit, einen Preprozessor zu benutzen. Davon abgesehen gibt es ein paar Gründe, warum es tatsächlich sinnvoll ist: Mixins (mit Parametern), Functions, Autoprefixing…

Entwickler: Momentan werden Ansätze wie OOCSS, SMACSS und BEM diskutiert. Wann sind diese sinnvoll?

Jens Grochtdreis: OOCSS ist mehr eine grundlegende Skizze, wie man gedanklich an ein umfangreiches CSS herangeht und Module im HTML auszeichnet. Es ist nie ausführlich ausformuliert worden, inspirierte aber alle anderen Ansätze. Interessanter finde ich SMACSS und BEM.

Inhaltlich fand ich SMACSS schon immer Klasse, vor allem weil dessen „Erfinder“ Jonathan Snook seine Regeln nicht als absolute Gesetze, sondern als grobe Orientierungen verstanden hat. BEM wiederum hat den Vorteil, dass es ein striktes, logisches, stringentes System ist, das für große und sehr große Projekte optimiert ist. Es ist mittlerweile eine Art Industriestandard, der von sehr vielen Entwickler verstanden und befolgt wird. Das erleichtert das Verständnis eines Projektes, in das man hineinkommt. 

Yara Mayer: Ein paar grobe Konzepte aus diesen Ansätzen sind, meiner Meinung nach, immer wichtig. Der Rest hängt davon ab, was für ein Projekt man gerade entwickelt. Wenn es Themes enthalten soll, dann gerne etwas wie OOCSS oder SMACSS. Aber auch dafür gibt es andere Lösungen, die durch einen Preprozessor oder CSS-Variablen ermöglicht werden. Viel entscheidender ist für mich, dass man von Anfang bis Ende die gleiche Strategie verwendet.

Im dritten Teil unseres JavaScript-Checks sehen wir uns an, mit welchen Trends sich die Experten in ihren Projekten beschäftigen. Bleiben Sie dran!

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -