Angular – Smart und Dumb Components


Nx ist für mich zum Grundstein jeder neuen Angular Anwendung geworden. Wir bei FORTIX haben schon viele Projekte mit Nx umgesetzt und
sind immer wieder begeistert, wie einfach es ist, Angular Apps in Monorepos zu entwickeln.
Sogar für einzelne Anwendungen, die nicht in einem Monorepo liegen, lohnt es sich, Nx zu verwenden.

## Was ist Nx?

Nx ist ein Open-Source Toolkit, das von [Nrwl](https://nx.app/company) entwickelt wurde. Es erweitert die Angular CLI um viele nützliche Features.
Es stellt Tools und Bibliotheken bereit, die uns Entwickler dabei unterstützen, effizienter zu arbeiten. Diese sind
besonders hilfreich für Projekte mit mehreren Anwendungen, Bibliotheken und geteiltem Code. Nx verbessert die Developer
Experience durch fortschrittliche Funktionen wie Codegenerierung, Dependency Graphs und konsistente Projektstrukturen.
Nx ist nicht nur für Angular Projekte geeignet, sondern auch für React, Node.js und viele weitere Technologien.

## Vorteile von Nx

- **Wiederverwendbarkeit von Code**: Mit Nx können wir Bibliotheken erstellen, die in mehreren Apps wiederverwendet
  werden können.
- **Effizenter Entwicklungsprozess**: Nx optimiert die Build- und Testprozesse und ermöglicht es uns, nur die geänderten
  Teile unserer Anwendung zu kompilieren und zu testen.
- **Dependency Graphs**: Nx erstellt einen Dependency Graphen, der uns hilft, die Abhängigkeiten zwischen unseren Projekten und
  Bibliotheken zu visualisieren.
- **Konsistente Projektstruktur**: Nx definiert eine konsistente Projektstruktur, die uns hilft, unsere Anwendungen und
  Bibliotheken besser zu organisieren. Dies erleichtert die Wartung und Weiterentwicklung unserer Anwendungen.
- **Moderne Tools**: Nx bietet moderne Tools wie [Cypress](https://www.cypress.io/), [Jest](https://jestjs.io/),
  [ESLint](https://eslint.org/), [Prettier](https://prettier.io/) und [Storybook](https://storybook.js.org/), die uns helfen,
  unsere Anwendungen zu entwickeln, testen und dokumentieren.

Wo Licht ist, ist auch Schatten. Nx ist nicht perfekt und hat auch einige Nachteile.

## Nachteile von Nx

- **Lernkurve**: Nx hat eine steile Lernkurve und es kann dauern bis alle Entwickler:innen sich mit den Konzepten und Tools
  vertraut gemacht haben.
- **Komplexität**: Ein Monorepo kann schnell sehr groß und komplex werden. Es ist wichtig, die Struktur und Organisation
  des Monorepos sorgfältig zu planen und zu pflegen.
- **Merge Konflikte**: In einem Monorepo kann es häufiger zu Merge Konflikten kommen, da mehrere Entwickler an verschiedenen
  Teilen des Codes arbeiten.
- **Zugriffskontrolle**: In einem Monorepo hat jeder Entwickler Zugang zum gesamten Code des Projekts. Es gibt keine einfache
  Möglichkeit Teile des Codes zu von unabsichtlichen Änderungen zu schützen. Deshalb sind Reviews und Tests umso wichtiger.

Nichtsdestotrotz überwiegen für mich die Vorteile von Nx und ich kann es nur empfehlen, es in jedem Angular Projekt zu verwenden.

## Nx in der Praxis

Ich möchte euch noch ein kleines Beispiel zeigen, wie wir bei FORTIX Nx in der Praxis verwenden.
Für unseren Kunden [Bundesverband Photovoltaic Austria](https://pvaustria.at/) durften wir schon 3 verschiedene Angular Projekte umsetzen.
Um dies möglichst effizient und somit auch kostengünstig zu gestalten, haben wir uns für die Verwendung von Nx entschieden. Dadurch konnten wir viele Vorteile
von Nx nutzen und die Projekte schneller und effizienter umsetzen.

Bei den Projekten handelt es sich um nützliche [Online PV-Tools](https://pvaustria.at/pv-tools/) für die Planung einer PV-Anlage.
Die Tools sind auf der Website des Bundesverband Photovoltaic Austria verfügbar:

- [SonnenKlar PV-Rechner](https://pvaustria.at/pv-rechner/)
- [SonnenKlar Föderkompass](https://pvaustria.at/foerderungen/)
- [PV-Profi-Suche](https://pvaustria.at/pv-profi/)

Alle Projekte leben in einem gemeinsamen Nx Monorepo. Mit dem Dependency Graph von Nx können wir die Abhängigkeiten zwischen
den Projekten und Bibliotheken visualisieren und so einen besseren Überblick über die Struktur des Monorepos erhalten.

```bash[class="line-numbers"]
nx graph
```

![](/images/blog/nx-monorepo-pva/pva-graph.png 'Nx Dependency Graph des PVA Monorepos')

Alle 3 Anwendungen sind im Corporate Design von PV Austria umgesetzt. Darum wurde eine UI-Bibliothek erstellt, die alle UI-Komponenten für die
verschiedenen Anwendungen enthält. Da es meistens ähnliche Komponenten in den verschiedenen Apps gibt,
konnten wir viel Code wiederverwenden und die Entwicklung beschleunigen.

Diese Anwendungen haben sonst keine weitere geteilte Businesslogik, deshalb haben wir keine weiteren Bibliotheken erstellt. In komplexeren
Anwendungen ist es aber möglich, mehrere Bibliotheken zu erstellen um so viel Code wie möglich wiederzuverwenden.

Wenn wir jetzt z.B. die PV-Profi-Suche App mit Cypress testen wollen, nimmt Nx uns viel Arbeit ab. Mit einem einzigen Befehl können wir
End-to-End Tests für unsere App konfigurieren:

```bash[class="line-numbers"]
nx generate @nx/cypress:cypress-project --name=pvexperts-e2e --project=pvexperts
```

Wenn wir jetzt den Dependency Graphen erneut anzeigen, sehen wir, dass ein neues Projekt für die Cypress Tests erstellt wurde:

![](/images/blog/nx-monorepo-pva/pva-graph-e2e.png 'Nx Dependency Graph des PVA Monorepos mit Cypress Tests')

## Fazit

Nx hat die Art und Weise, wie wir Angular Apps entwickeln, grundlegend verändert. Die Lernkurve ist steil, aber wenn man erstmal
die Konzepte und Tools verstanden hat, bietet Nx viele Vorteile, die die Entwicklung von Angular Apps oder Projekten mit anderen
Technologien deutlich effizienter machen.


Entwicklungs-Turbo: Nx Monorepos für Angular-Apps


Trotz guten Entwicklern und einem erfahrenen Projektteam ist der Erfolg eines Software Produktes nicht immer automatisch gewährleistet. Jahrelang eingespielte Entwicklerteams, ausreichend vorhandenes Know-How sowohl in Domäne als auch Tech-Stack gepaart mit genügend zeitlicher Flexibilität bleiben oft das Wunschszenario. Kurz gesagt, die Ressourcen sind knapp, die gesetzten Ziele hoch. Es gilt also mit diesen Rahmenbedingungen umzugehen, die Produktivität zu maximieren und die internen Voraussetzungen für einen effizienten Entwicklungsprozess zu schaffen.

Und dennoch ist in vielen Fällen genau hier noch Luft nach oben. Unklare Strukturen und Prozesse, mangelnder Fokus auf das Kernprodukt, unproduktive Meetings und teils ausbaufähige Architekturentscheidungen sind nur einige der Hürden, mit denen sich Produkt- und Entwicklerteams auseinandersetzen müssen. Gerade wenn Ressourcen nicht immer ausreichen und die Zeit drängt, können die richtigen internen Handgriffe dem Team die notwendige Struktur, Effizienz und Motivation verleihen.

#### Produktmanagement: Die Richtung festlegen und halten

Die Basis für einen optimalen Produktentwicklungsprozess entsteht bereits bei der Ausarbeitung der Produkt Strategie. Im Mittelpunkt, eine klar definierte Product Roadmap. Diese Roadmap sollte nicht nur kurzfristige Ziele festlegen, sondern auch eine klare Mission für das Produkt definieren. Ein gemeinsames Verständnis der Mission schafft Identifikation im Team, fördert die Zusammenarbeit und hilft dabei, die Entwicklung auf das Wesentliche zu konzentrieren. Dabei sollten ständige Richtungsänderungen und Insellösungen vermieden werden, da diese die Entwicklung verlangsamen und das Team demotivieren. Natürlich ist klar, dass auf gewisse Dynamiken im Markt reagiert werden muss und diese die Strategie beeinflussen können, allerdings haltet sich die Agilität an dieser Stelle idealerweise noch etwas in Grenzen.

#### Strukturierte Abläufe und klare Rollenverteilungen

Es hat gute Gründe, wieso Scrum der Grundstein für nahezu alle modernen Software Projekte ist. Es verteilt eindeutige Aufgabenbereiche, gibt einen transparenten und einheitlichen Arbeitsablauf vor und erlaubt somit für Flexibilität, Reaktionsschnelligkeit und Effizienz. Obwohl es nicht in allen Fällen notwendig ist einen Scrum-Prozess laut Lehrbuch einzuführen, sollte man sich den Vorteilen der Grundprinzipien von Scrum bewusst sein und bei Bedarf einen adaptierten Prozess implementieren. Das Ziel muss sein:

- Gut vorbereitete PI- und Sprintplanungen, welche durchdachte und ausführlich definierte Arbeitspakete verabschiedet und die Arbeitsbelastung ideal priorisiert
- Kompakte und regelmäßige Standup Meetings während des Sprints um den Informationsaustausch hochzuhalten und unnötige Meetings zu vermeiden
- Klare Rollenverteilung für direkte Kommunikation und kurze Entscheidungswege
- Gezieltes Dokumentieren von kritischen Informationen als Kriterium für Definition of Done
- Ständige Reflexion des Arbeitsprozesses und Team Dynamik durch regelmäßige Retrospective Meetings

Diese Grundprinzipien erlauben dem Entwicklungsteam vollen Fokus und Stabilität. Zusätzlich dazu wird es für neue Teammitglieder leichter sich schnell in das Projekt zu integrieren und Schritt für Schritt durch strukturierte Planung und direkte, regelmäßige Kommunikation den gewünschten Output zu produzieren.

#### Saubere Anforderungen und eine effektive Teststrategie

Viele haben es wahrscheinlich schon mitgemacht: Das Planungsmeeting geht wiedermal länger als geplant, Grundsatzdiskussionen nehmen die eigentlich wertvoll eingeplante Zeit für die Definition der Akzeptanzkriterien ein und jeder ist froh, wenn man das mühselige Meeting hinter sich lassen und mit der Umsetzung starten kann. Das Problem dabei, die geplanten Stories wurden nicht mehr im notwendigen Detail besprochen, Anforderungen wurden schlampig definiert und es herrscht zu viel Interpretationsspielraum. Dementsprechende Unsicherheit, Fehlinterpretationen und Missverständnisse während der Implementierung führen nun zu möglichen ungewünschten Outcomes und kostspieligen Verzögerungen.

Man sieht, die beiden oben angesprochenen Themen sind auch die Basis für ein sauberes Anforderungsmanagement. Aufbauend darauf ist es ausschlaggebend, die Lösungsspezifikation der Arbeitspakete nicht nur zu diskutieren, sondern auch vollständig und verständlich zu verschriftlichen. Somit wissen sowohl Entwickler und Product Owner genau was definiert wurde, das Risiko für Missverständnisse und zeitaufwendige Abstimmungsmeetings wird minimiert, und die Voraussetzungen für einen effizienten Review und Testing Prozess sind geschaffen.

Werden die Features nun on-time abgeschlossen und präsentiert, kann parallel direkt mit dem Testing angefangen werden während der nächste Sprint bereits in Entwicklung ist. Ergänzend zum bestehenden automatisierten Testing werden somit durch _Continuous Testing_ potenzielle Fehler frühzeitig erkannt und behoben. Dies ermöglicht nicht nur eine höhere Produktqualität, sondern reduziert auch das Risiko von teuren Nacharbeiten und langwierigen Testphasen vor dem Release.

#### Modularisierung von Architekturen für Flexibilität und Skalierbarkeit

Gerade in größeren Softwareprojekten mit einer Vielzahl an Entwicklern, oftmals sogar organisiert in mehreren Teams, kann eine suboptimale Architektur schnell mal zum Bottleneck werden. Je länger das Projekt andauert und die Applikation wächst, desto anspruchsvoller ist in der Regel die Entwicklung jedes einzelnen neuen Features und umso wichtiger ist der Fokus auf einen hoch-qualitativen und vor allem wartbaren Code.

Durch die Aufteilung eines komplexen Systems in unabhängige Module (z.B. bei Domain-Driven-Design) wird die Architektur klar strukturiert und getrennt, was die Flexibilität und Erweiterbarkeit erheblich verbessert. Modularisierung ermöglicht es, Änderungen in einem Teil des Systems vorzunehmen, ohne den gesamten Code zu berühren. Dies trägt zur Fehlerreduzierung bei und erleichtert es, neue Funktionen hinzuzufügen oder bestehende zu optimieren, ohne das gesamte System zu gefährden. Darüber hinaus fördert die Modularisierung die Zusammenarbeit in großen Entwicklerteams, da diese unabhängig voneinander an verschiedenen Teilen der Applikation arbeiten können.

#### Fazit

Um das volle Potenzial eines Entwicklungsteams auszuschöpfen benötigt es angefangen vom Produktmanagement bis hin zur Softwarearchitektur genügend Struktur, solide Planung, klare Rollenverteilung und gezielte Kommunikation. Auch wenn ein funktionierender Prozess gefunden wurde und die Produktivität stimmt, darf man sich nicht darauf ausruhen und muss sich laufend an die sich verändernden Situationen anpassen.

Ganz nach unserem Motto “Good people, good projects” kann natürlich der Entwicklungsprozess noch so feinjustiert sein, es braucht am Ende immer das richtige Team um den Projekterfolg sicherzustellen.


Erfolgsfaktoren für einen effizienten Entwicklungsprozess


Man stelle sich folgendes Szenario vor: Ein intensives Softwareprojekt wird endlich abgeschlossen, der Go-Live verläuft reibungslos und die Projektmitglieder erholen sich tagelang von der wohlverdienten Projektabschluss-Party. Also alles im grünen Bereich - bis dann ein paar Wochen später ein grober Fehler in der Applikation gefunden wird. Der Albtraum von allen Stakeholdern.

Wenn ein Fehler erst zu diesem späten Zeitpunkt gefunden wird, dann kostet die Behebung beispielsweise - jetzt mal ganz einfach gesagt fürs Verständnis - 100 Euro. Zu diesen 100 Euro zählen dann nicht nur die Kosten für die Behebung des Fehlers, sondern auch die Unzufriedenheit und mögliche Rufschädigung des Unternehmens. Hätte man den Fehler früher entdeckt - beispielsweise bei einem Sprint-Review - hätte die Behebung nur 10 Euro gekostet. Und hätte man diesen Fehler schon während der Entwicklung entdeckt? Dann hätten sich die Kosten für die Behebung wohl nur auf einen einzigen Euro belaufen, und es hätte keine potenziell unzufriedene Stakeholder, Rufschädigungen oder andere ärgerliche Folgen gegeben.

Dies ist die sogenannte “Rule of Ten” oder “1/10/100” Regel: Fehler sind mit jedem abgeschlossenen Produktlebenszyklus zehnmal teurer zu beheben. Dass an dieser Regel etwas dran ist - das mussten ehrlicherweise auch wir in der Vergangenheit schon erfahren. Doch wie verhindern wir das heute?

![Die Kosten pro Fehler explodieren exponentiell nach oben, wenn der Fehler in einer späteren Phase des Projekts gefunden wird.](/images/blog/rule-of-ten/rule-of-ten-graph.png 'Die Kosten pro Fehler explodieren exponentiell nach oben, wenn der Fehler in einer späteren Phase des Projekts gefunden wird.')

Wir haben nicht einfach aufgehört, Fehler zu machen: Erstens macht jeder Fehler. Zweitens sind sie nicht absichtlich und deshalb kann man sie auch nicht einfach so abstellen. Drittens lernt man mit dem richtigen Umgang von ihnen, weshalb Fehler nicht immer etwas Schlechtes sind. Deshalb geht es darum, so schnell wie möglich Fehler zu finden und zu korrigieren. Und zwar, bevor man in den nächsten Zyklus oder Sprint rutscht und sich die Behebungskosten verzehnfachen; Stichwort Prävention. Dies erreichen wir durch kompromisslose Qualitätsstandards und strenges Qualitätsmanagement.

Diese Standards reichen von Technologiewahl und DevOps bis zu Workflows und Codequalität. Beispielsweise wird unser Code immer vollautomatisch vom Tool [Sonar](https://www.sonarsource.com/) analysiert: Ist der Code für unsere Standards zu komplex und muss daher vereinfacht werden? Oder gibt es irgendwelche Sicherheitslücken oder Bugs? Anschließend muss noch ein weiteres Teammitglied den Code kontrollieren und freigeben, und erst dann landet er auch wirklich im finalen Projekt. Zusätzlich verwenden wir auch Unit-Tests, wodurch wir die gewünschte Funktion der Komponenten gewährleisten. Mehr zu unseren Qualitätsstandards und unserer Arbeitsweise findest du übrigens [hier](https://fortix.io/the-way-we-do).

Als [“Your partner in crime”](https://www.linkedin.com/posts/fortixio_your-partner-in-crime-activity-7036286285207986176-hX3f) setzen wir auf eine langfristige Zusammenarbeit. Und wie die “Rule of Ten” schön veranschaulicht, profitieren von unserer Qualität langfristig nicht nur die Geldbörsen und das Image unserer Kunden, sondern auch die Kunden von unseren Kunden. Beispiele hierfür sind unsere eindrucksvollen Projekte mit [ZIMA](https://fortix.io/case-study/zima) oder [amKumma](https://fortix.io/case-study/amkumma), die wir nach diesen beschriebenen Standards umgesetzt haben - und auch immer noch umgesetzt werden.


Rule of Ten: Darum ist Prävention wichtiger als Revision


Visual Studio Code ist schon lange eine der führenden IDEs für Webentwickler. Das liegt zweiffellos daran, dass VSCode
schlank und mit einer Vielzahl von Extensions erweitert werden kann. In diesem Post werde ich meine bevorzugten Add-ons vorstellen,
die ich täglich als Angular Entwickler im Einsatz habe.

### [Angular Language Server](https://marketplace.visualstudio.com/items?itemName=Angular.ng-template)

![](/gifs/blog/vscode-extensions/angular-language-server.gif 'Angular Language Server')

Ein absolutes MUSS in der Angular-Entwicklung. Dieses Tool hilft beim Erstellen von Angular Templates mit Autocomplete.
Ohne diese Erweiterung ist es fast unmöglich, fehlerfreie Angular Templates zu schreiben.

### [Angular Schematics](https://marketplace.visualstudio.com/items?itemName=cyrilletuzi.angular-schematics)

![](/gifs/blog/vscode-extensions/angular-schematics.gif 'Angular Schematics')

Das Angular Schematics Plugin erleichtert dir den Aufbau deiner Components. Mit einem Rechtsklick auf den
gewünschten Ordner kann ganz leicht eine neue Komponente hinzugefügt werden. Weitere Eingaben im folgenden Wizard
konfigurieren die neue Komponente, so wird das Erstellen von
[Smart und Dumb Components](https://fortix.io/blog/angular-smart-and-dumb-components) ein Kinderspiel!

### [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner)

![](/gifs/blog/vscode-extensions/vscode-jest.gif 'Jest Runner')

Mit dieser Extension erspart ihr euch eine Menge Zeit beim Schreiben von neuen Unit Tests.
Im Vergleich zu der bekannteren [vscode-jest](https://marketplace.visualstudio.com/items?itemName=Orta.vscode-jest)
Erweiterung, kann Jest Runner einen einzelnen spezifischen Test ausführen. Dazu wird einfach über jedem
Test auf "Run" geklickt, und schon wird der Test im Terminal ausgeführt.

### [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console)

![](/images/blog/vscode-extensions/nx-console-ui-light.png 'Nx Console')

Nx Monorepos kommen bei FORTIX Projekten oft zum Einsatz. In großen Angular Apps wird dazu auch NgRx verwendet. Mit Nx Console
können ganz leicht Libraries, Components, Services uvm. über eine UI generiert werden. Grundsätzlich ist es möglich, jedes Nx CLI Command
mit dieser Console auszuführen. Sobald ihr dieses Tool installiert habt, müsst ihr nie wieder nach einem Nx Command suchen.

### [Prettier - Code formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode)

![](/images/blog/vscode-extensions/prettier.png 'Prettier - Code formatter')

Der wahrscheinlich meistgenutzte Formatter in VSCode. Prettier arbeitet mit einem eigenen [Configuration File](https://prettier.io/docs/en/configuration.html)
mit dem die wichtigsten Formatierungsoptionen festgelegt werden können.

### [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)

![](/images/blog/vscode-extensions/eslint.png 'ESLint')

[ESLint](https://eslint.org/) ist ein Tool für statische Codeanalyse. Mit ESLint können mögliche Probleme und Bugs
noch während der Entwicklung gefunden und behandelt werden. Eigene Regeln und individuelle Konfigurationen für den Code sind ebenfalls möglich.

### [Tailwind CSS IntelliSense](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss)

![](/images/blog/vscode-extensions/tailwind.png 'Tailwind CSS')

Tailwind ist ein CSS Framework welches gerade einen regelrechten Hype erfährt.
Hunderte vordefinierte CSS Klassen werden durch diese Extension leicht auffindbar. Das Arbeiten mit Tailwind wurde für mich durch diese Hilfe erleichtert.

### [Color Highlight](https://marketplace.visualstudio.com/items?itemName=naumovs.color-highlight)

![](/images/blog/vscode-extensions/color-highlight.png 'Color Highlight')

Eine sehr simple Erweiterung die aber einen großen Nutzen hat. Es werden alle CSS/Web Farben im Code farblich hinterlegt.
Zum Beispiel wird dann <span style={{backgroundColor: "#6699cc"}}>#6699cc</span> blau eingefärbt.

Ich hoffe, dass all diese Erweiterungen es euch ermöglichen Zeit zu sparen und produktiver mit Angular zu arbeiten. Wenn
ihr noch weitere VSCode-Erweiterungen kennt die ihr täglich benützt, zögert nicht und meldet euch bei uns über Social Media oder schreibt mir eine [Mail](mailto:adrian.natter@fortix.io).


Die wichtigsten VSCode Extensions für Angular Developers


### Was ist eine native App?

Native Apps werden in der Programmiersprache entwickelt, auf der die jeweilige Plattform aufbaut.
Das sind Objective-C (und Swift) für [iOS](https://www.apple.com/at/ios) und Java (und Kotlin) für [Android](https://www.android.com/intl/de_de/). Das heißt konkret:
Eine App muss für Android und Apple zweimal von Grund auf entwickelt werden. Klingt nach viel Aufwand?
Ist es auch!

Warum werden dennoch heutzutage Apps nativ entwickelt? Der große Vorteil von [nativen Apps](https://www.dev-insider.de/was-ist-eine-native-app-a-827532/) ist die Performance.
Es kann direkt auf die Hardware des Mobilgeräts zugegriffen werden. Wenn eine App also stark auf Funktionen wie Kamera,
Bluetooth oder GPS zugreift, könnte es Sinn machen eine App nativ zu entwickeln. Außerdem werden grafikintensive
Spiele meistens nativ entwickelt, da hier die Rechenleistung des Gerätes besser ausgenutzt werden kann.

Native Apps benötigen in der Regel mehrere Entwickler bzw. Entwickler-Teams, da für iOS und Android zwei grundverschiedene
Entwicklungen durchgeführt werden. Dadurch werden die Aufwände erhöht und die Kosten für initiale Entwicklung und
Wartung steigen rasant an. Unternehmen, die mit dem Gedanken spielen, eine App zu entwickeln, sollten sich daher
gut überlegen, ob der Einsatz von nativen Apps der richtige Ansatz ist bzw. notwendig ist.

![Apps wie Uber sind nativ entwickelt da sie performant sein müssen und viele Funktionen wie GPS benötigen.](/images/uber-unsplash.jpg 'Uber App')

### Was ist eine hybride App?

Hybride Apps werden mit Webtechnologien (HTML, JavaScript und CSS) erstellt. Die Apps laufen dann in einem Container der
native Funktionen bereitstellt. Die App wird somit vom Betriebssystem abstrahiert und nur eine Codebasis ist nötig.
Optisch unterscheidet sich eine hybride App meist kaum von einer nativen App. Der Endbenutzer merkt darum meistens keinen
Unterschied zwischen hybriden und nativen Apps.

Eine Veröffentlichung im App Store ist wie bei einer nativen App ebenfalls möglich. Die Dateigröße der App ist aber im
Vergleich etwas größer und die Benutzung von nativen Funktionen etwas eingeschränkter. Wiederum merken das schlussendlich
die wenigsten Anwender sondern mehr die Entwickler der App.

Es gibt eine vielzahl von Frameworks die die Entwicklung von hybriden Apps vereinfachen. Unter anderem verwenden wir [Ionic](https://ionicframework.com/)
zur Entwicklung von Hybrid-Apps.

### Was sind Progressive Web Apps (PWA)?

Eine [Progressive Web App (PWA)](https://web.dev/progressive-web-apps/) ist eine Webanwendung die Features von nativen Apps bereitstellt. Sie sind somit eine Mischung
aus Webanwendung und nativer App. Der größte Unterschied zu anderen Apps ist, dass PWAs nicht im App Store veröffentlicht
werden können (bzw. nur durch Umwege)!

Eine PWA läuft nämlich im Browser des jeweiligen Geräts und wird, wie eine Webseite veröffentlicht. Benutzer haben beim
Aufrufen der Webseite im Browser die Möglichkeit die App auf ihrem Gerät zu installieren. Vorteil: Eine Webseite kann als PWA
entwickelt werden und dem Benutzer als App zur Verfügung gestellt werden. Zwei Fliegen mit einer Klatsche: Website und App in einem.

Wie bereits erwähnt können [PWAs](https://www.dev-insider.de/die-app-als-pwa--pro-und-contra-a-986616/) auf native Funktionen wie beispielsweise Push-Notification zugreifen. Zudem sind PWAs nach der
Installation offlinefähig. Das Problem bei der Sache ist Apple. Auf iOS Geräten können z.B. keine Push-Notifications versendet werden. Bei Android und Windows funktioniert es einwandfrei. Der Vollständigkeit halber muss auch erwähnt werden, dass eine PWA nicht auf alle nativen Funktionen des Geräts zugreifen kann.

Technisch werden solche Apps mit Web-Technologien umgesetzt. Bei uns ist primär das Framework [Angular](https://angular.io/) im Einsatz. Mit Angular
können unter anderem auch skalierbare Webanwendungen entwickelt werden. Mehr dazu in unserem Beitrag [Enterprise Angular Apps](https://fortix.io/enterprise-angular-apps/).

![Auf iOS kommen keine Push-Notifications einer PWA App an](/images/ios-unsplash.jpg 'iOS PWA')

### Was ist eine Cross-Plattform-App?

Mein persönlicher Favorit sind Cross-Plattform-Apps. Sie verbinden die Vorteile von hybriden und nativen Apps. Es ist möglich mit nur
einer Codebasis für beide Plattformen zu entwickeln, ohne dass es zu starken Einbußen bei der Performance kommt.

Da Smartphones in den letzten Jahren immer leistungsfähiger geworden sind fühlen sich Cross-Plattform-Apps so flüssig an wie native
Apps. Zusätzlich können native Features wie Push-Notification und GPS analog wie bei nativen Apps verwendet werden.

Berühmte Cross-Plattform Frameworks sind Xamarin, React Native oder [Flutter](https://flutter.dev/). Mit Flutter haben wir schon sehr gute Erfahrungen
gesammelt und können es wärmstes weiterempfehlen. Mehr über Flutter findest du in unserem Beitrag: [Flutter – Das Werkzeug für native
Apps in Rekordzeit](https://fortix.io/flutter-das-werkzeug-fur-native-apps-in-rekordzeit/)

### Fazit

Wie so oft ist es nicht Schwarz-Weiß. Je nach Anwendungsfall gibt es unterschiedliche Möglichkeiten eine App umzusetzen. Generell muss man
sich folgende Frage stellen:

- Wie abhängig ist die App von der Hardware des Geräts?
- Kann das Projekt auch als Webanwendung umgesetzt werden?
- Ist eine Veröffentlichung im App bzw. Google Play-Store gewünscht/notwendig? (Allein bei dieser Frage gibt es zahlreiche Argumente
  dafür und dagegen).

Es gibt Anwendungsbereiche, die eine native Entwicklung erfordern. Dennoch sprechen viele Argumente (immer mehr) für die Entwicklung
von Cross-Plattform-Apps. Wer voll auf Performance setzt kommt früher oder später um eine native Entwicklung nicht herum. Wer
andererseits eine App möchte, die plattformunabhängig und einen schnellen Proof-of-Concept der App benötigt, fährt mit Cross-Plattform-Apps
oder hybriden Apps besser.

Wenn du wissen möchtest, welches App Format sich für dein Projekt eignet kannst du uns gerne kontaktieren. Wir helfen dir gerne weiter!


Native, PWA, Hybrid und Cross-Plattform Apps einfach erklärt


Wordpress ist das meistgenutzte CMS der Welt. Dennoch gibt es zahlreiche Diskussionen, ob WordPress eine technisch „seriöse“ Lösung ist. Es scheint als hätte WordPress den Ruf ein „Bastler-Set“ für Jedermann zu sein, welches aber technologisch nicht ausgereift ist. Kritisierte Punkte sind unter anderem Performance, Sicherheit und Einschränkung des Designs. Eine Frage mit der wir öfters konfrontiert sind lautet: „Ist WordPress gut genug für meine Anwendung?“

Von vorne Weg: WordPress und FORTIX waren lange auf Kriegsfuß miteinander. Aufgrund der großen Verbreitung stoßt man in Web-Projekten regelmäßig auf das CMS. Deshalb setzten wir uns verstärkt mit dem CMS auseinander. Je mehr wir in die Tiefe abtauchten, wo der sagenumwobene WP-Core wartete, desto leichter fiel es uns, WordPress zu schätzen.

### Wie man WordPress nicht verwenden sollte:

Eine Website kann mit wenig technischem Knowhow „entwickelt“ werden. Frei nach dem Motto „Heutzutage kann jeder Web-Entwicklung“. Oft werden fertige Templates oder Page-Builder wie [Elementor](https://elementor.com) herangezogen. Für einen Basisfall (One-Pager mit statischen Informationen) mag das auch funktionieren, allerdings läuft der ungezielte Einsatz von solchen Instrumenten oft auf unterirdische Werte im Bezug auf Performance, Wartbarkeit, Erweiterbarkeit und Modularität hinaus. Hier noch ein Plugin und dort noch eines und schwups – das Chaos ist perfekt. Manche Plugins werden in weiterer Folge gar nicht mehr gewartet (führt zu Sicherheitslücken), manche Updates gehen schief und irgendwann weiß man gar nicht mehr, welches Plugin welchen Anwendungsfall erfüllt. Fällt dann auch noch der über 3-Ecken bekannte „Entwickler“ weg, wird es kritisch. Spätestens dann sucht man sich Hilfe vom professionellen Entwickler. Die Empörung der Seitenbetreiber ist dann oft groß, wenn die Diagnose heißt: „[Sie reiten hier ein totes Pferd.](https://www.youtube.com/watch?v=RaTxNCQcYis&ab_channel=%C3%96sterreichischeAlternative) Da kann man nichts mehr machen. Ich rate die Website neu zu entwickeln.“

Heißt das man soll keine Page-Builder verwenden? Nein! Der richtige Anwendungsfall muss gegeben sein und zumindest ein Grundverständnis für Web-Entwicklung sollte vorhanden sein. Das Weiße Haus setzt auf der Seite den klassischen [Gutenberg-Editor](https://de.wordpress.org/gutenberg/) ein, während bei einigen unserer Projekte Elementor zum Einsatz kommt (z.B. Website [Hagen Management](https://hagen.management/), [Gerd am Herd](https://gerd-am-herd.at/), und teilweise auch bei unserer eigenen Seite).

Und was ist mit Plugins? Auch hier ist es ähnlich. Der gezielte Einsatz ist entscheidend. Die WordPress-Community ist riesig. Dementsprechend werden sowohl gute als auch schlechte Plugins angeboten. Hier heißt es abwägen und recherchieren. Wer steckt hinter dem Plugin? Hobby-Coder oder Unternehmen? Bei wie vielen Seiten ist das Plugin im Einsatz? Wird das Plugin gewartet? Gibt es regelmäßige Updates? Und und und. Ein Klassiker bei uns ist z.B. das SEO-Plugin Yoast. Auch die neue White House Seite hat [Yoast](https://yoast.com/) in Verwendung.

Wir kratzen hier noch an der Oberfläche. Sobald der Anwendungsfall komplexer wird, muss gesondert evaluiert werden, ob bzw. wie WordPress eingesetzt werden kann. Grundsätzlich ist WordPress sehr flexibel und bietet Entwicklern gut dokumentierte [APIs](https://developer.wordpress.org/rest-api/) und [Hooks](https://developer.wordpress.org/plugins/hooks/) an. Somit stehen konzeptionell einige Türen offen, wie z.B. die Trennung zwischen Front- und Backend. Dabei nutzt man die Stärken von WordPress und kombiniert diese mit Technologien wie beispielsweise Angular, Vue oder React. Wer mehr darüber erfahren will, sollte sich mit dem Thema Headless-CMS auseinandersetzen. Speziell um [Gatsby](https://www.gatsbyjs.com/) entwickelte sich in den letzten Monaten ein Hype.

Tiefer will ich hier nicht gehen, sonst sprengt es den Rahmen. Das Fazit lautet: WordPress ist das meistverwendete CMS der Welt. Das heißt schon mal was. Zunächst von uns kritisch beäugt, entwickelte sich WordPress mit fortlaufendem Wissenstand zu einer technischen Variante, auf die wir oft und gerne zurückgreifen. Wie WordPress eingesetzt wird, hängt dabei immer vom Anwendungsfall ab. Pauschale Aussagen sind nicht möglich und unseriös. Wie immer in der Entwicklung ist der Schlüssel zum Erfolg das einhalten von Best-Practices und [Standards](https://fortix.io/die-12-faktoren-app/). Das gilt auch im WordPress-Umfeld. Abschließend zurück zur Frage, ob WordPress nicht zu „schwach“ für das eigene Vorhaben ist? Wenn Joe Biden und das Weiße Haus auf WordPress setzen, dann stehen die Chancen nicht schlecht, dass WordPress auch für Dein digitales Projekt eine spannende Alternative bietet.


Web Entwicklung

Angular – Smart und Dumb Components

Share this post

Weitere Blogs

Eine Auswahl unserer letzten Blogs

Entwicklungs-Turbo: Nx Monorepos für Angular-Apps

Erfolgsfaktoren für einen effizienten Entwicklungsprozess

Rule of Ten: Darum ist Prävention wichtiger als Revision

Die wichtigsten VSCode Extensions für Angular Developers

Native, PWA, Hybrid und Cross-Plattform Apps einfach erklärt

US-Wahl 2020 aus technischer Sicht: Was Joe Biden mit WordPress zu tun hat