Rückblick: React Amsterdam 2016

Diesen Monat durfte ich die erste Ausgabe der neuen JavaScript-Konferenz React Amsterdam miterleben. Die Konferenz ist aus dem ebenfalls sehr jungen React Meetup in Amsterdam entstanden, welches im Februar sein einjähriges Bestehen feierte. Trotz der sehr kurzen Vorlaufzeit haben die OrganisatorInnen ein interessantes Line-Up aus 15 Speakern in einer mindestens ebenso interessanten Location auf die Beine gestellt.

Die Konferenz fand in der Szene-Location „Pllek“ auf dem Gelände der ehemaligen NDSM Schiffswerft statt, wo in mitten von Schiffscontainern, Sandstrand und Sonnenliegen trotz des wechselhaften Wetters beinahe Nordsee-Feeling aufkam. Vollständig ausgebucht war es leider zuweilen etwas eng in der Vortragshalle und die Sitzgelegenheiten wirkten doch sehr provisorisch, das tat der Qualität der jeweils 30-minütigen Vorträge allerdings keinen Abbruch. Die Talks wurden auf Video aufgezeichnet und auf YouTube veröffentlicht.

Keynote: Liberty Global

Den Auftakt machte ein Vice President des Hauptsponsors der Konferenz, Liberty Global, dem Mutterkonzern der deutschen Unitymedia. Neben vielen lobenden Worten für die Konferenz selber und dem Versprechen, dass React Amsterdam nächstes Jahr noch größer und besser sein wird, wurden ein paar Einblicke in das Verhältnis zwischen dem Konzern und React. Liberty Global habe über die Jahre einen Wandel erfahren, das Unternehmen verstehe sich inzwischen nicht mehr nur als Internet- und Telekommunikationsanbieter, sondern vor allem als Software-Unternehmen.

Interessante Take-Home-Message: die Oberfläche der Horizon-Box wurde von Liberty Global vollständig in React umgesetzt, der Konzern sehe React als die Zukunft der UI-Entwicklung und Amsterdam solle die (europäische) Hauptstadt von React werden. Tatsächlich seien in und rund um Amsterdam viele Startups angesiedelt, die in ihren Anwendungen auf React setzen.

Migrating Safely to React

Slide in einem Talk: "Solve real problems"
Die wahrscheinlich wichtigste Message von React Amsterdam: „Solve real problems“ / „Löst echte Probleme“

(Video/Slides) Jamis Charles berichtete über die Migration von Backbone zu React und Redux bei PayPal. Das größte Problem bei Backbone sei das Debugging gewesen, da durch diverse Abstraktionen und mehrschichtige Views häufig nicht nachvollziehbar sei, an welcher Stelle sich die leider recht häufigen State-Bugs eingeschlichen haben. Ein weiterer Gewinn bei der Migration zu React sei, dass React es einfacher mache Features oder Widgets isoliert zu implementieren, ohne den bestehenden Code vollständig neu schreiben zu müssen. Dadurch sei es möglich ein Projekt inkrementell nach React zu portieren, statt die gesamte Entwicklung für ein Rewrite auf Eis zu legen. Eine Besonderheit hierbei sind sicherlich die zahlreichen „escape hatches“ (Notausgänge), die es ermöglichen, Legacy-Code von React abgeschirmt einzubetten.

Die Haupterkenntnis scheint mir jedoch der Unterschied zwischen „simple“ (simpel im Gegensatz zu komplex) und „easy“ (einfach im Gegensatz zu schwierig) zu sein: viele Frameworks und Libraries locken damit, einfach zu sein, und ermöglichen einen sehr leichten Einstieg. Dies geschehe jedoch meist auf Kosten der Komplexität; Projekte würden im Laufe der Entwicklung zunehmend komplexer und schwieriger zu warten und weiterzuentwickeln. React hingegen ist konzeptionell extremst simpel, auch wenn dies mit einer anspruchsvolleren Lernkurve einhergeht. Die Produktivität und Wartbarkeit sei bei simplen Lösungen mittel- und langfrastig deutlich stärker, als bei „einfachen“.

Schlussworte: man solle so viel Logik wie möglich in „vanilla JS“, also ohne Frameworks, umsetzen, da dies zu Code führt, der nicht von Framework-Wechseln betroffen sein wird. React mache dies mit Redux durch das strenge State-Handling sehr einfach. Außerdem die Ermahnung „Solve real problems“ („Löst echte Probleme“): obwohl die vollständige Migration zu React und Redux das Endziel ist, hat PayPal immernoch einen großen Teil des alten Backbone-Codes behalten. Andere Dinge sind momentan wichtiger bis es echte Gründe gibt, den alten Code zu überführen (z.B. Feature Requests, Bugs, etc).

