
Spätestens seit dem Release von Version 17 ist klar, dass das Angular Team eine neue Richtung einschlagen will. Im Mittelpunkt davon: Angular Signals. Diese sollen den Einstieg in die Angular Welt erleichtern, die Change Detection optimieren und das kontroverse RxJS zu einem optionalen, allerdings immer noch mächtigen, Werkzeug anstatt integralen Bestandteil des Frameworks machen.

Das NgRx Team hat zeitgleich mit dem Angular 17 Release die erste Version der @ngrx/signals Library veröffentlich und bietet damit direkt eine flexible und einfache Möglichkeit zum signal-based State Management an. Der darin enthaltene lightweight Signal State und etwas umfangreichere Signal Store sind dabei komplett abgekapselt zum bereits etablierten RxJS-based NgRx Store und Component Store zu betrachten.

Doch inwieweit unterscheidet sich der Signal Store von bisherigen State Management Lösungen, welche Features kommen out-of-the-box mit und ist eine zusätzliche externe Library überhaupt notwendig für das State Management von Signals? Wir haben den NgRx Signal Store bereits seit einem halben Jahr im Einsatz und ziehen Fazit.

#### Signal State

Wie bereits erwähnt gibt es zwei verschiedene Ausprägungen der NgRx Signals Library. Der Signal State ist eine lightweight und minimalistische Utility zum Verwalten von signal-based State. Dieser eignet sich beispielsweise besonders gut für abgekapselte States auf Komponenten Ebene. Dazu wird einfach die signalState Funktion aus dem Package eingebunden und mit dem initialen State initialisiert.

```jsx
import { signalState } from '@ngrx/signals';

const userState =
  signalState <
  UserState >
  {
    firstName: 'John',
    lastName: 'Doe',
    address: {
      street: 'Street 1',
      zip: 1234,
    },
  };
```

Sieht auf den ersten Blick nicht viel anders aus als ein gewöhnliches Angular Signal, unterscheidet sich aber folgendermaßen:

- **Deep Signal:** Der Signal State erzeugt im Hintergrund nicht nur für das userState Objekt ein readonly Signal, sondern zusätzlich auch für jedes verschachtelte Property. Somit kann beispielsweise die address Property mit userState().address und userState.address() ausgelesen werden und erlaubt für “fine-grained reactivity”. Konsumenten des Signals können den State also auf Property Ebene auslesen und werden bei anderen Änderungen des States nicht benachrichtigt und unnötige Change Detection Cycles bleiben erspart.
- **Immutable State Updates:** Um unerwartete Side Effects zu verhindern, bietet die patchState Funktion die Möglichkeit an den State auf eine kontrollierte Art und Weise zu aktualisieren.

```jsx
import { patchState } from '@ngrx/signals';

patchState(userState, { firstName: 'Jane' });
patchState(userState, (state) => ({ address: { ...state.address, zip: 5678 } }));
```

Zusätzlich dazu können auch wiederverwendbare State Updaters erstellt werden.

```jsx
import { PartialStateUpdater } from '@ngrx/signals';

function setZip(zip: number): PartialStateUpdater<{ address: Address }> {
  return (state) => ({ address: { ...state.address, zip } });
}

patchState(userState, setZip(5678));
```

Dieser funktionelle Ansatz zum State Management ermöglicht hohe Flexibilität und deckt wahrscheinlich die Anforderungen der meisten Use Cases ab.

#### Signal Store

Mit dem Signal Store hat NgRx die Basis Funktionalität des Signal States um einige Features erweitert und ist in der Lage komplexeren Anforderungen gerecht zu werden. Der Store wird mit der signalStore Funktion erstellt und liefert ein Injectable Service zurück. Der generierte Service kann entweder in root provided werden und als Singleton einen applikationsweiten State verwalten oder direkt in Komponenten provided werden und als Component Store eingesetzt werden. Der Signal Store umfasst folgende Konzepte:

