Vielleicht haben Sie mittlerweile auch einen Reflex wie wir entwickelt: Jedes Mal, wenn Sie eine neue Webseite öffnen, wandert Ihr Mauszeiger ganz automatisch in die Mitte, um das Wegdrücken des unter einer tiefen Hassliebe leidenden Cookie-Banners vorzubereiten. Umso verwunderter waren Sie vielleicht, als Sie auf unsere Webseite stießen. Wo ist denn nun eigentlich unser Cookie-Banner? Die Antwort ist keine Fehlfunktion Ihres Browsers oder ein unterbewusstes und vergessenes Wegdrücken des Banners: **Wir haben keinen Cookie-Banner.** Aber wie ist das möglich? Ein Exkurs in die Entwicklung des Datenschutzes im Internet und weshalb Abmahnanwälte bei uns wenig Chance haben (und wie diesen auch bei Ihrer Webseite die Lust vergehen kann).

## Cookies: Wieso, weshalb, warum

Mit Auftreten des Phänomens "Web 2.0" wurde gefühlt auf wöchentlicher Basis eine neue Methode entwickelt, Webseiten-Besucher möglichst effektiv in ihrem Surfverhalten zu tracken. Das reicht von der Erfassen der IP-Adresse über skurrile Methoden, Nutzer über Browsereigenschaften wie die Bildschirmauflösung zu "fingerprinten" bis eben zum Speichern einer kleinen Datenmenge auf dem Computer des Nutzers: dem Cookie. Über die Jahre ist die Verwendung solcher Trackingmaßnahmen jedoch ausgeufert und (zumindest in der Europäischen Union) schlussendlich, zurecht, in einem harten, gesetzlichen Vorgehen gegen diese geendet: Der europäischen Datenschutzgrundverordnung (DSGVO) und dem deutschen Bundesdatenschutzgesetz (BDSG). Auch wenn das Effektivwerden dieser gesetzlichen Änderungen einen langen Vorlauf hatte, fühlte es sich dann am 25. Mai 2018 plötzlich doch so an, als wäre über Nacht die Sintflut über das Internet hereingebrochen.

Mit der DSGVO und der plötzlichen Verwunderung darüber, dass personenbezogene Daten einem rechtlichen Schutz unterliegen, mussten neue, datenschutzfreundliche Methoden her, um Analyse zu betreiben. Dachte der eine oder andere vielleicht zumindest. Die Realität sah nämlich ganz anders aus: Rechtliche Grauzonen wie das (inzwischen gekippte) "US-EU Privacy Shield" oder eben die Cookie-Banner entstanden, um die invasiven Tracking-Methoden weiterhin aufrecht zu erhalten.

## Tracking auf datensparsam

Auch vor Inkrafttreten der DSGVO haben wir auf unserer Webseite bereits auf die Verwendung von Tools verzichtet, die bekanntermaßen eher sorglos mit Daten von Nutzern umgingen. Dazu gehörten insbesondere Google Analytics, welches mit neuer Rechtsprechung inzwischen tatsächlich auch in der Praxis immer mehr Boden in der EU verliert. Wie aber bekommen wir es hin, so ganz ohne Cookies und damit Cookie-Banner auszukommen?

### Den Status Quo analysieren

Wenn keine Cookies oder andere invasive Tracking-Mechanismen verwendet werden, benötigt man keinen Banner. So weit, so selbstverständlich. Dies betrifft übrigens nur technisch nicht unbedingt notwendige Cookies. Technisch zwingend notwending sind jedoch ohnehin nur die wenigsten Cookies (darunter zählen z.B. Cookies, welche den Inhalt eines Warenkorbs speichern). Die Reichweite von Cookies ist jedoch vielen nicht so genau bewusst: So gut wie jedes Drittanbieter-Tool, welches Sie auf Ihrer Webseite einbinden, speichert Cookies auf dem Rechner des Nutzers und/oder funkt nachhause. Oft handelt es sich hierbei sogar um US-Unternehmen, womit die Übertragung der Daten insbesondere nach dem Ungültigwerden des "Privacy Shields" umso problematischer ist. Das muss jedoch nicht sein: Es gibt genügend datenschutzfreundliche Alternativen für so gut wie jedes Problem.