Building Loveable UIs

(Video/Slides) Henrique Alves präsentierte einen gewagten Ansatz, Styling mit React-Komponenten umzusetzen. Ausgehend von ähnlichen Ideen, wie Atomic Design, sollen Komponenten auf Basis von einfacheren Bauteilen definiert werden. Anstatt atomare CSS-Klassen dabei jedoch eins-zu-eins in Komponenten zu übersetzen, sieht sein Ansatz vor, auf Inline Styles (also CSS in HTML „style“-Attributen) aufzubauen. Vorteil: Details wie Farben und Schriftgrößen werden dadurch parametrisierbar, das Styling bleibt an einem Platz (genauer: in den jeweiligen Komponenten statt in CSS-Dateien). Dies sei außerdem konsequent, da zukünftige Erweiterung in React wie Layoutsysteme und Animationen ohnehin auf Inline Styles aufbauen werden müssen.

Persönlich denke ich, dass CSS als Sprache besser zur Definition von Stylesheets geeignet ist, als Object-Literals in JavaScript. Moderne Ansätze wie CSS Modules und Sprach-Features wie calc (was seit IE9 in allen modernen Browsern unterstützt wird) sowie Präprozessoren wie PostCSS (oder Sass, Less, Stylus, Styl, etc) lösen bereits die meisten Probleme, die Inline Styles (oder Style-Generatoren wie JSS) zu lösen versuchen. Auch der Vergleich zu JSX scheint nicht ganz gerechtfertigt: trotz der oberflächlichen Ähnlichkeit zu HTML handelt es sich bei JSX um eine Syntax zur Instanzierung von Komponenten; dass einzelne Komponenten dabei DOM-Elementen entsprechen, ist ein reines Implementationsdetail (was React Native u.ä. beweisen).

JavaScript Style Sheets

Plüschiger Orca mit Katzenkopf und der Aufschrift "#fatigue" sowie dem React Amsterdam Logo.
Das inoffizielle Maskottchen von React Amsterdam 2016: der Hashtag bezieht sich auf die Erschöpfung, mit dem ständigen Wandel des JavaScript-Ökosystems mitzuhalten (und auf Inline Styles).

(Video/Slides) Oleg Slobodskoi präsentierte seine Library JSS, welche es ermöglicht Styles in JavaScript zu definieren, dabei aber trotzdem CSS-Stylesheets für den Browser zu generieren. Die Probleme, die JSS lösen möchte, sind ähnliche, wie die des Vorredners: CSS-Klassen verwenden einen gemeinsamen globalen Namespace, Änderungen in der Reihenfolge führen zu unvorhergesehenem Verhalten und die Kombination verschiedener Klassen innerhalb eines Elements kann zu impliziten Abhängigkeiten und Konflikten führen.

Besonderer Vorteil von JSS: obwohl als Output CSS generiert wird, profitieren JSS-Styles von der selben Dead Code Elimination, wie sonstiges JavaScript. Bedeutet im Klartext, dass es nicht mehr dazu kommen kann, dass Stylesheets stetig wachsen, weil unnütze Klassen herumgeschleppt werden, von denen keiner weis, ob sie nicht vielleicht doch noch gebraucht werden. Gegenüber reinen Inline Styles ist außerdem noch zu erwähnen, dass JSS CSS-Features wie Mediaqueries unterstützt, die sonst nur in „echtem“ CSS verfügbar sind. Lobenswert auch der abschließende Appell: JSS sei nicht für jeden die richtige Lösung, man solle offen gegenüber Alternativen bleiben; „Use tools that solve your problems“ (Verwendet Werkzeuge, die eure Probleme lösen).

Mastering Server-rendered Apps

(Video/Slides) Sven Anders Robbestad, Autor von ReactJS Blueprints, ergriff Partei für das häufig vernachlässigte Server-Side-Rendering von React-Anwendungen. Server-Side-Rendering sei nicht nur der Ursprung von Web-Anwendungen (schließlich wurde sogar JavaScript ursprünglich von Netscape auch schon serverseitig verwendet), sondern sei auch zukünftig ein wichtiger Bestandteil des Webs. Client-seitiger Rendering-Code greife selbst bei schnellen Internetverbindungen erst spät und bei schlechten Verbindungen oder dem Einsatz von Script-Blockern garnicht. In diesen Situationen könne severseitig gerendertes React das Abspringen von sonst gefrusteten Nutzern verhindern.