- `withState`: Analog zum signalState kann mit der withState Funktion der initiale State des Stores gesetzt werden.
- `withComputed`: Basierend auf den initial erstellten Signals können direkt im Store berechnete Werte (Computed Values) definiert werden. Damit kann featurespezifische Logik von der Komponente in den Store ausgelagert werden und hilft dabei die Komponenten schlank zu halten.
- `withMethods`: Um zu vermeiden, dass der State von überall in der Applikation aktualisiert werden kann, werden mit der withMethods Funktion die State Update Logik bereit gestellt und führt mögliche asynchrone Side Effects entweder mit Promises aus oder wie bisher mit RxJS mithilfe der rxMethod Funktion.
- `rxMethod`: Wer nicht komplett auf die Stärken der RxJS Operators verzichten will, kann ganz einfach mit rxMethod Funktionalität ausgehend von einem Observable Stream ausführen. Entweder durch manuelle Trigger oder als Reaktion auf einen Signal Change emitted das Source Observable einen neuen Wert und macht es so möglich komplexere Side Effects zu handhaben.
- Lifecycle Hooks: Die mitgelieferten onInit und onDestroy Hooks machen den Store noch unabhängiger und in sich konsistent. Man sieht beispielsweise auf einen Blick, wie sich der initiale State zusammensetzt, ohne die gesamte Applikation für Methodenaufrufe durchsuchen zu müssen.
- Custom Features: Das auf den ersten Blick vielleicht unscheinbarste Feature ist womöglich das Mächtigste. Der Signal Store ermöglicht es wiederkehrende State Logik in eigene Features zu kapseln, die je nach Bedarf in den Store eingebunden werden. So kann man beispielsweise eine Loading/Error State Logik (inklusive State Properties, Computed Properties, Methods, etc.) auslagern und jeder Store der dieses Features aktiviert kann mit nur einer Code Zeile auf diese Logik aufbauen. Die perfekte Ausgangssituation für eine flexible Softwarearchitektur.

Ein Beispiel für einen simplen Signal Store könnte folgendermaßen aussehen.

```jsx
import { patchState, signalStore, withComputed, withMethods, withState} from '@ngrx/signals';
import { rxMethod } from '@ngrx/signals/rxjs-interop';
import { withLoadingState } from '../loading-state-feature';
[...]

const initialState: UsersState = {
  users: [],
  filter: ''
};

@Injectable({ providedIn: 'root' })
export class UserStore extends signalStore(
  withState(initialState),
  withLoadingState(), // <- Activate Custom Feature to access isLoading property
  withComputed(({ users, filter }) => ({
    usersCount: computed(() => users().length),
  })),
  withMethods((store, usersService = inject(UsersService)) => ({
    updateFilter(filter: string): void {
      patchState(store, { filter });
    },
    connectFilter: rxMethod<string>(
      pipe(
        debounceTime(300),
        distinctUntilChanged(),
        tap(() => patchState(store, { isLoading: true })),
        switchMap((query) => {
          return usersService.getByFilter(filter).pipe(
            tapResponse({
              next: (users) => patchState(store, { users }),
              finalize: () => patchState(store, { isLoading: false }),
            })
          );
        })
      )
    ),
  })),
  withHooks({
    onInit(store) {
      store.connectFilter(store.filter);
    },
  })
);
```

#### Fazit

Durch den funktionellen Ansatz und der flexiblen Anwendung bringt der Einsatz der Library viele Vorteile und wenige bis keine Nachteile mit. Das State Management verleiht der Applikation ausreichend Struktur und eine einheitliche Architektur bei geringem Overhead und gleichzeitig minimaler Vergrößerung der Bundle Size.

Unsere wichtigsten Erkenntnisse:

- **Flexibilität:** Je nach Feature oder Komponente kann der Store als Component Store oder globaler App Store eingesetzt werden. Sollte unklar sein, an welcher Stelle der App Struktur der Store erstellt und eingebunden wird, gilt als Faustregel den Store so spezifisch wie möglich zu integrieren. Sollte es notwendig sein, den Store globaler zu machen, ist das mit wenig Aufwand möglich. Somit können unnötige Abhängigkeiten einfach vermieden werden.
- **Schlanke Komponenten:** Mit der withComputed Methode lässt sich Komponentenlogik einfach und an einer Stelle im Store definieren und sorgt dafür, dass die Komponenten möglichst klein und wartbar bleiben. Der Einsatz von Computed State Properties versichert stabile und berechenbare Change Detection Cycles.
- **Custom Features:** Generische und wiederkehrende Logik lässt sich unkompliziert in eigene Files auslagern und fördert eine flexible Architektur.

Gerade in Projekten mit begrenztem vorhandenen RxJS Know How erleichtert der Signal Store die initiale Implementierung des State Managements und das Onboarding neuer Entwickler. Die Architektur des klassischen NgRx State Management mit strikter Trennung von Actions, Effects, Reducers und Selectors hat natürlich Vorteile in größeren Projekten, ist die etabliertere Lösung und ist von vielen Teams möglicherweise noch die präferierte Option. Dennoch sehe ich die den Signal State/Store als die flexiblere und einfachere State Management Lösung an, vor allem aufgrund des Shifts in Richtung Signals im Angular Framework.


NgRx Signal Store – worth the hype?


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


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


Ein sehr oft eingesetztes Konzept ist die Unterteilung von Angular Components in Smart und Dumb Components (oder Container und Presentational Components).

Kurz und knackig lassen sich Smart und Dumb Components so unterscheiden:

