React ist eines der beliebtesten Frontend-Frameworks für JavaScript-Projekte. Jahr für Jahr findet es sich auf den vordersten Plätzen der am häufigsten genutzten JavaScript-Frameworks! Was macht React aber so beliebt? Wie hat sich React in den letzten Jahren weiter entwickelt? Und was fehlt noch, um das Framework noch besser zu machen? Auf den JavaScript Days haben wir mit Elmar Burke und Hans-Christian Otto über diese Fragen gesprochen. Die Speaker erklären im Interview, was React ausmacht und warum die noch recht neuen Hooks so spannend sind.
JavaScript Days: Was ist denn das Spannende an React, was macht React aus?
Hans – Christian Otto: Ich glaube da, gibt es relativ viel, was React ausmacht. Mittlerweile ist es ja so, dass viele Technologien sich einander angleichen, aber es gibt immer noch ein paar Dinge, die besonders sind, auch für React. Ich habe da eine Geschichte vor ein paar Monaten erlebt, da habe ich bei einer User Group einen Vortrag gehalten zum Thema Testing von React-Anwendungen, und direkt davor gab es einen Vortrag zum Thema Testing von Angular-Anwendungen. Ich glaube, dass Angular ein sehr gutes Framework ist und dass es auch sehr viel Funktionalität und sehr viel Convenience mitliefert, die automatisch im Hintergrund passiert. Das Problem war, dass sich das im Testen widergespiegelt hat. Das Testen von React-Komponenten ist – meistens! – sehr, sehr einfach, weil das einfach pure Funktionen sind, die bekommen Daten, die stellen die Daten dar. Auch wenn irgendwelche Funktionalität stattfinden soll, irgendwelche Backend Services aufgerufen werden, dann ist das etwas, das irgendwie eingereicht wird, meist in Form eines Callback. Das ist sehr einfach zu testen, es passiert sehr wenig Magie im Hintergrund. Wenn ich mir dann die Tests mit Angular angeschaut habe (ich bin kein Angular-Experte), wurde da immer ein Testbrett in irgendeiner Form initialisiert, es wurde häufig dieser Dependency-Injection-Container initialisiert. Das heißt, es muss sehr viel passieren, um eine Angular-Komponente erstmal zu rendern, und das ist bei React so, dass eigentlich fast alles, was passiert, sehr explizit ist, und wenig implizit im Hintergrund passiert, was man in Testsituationen beispielsweise erstmal noch verstehen und aufsetzen muss. Das ist so einer der Knackpunkte für mich bei React, dass sehr deutlich ist, was passiert, und es passiert sehr wenig, was man nicht erwarten würde.
Elmar Burke: Es passiert tatsächlich sehr wenig von dem, was man nicht erwarten würde. React ist sehr einfach vorhersagbar, das ist einer der Kernpunkte daran, man gibt Daten rein und man kriegt Daten zurück. Es ist immer sehr einfach vorhersagbar. Diese Vorhersagbarkeit der Komponente spiegelt sich dann natürlich auch in den Tests wider. Wenn ich die gleichen Daten reingebe, dann muss immer das Gleiche passieren, unabhängig davon, was rundum ist, wie das Testbrett aufgebaut ist oder wie auch immer. Das ist ein ganz großer Vorteil von React. Das bieten andere Frameworks oder andere Libraries natürlich auch, aber das ist momentan ein ganz großes Alleinstellungsmerkmal von React im gesamten Ökosystem.
Hans – Christian Otto: Damit gehen wir beide auf das Thema der funktionalen Programmierung ein, dass es eben eher eine funktionale Denkweise als eine klassenbasierte Denkweise ist. Ein weiterer Punkt, der da für mich so ein bisschen reinspielt ist, dass React eine JavaScript-Bibliothek ist, wo man JavaScript lernen muss, wo man JavaSript verwenden und verstehen muss. Bei Angular ist es meines Wissens heute so, dass beispielsweise ein Iterieren über ein Array in einem Template etwas ist, wofür man eine Templatefunktionalität von Angular kennen und aufrufen muss. In React verwendet man das Map, das JavaScript-Arrays seit Jahren mitliefern. Das sind so Kernpunkte für mich.
Elmar Burke: Das ist einer der Punkte, die du gerade ansprachst, das Iterieren von Listen zum Beispiel. Das ist etwas, was ganz gut zeigt, dass React eigentlich immer nur ein Zusammenschluss von ganz vielen bestehenden Technologien ist, die schon da sind, die nur neu zusammen verdrahtet wurden. Es ist das JSX, das auf den ersten Blick mit React zusammenkam, das aber auch schon alt ist und das es schon vorher gab. Es ist das Virtual DOM, das es vorher auch schon gab, das für uns wegabstrahiert ist. Es ist das Iterieren über Listen, das im Grunde pures JavaScript ist und das viele Entwickler dann auch schon kennen. Es ist also nichts, was man speziell für React lernen müsste, um erstmal starten zu können. Das Wissen von React kann man in vielen anderen Bereichen dann auch wiederverwenden, denn React setzt auf die komponentenbasierte Anwendungsentwicklung auf, einem Trend, der im Web spätestens, seit Polymer mit den Web Components durch Google vorangetrieben wird, gestartet wurde. Dass ich also Komplexität kapseln kann, und dieses Wissen ist etwas, das man für React lernen muss. Ab diesem Punkt ist das Wissen aber wieder übertragbar. Das Schöne an React ist, dass man kein Framework oder eine Library lernt, sondern Patterns, und diese Patterns sind später wieder übertragbar.
Hans – Christian Otto: Man lernt ja nicht nur Patterns, sondern man lernt eben auch die Sprache JavaScript dabei sehr intensiv und muss sie lernen. Das würde ich aber gleichzeitig auch als kleinen Nachteil verkaufen, weil, wenn man zum Beispiel ein Angular-Tutorial von vorne bis hinten durchspielt, man alle Bausteine lernt, die man für Angular können muss. Bei React ist es so: ein React-Tutorial bringt einem React bei, und Wissen über JavaScript sollte man da schon ein bisschen, bis zu einem gewissen Grad mitbringen. Das heißt, ein Tutorial über Angular ist umfassender als eines von React, weil React-Tutorials häufig Wissen über JavaScript voraussetzen. Also ist es ein bisschen auch ein zweischneidiges Schwert.
Elmar Burke: Es ist nicht nur das Wissen von JavaScript, das vorausgesetzt wird, es ist natürlich auch das Wissen, wie das DOM funktioniert und es ist auch das Wissen, wie CSS funktioniert, wenn man im modernen Frontend arbeitet. Das Basiswissen sollte also ohnehin für Entwickler da sein, dazu gehören im modernen Frontend normalerweise JavaScript, HTML bzw. DOM und das CSS. Das ist eben Basiswissen. Das muss man sich mühsam erarbeiten, aber das muss man sich eben auch bewusst machen, und es gehört einfach zur Webentwicklung im Jahr 2019 noch immer dazu.
JavaScript Days: : Und darin liegt dann auch eine der Schwierigkeiten für Anfänger bei der Arbeit mit React? Oder gibt es da noch andere Bereiche, die zu Schwierigkeiten führen können?
Hans – Christian Otto: Naja, also ich glaube, dass eine der Schwierigkeiten durchaus mit dem Thema JSX mitkommt. Bei React ist es ja so, dass man mehr oder weniger HTML- und JavaScript-Code mischt und in eine Datei schreibt. Ich bin PHP-Entwickler, wir PHP-Entwickler haben da sehr schlechte Erfahrungen mit gemacht, deswegen war ich React gegenüber anfangs sehr skeptisch. Aber mittlerweile hat sich als großer Vorteil für mich herausgestellt, dass ich eben Code, der zusammengehört, in einer Datei zusammenführe. Also, wenn ich einen Button implementiere und habe JavaScript-Code in der einen und HTML in der anderen Datei und vielleicht noch CSS in der dritten Datei liegen, dann ist das ja immer noch nicht lose gekoppelt, sondern diese drei Dateien gehören immer in jedem Fall zusammen. Insofern macht es für mich schon Sinn, dass es in einer Datei ist. Das bringt aber auch ein kleines Problem mit: Es sieht aus wie HTML, es ist aber eigentlich kein HTML. Ich habe es also mehrfach in Kundenprojekten erlebt, dass Entwickler einfach dahergegangen sind und haben sich ein Twitter-Bootstrap-Template genommen und das HTML gecopied und -pasted und in die React-Komponente gegossen. Erstens führte das zu Problemen, weil beispielsweise CSS-Klassen in React anders referenziert werden als in HTML. Zweitens führte das aber dazu, dass wir Komponenten hatten, die sehr groß waren, die sehr viel HTML schon beinhaltet haben. Dann kam auch nochmal Funktionalität dazu, also insofern war das schon so, dass es nicht unbedingt zum saubersten Code führte, dass es einem so leicht gemacht wird, einfach HTML da reinzukopieren und an ein paar Stellen JavaScript dazuzumischen. Das ist schon eine Schwierigkeit, die ich da irgendwie sehe.
Elmar Burke: Andersrum bietet React die Möglichkeit, alle Sachen, die zu einer Komponente führen, zusammenzulegen. Dazu gehört der State der Anwendung, d. h. welche Daten stecken in meiner Komponente? Dazu gehört das Styling, also Themen wie CSS in JavaScript sind im Moment ein großer Game Changer. Es geht nicht darum, dass wir CSS jetzt in Objektnotation schreiben müssen, sondern es geht darum, dass unser CSS sehr dicht an die Komponente heranwandert und so modulare Entwicklung möglich wird. Wir haben nicht mehr dieses, ich nenne es immer scherzhaft, Blockchain CSS, das depend-only ist, und in der Mitte, wenn man da was verändert, bricht alles zusammen. Das brechen wir damit auf, und dadurch wird es wartbar, und damit wird Komplexität besser überblickbar. Wenn ich einen kleinen Teil der Anwendung anpasse, dann betrifft es nur einen kleinen Teil der Anwendung und nicht alles, und darin ist React wirklich stark.
Hans – Christian Otto: Es gibt für mich da noch etwas, ich glaube, dass es auch kein React-spezifisches Problem ist, sondern meine Schätzung ist, dass es eigentlich bei allen Frameworks heute so ist: Viele Entwickler, die heute JavaScript entwickeln und in React oder Angular einsteigen, sind ursprünglich Backend-Entwickler gewesen. Die sind es gewohnt, in Java, in C#, in PHP etc. große komplexe Anwendungen zu entwickeln, und versuchen, die Muster, die sie kennen gelernt haben, wieder genau mit ins Frontend zu bringen. Das funktioniert, glaube ich, bei Angular ein bisschen besser, aber es gibt einen Dependency-Injection-Container usw. Bei React wird das ein bisschen schwierig, wenn man sich nicht darauf einlässt, zu realisieren: „Hey, auch wenn die Sprache vielleicht ein bisschen Ähnlichkeit hat zu meinem Java, zumindest vom Namen her, ist die Denkweise dann doch eine ganz andere.“ Gerade bei React schreibt man sich nicht mehr ganz viele Klassen, die irgendwie interagieren, sondern man arbeitet eher funktional, man versucht, im Mutable zu arbeiten. Wir hatten zum Beispiel gerade einen Teilnehmer, der viele sehr smarte Fragen gestellt hat, und der hat an einer Stelle nicht verstanden, warum ich jetzt hier nicht einfach eine Funktion aufrufe, weil das doch auch funktioniert. Ja, das geht erstmal, das ist aber nicht die React-Denkweise. Das funktioniert für eine kleine Anwendung, wie wir das hier im Workshop natürlich erstmal entwickeln. Wir können ihm da aber keine echten Probleme zeigen, die in so einer kleinen Anwendung entstehen. Wenn wir aber eine große Anwendung bauen, die wartbar sein soll, dann müssen wir andere Muster anwenden, als wenn wir das bei einer Backend-Anwendung machen, weil die eben eigentlich komplett anders ticken. Insofern ist das eine ganz typische Herausforderung für mich, dass man, wenn man aus dem Backend kommt und ins Frontend wechselt, eine sehr andere Denkweise in React oder auch in JavaScript im Allgemeinen hat. Deswegen haben wir hier in der Veranstaltung mittlerweile diesen Workshop am ersten Tag, der so ein bisschen ein Einstieg für Backend-Entwickler in das Thema JavaScript sein soll, weil dann doch Dinge anders funktionieren, Klassen ganz anders funktionieren als in einem Java oder in einem .NET.
Elmar Burke: Es ist dann wieder genau das Gleiche, dass auch HTML anders funktioniert als das, was wir in HTML auf den Server schreiben, wenn wir Server-side Rendering machen, also wenn wir HTML-Schnipsel als Text einfach über den Server senden. Das funktioniert anders im Frontend, und das müssen Entwickler auch lernen. Also gerade, wenn man auch aus dem Backend kommt, dann hat man mit UI-Entwicklung relativ wenig zu tun. Der große Unterschied ist, dass wir nicht nur unterschiedlichen technologischen Stack haben, d. h. dass wir JavaScript anstelle von Java verwenden, dass wir HTML und CSS haben, sondern dass wir auch noch das Problem haben, dass unsere Anwendung eine lange Laufzeit hat und wir da ziemlich schnell in Memory Leaks reinlaufen können. Bei Serveranwendungen laufen die Anwendungen auch lange, aber die Phasen sind kürzer, und das ist ein großer Unterschied, den die Teilnehmer lernen müssen.
JavaScript Days: Wenn ihr auch schon sagt, Dinge, die die Teilnehmer lernen müssen – habt ihr vielleicht einen Tipp für Anfänger oder Einsteiger in die Entwicklung mit React, um typische Fehler zu vermeiden?
Hans – Christian Otto: Ich glaube, ein ganz typischer Fehler, den wir auch eben schon angesprochen haben, ist, dass man verstehen muss, dass man sich in einem anderen Ökosystem befindet. Eine Klasse in JavaScript ist einfach etwas anderes als eine Klasse in Java. Ich glaube, das ist der wichtige Punkt: Man muss sich darauf einlassen, ein neues Ökosystem kennenzulernen, und man sollte nicht einfach alle Patterns, die man aus PHP, aus Java usw. kennt, genauso mit ins Frontend bringen. Das ist etwas, das ich bei einem Projekt, in dem sehr gute Backend-Entwickler eine JavaScript- oder eine React-Anwendung gebaut haben, beobachtet habe. Das war eine solide Anwendung, aber da sind einfach so ein paar Sachen, wenn man da einen Standard-Frontend-Entwickler dransetzt, wird der sich denken: „Was zur Hölle, warum?“ Und ich glaube, wenn man diese Entwickler fragen würde, warum sie diese Entscheidung getroffen haben, dann ist da sehr viel „weil wir es so aus dem Backend gewöhnt sind“. Man muss einfach verstehen, dass Backend- und Frontend-Entwicklung eben zwei sehr unterschiedliche Disziplinen sind.
Elmar Burke: Eine andere Sache, die ziemlich schnell Einstiegshürde ist: dass Frontend-Anwendungen häufig als „das-ist-doch-alles-langsam“ gesehen werden. Das ist nicht der Fall. Wenn wir Daten übers Netzwerk laden müssen, dann ist es immer langsam, und wenn wir für alles große Libraries einbauen, dann wird es natürlich langsam. Ich denke, es ist auch eine große Hürde, die einen großen Unterschied zur Backend-Entwicklung macht, dass wir im Kleinen Daten übertragen müssen, die möglichst klein sind, der ausführbare Code möglichst klein sein muss. Zwar gibt es das im Backend auch – wenn man auf Kubernetes setzt, möchte man seinen App-Wandel auch möglichst klein haben – aber dann ist es halt auch klein genug, wenn es 10 MB sind. Das ist nur fürs Frontend dann ziemlich groß, und wir wollen maximal ein Zehntel, wirklich als Obergrenze, haben. Das ist auch ein großer Game Changer, um dieses Pattern „Frontend-ist-doch-langsam-und-die-Welt-ist-schlecht“ anders zu sehen.
JavaScript Days: Trotzdem wachsen Anwendungen natürlich, und die Interessen daran, was mit dieser Anwendung gemacht werden soll, verändern sich mit der Zeit. Welche Libraries und Tools muss man denn bei React kennen oder sollte man für wachsende Anwendungen einsetzen?
Elmar Burke: Es gibt so Standard-Tooling-Sachen, die eigentlich immer eingebettet werden. Das ist die React Testing Library, um gute Patterns für das Testen von React zu verwenden. Es gibt nun die Hooks in React in Core, die praktisch sind fürs State Management in lokalen Komponenten. Einher mit React geht sehr häufig auch die Entwicklung mit Redux, die dann App State als globalen State aufbaut. Redux sollte man gehört haben, wenn man mit React arbeitet. Neben Redux gibt es dann aber auch tolle State Management Libraries, sowas wie MobX, das einen ähnlichen Ansatz fährt, aber ganz anders funktioniert. Es gibt viele tolle Möglichkeiten, und man sollte sich das rauspicken, was am besten passt, was dann auch wieder eine der Schwierigkeiten bei React ist. Man kann sich halt alles aussuchen.
JavaScript Days: Du hattest gerade auch schon das Thema der Hooks bei React angesprochen, das ist ja noch ein ganz neues Konzept, das mit 16.8 gerade final ausgeliefert wurde. Könnt ihr uns noch ein bisschen mehr dazu sagen, was man damit machen kann und was sich damit ändert?
Elmar Burke: Mit Hooks kommen in React andere Möglichkeiten, um State zu verwalten, und zwar in Functional Components. Das Schöne ist, dass wir nun einen statisch evaluierbaren Code haben, der uns Fehler ziemlich schnell deutlich macht, wenn wir auf State angewiesen sind. Wenn wir also zum Beispiel auf Basis einer Property Daten laden wollen, die wir reingegeben bekommen, können wir nun automatisiert überprüfen, ob jedes Mal, wenn sich die Property ändert, die Daten erneut laden. Wir können nun alles in Funktionen schreiben, was den Code etwas sauberer macht. Wir müssen nicht mehr die Class Components benutzen, die auch hier und da mit diesem sys-Wörtchen schonmal schwieriger in JavaScript zu verstehen sind. Wir gehen also vielen Problemen aus dem Weg, die wir sonst standardmäßig drin haben.
Hans – Christian Otto: Ich habe immer so das Gefühl, dass ich irgendwie der Einzige bin, der noch nicht an jeder Stelle immer sagt: „Hooks sind eine gute Idee für die Zukunft“. Mir tut das immer so ein bisschen weh, weil wir gerade beide diese deterministischen puren Funktionen als einen großen Vorteil von React angesehen haben. Und durch Hooks wird das Ganze so ein bisschen verwaschen. Eine Funktionskomponente, die Hooks verwendet, ist nicht mehr eine pure Funktion, in die ich Daten reingebe, und abhängig von den Daten gibt sie mir genau das Gleiche; sondern es kommt noch diese „Magie der Hooks“ dazu. Es ist so, dass die Magie, die da existiert, eigentlich nicht sehr magisch und nicht sehr deterministisch ist und beispielsweise in der von dir angesprochenen React Testing Library und sicherlich in allen anderen React-Testing-Tools heutzutage auch drinnen ist, sodass es immer noch einfach ist. Aber für mich versteckt es einfach sehr viel Komplexität, wovor ich immer ein bisschen Angst in solchen Fällen habe. Deswegen bin ich mal noch gespannt; wir haben in React die Mixins vor ein paar Jahren gehabt, dann kam die Idee, High Order Components zu machen, dann kamen die Render Props als das neue tolle Ding, und jetzt sind es eben die Hooks. Ich würde mal gucken, was wir in drei Jahren machen, ob es da immer noch Hooks sind, oder ob wir in drei Jahren wieder den Nachfolger haben, weil wir die Probleme von Hooks kennengelernt haben. Also ich glaube, Hooks sind einfach noch sehr jung und sehr frisch, weswegen ich erstmal noch ein bisschen vorsichtig bin. Das steht auch in der React-Anleitung drin, und das ist auch ein Hinweis, den man oft auf Konferenzen hört. Man sollte nämlich nicht die komplette Anwendung jetzt umschreiben, sodass alles durch Hooks ersetzt wird. Es macht Sinn, das mal so Schritt für Schritt auszuprobieren. Ich finde es auch sehr elegant, was man mit funktionellen Komponenten, mit Hooks bauen kann, und ich bin Backend-Entwickler gewesen, d. h., für mich sind die Klassenkomponenten was Schönes und nichts Böses gewesen. Aber ich verstehe schon, dass es teilweise schon sehr viel aussagekräftiger ist, wenn wir an der Stelle mit Hooks arbeiten.
Elmar Burke: Es hat sich eigentlich kein Pattern durch Hooks verändert, nur die Schreibweise ist anders geworden. Das, was vorher Class Components war und was State verwaltet oder über Lifecycle irgendwie etwas gemacht hat, ist nun in Hooks gewandert. Trotzdem behalten wir unsere Pure Components, die eigentlich nur einen State anzeigen, also ausschließlich auf Properties reagieren, nach wie vor bei. Wir verschieben nur Sachen in andere Function Components.
Hans – Christian Otto: Da ist aber genau der Punkt. Man erwartet bei einer Functional Component bisher noch nicht, dass sie sowas macht, d. h., dass wir da an der Stelle umlernen und verstehen müssen, dass auch eine Functional Component keine pure Funktion mehr ist. Was noch so ein Ding ist, weswegen ich Hooks manchmal kritisch sehe, wir haben das anfangs gesagt: In React ist alles eine Komponente, wir haben diese komponentenbasierte Anwendungsentwicklung. Bei beispielsweise den Komponenten mit Render Props war es auch so, dass wir unsere Logik sehr intensiv in Komponenten gepackt haben, und da sehe ich jetzt den Trend, dass diese Logik in Hooks wandert und damit nicht mehr in Komponenten drin ist. Das ist auch so einer der Punkte, bei denen ich mir denke, ich sehe zwar den Charme daran, aber ich bin noch nicht überzeugt, dass das wirklich der Schritt in die richtige Richtung oder die endgültige perfekte Lösung sein wird.
Elmar Burke: Das Schöne ist, Hooks sind immer noch Teil der Komponente und dadurch auch wiederverwendbar. Wenn wir einen State haben, der zum Beispiel User online anzeigt und uns immer wieder anzeigt, ob der Benutzer online ist oder nicht, ist er wiederverwendbar in anderen Components. Das ist ein großer Vorteil, denn das war vorher mit Class Components so nicht möglich; mit Render Props zwar schon, aber dann sind wir auch wieder im Render-Zyklus, und wenn wir die „nesten“ wollen, sind wir ziemlich weit eingerückt und das macht Code einfacher.
JavaScript Days: : Hooks sind also ein Thema, das man durchaus noch diskutieren kann, und von dem noch nicht ganz klar ist, wie es sich weiterentwickeln wird. Gibt es denn vielleicht noch irgendetwas anderes bei React oder auch im Ökosystem, das ihr euch für die nächsten Jahre wünschen würdet, oder bei dem ihr denkt, da könnte sich React gut nochmal weiterentwickeln?
Hans – Christian Otto: Also erstmal eine etwas allgemeinere Sache, die ich mir wünschen würde, ist, dass sich mehr Leute mit dem Thema Typing beschäftigen. Ich bin seit Jahren ein großer Fan von TypeScript, weil es mir das Entwickeln einfacher macht. Meine ID weiß, was ich da tue, und ich rate nicht nur, sondern ich sehe, dass ich, wenn ich eine bestimmte Action habe, dann da folgende Daten bekomme. Darauf kann ich mich verlassen. Das ist aber mehr so eine allgemeinere Ökosystem-Sache. Worauf ich sehr gespannt bin, ist in der nächsten React-Version das Thema Suspense, dass also das Laden asynchroner Daten nochmal ganz anders wird, auch wenn ich da ebenfalls ein bisschen kritisch war. Denn mir hat man mal beigebracht, ich soll keine Exceptions werfen, um Programmfluss zu steuern. Es sind keine Exceptions, die da geworfen werden, aber es wird geworfen, und das heißt, das ist etwas, bei dem ich auch noch so ein bisschen skeptisch bin, wobei der Code, den man da am Ende schreibt, finde ich, sehr elegant ist. Da bin ich sehr neugierig.
Elmar Burke: Also React kapselt für uns sehr viele Sachen weg. Wenn man sich den Code der Virtual DOMs anschaut, dann schlägt man auch die Hände über dem Kopf zusammen. Aber das ist ein Implementierungsdetail, genauso wie das Werfen von irgendwelchen Daten in Suspense ein Implementierungsdetail ist, und uns erstmal nicht interessieren muss, wie das funktioniert. Genauso wissen die wenigsten, wie denn JSX umgeformt und was da hinterher erzeugt wird. Das ist im Zweifel ein Implementierungsdetail, und ich denke, Suspense ist ein sehr eleganter Weg, Daten zu laden, und gerade im Zusammenspiel mit Hooks macht es das sehr einfach. Wir können, wenn Fehler beim Laden von Daten passieren, an einer zentralen Stelle zeigen, dass da irgendwas schiefgelaufen ist, und das macht Code einfach und vorhersagbar, und gerade vorhersagbarer Code ist das, was wir als Entwickler haben wollen.
