{"id":8141,"date":"2018-01-04T12:44:07","date_gmt":"2018-01-04T11:44:07","guid":{"rendered":"https:\/\/www.centigrade.de\/blog\/?p=8141"},"modified":"2018-01-04T13:31:09","modified_gmt":"2018-01-04T12:31:09","slug":"angular-react-modernen-wetechnologien-entgegentreten","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/angular-react-modernen-wetechnologien-entgegentreten\/","title":{"rendered":"Angular oder React? Modernen Web-Technologien offen begegnen"},"content":{"rendered":"

\"\"<\/a><\/p>\n

Selbst gro\u00dfe Firmen in der Industrie k\u00f6nnen nicht bestreiten, dass es neben klassischen Desktop-Frontend-Technologien, wie WinForms oder WPF,<\/a> eine bemerkenswerte Bewegung in Richtung Web-Frontend-Technologien gibt. Als UX Dienstleister, der seine Kunden zu gro\u00dfen Teilen auch im Frontend-Engineering unterst\u00fctzt, werden wir oft gefragt, welche Technologie am besten zu den Bed\u00fcrfnissen des Kunden passe und welche er demnach w\u00e4hlen solle. Neben vielen relevanten Bibliotheken und Frameworks, sind Angular<\/a>*<\/em> und React<\/a> die zwei vorherrschenden Platzhirsche. Es ist nicht einfach die Frage zu beantworten, f\u00fcr welche der beiden Technologien man sich entscheiden solle. Ein Ansatz ist die Betrachtung verschiedener Kriterien in Bezug auf einen fest definierten Satz von Anforderungen seitens der Entwickler. Im Folgenden werde ich eine Antwort darlegen, die wir f\u00fcr uns bei Centigrade gefunden haben und von der wir denken, dass sie f\u00fcr unsere Kunden am hilfreichsten sein wird.<\/p>\n

Warum sollte man Web Technologien nutzen?<\/h3>\n

Zun\u00e4chst m\u00fcssen wir beantworten, warum es sinnvoll sein kann, \u00fcberhaupt eine Web-Technologie f\u00fcr das Frontend-Engineering auszuw\u00e4hlen. Eine solche Entscheidung aufgrund von popul\u00e4ren Schlagworten oder Trends zu treffen ist kein guter Grund, jedoch h\u00e4ufig die initiale Motivation und der Grund warum dieses Thema \u00fcberhaupt aufkommt. Web-Frontend-Technologien sind eine Chance echte plattform\u00fcbergreifende Systeme umzusetzen. Dies kann sich nicht nur auf Betriebssysteme (wie Windows oder Unix), sondern auch auf mobile Ger\u00e4te und grunds\u00e4tzlich auf alles beziehen, auf dem ein Browser l\u00e4uft. Moderne clientseitige Web-Frameworks gehen sogar noch einen Schritt weiter, indem sie vom Browser abstrahieren, sodass nativ sogar Desktop-, Mobil- oder komplett andere Systeme adressiert werden k\u00f6nnen. Im Hinblick auf die heutige Digitalisierung und Industrie 4.0, wobei viele unterschiedlichste Ger\u00e4te untereinander verbunden sind, kann diese Flexibilit\u00e4t oft eine entscheidende Anforderung sein. Allein aus diesem Grund ist es durchaus berechtigt Web-Technologien in Erw\u00e4gung zu ziehen.\u00a0 \"\"<\/a><\/p>\n

<\/p>\n

Angular und React<\/h3>\n

Angular wird entwickelt von Google, hinter React steht Facebook; beides sind Gro\u00dfkonzerne. Die Technologien haben eine enorm gro\u00dfe Community und (bezogen auf das Web-Engineering) eine eher lange und mittlerweile stabile Entwicklungshistorie. Nachdem wir deren Evolution \u00fcber einen l\u00e4ngeren Zeitraum beobachtet haben, k\u00f6nnen wir gewissenhaft sagen, dass sowohl Angular als auch React in Produktivumgebungen genutzt werden k\u00f6nnen und werden.<\/p>\n

In ihren Grundkonzepten sind sich Angular und React sehr \u00e4hnlich: Beide sind Komponenten-basiert, was bedeutet, dass alle Anwendungen gebaut werden indem man mehrere kleine, in sich geschlossene Komponenten mit einer klaren Zust\u00e4ndigkeit zu einem gro\u00dfen Gesamtsystem zusammenstellt. Da es heutzutage im Web-Engineering als Bad Practice gesehen wird, wenn das sogenannte DOM (Document Object Model<\/a> des Browsers auf direktem Wege manipuliert wird (siehe jQuery<\/a>), basieren beide Technologien auf der Idee der DOM-Abstraktion. Deklariert man Angular oder React Komponenten auf der View-Ebene, beschreibt man damit nur wie die Applikation aussehen soll, w\u00e4hrend die Frameworks mit Hilfe von intelligenten Algorithmen diese Informationen am performantesten verarbeiten. Durch diese Abstraktion von konkreten DOM-Elementen des Browsers ist es m\u00f6glich, nativ andere Zielsysteme wie zum Beispiel Android oder iOS, Backend-Server oder sogar IoT-Ger\u00e4te anzusprechen. Die Entwickler hinter Angular und auch React arbeiten auf mehreren Ebenen sehr intensiv daran, die Performanz, Architektur, Flexibilit\u00e4t und die sogenannte Developer Experience zu verbessern. Zusammengefasst erf\u00fcllen damit beide Technologien, insofern sie im vorgesehenen Sinne genutzt werden, die oben genannte Multi-Plattform-Anforderung.<\/p>\n

Framework und Library<\/h3>\n

Da die Kerngedanken und eben genannte technischen Schl\u00fcsselkriterien ziemlich \u00e4hnlich sind, fokussieren wir uns nun auf die Unterschiede zwischen Angular und React, um f\u00fcr oder gegen eines der beiden sprechen zu k\u00f6nnen. Der Hauptunterschied ist, dass Angular als Framework oder gar Plattform bezeichnet wird, wohingegen man React als Bibliothek auffasst. Wie der englische Begriff schon aussagt, bietet ein Framework (zu Deutsch Rahmenwerk) einen Rahmen, in den sich der Quellcode einer Applikation einf\u00fcgen kann. Damit einher geht, dass es eine Menge an vordefinierten Beschr\u00e4nkungen wie beispielsweise Programmiersprachen, Werkzeuge oder Muster gibt, die man nutzen und an die man sich halten sollte. Im Gegensatz dazu kann eine Library vom Applikationscode in flexiblerer Art und Weise konsumiert werden. Man kann React w\u00e4hlen und nur punktuell einbinden, w\u00e4hrend man fehlende Teile ab einem gewissen Punkt selbst hinzuf\u00fcgen muss. Diese Flexibilit\u00e4t hat sowohl Vor- als auch Nachteile.<\/p>\n

Angular ist restriktiver, gibt klare Wege und Grenzen vor und macht es einem schwerer aus diesen auszubrechen. Auf der anderen Seite werden dadurch bereits etablierte Best Practices vorgegeben, was dazu f\u00fchrt, dass man ohne lange Entscheidungsprozesse schnell damit starten kann. Existiert bereits eine fest definierte und etablierte Toolchain, kann es wiederum leichter sein, dort React zu integrieren und auf die eigenen Bed\u00fcrfnisse anzupassen. Man ist jedoch auch gezwungen diese Integrationen selbst durchzuf\u00fchren und die passenden Werkzeuge auszuw\u00e4hlen, dort wo die Bibliothek keine vorgibt. Insbesondere f\u00fcr Neueinsteiger oder in zeitkritischen Projekten kann dies schnell etwas \u00fcberfordernd wirken.<\/p>\n

\"\"<\/a>

Integration in etablierte Werkzeuge und Abl\u00e4ufe mit Angular als Framework gegen\u00fcber der freien Adaption von React als eine von mehreren Bibliotheken in der eigenen Codebasis.<\/p><\/div>\n

Eine Entscheidung basierend auf dem UX-Prozess<\/h3>\n

Da es unser initiales Ziel war, zwischen den beiden Technologien einen Favoriten auszuw\u00e4hlen, wollen wir nun einen kurzen Blick auf die speziellen Entscheidungskriterien aus dem Blickwinkel des Frontend-Engineerings werfen. Sie sind der Schl\u00fcssel in der Dom\u00e4ne der UX Dienstleistungen.<\/p>\n

Centigrade Design Engineers<\/a> arbeiten mit den Backend-Entwicklern auf Kundenseite eng zusammen und sind darauf angewiesen eine enorme Menge an Look-&-Feel-Ressourcen einer Applikation zu verwalten. Bereits in kleineren Projekten entstehen dabei beispielweise viele CSS Stile und Klassen. Es ist essentiell, dass diese Style-Informationen modularisiert, wiederverwendet und in einer gut wartbaren Art und Weise strukturiert werden k\u00f6nnen. Dar\u00fcber hinaus darf der architektonische Aufbau dieser Ressourcen die Performanz einer Anwendung in keinem Fall negativ beeinflussen. Zus\u00e4tzlich zur Erstellung statischer Stilinformationen (der Look), ist es wichtig, dass die Interaktionen und das Layout-Verhalten (das Feel) exakt so umgesetzt werden k\u00f6nnen, wie es in vorangegangen Schritten des konzeptionellen und visuellen Designs definiert wurde. Beide Aspekte, das Aussehen sowie das Verhalten der Anwendungen, m\u00fcssen gut in Zusammenarbeit mit den Backend-Entwicklern unserer Kunden implementiert werden k\u00f6nnen. Aus diesem Grund m\u00f6chte man die Schnittstellen, an denen das Frontend auf das Backend trifft, klar definieren, sodass beide Team Mitglieder parallel arbeiten k\u00f6nnen, ohne sich gegenseitig zu behindern.<\/p>\n

Das Styling von Angular Applikationen kann gut strukturiert durch SASS<\/a> und eine Kombination aus dem Anlegen von globalen und Komponenten-basierten Style-Informationen durchgef\u00fchrt werden. Es gibt noch keine eindeutige Vorgabe oder eine klare Best Practice wie das Styling in React Anwendungen durchzuf\u00fchren ist. Styled Components<\/a>, CSS Modules<\/a> und weitere Techniken treten hier in Konkurrenz zueinander.<\/p>\n

Viele unserer eigenen, als auch die Entwickler unserer Kunden kommen aus der Entwicklung mit C# und WPF. Angular Anwendungen in einem eher klassischen MVVM<\/a>\/MVC-Stil umzusetzen, f\u00fchlt sich daher etwas nat\u00fcrlicher an als die funktionale Art der Programmierung in React mit einem starken Fokus auf dem Konzept der Unver\u00e4nderbarkeit<\/a>. Beide Entwicklungsmuster haben ihre Vor- und Nachteile, jedoch werden insbesondere Neueinsteiger (mit einem .NET Hintergrund) im Web-Bereich wom\u00f6glich bei React eine steile Lernkurve vernehmen.<\/p>\n

Die Angular Plattform hat nicht nur TypeScript<\/a> (was wir im Besonderen sch\u00e4tzen gelernt haben, da es eine gute Zusammenarbeit im Team erm\u00f6glicht und die Vorhersehbarkeit im Code f\u00f6rdert), die Angular CLI<\/a> und viele weitere n\u00fctzliche Entwicklerwerkzeuge integriert. Es liefert auch eine gro\u00dfartige Dokumentation und einen gut geschriebenen Styleguide<\/a>, der sich automatisiert in die praktische Arbeit mit Angular integrieren l\u00e4sst. Wenn wir mit React arbeiten, m\u00fcssen wir eine Menge von kleinen Entscheidungen treffen, wenn es darum geht, die verschiedenen Bestandteile unserer Toolchain zu definieren. Beispielsweise erfordert die Nutzung von TypeScript in React zus\u00e4tzliche Schritte, da hier f\u00fcr gew\u00f6hnlich Babel<\/a> als Transpiler zu JavaScript genutzt wird.<\/p>\n

Die Auswahl von React bedingt die Evaluation, Entscheidung und Einigung in Bezug auf einen ganzen Satz an Technologieentscheidungen, welche in der Zusammenarbeit mit unseren Kunden in jedem einzelnen Schritt der Arbeitsabl\u00e4ufe getroffen werden m\u00fcssen. Das ben\u00f6tigt initial zus\u00e4tzlichen Aufwand, bevor man sich auf die Entwicklung der tats\u00e4chlichen Anwendungslogik fokussieren kann. Besteht das Bed\u00fcrfnis \u2013 das dann zumeist von unseren Kunden ausgeht \u2013 eine sehr feingranulare Kontrolle \u00fcber die Einzelbestandteile zu haben, w\u00fcrde man daf\u00fcr eher React w\u00e4hlen, wo man genau diesen Weg dann aber auch beschreiten muss. Eine solche Feingranularit\u00e4t ist in Angular durchaus m\u00f6glich, jedoch in der Form nicht empfohlen.<\/p>\n

Zusammenfassung<\/h3>\n

Um nun mit unseren speziellen Entscheidungskriterien im Hinterkopf zu einem Schluss zu kommen, haben wir bei Centigrade aufgrund seiner reibungslosen Integration und dem hohen Level der Produktivit\u00e4t eine Pr\u00e4ferenz zu Angular als unsere prim\u00e4re Technologie im Frontend-Web-Engineering. Angular als Framework wird eine gute Wahl sein, wenn Sie nach einer stabilen L\u00f6sung mit einer Menge von vor- aber gut definierten Bestandteilen suchen. Es gibt au\u00dferordentlichen Toolsupport und eine gro\u00dfartige Community. React als Library mag passender sein, falls Sie von Beginn an die vollst\u00e4ndige Kontrolle \u00fcber jegliche Teilbereiche haben m\u00f6chten. Eine solche Entscheidung ist immer kontextabh\u00e4ngig, weshalb wir uns aus diesem Grund im Allgemeinen nicht gegen React aussprechen. Wir haben einfach sehr gute Erfahrungen mit der Angular Plattform gemacht und so gut wie keine Hindernisse bei der Realisierung selbst komplexer und gro\u00dfer Projekte angetroffen. Jeglichen neuen Technologien, wie Angular und React, treten wir offen entgegen, solange sie uns dazu bef\u00e4higen, Produkte zu entwickeln, die eine gro\u00dfartige UX bieten und die Nutzer am Ende gl\u00fccklich machen.<\/p>\n

Sind Sie interessiert an tiefgehenden Technologiebesprechungen oder haben Sie weitere Fragen, wie man eine gute UX durch das Zusammenspiel von Design und Implementierung zu Tage bringt? Dann werfen Sie doch einen Blick auf unsere Engineering-Dienstleistungen<\/a>.<\/p>\n

 <\/p>\n

<\/h3>\n

*Wenn wir von Angular<\/em> sprechen, beziehen wir uns auf Angular ab Version 2 (momentan 5). Angular vor diesen Versionen, Angular 1.x, wird auch AngularJS<\/a> genannt. Damit folgen wir der offiziellen Nomenklatur von Google<\/a>.<\/p>\n","protected":false},"author":42,"featured_media":0,"template":"","tags":[513,514,515],"class_list":["post-8141","blog","type-blog","status-publish","hentry","tag-angular","tag-react","tag-web-engineering"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/8141","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/users\/42"}],"version-history":[{"count":0,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/8141\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/media?parent=8141"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/tags?post=8141"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}