Der erste Schritt muss hierbei jedoch sein, den aktuellen Status bzw. die aktuell durch die eigene Webseite gespeicherten Cookies zu analysieren. Hierzu können Sie entweder browsereigene Funktionalitäten (den "Web-Inspektor") nutzen oder aber auf Tools wie [PrivacyScore](https://privacyscore.org/) zurückgreifen. Notieren Sie sich sämtliche Cookies und Verbindungen zu Drittanbietern und analysieren bzw. recherchieren Sie, woher diese stammen.

### Datensparsame Alternativen

Nachdem Sie wissen, wohin Ihre Webseite überall nachhause telefoniert und welche Daten auf dem Rechner des Nutzers alle gespeichert werden (und v.a. wieso), können Sie diese Drittanbieter durch andere Anbieter ersetzen, welche sich dem Schutz personenbezogener Daten zugeschworen haben. Eines vorab: Der große Nachteil (oder Vorteil?) hierbei ist allerdings, dass viele dieser Tools kostenpflichtig sind. Wo kein Geld mit Daten Ihrer Nutzer verdient werden kann, muss nunmal anders Geld verdient werden. Viele dieser Tools sind jedoch open-source und können zum Teil kostenfrei auf eigenen Servern gehostet werden (was nochmal eine ganze Ecke datenschutzfreundlicher ist!), was jedoch ein technisches Verständnis oder immerhin eine gute IT-Abteilung (ebenfalls sinnvollerweise mit technischem Verständnis) erfordert.

Nachfolgend listen wir Ihnen einige der Tools und Methoden auf, welche wir nutzen, um so datensparsam wie möglich zu agieren und gänzlich auf lästige Cookie-Banner verzichten zu können.

#### Google Analytics

Machen wir uns nichts vor: Der Elefant im Raum ist immer noch Google Analytics. Viel zu gewöhnt sind wir an dieses mächtige Werkzeug bereits. Leider ist es unter allen Tools, die man auf seine Webseite so einbinden kann, auch jenes, welches am sorglosesten mit den Daten der Nutzer umgeht. Verschiedenste Rechtsurteile haben inzwischen auch dafür gesorgt, dass der Einsatz von Google Analytics in der EU in der Praxis unmöglich ist.

Eine datenschutzfreundliche Alternative, welche wir verwenden, ist das Tool **Simple Analytics** der niederländischen, gleichnamigen Firma. Simple Analytics verzichtet gänzlich auf das Setzen von Cookies. Beim Öffnen der Webseite wird ein Skript von Simple Analytics abgerufen (von europäischen Servern), welches die Aufgabe übernimmt, den Nutzer während seines Website-Besuchs zu tracken. Dabei wird jedoch insbesondere auch auf das Tracken der IP-Adresse oder anderen personenbezogenen Daten verzichtet. Das Tracking läuft gänzlich über den HTTP-Referrer. Um nicht gänzlich in technische Details zu verschwinden, können Sie bei Interesse [hier mehr erfahren](https://docs.simpleanalytics.com/what-we-collect).

Eine weitere Alternative ist unter anderem Matomo, welches auch auf eigenen Servern gehostet werden kann.

#### Google Maps

Google Maps war lange Zeit die einzige Verbindung zu einem Drittserver, die auf unserer Webseite erfolgte. Leider gibt es hier noch immer keine datenschutzfreundliche, aber zugleich einfach zu implementierende Alternative. Auf unserer Webseite verwenden wir die **OpenStreetMap**. Das Problem? Grundsätzlich kommt diese zwar ohne das Setzen von Cookies aus, der Abruf der Kartendaten erfolgt jedoch trotzdem von OpenStreetMap-Servern, denen Fastly CDN (ein Content Delivery Network), welches auf amerikanischen Servern betrieben wird, vorgeschaltet ist. Auch ist die Datenschutzerklärung von OpenStreetMap selbst nicht rechtskonform. Die Verwendung der OpenStreetMap im Auslieferungszustand ist datenschutzrechtlich insofern nicht rechtens.

Daher haben wir uns hier mit einem kleinen Trick beholfen, welchen wir auch für andere Drittanbieterdienste (u.a. Cloudinary, das von uns verwendete Content Delivery Network) verwenden: Wir haben einen sogenannten HTTP Proxy zwischen die Verbindung von Ihrem Browser und den OpenStreetMap-Servern geschaltet. Bei Abruf der Karte fragt Ihr Browser die Kartendaten also nicht direkt bei OpenStreetMap an, sondern auf unserem Server. Unser Server leitet die Anfrage dann an OpenStreetMap weiter. OpenStreetMap kann daher nur den Zugriff über die IP-Adresse **unseres Servers** sehen. Ihre IP-Adresse bleibt verborgen.

Zwar kann OpenStreetMap grundsätzlich auch datenschutzkonform mittels dem eigenen Hosten eines so genannten "Tile Servers" betrieben werden. Die Installation und Wartung eines solchen Servers ist jedoch so unverschämt kompliziert, dass sich das für die meisten Anwender nicht lohnen dürfte.

Hier bleibt insofern in Zukunft zu hoffen, dass sich der Markt hierhingehend noch etwas öffnet und einfach zu verwendende, "out of the box" datenschutzkonforme Optionen hinzukommen.

#### Zoom & Co.

Zoom, Microsoft Teams, Google Meet, Whereby... na, kräuseln sich bei Ihnen auch schon die Nackenhaare? Viele dieser Videokonferenz-Tools werden von US-Unternehmen betrieben und sind insofern datenschutzrechtlich nicht unbedingt die besten Optionen. Wir setzen daher auf eine selbst gehostete Instanz von **Jitsi Meet**, welche wir noch ein klein wenig optimiert haben, um Verbindungen zu Drittservern wie Gravatar sowie das Aufzeichnen von IP-Adressen gänzlich zu deaktivieren. Selbst im Auslieferungszustand erfüllt Jitsi jedoch bereits die geltenden Datenschutzvorschriften. Eine weitere Alternative ist Big Blue Button.

#### Google Fonts

Zugegebenermaßen vielleicht etwas am Thema vorbei, da keine Cookies per se gespeichert werden, aber hinsichtlich der immer noch weiten Verbreitung mindestens genauso wichtig: Google Fonts. Grundsätzlich ist die Verwendung der hübschen, von Google zur Verfügung gestellten Schriftarten auch datenschutzrechtlich kein Problem. Wir verwenden mit Montserrat immerhin auch eine (welche Ihnen gerade das Lesen dieses Textes ermöglicht!). Das Problem, welches auf vielen Webseiten weiterhin besteht [und in den letzten Wochen zu einer regelrechten Abmahnwelle geführt hat](https://www.e-recht24.de/google-fonts-scanner), ist die Einbindung der Fonts per Link-Tag zu den Servern von Google.

Statt dessen müssen die Fonts zwingend lokal eingebunden werden, das heißt, auf dem selben Server gehostet werden wie der Rest Ihrer Webseite. Die Einbindung ist nicht allzu kompliziert und wird durch nützliche Tools wie den ["Google Web Fonts Helper"](https://gwfh.mranftl.com/fonts) noch weiter vereinfacht.

christina-branco-7P-wc2Z2Ujs-unsplash.jpg

Wie kann eine Webseite DSGVO-konform ohne Cookie-Banner betrieben werden? Wir zeigen es Ihnen an einem praxisnahen Beispiel.

Wo ist eigentlich euer Cookie-Banner?

Als moderne Digitalagentur versuchen wir stets, uns weiter fortzubilden und mit unserer Umwelt zu wachsen. Eine Technologie, die in den letzten Jahren rasant an Fahrt aufgenommen hat und inzwischen jedem ein Begriff sein dürfte, ist die **Künstliche Intelligenz** (KI / AI), bzw. um genau zu sein, Machine Learning. Unlängst ist diese Technologie in zahlreiche Branchen eingedrungen und macht Arbeitsabläufe einfacher, effizienter und kostengünstiger. Vor kurzem hatten wir die Möglichkeit, ein ML-Projekt für einen Kunden von Grund auf zu entwickeln und in der Praxis zu testen. Ein Erfahrungsbericht.

## Was ist Machine Learning überhaupt?
Machine Learning ist eine Disziplin im breiteren Feld der "künstlichen Intelligenz". Bisher war es in der Softwareentwicklung so, dass ein Entwickler Regeln geschrieben hat, mit welcher ein Computer Eingaben verwerten und Ergebnisse ausgeben konnte. Im Vorfeld bekannt waren auf dem "klassischen Weg" daher stets die Eingaben und die Regeln. Die Ausgaben waren Unbekannte in der Gleichung.

Machine Learning stellt dieses Konzept etwas auf den Kopf: Anstatt dem Computer Eingaben und Regeln zu geben, belassen wir die Regeln als Unbekannte und geben dem Computer somit nur noch die Eingaben - mitsamt dazugehörigen Ausgaben. Das hört sich vielleicht zunächst etwas komisch an, ist aber, zumindest oberflächlich, leicht erklärt. Wir füttern ein Machine Learning Modell mit tausenden von Eingabe-Ausgabe-Kombinationen (Trainingsdaten), woraufhin der Computer die Regeln, wie er von einer Eingabe auf eine dazugehörige Ausgabe kommt, selbst "erlernt". Dazu betrachtet er die Trainingsdaten in zahlreichen Durchläufen (auch "Epochen" genannt) und verändert dabei immer ein wenig die Gewichtung der Verbindungen zwischen den einzelnen Neuronen, die im KI-Modell definiert wurden. Damit funktioniert ein Machine Learning Modell ähnlich zum menschlichen Gehirn, nur sehr viel kleiner und weniger komplex. Ein KI-Modell kann daher nicht eigenständig denken oder gar empathisch werden. Statt dessen kann es nur innerhalb der vordefinierten Grenzen, also der gegebenen Trainingsdaten, lernen und handeln. Wenn im Training alles richtig läuft, kann ein optimales KI-Modell dann **aus den gegebenen Trainingsdaten generalisieren**, also die gelernten Regeln auf neue, noch nicht gesehene Eingaben, anwenden und zu schlüssigen Ergebnissen kommen. Damit das funktioniert, sind zahlreiche Komponenten essentiell, unter anderem die Qualität als auch Quantität der Trainingsdaten, die Aufbereitung dieser, die Anzahl der Epochen, die Hyperparameter (hierzu kommen wir später noch) und vieles mehr. 

## Fußball ist reiner Zufall! Oder?
Vor einiger Zeit kam ein Interessent mit einer klaren Aufgabenstellung zu uns in die Agentur: "Entwickelt eine Fußball-Formel!". Okay, zugegeben: Vielleicht nicht ganz so im Wortlaut, aber Ziel des Projektes war es, Gewinnwahrscheinlichkeiten im Fußball für eine internationale Sportplattform zu berechnen. Das Prinzip dürfte einigen bereits aus dem Bereich der Sportwetten bekannt vorkommen. Sportwettenanbieter (Buchmacher) berechnen für jedes Spiel, auf welches auf ihrer Plattform gewettet werden kann, Wahrscheinlichkeiten für unterschiedlichste Spielereignisse, beispielsweise den Gewinner des Spiels oder die Anzahl der Tore. Buchmacher setzen hierfür auf eine Vielzahl an Algorithmen. Das Prinzip des Machine Learnings hingegen ist noch recht neu.

Die Frage, die der Kunde mit diesem Projekt erörtern und beantworten wollte, war daher: "Kann ein Machine Learning Modell den Buchmacher schlagen?". Nach agilem Verfeinern der Projektanforderungen sowie dem Sammeln von tausenden Datensätzen aus vergangenen Spielen unterschiedlichster Fußballligen, u.a. der Bundesliga, legten wir also mit der Umsetzung los.

## Das erste Test-Modell
Um uns mit den Daten vertraut und erste Gehversuche zu machen, haben wir uns direkt an ein erstes Test-Modell gesetzt. Bevor es aber an die eigentliche Entwicklung des Machine Learning Modells gehen kann, ist es zunächst wichtig, die Trainingsdaten so aufzubereiten, dass ein neuronales Netzwerk mit diesen überhaupt arbeiten kann. Für das erste Modell haben wir die folgenden Datenpunkte als Eingabeparameter verwendet:
- Heim-Team-ID
- Auswärts-Team-ID
- Arena-ID
- Saison (Jahr)
- Spielrunde
- Wochentag
- Abendspiel
- Heim-Team Ligapunkte
- Auswärts-Team Ligapunkte

Dies stellt unserer Ansicht nach eine solide Basis dar, um erste, sehr einfache Vorhersagen über den Spielausgang treffen zu können. Die IDs (Identifier) wie für die Teams und die Arena wurden "one-hot encoded". Würden wir diese nicht entsprechend enkodieren, könnte ein ML-Modell diese gegebenenfalls als einfache, numerische Werte betrachten und so falsche Schlussfolgerungen ziehen. Daher ist es wichtig, diese klar voneinander zu trennen, was in der Praxis oft durch eine One-Hot-Encoding geschieht, womit die Datenwerte in ein eindimensionales Array aus Nullen und Einsen überführt werden, in welchen jeweils genau ein Wert eine Eins ist, und alle anderen Werte eine Null. Andere Werte wie die Spielrunde oder die Ligapunkte haben wir hingegen als numerische Werte belassen.

Auch haben wir für dieses Modell der Einfachheit halber alle Datensätze, in welchen einer oder mehrere dieser Datenpunkte gefehlt haben, entfernt. So ist garantiert, dass das ML-Modell mit möglichst "puren" und einfachen Daten lernt.

### Entwerfen des Modells
Im nächsten Schritt ging es um die Konzeption des eigentlichen ML-Modells. Auch hier haben wir uns für den ersten Prototypen auf ein möglichst einfaches Modell beschränkt, um dieses im Nachhinein bestmöglich optimieren und feinjustieren zu können. Für die Entwicklung des Modells wurde das bekannte Framework **Tensorflow** von Google verwendet sowie das darauf aufbauende bzw. abstrahierende Framework Keras. Mit Keras ist es sehr einfach, simple Modelle mit "vorgefertigten" Netzwerkschichten zu entwerfen. Um nicht zu sehr ins Technische auszuschweifen, sei an dieser Stelle gesagt, dass wir nach einigen Versuchen bei einem Modell mit einem eingehenden Flatten-Layer (welcher die Kombination aus one-hot-encoded und numerischen Werten in ein simples, eindimensionales Array konvertiert), zwei unsichtbaren Dense-Layern mit dazugehörigen Dropouts sowie einem Ausgangs-Layer gelandet sind.

### Ergebnisse und Auswertung
Zu unserem Glück begann mit Fertigstellung des ersten Prototypen gerade die neue Saison der Fußball-Bundesliga. Ein perfekter Moment, um die KI direkt live auszuprobieren. Nachdem jeder in der Agentur persönliche Wetten getroffen hat, durfte die KI an die Reihe. Zunächst war ein zugegebenermaßen eher einfaches Spiel an der Reihe: Eintracht Frankfurt gegen den FC Bayern München. Die KI prognostizierte einen Gewinn der Münchner zu 66%. Hätten die Münchner stattdessen den Heimvorteil gehabt, progonostizierte die KI eine Gewinnchance von über 75%. Schlüssig - und am Ende tatsächlich richtig. Die Bayern gewannen das Spiel 1:6. Interessant war, dass die prognostizierte Gewinnchance der Münchner mit voranschreitenden Spieltagen immer weiter stieg. Ein Zeichen dafür, dass der KI zu Beginn der Saison noch wichtige Daten fehlen, um wirklich überzeugende Vorhersagen zu treffen.

Die grafische Auswertung anhand der Testdaten (also Datensätze, welche die KI im Trainingsprozess nicht gesehen hat, sondern welche nur für die Auswertung des Modells verwendet werden) war hingegen eher ernüchternd, wenn auch absolut den Erwartungen entsprechend:
![Grafische Auswertung des ersten KI-Modells. Zu erkennen ist, dass die Vorhersagenpräzision bei den Testdaten bei rund 50% konvergiert.](https://api.kuatsu.de/proxy/cloudinary/kuatsu/image/upload/v1661526177/val_accuracy_311fe6b635.png)

Zu erkennen ist hier, dass die Präzision der Vorhersagen der KI bei rund 50% konvergiert. Somit liegt die Präzision definitiv weit höher als die reine Zufallswahrscheinlichkeit von 33% bei drei möglichen Spielausgängen (Heimsieg, Unentschieden, Auswärtssieg). Mit 50% kann jedoch noch kein Krieg gegen die Wettquoten der Buchmacher gewonnen werden.

## Das zweite Modell "Jarvis"
Also zurück an die Blaupausen. Basierend auf unseren Erfahrungen mit dem ersten Modell wurde dieses feinjustiert, auch wurden die verwendeten Datenpunkte angepasst und die Aufbereitung der Daten etwas modifiziert. Da es sich bei diesem Modell um das beim Kunden produktiv eingesetzte Modell handelt, können wir an dieser Stelle natürlich nicht allzuviele Details verraten. Jedoch haben wir die Datenpunkte beispielsweise um die Startaufstellungen sowie zahlreiche Details zu den jeweiligen Spielern ergänzt. Das Modell hat somit Gelegenheit, auch die einzelnen Aufstellungen zu betrachten und gegeneinander zu vergleichen. Das Alter der Datensätze wurde zusätzlich begrenzt, sodass keine Datensätze aus sehr alten Saisons, beispielsweise 2011, mehr ins Training einfließen.

Abschließend haben wir die Hyperparameter des Modells feinjustiert. Die optimalen Hyperparameter, also beispielsweise der verwendete Optimizer, die Anzahl der versteckten Layer im Modell, oder auch die verwendete Loss-Funktion, sind Gegenstand zahlreicher Diskussionen in Entwickler-Communities und der Wissenschaft und für jedes Modell individuell. Eine beliebte und einfache Möglichkeit, diese zu optimieren, ist über einen automatischen Tuner wie "KerasTuner". Bei der Verwendung von KerasTuner wird das Modell mit immer verschiedenen Hyperparametern trainiert, welche wiederum über bestimmte Algorithmen stets angepasst werden. So werden die optimalen Rahmenbedingungen für die Funktionalität des Modells geschaffen.

Nach erfolgreicher Erweiterung der verwendeten Datenpunkte sowie Feinjustierung der Hyperparameter konnte das Modell vollends überzeugen. Unser bestes Modell konnte eine Präzision (Accuracy) auf den Validierungsdaten von über 71% erreichen. Somit ist dieses Modell rund 42% besser als unser erstes Modell - ein voller Erfolg. Mit 71% wurde darüberhinaus etwas anderes geschafft: Die Gewinnwahrscheinlichkeit des Favoriten einiger, ausgewählter Buchmacher lag durchgehend bei knapp unter 71%. Somit konnte unser Modell bessere Werte als die von Buchmachern verwendeten Algorithmen erreichen.

Natürlich mussten wir der künstlichen Intelligenz daraufhin auch einen Namen geben: Sie wurde liebevoll **Jarvis** getauft, angelehnt an die künstliche Intelligenz von Tony Stark in den "Iron Man" Filmen.

## Takeaways und Fazit
An diesem praktischen Projekt kann gesehen werden, welche Erfolge bereits mit einfachen KI-Modellen in komplizierten Märkten erreicht werden können, und welche Dimensionen mittels der Optimierung der verwendeten Trainingsdaten und Hyperparameter erreicht werden können. Die Entwicklung von Machine Learning Modellen wird unser Agenturleben in den nächsten Jahren immer stärker begleiten - wir sind darauf vorbereitet.

_Möchten auch Sie Bereiche in Ihrem Unternehmen digitalisieren oder sogar unter der Verwendung einer KI effizienter und kostengünstiger machen? [Sprechen Sie uns an.](/kontakt)_

gertruda-valaseviciute-xMObPS6V_gY-unsplash.jpg

Erfahren Sie, wie wir eine KI für einen Kunden entwickelt haben, welche Fußballergebnisse vorhersagen und dabei Wettquoten der Buchmacher schlagen kann.

KI in der Praxis: Wie sie Ihr Unternehmen unterstützen kann

Mann sieht sich PageSpeed Insights Auswertung auf seinem Laptop an

man-pagespeed-insights.png

Was sind Core Web Vitals? Wir erklären Ihnen einen der wichtigsten Rankingfaktoren von Google und geben Ihnen einen praktischen Guide für 2022 mit.

Core Web Vitals: Ein Field Guide für 2022

Bei der Entwicklung bzw. Planung einer neuen App stoßen die meisten schnell auf eine Frage: Hybrid oder nativ? Die meisten Apps sollen auf mehreren Systemen gleichzeitig laufen, meist iOS, Android und gegebenenfalls als Web App. Daher sollte man unbedingt die Vorteile, aber auch Nachteile sowie die Einsatzzwecke dieser beiden Ansätze verstehen. Beide dieser Herangehensweisen erfüllen ihren eigenen Zweck und passen für unterschiedliche Projekte. Wieso wir im Kundengespräch jedoch für die meisten Anwendungszwecke die Entwicklung einer hybriden App (oft auch _cross-platform_ genannt und nicht zu verwechseln mit WebView Apps oder PWAs, also Progressive Web Apps) empfehlen, möchten wir hier anhand von sieben Vorteilen eben dieser aufzeigen.

## Eine einzige Codebase
Der größte Vorteil von hybriden Apps war es schon immer, dass nur eine einzige Codebase verwaltet werden muss. Während bei der nativen App-Entwicklung für jedes zu unterstützende System eine eigene App programmiert werden muss, verfolgt die hybride Entwicklung einen Universalansatz. Es wird nur eine einzige App geschrieben, welche anschließend in eine native App kompiliert wird um so auf den gängigen Systemen zu laufen. Der Vorteil dürfte auf der Hand liegen: Sowohl am Budget als auch der benötigten Arbeitszeit für die Entwicklung kann mächtig gespart werden. Anstatt mehrere Entwickler an verschiedenen Systemen arbeiten zu lassen, kann oft ein einziges Entwicklungsteam die Programmierung für alle Systeme im Raketentempo vornehmen.

Dieser Vorteil ergibt sich nicht nur bei der ersten Entwicklung, sondern auch im weiteren Verlauf. Wenn neue Funktionen hinzugefügt oder die App anderweitig gewartet werden soll, sind Anpassungen binnen weniger Arbeitsstunden erledigt und auf allen Systemen gleichzeitig einsatzbereit. Dies spart nicht nur Kosten, sondern ist auch für die Nutzer umso erfreulicher.

## Performance wie der große Bruder
Vor nicht allzu langer Zeit standen hybride Apps noch massiv in Verruf. Zu diesen Zeiten entstand gerade das noch heute sehr populäre Ionic Framework, welches eines der Vorreiter in seinem Bereich war. Leider hatten Apps, die damals auf diese Art und Weise programmiert wurden, ein massives Problem: Performance. Selbst für den Laien war es einfach, zu erkennen, dass eine App nicht für das jeweilige System optimiert war. Grafikfehler, Stotterer und Abstürze gehörten zur Tagesordnung.

Inzwischen eilen hybride Apps, und die Frameworks in denen sie programmiert sind wie React Native oder Flutter, ihrem Ruf jedoch meilenweit voraus. Performance-Probleme gibt es inzwischen kaum noch. Ganz im Gegenteil sogar erreichen diese nahezu ähnliche Geschwindigkeiten wie rein native Apps. Der Nutzer kann in den meisten Fällen keinen Unterschied mehr feststellen. Dadurch setzen sie sich sehr stark von sogenannten WebView Apps ab, welche noch immer mit selbigen Problemen zu kämpfen haben. WebView Apps unterscheiden sich von hybriden Apps, welche zu nativen Apps kompiliert und optimiert werden, dadurch, dass diese einfach gesagt nur eine Webseite in einem Wrapper anzeigen. Dass sich hierdurch automatisch Performanzprobleme ergeben, dürfte klar sein. Eine App, die native UI-Funktionalitäten und System-APIs unterstützt (wie es moderne, hybride Apps tun) wird immer schneller sein, als eine Webseite, die auf dem Smartphone gerendert wird.

## Großartige User Experience
Dieser Punkt geht Hand in Hand mit dem vorherigen Punkt. Durch die native Performance hybrider Apps und der Möglichkeit, System-APIs wie Apple Health, HomeKit oder ähnliche einzubauen, ergibt sich eine fantastische Nutzererfahrung. Und selbst wenn eine Systemfunktionalität mal nicht von Haus aus vom verwendeten Framework verwendet wird, ist es in den allermeisten Fällen möglich, diese mit relativ wenig Aufwand nachzurüsten.

## Offline-Nutzbarkeit
In diesem Punkt stellen wir die hybride App weniger in den Vergleich zur nativen App, sondern viel mehr zum „kleinen Bruder“ – der WebView App. Der Kernvorteil gegenüber einer solchen liegt nämlich darin, dass die App unabhängig von einer bestehenden Internetverbindung genutzt werden kann. Die App ist mitsamt allen benötigten Funktionalitäten auf dem Gerät des Nutzers installiert und muss sich daher nicht bei jedem Öffnen neu laden.

**Zugegeben**: Durch cleveren Einsatz von Caching können viele Web Apps inzwischen auch offline laufen (man spricht dann auch von einer PWA, also einer Progressive Web App). Oft ist es jedoch so, dass hier bestimmte Features trotz dessen nicht ohne Internetverbindung funktionieren, da diese nicht auf alle System-APIs zurückgreifen können und so oft eine dauerhafte Serververbindung benötigen. Dieses Problem gibt es beim Einsatz von hybriden Apps nicht. Auch ist die Entwicklung einer hybriden App inzwischen oft günstiger als die einer offline verfügbaren Progressive Web App.

## Ein kleiner Disclaimer…
Auch wenn wir von der hybriden App-Entwicklung absolut überzeugt sind, so eignet sie sich jedoch nicht für alle Arten von Projekten. In bestimmten Fällen macht es durchaus Sinn, native Apps für jedes zu unterstützende System zu entwickeln. Vor allem wenn es um neu erschienene Systemfunktionalitäten geht, kommt die hybride App-Entwicklung oft an ihre Grenzen. Auch wenn herausragende Performance wichtig für die Funktion der App ist, kann eine hybride App – trotz der sich immer weiter verbessernden Performanz dieser – vielleicht nicht mehr mithalten.

**Sie sind sich noch unsicher, welcher Ansatz der Richtige für Sie ist? [Wir beraten Sie gerne in einem unverbindlichen Erstgespräch.](/kontakt)**

balazs-ketyi-sScmok4Iq1o-unsplash.jpg

Sie planen die Entwicklung einer App und wissen nicht, ob eine native oder hybride Entwicklung sinnvoller ist? Wir klären auf.

4 Vorteile von hybriden Apps in 2022

Bereits seit einiger Zeit stellt TypeScript unsere primäre Sprache dar, sowohl für interne Projekte als auch Kundenprojekte. Bereits seit Beginn arbeiten wir hauptsächlich mit JavaScript (in Kombination mit einigen Frameworks wie React und NodeJS), da die Flexibilität und der vielseitige Anwendungsbereich der Sprache es uns ermöglichen, eine Codebase in derselben Sprache für ein gesamtes Projekt, inklusive Web und Mobile App sowie Backend, zu nutzen. Nicht lang ist es her, dass wir all unsere aktuellen Projekte einer TypeScript Migration durchzogen haben.

Auch wenn jedes JavaScript-Projekt technisch gesehen ein gültiges TypeScript-Projekt ist, da TypeScript ein Superset von JavaScript darstellt, so ist nicht automatisch jedes JavaScript-Projekt auch ein _gutes_ TypeScript-Projekt. Fügen Sie TypeScript zu einer bestehenden JavaScript-Codebase hinzu, so werden alle Variablen, Konstanten und Objekte, welche sich nicht aus dem engeren Kontext für den Compiler ergeben, als vom Typen any betrachtet. Dass dies nicht im Sinne des Erfinders ist, dürfte klar sein. TypeScript wurde eben mit dem Hintergedanken entwickelt, strikte Typen in JavaScript nutzen und auf dynamische Typisierung weitgehend verzichten zu können. Als Entwickler sind Sie also gezwungen, für viele dieser Objekte händisch die Typisierung vorzunehmen. Logisch, dass sich dabei zwei Mal überlegt wird, ob dies wirklich notwendig ist und der Nutzen den Kosten bzw. dem Zeitaufwand überwiegt.

Zwar gibt es inzwischen zahlreiche Tools und Programme, wie [„ts-migrate“ von Airbnb](https://medium.com/airbnb-engineering/ts-migrate-a-tool-for-migrating-to-typescript-at-scale-cd23bfeb5cc) (welche TypeScript ebenfalls als offizielle Frontend-Sprache nutzen!), welche die Migration zu TypeScript vereinfachen sollen. Doch auch diese sind selbstredend bei weitem nicht perfekt und verhindern auch nicht das manuelle Typisieren von Objekten. Computer sind schließlich nicht wirklich gut darin, die Semantik hinter Ihrem Code zu verstehen (auch wenn sich dies in Zeiten von Deep Learning und KIs wie GitHub Copilot rasant ändert). Nun stehen wir also vor einem Dilemma: **Migrieren – oder die alten Codebases weiter verwalten?**

## Warum TypeScript einfach besser ist
Bevor wir uns also der Frage widmen, ob die Migration bestehender JavaScript-Projekte sinnvoll ist, schauen wir uns zunächst einmal die zwei größten Vorteile von TypeScript an.

- **Der TypeScript Compiler (TSC).** Der unserer Ansicht nach größte Vorteil bei der Nutzung von TypeScript liegt im Compiler. JavaScript ist normalerweise eine interpretierte Skriptsprache, welche vom Browser während der Laufzeit interpretiert und ausgeführt wird. Eine Kompilierung ist daher nicht notwendig. TypeScript wird zu JavaScript transkompiliert (wodurch der Browser den kompilierten Code wiederum als normales JavaScript interpretieren kann). Der Vorteil liegt hierbei vor allem darin, dass TypeScript-Code auch zu älteren JavaScript- / ECMAScript-Versionen transkompiliert werden kann. So können Sie auch dann moderne Funktionen wie Promises nutzen, wenn Sie Ihre Anwendungen für ältere Browser bzw. Umgebungen bauen. TypeScript kümmert sich darum, die Features in äquivalente Strukturen der avisierten JavaScript-Version zu kompilieren.
- **Fehlererkennung zur Build-Zeit.** Selbstverständlich bringen interpretierte, und nicht kompilierte Sprachen auch Vorteile wie schnellere Entwicklungsabläufe mit sich, jedoch auch einen gravierenden Nachteil. Viele Fehler, die normalerweise ein Compiler auffangen könnte, fallen erst während der Laufzeit auf. TypeScript kann hier in der größten Kategorie nachhelfen, den Typfehlern. Jeder/Jedem JavaScript-Entwickler:in wird es irgendwann einmal passiert sein, dass sie / er versehentlich auf Attribute von `undefined` oder `null` zugreifen wollte. **TypeScript kann solche Fehler noch verhindern, bevor es die Anwendung in die Staging- oder gar Produktionsumgebung schafft.**

## Warum und wie wir alle (aktuellen) Projekte migriert haben
Gründe für die TypeScript Migration gibt es also reichlich. Doch lohnt es sich wirklich, auch bestehende, zum Teil riesige Codebases zu migrieren? Die Antwort, die wir uns auf diese Frage gegeben haben, war ein ganz klares **Ja**. Nachdem wir TypeScript für einige neue Projekte bereits länger verwendet haben und in den Genuss statischer Typisierung in JavaScript gekommen sind, fiel die Entscheidung mehr als leicht. Die Umsetzung hingegen ist eine andere Hausnummer. Viele unserer laufenden Kundenprojekte in JavaScript waren mehrere zehntausend Zeilen lang – wo also anfangen?

### Den Status Quo bestimmen.
Wenn Sie nicht schon zuvor mit TypeScript-„Alternativen“ wie JSDoc gearbeitet haben, ist die Wahrscheinlichkeit hoch, dass Sie recht wenig Ahnung haben, welche Funktion eigentlich welche Typen verwendet. Man sollte sich daher zunächst eine Übersicht über den aktuellen Stand verfassen. Mit welchen Schnittstellen spricht die Anwendung? Welche Daten werden gelesen und geschrieben? Ist die Herkunft dieser Daten typsicher? Eine großzügige Dokumentation des Codes macht sich spätestens hier bemerkbar.

### Den „Strict“ Mode aktivieren.
Generell macht TypeScript unserer Ansicht nach so richtig nur mit Nutzung im „Strict“ Modus Sinn. Ohne Aktivierung dessen spendiert TypeScript zwar weit mehr Bewegungsspielraum, indem beispielsweise implizites Any erlaubt wird. Genau das soll jedoch durch die Migration verhindert werden. Wir möchten dynamische und nicht-statische Typen verbieten, weshalb wir uns durch fehlende Nutzung des Strict Mode ein eigenes Loch buddeln.

Als wir unsere ersten Projekte zu TypeScript migriert haben, haben wir unsere Projekte stets zunächst im „Non-Strict“ Modus von TypeScript migriert. Erst im Anschluss haben wir den Strict Mode aktiviert und die restlichen Fehler ausgeweidet. Wir haben jedoch schnell festgestellt, dass dies nicht die effektivste Methode ist. **Aktivieren Sie den Strict Mode bereits zu Anfang der Migration.** Sie werden sich im weiteren Verlauf viel Kopfzerbrechen sparen. Fehlerbehebungen und Optimierungen, die Sie im ersten Schritt durchführen, müssen teils nach Aktivierung des Strict Modes wieder gänzlich verworfen werden. Auch wenn der Fehler-Tab in Ihrer Entwicklungsumgebung Sie vielleicht einschüchtern mag: Nutzen Sie von Anfang an den Strict Mode.

### Deklarationsdateien installieren
Ein Großteil der von TypeScript angezeigten Fehler stammt wahrscheinlich gar nicht von Ihrem Code, sondern entspringt dem node_modules Ordner. Dies liegt schlicht daran, dass in den meisten Modulen keine Typdeklarationen von Haus aus dabei sind. Glücklicherweise gibt es von der Open-Source-Community nahezu zu jedem Modul passende Typdeklarationen. Zu einem Modul „some_module“ können Sie diese in der Regel mit `$ npm install @types/some_module` installieren. Hat Ihre Anwendung jedoch einen sehr spezifischen Anwendungszweck und nutzen Sie daher auch sehr spezielle Libraries, so kann es vorkommen, dass keine passenden Typdeklarationen vorliegen. Anstatt diese Libraries nun jedoch einfach als Any zu deklarieren, investieren Sie die Zeit und legen Sie Typdeklarationen an. **Tech Debt ist ein echtes Problem – und Sie möchten sich zu diesem Zeitpunkt nicht darin verwickeln.**

### Klassen und Funktionen migrieren
Bevor Sie sich den Kleinteilen zuwenden, ist es eine gute Idee, zunächst die verwendeten Klassen, Funktionen und größeren Objekte Ihrer Anwendung zu typisieren. Es ist wahrscheinlich, dass diese immer wieder im Code verwendet werden. Dadurch eignen sich diese als erster Kandidat, da die Typisierung der anderen Variablen und Objekte sich so später weitaus einfacher gestalten wird. Wir haben uns bei unserer Migration daher zunächst Dinge wie Middlewares, Models usw. vorgenommen. Indem wir diesen möglichst genaue Typen gaben, fiel es in den kleineren Funktionen und Abschnitten des Codes später weitaus einfacher, diese zuzuordnen und zu typisieren.

Achten Sie darauf, bei der Typisierung möglichst streng, aber nicht zu streng vorzugehen: TypeScript ist ein sehr mächtiges Werkzeug, und Sie können Ihre Typen so streng machen, wie es Ihnen beliebt. Allerdings, _„don’t over-engineer“_! Sich in den Typen zu sehr auszutoben macht vom Kosten-Zeit-Faktor ab einem bestimmten Punkt nur noch wenig Sinn.

### Other stuff…
Ein Großteil der Arbeit wurde nun in recht kurzer Zeit erledigt. Nun geht es jedoch an die Kleinigkeiten. Erfahrungsgemäß reicht es hier meist, Variablen und Co. einen der vorgefertigten Typen wie „string“ zu geben. Auch hier gilt das bekannte Don’t Over-Engineer Prinzip.

Auch Ihre Tests sollten Sie an TypeScript anpassen. Viele der bekannten Test Frameworks sind für TypeScript optimiert und arbeiten damit problemlos.

## Fazit
**TypeScript ist womöglich das Beste, was JavaScript in den letzten Jahren passiert ist.** Der Trend geht laut den letzten [StackOverflow Surveys](https://insights.stackoverflow.com/survey/2021) immer weiter in Richtung statisch typisierte Sprachen. Die Flexibilität von JavaScript und eine sichere Typisierung machen so jedes Projekt zukunftssicher und einfach zu verwalten. Seit unserer vollständigen TypeScript Migration ist es bei uns de-facto Standard, und wir möchten es nicht mehr missen.

_Möchten auch Sie Ihre Webseite, Ihre Anwendung oder Ähnliches modernisieren und frischen Aufwind für Ihre Digitalisierung generieren? [Sprechen Sie uns an](/kontakt)._

coding-green-text-laptop.jpg

TypeScript ist auf der Überholspur. Doch lohnt sich die TypeScript Migration? Und wie ist sie in großen Codebasen zu meistern? Ein Einblick.

Blog

Neueste Blog-Einträge

Wo ist eigentlich euer Cookie-Banner?

KI in der Praxis: Wie sie Ihr Unternehmen unterstützen kann

Core Web Vitals: Ein Field Guide für 2022

4 Vorteile von hybriden Apps in 2022

Ein Leitfaden für die TypeScript Migration