React ist von Natur aus in der Lage, Komponenten serverseitig zu rendern — egal, ob wir die Anwendungen dann „universal“, „isomorph“ oder (wie vom Speaker vorgeschlagen) „shared“ nennen. Das eigentliche Problem, welches im Talk leider nicht genauer erwähnt wurde, ist es, vor dem (einmaligen) Rendern zu bestimmen, welche Daten vorgeladen werden müssen, um den vollständigen State bieten zu können, den die Anwendung zum vollständigen Rendern benötigt. Viele Libraries im React-Ökosystem setzen dabei leider auf das Nachladen von kritischen Daten, was beim serverseitigen Rendern bedeutet, dass für manche Inhalte nur Ladeseiten dargestellt werden können. Karolina Szczur, Co-Organisatorin von JSConf EU, bringt es auf den Punkt: leere Seiten mit Warnhinweisen oder sich ewig drehende Ladebalken sind nicht akzeptabel. React erlaubt es uns, diese Probleme zu lösen.

React Native Architecture Overview

Architekturdiagramm von React Native
Die Architektur von React Native aus Sicht der Implementation: für Anfänger vielleicht doch ein wenig abschreckend.

(Video/Slides) Tadeu Zagallo aus dem React Native Team gab eine abstrakte Einführung in die Implementation von React Native. Es wurde am Beispiel einer minimalistischen React Native App für iOS erklärt, wie die einzelnen Teile ineinander greifen, von der JavaScript-VM über die Layout-Engine bis hin zu UIKit und der Native-Bridge, über welche JavaScript-Code mit nativem Code kommuniziert. Der Talk war im vergleich zu den anderen Vorträgen auf der React Amsterdam sicherlich eher für Forgeschrittene React-Anwender gedacht, die zumindest schon einmal eine Einführung in React Native gesehen haben; Neulinge im Publikum waren damit zum Teil leider etwas überfordert.

Meine persönliche Erkenntnis: es ist durchaus möglich mit sehr wenig Objective-C- oder Java-Code native Komponenten zu schreiben, auch wenn definitiv tiefere Kenntnisse der jeweiligen Programmiersprache und APIs von Vorteil sind. Der Einstieg für Native-Entwickler, die bereits JavaScript beherschen, scheint deutlich einfacher, als gedacht.

Building Reactive GraphQL Apps with Apollo

(Video/Slides) Martijn Walraven von Meteor präsentierte das GraphQL-Framework Apollo. Die Server-Komponente scheint zwar in erster Linie für Meteor-Nutzer relevant, der Client scheint jedoch auch mit anderen GraphQL-Servern kompatibel zu sein. Ein unerwartetes Eingeständnis in diesem Talk war, dass Meteor sich in näherer Vergangenheit von einem Großteil der Eigenentwicklungen verabschiedet und diese durch „gängigere“ Tools ersetzt hat (wie z.B. der Wechsel von Blaze zu React, oder der Wechsel von Atmosphere zu NPM) und sich dadurch die Frage stelle „was dann von Meteor noch bleibe“. Mit dem Wechsel von einer direkten MongoDB-Integration zu GraphQL mit Apollo scheint die Antwort „nicht viel“.

Auch wenn ich die Zukunft von GraphQL näher an der Datenbank sehe, scheint Apollo eine interessante Alternative zu anderen GraphQL-Lösungen wie Relay. Insbesondere bei der Integration von mehreren heterogenen Datenquellen (z.B. MongoDB als Dokumentdatenbank, Redis für Session-Daten, Influx für Ereignisse) kann es sinnvoll sein, mit GraphQL eine gemeinsame, einheitliche API anzubieten. Und laut den Entwicklern ist Apollo vollständig unabhängig von Meteor selbst. Dass der Talk auf der React Amsterdam ohne den üblichen Meteor-Hype auskam, sehe ich als positives Zeichen.

React for Game Development

(Video/Slides) Johannes Stein zeigte einen Einblick in seine Experimente, einfache Spiele für Game Jams mit React zu entwickeln. Nach einer kurzen Einführung in die Unterschiede zwischen Event-basierten und Loop-basierten Spielen gab es ein paar Beispiele dafür, wie sich Konzepte aus der Spielentwicklung in React umsetzen lassen. Das Hauptargument für den Einsatz von React statt den üblichen Game-Frameworks, wie Phaser und co, war jedoch die einfache Regel „Use the tools you’re familiar with“ (Verwendet die Tools, mit denen ihr euch auskennt). Dass React es dann einfach macht, ein Browserspiel auf mobile Plattformen zu portieren, ist eher ein netter Nebeneffekt.