- eine Smart Component kann externe Abhängigkeiten haben und darf Nebeneffekte triggern (z.B.: API Calls)
- eine Dumb Component hat keine externe Abhängigkeiten und produziert keine Nebeneffekte. Kommunikation mit der Parent Component soll nur über `@Input()` und `@Output()` [Decorators](https://angular.io/guide/inputs-outputs) erfolgen.

Smart Components beinhalten meistens mehrere Dumb Components und werden meistens direkt von einer Route aufgerufen und triggern das Laden von Daten aus einem Service Layer. Eine klassische Smart Component ist eine Liste, die bei Initialisierung Daten lädt:

![Eine Liste als Smart Component](/images/pet-list-component.png 'Eine Liste als Smart Component')

Dumb Components nehmen Daten entgegen und zeigen diese an. Zusätzlich lösen sie Events aus, auf denen die Smart Components reagieren können. Sie haben keinen Zugriff auf Services, um Daten auszulesen bzw. zu speichern. Diese Eigenschaften machen Dumb Components sehr leicht an verschiedenen Stellem wiederverwendbar in unserer App. Zum Beispiel können wir eine Card Component erstellen, um Daten in einer Material Card anzuzeigen:

![Card als Dumb Component](/images/card-component.png 'Card als Dumb Component')

Ein weiterer Vorteil ist, dass in Dumb Components die Angular Change Detection auf [OnPush](https://angular.io/api/core/ChangeDetectionStrategy) gestellt werden kann. Angular führt die ChangeDetection nun nicht mehr automatisch aus, sondern wartet darauf, bis sich die Werte in den `@Input()` Decorators ändern. Dies reduziert den Change Detection Zyklus dramatisch und bringt bei großen Applikationen einen riesigen Performance Boost.

Wir haben durch Anwenden dieses einfachen Patterns, die Wiederverwendbarkeit von Components und die Performance in einigen Angular Applikationen schon steigern können.

Wenn du noch Fragen speziell zu Angular hast oder Unterstützung bei der Entwicklung von skalierbaren Apps brauchst, melde dich einfach bei uns unter [office@fortix.io](mailto:office@fortix.io).


Angular – Smart und Dumb Components


Angular bietet umfangreiche Features an. Trotzdem muss der Einsatz – wie bei jeder anderen Technologie auch – mit Bedacht gewählt sein. Angular als eierlegende Wollmilchsau zu bezeichnen wäre somit falsch. Beispielhaft würden wir derzeit bei der Entwicklung einer multi-Page E-Commerce Plattform nicht auf Angular setzen, sondern auf traditionelle Web-Technologien wie PHP bzw. WordPress. Angular glänzt aber bei der Umsetzung von sogenannten [Single-Page-Webanwendungen](https://de.wikipedia.org/wiki/Single-Page-Webanwendung) (single-page application, kurz SPA). Technisch gesehen handelt es sich bei einer SPA um eine Webanwendung, die aus einem einzigen HTML-Dokument besteht und deren Inhalt dynamisch geladen wird. Zum Vergleich: Bei Multi-Page-Webanwendungen wird bei jedem Klick ein neues HTML-Dokument vom Server generiert und an den Benutzer geschickt.

![Angular kommt oft bei internen Dashboards in Unternehmen zum Einsatz](/images/dashboard-unsplash.jpg 'Angular Dashboard')

Der Code in Angular wird in [TypeScript](https://www.communardo.de/blog/drei-gruende-warum-typescript-das-bessere-javascript-ist/) geschrieben. TypeScript ist eine Erweiterung von JavaScript, welches auf die Typisierung von Objekten setzt. Eine spannende Option, um sich gegen Laufzeitfehler zu schützen. Fehler und Bugs können daher früh im Entwicklungsprozess gefunden und behoben werden. Auch das Debuggen in Editor und Browser gestaltet sich mit TypeScript angenehmer. Die UI wird mit bewährten HTML und CSS umgesetzt. Angular bietet die Möglichkeit Module zu erstellen, die wiederum aus mehreren Komponenten bestehen. Diese Unterteilung vereinfacht das automatisierte Testen des Codes und erhöht die Wartbarkeit von Angular Projekten.

Welche Enterprise Applikationen wurden mit Angular schon umgesetzt? Laut Stephen Fluin, Developer Relations Lead bei Google, kommen Angular Applikation zu [90% im internen Unternehmensnetzwerk](https://sdtimes.com/webdev/angular-powers-business-apps-in-the-enterprise/) zum Einsatz. Unternehmen erstellen Angular Applikationen für den internen Gebrauch, um ihre Businessprozesse zu beschleunigen und Arbeitsabläufe zu vereinheitlichen.

Neben Google setzen viele weitere Konzerne auf Angular, um ihre digitalen Plattformen umzusetzen. Eine nicht vollständige Liste gibt es unter [madewithangular.com](https://www.madewithangular.com/categories/angular/).

[FORTIX](https://fortix.io/) hat schon einige Web-Anwendungen in Angular umgesetzt und kann Ihrem Unternehmen Expertise in diesem Bereich bieten. Für ein unverbindliches Beratungsgespräch stehen wir gerne zur Verfügung.


Enterprise Angular Apps


### Der barrierefreie Zugang zu Websites ist noch längst kein Standard.

![](/images/probleme-barrierefreier-zugang.png)

Gerade Designer und Entwickler in der Softwarebranche haben eine extrem wichtige Position. Sie sind das Nadelöhr zwischen Menschen und der digitalen Welt und tragen somit auch die Verantwortung, diese Welt so barrierefrei wie möglich zu gestalten. Stichwort Universal Design (Nutzungsmöglichkeit, Flexibilität, Intuition, Aufbereitung Informationen, Fehlertoleranz, geringer körperlicher Aufwand, Größe & Freiraum für Zugang). Besucher sollen unabhängig von ihrer persönlichen Einschränkung alle Inhalte aufnehmen können. Das Ziel: Visuell ansprechende aber auch durch technische Hilfsmittel erkennbare digitale Inhalte.

### EU-Richtlinie 2016/2102

Dieses Anliegen verfolgt auch das Gremium World Wide Web Consortium (W3C), welches versucht, einen Standard zur Barrierefreiheit im Web, zu erreichen. Um an das Ziel zu gelangen, hat das W3C einen Leitfaden bestehend aus zwölf Richtlinien veröffentlicht, die auf den vier Prinzipien wahrnehmbar, bedienbar, verständlich & robust beruhen. Darin enthalten sind Alternativen, wie zum Beispiel eine Audiodeskription eines Videos, und Empfehlungen, wie e.g. der Verzicht auf aufblitzende Elemente.

### Welche Barrieren können auftreten?

- Technische Einschränkungen
  - Inhalte sind nicht für die Ausgabe mittels Unterstützungs-technologie abrufbar, kaputter Smartphone-Lautsprecher
- Beeinträchtigung der Sehkraft
  - Totale Farbenblindheit, Gelb/Blau-Rot/Grün-Farbenblindheit, Weitsichtigkeit, Tunnelblick, Sonnenschein
- Einschränkungen des Hörens
  - Taube Personen
- Motorische Beeinträchtigung
  - diverse körperliche Barrieren
- Beeinträchtigung des Lesens & Schreibens
  - Legasthenie, Wortschatz
- Konzentrations-Schwierigkeiten
  - e.g. ADHS

### Wie erleben Menschen mit Beeinträchtigung eine Website?

Um sich zu sensibilisieren und ein Gespür dafür zu bekommen, wie Websites für beeinträchtigte Personen aussehen, gibt es ein Chrome Plugin, welches unterschiedliche Beeinträchtigungen simuliert:

[https://chrome.google.com/webstore/detail/web-disability-simulator/olioanlbgbpmdlgjnnampnnlohigkjla](https://chrome.google.com/webstore/detail/web-disability-simulator/olioanlbgbpmdlgjnnampnnlohigkjla)

Um darauf reagieren zu können, stellt Chrome mit den Entwicklertools über Lighthouse eine Analyse von Websites zur Verfügung, die die Barrierefreiheit überprüft.

![](/images/lighthouse.png 'Lighthouse')

### Worauf können wir beim Erstellen einer Website achten?

- Klare Trennung von Inhalt, Struktur & Design
  - für eine bessere Übersichtlichkeit
- Skalierbarkeit beachten
  - em- oder %-Angaben
- Reaktionsfähigkeit
  - Einhalten der Struktur mit h1, h2, h3 etc.
- HTML-Grundbegriffe
  - für das Einbinden individueller Styles
- Navigation
  - Steuerung durch Tastatur
- Kontraste
  - Farben wählen mit hohem Kontrast, so gibt es keine Probleme bei Farbenblindheit
- Hochdeutsch
  - damit Programme den Inhalt lesen können
- Einfache Sprache
  - sodass Sätze nicht zu komplex werden und nachvollziehbar sind
- Metadaten
  - Title-Tags & Meta-Description nutzen, damit die Suche vereinfacht wird
- Text-/Bildalternativen
  - Screenreader benötigen sie für die Sprachausgabe
- Keine wichtigen Inhalte verstecken
  - wie Impressum oder Kontakt

„Das Internet sorgt schon heute dafür, dass Menschen mit Behinderungen autonom und selbstbestimmt an der Gesellschaft teilhaben können.“

– Iris Hobler, Coachin & Journalistin

Durch das Anpassen der Inhalte profitiert schlussendlich nicht nur der Nutzer: Die Zielgruppe erweitert sich, da ein größerer Personenkreis das Angebot uneingeschränkt erfahren kann. Eine Reduzierung der Entwicklungs- und Instandhaltungskosten bringt den Vorteil, dass Inhalte leicht ausgetauscht werden können. Und durch die Möglichkeit, die Website auf mobilen Geräten optimiert anzuzeigen, kann auf eine zusätzliche mobile Version verzichtet werden. Eine saubere Struktur bringt wiederum SEO-Vorteile mit sich.

Geben wir den ca. [1,7 Mio. Menschen mit temporärer oder dauerhafter Beeinträchtigung in Österreich](http://www.statistik.at/wcm/idc/idcplg?IdcService=GET_PDF_FILE&dDocName=111234) die gleiche Chance im Web ohne Schwierigkeiten zu surfen, wie es Personen ohne tun können.


Barrierefreier Zugang im Web


### Was sich ab Mai 2021 im Google Ranking ändert.

Die Core Web Vitals stellen neue Faktoren zur Messung und Bewertung einer Website dar.

Die Nutzerfreundlichkeit im Web wird in Zukunft immer mehr von Bedeutung sein. Google als Marktführer ist dabei ganz vorne mit dabei, dies zu gestalten. Und wie letztes Jahr bereits von Google angepriesen, soll es im Jahr 2021 Änderungen im Google-Suchmaschinen-Ranking geben.

> We're announcing that page experience ranking signals for Google Search will launch in May 2021. This will combine Core Web Vitals and previous UX-related signals.
>
> Learn more: [https://t.co/OrrR8LDl1a](https://t.co/OrrR8LDl1a)
>
> — Google Search Central (@googlesearchc) [November 10, 2020](https://twitter.com/googlesearchc/status/1326192937164705797?ref_src=twsrc%5Etfw)

Nun ist es soweit und zum 1. Mai 2021 werden neue Faktoren hinzugezogen, die sogenannten Page Experience Signals. Sie fallen unter die Core Web Vitals und messen & stellen die Nutzerfreundlichkeit von Websites in den Fokus. Hauptaugenmerk liegt hier auf der mobilen Nutzerfreundlichkeit, verbunden mit der technischen Performance. Zurückzuführen ist diese Entscheidung auf die weltweit hohe Anzahl (über 70%) an mobilen Besuchern von Websites. Damit gibt Google – der in meinen Augen immer noch unzureichenden – mobile-first-Entwicklung einen Schub.

### Wie sah das organische Google-Ranking bisher aus (vereinfachte Darstellung)?

**Keywords**  
Wer auf seiner Website mit Keywords arbeitet, wird dafür bei der Suche belohnt: Die Suchmaschine geht bei der Eingabe derer während der Suche davon aus, dass die Seiten, die diese Wörter enthalten, relevant für die Suchanfrage sind. Google selbst analysiert sie und bildet eine Wolke aus inhaltlich verwandten Wörtern und Synonymen.

**Struktur und Sauberkeit**  
Experten sehen die Struktur einer Website als ein ebenso wichtiges Element an, welches bei der Erstellung von Websites unbedingt beachtet werden sollte. Dazu zählen Aufzählungen, Nummerierungen und Tabellen. Ebenso spielt die Ladegeschwindigkeit eine entsprechende Rolle: Sauberer Code, optimierte Grafiken und sinnvolle Stylesheets wirken sich positiv im Ranking aus.

**Links**  
Damit Besucher schnell und gezielt zum gewünschten Suchergebnis gelangen können, berücksichtigt Google die Verlinkung zu weiteren Seiten beim Ranking.

**HTTPS**  
Damit sicheres Surfen als Service von Google gewährleistet werden kann, belohnt sozusagen Google das Surfen unter HTTPS mit einem besseren Ranking.

„Was nicht rankt, wird rankend gemacht.“

– Unbekannt

### Was ändert sich ab 1. Mai 2021?

Zukünftig werden neben diesen Faktoren drei weitere in die Bewertung aufgenommen, die Core Web Vitals. Dazu zählen Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) und First Input Delay (FID). Sie bewerten die Qualität einer Website und haben technische Zusammenhänge, welche innerhalb der ersten Sekunden des Besuches von immenser Bedeutung sind.

![](/images/core-web-vitals-blog.png 'Core Web Vitals')

**Largest Contentful Paint**  
Wie lange dauert es, bis einem Besucher der visuell sichtbare, größte Inhalt angezeigt wird? Grund dafür, den größten Block in die Bewertung miteinzuberechnen, ist die Annahme von Google, dass es sich dabei um den relevantesten Inhalt handelt, welcher eben durch die Suchanfrage gefunden werden soll. Tipps für gute Ergebnisse:

- Dateigrößen optimieren
- Frameworks anstelle einer üppigen HTML-Seite
- Einbindung von Content Delivery Networks

- Nutzen von Server-Caches
- Externe Quellen zeitig verbinden
- Wenig Einsatz von CSS und JS

**Cumulative Layout Shift**  
Wer kennt es nicht? Beim Besuch einer Website verschiebt sich ruckartig der Inhalt und ehe ich den gesuchten Button betätigen kann, bin ich bereits am Seiten-Ende und muss erneut nach ihm suchen. Genau hier setzt CLS an: Google misst, wie oft und wie weit sich Elemente ohne die Interaktion des Besuchers verschieben. Diese beiden Werte werden zusammengelegt und stellen das neue CLS dar. Tipps für gute Ergebnisse:

- Schriftarten vorab laden
- Content-Blöcke im Quelltext hinterlegen

**First Input Delay**  
Bei First Input Delay geht es darum, wie lange eine aufgerufene Website braucht, auf eine Eingabe des Besuchers zu reagieren. Hierbei sind die Servergeschwindigkeit und der Browser von Belang, welche dem Besucher eine leichte Bedienung ermöglichen sollen. Tipps für gute Ergebnisse:

- Wichtigste Elemente als Erstes laden

- Kleine JS-Teile

Es lässt sich festhalten, dass Google nun großen Wert auf mobile-freundliche Websites legt. Durchaus wahrscheinlich ist, dass sich die Schwellenwerte dafür, was als schnell oder nicht schnell gilt, in Zukunft ändern werden.


Änderungen im Google Ranking – Die Core Web Vitals


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.


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


Die Twelve-Factor App Methode lässt sich auf Software anwenden, die in jeder beliebigen Programmiersprache (C#, Java, TypeScript, PHP, Python, …) entwickelt wird. Die Methode unterstützt zudem eine beliebige Kombination von Diensten (Datenbank, Message Queue, Cache, …). Die Konzepte können ebenfalls auf jedes beliebige Framework, wie das Web-Framework [Angular](https://angular.io/) oder das Mobile-Framework [Flutter](https://flutter.dev/), angewendet werden.

Wir haben die 12 Faktoren in einer Checkliste zusammengefasst:

### 1. Codebasis

Änderungen am Code sollen mit Hilfe von Versionsverwaltung getrackt werden. Mit Tools wie [Git](https://git-scm.com/) wird die Zusammenarbeit im Team erst ermöglicht. Dabei hat jeder Entwickler seine eigene Version des Codes und der Single-Point-of-Truth ist der Code in der Versionsverwaltung (repository). Für einen Release der Software wird der Code im Repository dann kompiliert, getestet und in der Cloud bereitgestellt.

### 2. Abhängigkeiten

Softwareabhängigkeiten (dependencies) sind externe Bibliotheken, die in vielen verschiedenen Apps verwendet werden können. Falls externe Bibliotheken verwendet werden, müssen diese explizit in einem „package manager“ spezifiziert werden. Es darf nie die Annahme getroffen werden das eine Abhängigkeit auf einem System schon vorhanden ist.

### 3. Konfiguration

Die Konfiguration einer App ist alles was sich wahrscheinlich zwischen verschiedenen Bereitstellungen (dev, test, staging, production) verändert. Konfigurationen dürfen nicht als Konstanten im Code gespeichert werden. Konfiguration und Code müssen immer strikt getrennt sein. Am besten wird die Konfiguration in Umgebungsvariablen (env) gespeichert. Dadurch wird ausgeschlossen, dass versehentlich [Zugangsdaten](https://dzone.com/articles/git-secrets-api-keys) in die Versionsverwaltung eingecheckt werden 😉

### 4. Unterstützende Dienste

Ein unterstützender Dienst ist jeglicher Dienst, den die App über das Netzwerk abruft. Dazu zählen zum Beispiel Datenspeicher (SQL/No-SQL Datenbanken, Objektspeicher), Message-Queue Systeme (RabbitMQ, Google Cloud Pub/Sub, …) oder SMTP-Dienste für das Senden von E-Mails (Sendgrid, [Mailchimp](https://mailchimp.com/de/), …). Jeder Dienst soll über eine URL, die in der Konfiguration gespeichert ist, erreichbar sein. Wenn z.B. eine Datenbank ausgetauscht wird, soll keine Änderung am Code erfolgen. Änderungen sollen lediglich über die Konfiguration gemacht werden.

### 5. Build, Release, Run

Jede Codeänderung muss diese drei Phasen durchlaufen. Es soll nicht möglich sein, Änderungen am Code während der Laufzeit zu machen. Um diese Phasen zu automatisieren soll ein CI/CD Tool (Travis CI, Jenkins, Bitrise, …) verwendet werden. Neue Build‘s werden durch die Entwickler der App ausgelöst, indem sie neuen Code in die Versionsverwaltung einchecken. Somit ist jeder Build eindeutig auf eine bestimmte Version des Codes zurückzuführen.

### 6. Prozesse

Die App sollte auf einer [„Shared Nothing“](https://de.wikipedia.org/wiki/Shared_Nothing_Architecture) Architektur aufgebaut werden. D.h. die App ist unabhängig von anderen Apps und kann einen eigenen Prozessor und Speicher verwenden. Ein Abstürzen der Applikation darf nie dazu führen das andere Services beeinträchtigt werden. Alle Daten, die von der App verwendet werden, müssen in einer Datenbank gespeichert werden. Dies garantiert die Skalierung unter hoher Last, da nahezu unbegrenzt neue Instanzen der App gestartet werden können. 🚀

### 7. Bindung an Ports

Eine Zwölf-Faktoren-App soll nicht an einen Anwendungscontainer wie Apache Tomcat gebunden sein. Die Anwendung soll einen eigenen Web Server o.ä. integrieren, damit diese über einen bestimmten Port erreichbar ist.

### 8. Nebenläufigkeit

Die Anwendung soll anhand von Prozesstypen wie Hintergrund-, Web- und Worker-Prozessen in unabhängige Prozesse aufgeteilt werden. Somit kann eine einfache Skalierung garantiert werden. Falls ein Teil der Anwendung eine hohe Auslastung widerfährt, können von diesem Prozesstyp mehrere Instanzen gestartet werden.

### 9. Einweggebrauch

Prozesse einer App sollen schnell gestartet und gestoppt werden können. Dies erleichtert schnelles skalieren während Belastungsspitzen und ein schnelles Bereitstellen von Code. Die Startzeit eines Prozesses sollte so gering wie möglich sein. Zusätzlich sollten Prozesse auch schnell gestoppt werden können, damit sie die verwendeten Ressourcen wieder für andere Services zur Verfügung stellen.

### 10. Dev-Prod-Vergleichbarkeit

Die Entwicklungsumgebung sollte so sehr wie möglich der Produktionsumgebung ähneln. Unterschiede zwischen den verwendeten Diensten können Inkompatibilitäten verursachen, die erst beim Bereitstellen in der Produktionsumgebung erkennbar werden. Eine Zwölf-Faktoren-App ist auf [Continuous Deployment](https://www.dev-insider.de/was-ist-continuous-deployment-a-652804/) ausgelegt, indem sie die Unterschiede zwischen Entwicklung und Umgebung klein hält.

### 11. Logs

Logs sind ein Datenstrom von Ereignissen, die das Verhalten einer laufenden App sichtbar machen. Eine Zwölf-Faktoren-App soll sich nicht selbst um Logs kümmern und diese z.B. in eine Datei schreiben. Es sollte ein separater Service verwendet werden, der diese Logs verwaltet und übersichtlich darstellt.

### 12. Admin-Prozesse

Verwaltungsprozesse wie das Erstellen von Berichten oder die Migration von Datenbankschemas müssen von der Anwendung selbst entkoppelt sein. Die Ausführung eines Admin-Prozess darf die eigentliche Anwendung in keiner Weise beeinflussen.

Das Zwölf-Faktoren-Modell deckt also viele Aspekte der Entwicklung einer Anwendung ab. Das Modell ist gut dazu geeignet, zukunftsorientierte Anwendungen für die Cloud zu entwickeln. 👍

Je nach Anwendungsfall müssen die Methoden angepasst werden, für Internet-of-Things Anwendungen gelten natürlich andere Regeln wie für Web-Anwendungen. Dennoch stellt diese Methode eine gute Basis dar, um einen Überblick an die Anforderungen moderner App-Entwicklung zu bekommen.

**[FORTIX](https://fortix.io)** hat die Methode für Zwölf-Faktoren-Anwendungen verinnerlicht und entwickelt für Sie moderne Software die nahtlos skaliert werden kann. 💪💻

Dabei halten wir uns an eine Vielzahl von Best Practices, um die Wartbarkeit und Erweiterbarkeit des Codes zu verbessern. Wir entwickeln Cloud native und Internet-of-Things (IoT) Anwendungen die auf jedem beliebigen Cloud Provider (AWS, Azure, Google Cloud, Software AG, …) ausgeführt werden können.

Wenn Sie mehr über den Entwicklungsprozess bei FORTIX erfahren wollen können Sie uns gerne [kontaktieren](https://fortix.io/die-12-faktoren-app/#). Wir freuen uns! 🎉

### Links

- [Twelve-Factor App](https://12factor.net/)
- [Twelve-factor app development on Google Cloud](https://cloud.google.com/solutions/twelve-factor-app-development-on-gcp)
- [Applying the Twelve-Factor App Methodology to Serverless Applications](https://aws.amazon.com/de/blogs/compute/applying-the-twelve-factor-app-methodology-to-serverless-applications/)
- [Twelve-Factor WordPress App](https://roots.io/twelve-factor-wordpress/)


The Twelve-Factor App


Wieviel kostet eine Webseite im Jahr 2020? Soviel wie ein Auto oder ein Haus. Kurz gesagt, es ist unmöglich einen pauschalen Preis für eine Webseite zu nennen. Genau wie bei einem Auto kommt es unter anderem auf die Zusatzleistungen an. Möchte ich ein Auto in Standardausführung ohne großem Schnick-Schnack oder möchte ich das Topmodell mit Fahrassistent und autonomen Parkassistent? Bei einer Webseite muss man sich analog dazu überlegen ob ich eine Webseite mit Standardtemplate möchte oder ob ich durch grafische Schmankerln meine Besucher überzeugen will. Dabei muss man wissen: Der erste Eindruck zählt. Eine professionelle Webseite suggeriert unterbewusst ein professionelles Unternehmen. Der Anspruch an sich selbst und das eigene Unternehmen entscheidet schlussendlich darüber, wie der Webauftritt aussieht und was er kostet – „You get what you pay for“.

![Wieviel kostet eine Webseite? Soviel wie ein Auto...](/images/carchassis.png)

Um dennoch eine annähernd reale Kostenschätzung für eine Webseite zu erstellen müssen einige Faktoren geklärt werden:

- Verwendet die Seite ein Template oder ein maßgeschneidertes Design?
- Wie soll der Inhalt verwaltet werden?
- Wird der Inhalt durch den Auftraggeber erstellt?
- Werden Stockbilder oder professionelle Bilder eines Fotografen verwendet?
- Müssen Daten von einem internen System angezeigt werden?

Es muss also einiges im Vorhinein geklärt werden bevor einer Webseite ein Preisschild angehängt werden kann. Eine direkte Antwort bzw. ein Pauschalangebot auf die Frage: „Wie viel kostet eine Webseite?“ ist unseriös. Zusätzlich zu den initialen Kosten muss auch noch Budget für die laufenden Kosten eingeplant werden. Eine Webseite benötigt Hosting, Updates und regelmäßige Backups. Sonst wird aus dem neuen schönen Webauftritt bald ein gefundenes Fressen für Sicherheitswarnungen, Spammer und Hacker. Hierfür sollten je nach Umfang und gewünschter Ausfallsicherheit ein Wartungsvertrag abgeschlossen werden. Zusätzlich muss auch ein Werbebudget eingeplant werden. Denn was nutzt mir ein Sportwagen ohne Benzin?

![Selbst der beste Sportwagen fährt ohne Benzin keinen Meter...](/images/supercar-unsplash.jpg)

Warum sollte man sich das alles antun, wenn man einfach ein Webseiten-Baukastensystem à la Squarespace verwenden kann? Für einfache Webseiten die lediglich Kontaktinformationen beinhalten ist das sicherlich eine interessante Variante. Man sollte allerdings bedenken, dass sobald etwas nicht mit den Vorlagen des Baukastensystems gelöst werden kann, einige Herausforderungen warten. Abweichen vom Baukasten-Standard ist oft schmerzhaft – für den Entwickler, die Wartung, das SEO-Ranking und das Portemonnaie.

Man kann folgendes festhalten: Die Preisspanne für eine Website ist kaum einzugrenzen. Um ein seriöses Angebot zu erhalten, sollte man die genauen Anforderungen beschreiben. Kritische Fragen seitens der Entwickler sind ein gutes Zeichen, da somit der Scope abgeschätzt wird. Schnelle und kostengünstige Angebote – ohne Details zu kennen – sind unglaubwürdig und können in die Kategorie „Foot-in-the-door“ eingeordnet werden. Auch wenn es verlockend klingen mag, kann sich so ein „Schnäppchen“ im Nachhinein als böse Überraschung entlarven.


Webentwicklung: Angular & React

Custom Software to solve any challenge.

Software On-Demand

Frontend

Backend

Scalable Architecture

Wirtschaftsregion amKumma

Eine Region im digitalen Wandel

Culture Institute AG

The Culture App

REMAX

Wie viel ist mein Grundstück wert?

Choose your package

Product Ownership

UI/UX Design

Architecture

Development

Blogs zu Web Entwicklung