Wer sich in Deutschland auf die IHK-Abschlussprüfungen im IT-Bereich vorbereitet, stößt schnell auf ein frustrierendes Problem: Brauchbares Material existiert meist nur als statische PDF-Dateien, als unübersichtliche Forenbeiträge oder auf Plattformen mit Registrierungszwang, die schon bei einer kurzen Bahnfahrt ohne Netzverbindung unbenutzbar werden.

Ich wollte eine Lösung, die schnell lädt, auf jedem Endgerät zuverlässig funktioniert, keine persönlichen Daten sammelt und komplett ohne aktive Internetverbindung auskommt.

Daraus ist eine dreiteilige Suite für die Prüfungen AP1, AP2 Fachinformatiker Anwendungsentwicklung und AP2 Systemintegration entstanden. Das Projekt umfasst mittlerweile über 2.900 strukturierte Fachfragen, einen interaktiven Subnetz-Rechner für Netzwerk-Berechnungen, eine SQL-Sandbox zur praktischen Abfrage-Übung und ein durchsuchbares Fachglossar.

Hier sind die architektonischen Entscheidungen hinter dem Projekt und die Gründe, warum ich mich bewusst gegen moderne Standard-Frameworks entschieden habe.

1. Warum kein React oder Vue?

Der naheliegende Weg für eine moderne Webanwendung führt fast immer über React, Vue oder Svelte. Ich habe mich nach den ersten Prototypen bewusst dagegen entschieden und das gesamte Frontend mit reinem Vanilla JavaScript (ES6+) und lokal eingebundenen Stylesheets umgesetzt.

Der Hauptgrund war Performance und Ladezeit. Eine Lern- und Trainingsanwendung braucht keine Hunderte Kilobyte an JavaScript-Framework-Laufzeitumgebungen, die der Browser erst parsen und kompilieren muss, bevor die erste Interaktion möglich ist. Die Tracker-Seiten sind in unter 100 Millisekunden vollständig einsatzbereit.

Dazu kommt der Wartungsaufwand: Ohne externe npm-Abhängigkeiten in der Produktion gibt es keine Breaking Changes durch Third-Party-Updates, keine Sicherheitsrisiken in verschachtelten Modulbäumen und keinen Build-Schritt, der fehlschlagen kann. Die Dateien liegen als schlankes HTML, CSS und JavaScript direkt auf dem Server.

2. Echtes Offline-First statt Alibi-PWA

Viele Webanwendungen tragen das Label Progressive Web App, laden aber beim Start im Hintergrund trotzdem Daten von einer externen API nach. Wenn der Nutzer im Zug im Funkloch sitzt, steht er vor einem Lade-Spinner.

Die gesamte Prüfungs-Suite ist konsequent auf Offline-Betrieb ausgelegt. Ein eigener Service Worker fängt Netzwerkanfragen ab und speichert die gesamte Anwendung inklusive aller Datensätze, Icons und Werkzeuge beim ersten Besuch im Browser-Cache. Über eine gezielte Cache-Busting-Strategie mit Versionsschlüsseln wird sichergestellt, dass neue Fragen und Feature-Updates im Hintergrund geladen und beim nächsten Seitenaufruf nahtlos aktiviert werden.

Der Lernstand, individuelle Notizen und Favoriten werden ausschließlich im lokalen Speicher (localStorage) des jeweiligen Browsers gehalten. Es existiert keine zentrale Datenbank, kein Benutzerkonto und kein Tracking. Was der Nutzer übt, wie oft er Aufgaben wiederholt und wo Wissenslücken liegen, verlässt niemals das Endgerät. Für den Wechsel zwischen verschiedenen Geräten steht eine lokale JSON-Export- und Import-Funktion bereit.

3. Schnelle Suche bei über 2.900 Datensätzen

Wenn eine clientseitige Anwendung fast 3.000 strukturierte Fachfragen, Diagramme und Erklärungen verwalten muss, wird die Performance bei der Filterung schnell zum Flaschenhals. Wer bei jedem Tastendruck im Suchfeld den gesamten DOM-Baum manipuliert, riskiert spürbare Ruckler auf Mobilgeräten.

Die Filter- und Suchlogik greift deshalb nicht direkt auf das DOM zu, sondern arbeitet auf Map- und Array-basierten Datenstrukturen im Speicher. Bei Eingaben im Suchfeld oder beim Filtern nach Modulen wird zunächst im Speicher gefiltert und erst das finale Ergebnis in den sichtbaren Viewport gerendert. Dadurch reagieren die interaktiven Komponenten, wie die Lernkarten mit Spaced-Repetition-Algorithmus oder das Glossar, verzögerungsfrei auf Eingaben und Tastatur-Shortcuts.

4. Die native Brücke: Google Play Store via TWA

Um Nutzern den Zugriff so einfach wie möglich zu machen, habe ich die Suite zusätzlich als Android-Apps im Google Play Store veröffentlicht.

Statt den gesamten Code in Kotlin oder Java neu zu schreiben, kommen Trusted Web Activities (TWA) zum Einsatz. Die Android-App fungiert dabei als verifizierter, nativer Container, der den kryptografisch bestätigten Web-Origin lädt. Da die Webanwendung bereits durch den Service Worker komplett offline-fähig war, verhält sich die Store-Version wie eine vollwertige native App.

Der große Vorteil dieser Architektur: Änderungen, Fehlerkorrekturen und neue Fragen müssen nur im Web-Repository aktualisiert werden. Sobald die Web-Version live ist, steht das Update automatisch auch den Nutzern der Play-Store-App zur Verfügung, ohne jedes Mal einen zeitraubenden Review-Prozess durchlaufen zu müssen.

Fazit

Die Entwicklung der Suite hat einmal mehr gezeigt, dass man nicht für jedes Projekt komplexe Framework-Stapel benötigt. Eine klare Architektur mit Web-Standards reicht oft völlig aus, um extrem schnelle, wartungsarme und datenschutzfreundliche Software zu bauen.

Die Quellcodes sind als Open-Source-Software unter der AGPLv3-Lizenz auf GitHub frei zugänglich. Die Anwendungen laufen werbefrei unter ap1.cwillam.de, ap2.cwillam.de und ap2-fisi.cwillam.de.