React Component Library

(Video/Slides) Robert Haritonov von Liberty Global gab in diesem Lightning Talk einen kurzen Einblick in Komponentenbibliotheken als Werkzeug um wiederverwendbare Komponenten zu bauen. Vorgestellt wurden React Styleguidist, React Storybook und Source.

React WebGL in Liberty Global

(Video) Denis Radin (ebenfalls von Liberty Global) zeigte in diesem Lightning Talk, wie Liberty Global mit React Liberty einen eigenen React-Renderer verwendet, der wahlweise ReactDOM oder WebGL als Ausgabe unterstützt. Das Horizon-UI wird im Web-Interface regulär über ReactDOM gerendert. Auf dem TV-Interface werden die Komponenten stattdessen mit WebGL dargestellt, was eine bessere Nutzung der Hardware und des entsprechend optimierten Embedded-Browsers ermöglicht.

Testing React Applications

(Video/Slides) Jack Franklin gab eine Einführung in das Testen von React-Komponenten. Neben dem erneuten Hinweis darauf, die meiste Logik außerhalb von Frameworks und React-Komponenten möglichst simpel zu halten, wurde das React-Testing-Tool Enzyme vorgestellt, welches durch Shallow Rendering GUI-Tests drastisch vereinfachen kann. Der größte Teil des Vortrags befasste sich damit, die Funktionalität von Enzyme zu rekonstruieren, um den Mehrwert des Tools darzustellen.

"TweetCube"-Würfel als Projektionsfläche für Live-Tweets und Avatare.
Der TweetCube neben der Bühne lenkt mit Live-Tweets unter dem Hashtag #reactamsterdam von den Talks ab.

Introducing and Implementing React at Coolblue

(Video) Paul van Dam von Coolblue (einem weiteren Sponsor) erzählte von der Erfahrung mit React bei Coolblue. Die Erkenntnisse spiegelten im Wesentlichen die der Vorredner wieder. Quintessenz: React ist toll.

Transparent Reactive Programming and Mutable Data Structures

(Video/Slides) Michel Weststrate stellte MobX als Alternative zu Redux vor. Während Redux auf Immutabilität, also sich nicht verändernde Datenstrukturen, und explizite Mutationen durch Action Creator, Actions und Reducer baut, verspricht MobX ähnlich wie AngularJS 1 mutierbaren State selbst zu verwalten. Das geschieht ähnlich wie bei Knockout.js mit Hilfe von Observables und Computed Observables, welche in View Models über Decorator definiert werden.

An dieser Stelle fühlte ich mich an den ersten Talk und den Unterschied zwischen „simple“ und „easy“ erinnert: MobX verspricht „easy“ zu sein, in dem es mit einer minimalen quasi unsichtbaren API auskommt; Redux hingegen ist „simple“, obwohl es unter Umständen ein wenig dauern kann, bis man das Zusammenspiel zwischen State, Action Creators, Actions und Reducern vollständig durchblickt lässt sich die grobe Implementation in 100 Zeilen nachbauen und die Trennung von Reducern und Action Creators führt automatisch zu testbarerem und wiederverwendbarerem Code.

Solving a Tooling Problem for React Native

(Video/Slides) Alexey Kureev und Mike Grabowski, die Maintainer des React Native Package Managers RNPM, erklärten die Probleme, die es bisher mit dem Tooling um React Native herum gibt: warum RNPM existiert (weil Native-Dependencies komplexer sind als reine JavaScript-Dependencies) und dass es nervt, dass man darum mit drei verschiedenen Tools arbeiten muss: NPM, RNPM und react-native-cli. Als Ergebnis gab es eine bedeutende Ankündigung für alle React Native Nutzer: RNPM wird zukünftig ganz offiziell Teil von react-native-cli sein.

Fazit

Alan
Alan

Ein gelungener Auftakt für eine junge Konferenz mit anspruchsvollen Tech-Talks. Einzig negativ waren die auf Dauer doch sehr unbequemen Sitzmöglichkeiten und der geringe Platz während den Pausen: da die gesamte Veranstaltung in einer Halle stattfand, handelte es sich bei einigen Sitzen um Klappstühle, die für die Pausen beiseite geschafft wurden. Ich freue mich jedenfalls auf React Amsterdam 2017 und bin gespannt, was die OrganisatorInnen auf die Beine stellen, wenn sie ein ganzes Jahr für die Planung Zeit haben.