Webauftritt ohne Kompromisse
Wie eine Portfolio-Krise nach dem Bootcamp, US-Politik-Frust und Framework-Müdigkeit zu einer Website führten, die komplett ohne externe Abhängigkeiten auskommt.
Es begann mit einer Portfolio-Krise
2025, ich saß vorm PC, wollte nach dem Bootcamp eine Portfolio-Seite basteln, wusste noch nicht wie es weitergehen sollte. Eine simple Website, um mich zu präsentieren - was soll schon schiefgehen?
Dann passierte das, was alle paar Jahre in den USA passiert: Politischer Wahnsinn. Sturm aufs Kapitol, Begnadigungen, der ganze Zirkus. Ich schaute auf meine geplante Tech-Stack-Liste: Firebase, Google Fonts, verschiedene CDNs, Analytics-Services.
Und dachte mir: "Die spinnen die Ammis, scheiß auf Firebase und co - ich baue es selbst."
Was als politischer Widerwille begann, wurde zur fundamentalen Entwicklungsphilosophie: So gut es geht keine externen Abhängigkeiten.
Der US-Politik Wendepunkt
Sturm aufs Kapitol + Begnadigungen = Vertrauensverlust in US-Tech-Unternehmen. Warum sollte ich meine Portfolio-Daten amerikanischen Services anvertrauen?
Framework-Detox: "Jede Woche ein 'besseres' Framework"
Parallel dazu entwickelte sich meine Framework-Müdigkeit. Für jemanden, der 2 mal im Jahr an einem Webauftritt tüftelt, ist es frustrierend: Gefühlt kommt jede Woche ein "besseres" Framework raus. Abhängigkeiten, potenzielle Tracker, Sicherheitslücken - da hab ich kein Bock drauf.
Die Zahlen sprechen für sich:
Framework-Wahnsinn in Zahlen
Für ein "Hello World" Portfolio? Völlig oversized.
Also dachte ich mir: Scheiß drauf. Was geht, schiebe ich ins Backend. Das bisschen JS, das bleibt, mache ich vanilla - basta.
Backend-First Philosophie
Meine Lösung war radikal simpel: Frontend ist Frontend, Backend ist Backend. Warum eine Armada an JS-Abhängigkeiten, wenn das Backend die echte Arbeit macht?
Klare Verantwortlichkeiten
Backend Responsibilities
- • Business Logic
- • Datenverarbeitung
- • APIs
- • Validierung
- • State Management
Frontend Responsibilities
- • DOM Updates
- • API Calls
- • User Events
- • That's it.
Vanilla JS: "Das bisschen"
Für DOM-Updates und API-Calls brauche ich kein 500MB node_modules Verzeichnis. fetch(), querySelector(), addEventListener() - reicht.
Einfache JS-Module, die HTML-Strings zurückgeben. Keine Build-Tools, keine komplexen State-Management-Pattern, einfach verständlicher Code.
JavaScript-Exploration: Die Separation
Während der Portfolio-Entwicklung habe ich verschiedene JS-Ansätze ausprobiert: Komplexe SPAs, State Management, Component Libraries. Bis mir klar wurde: Ich verkompliziere das Ganze unnötig.
Die Journey war erhellend: Erst SPA mit State Management (Overkill für Portfolio), dann Component Libraries (90% nicht genutzt), Server-Side Rendering experiments, bis zur Erkenntnis: Backend macht alles, Frontend nur Display.
Warum komplexe Frontend-Logik, wenn das Backend sowieso da ist? Lass das Backend rechnen, validieren, entscheiden. Frontend macht nur: anzeigen.
JavaScript-Exploration Timeline
Das Ergebnis heute
Portfolio-Seite läuft ohne eine einzige externe Abhängigkeit. Kein Firebase, kein CDN, keine US-Services. Alles self-hosted, alles unter Kontrolle. Komplette Kontrolle ohne politische Bauchschmerzen.
Die Website ist schnell, sicher und funktioniert ohne Build-Tools. Kein Framework-Overhead, keine Security-Warnings von npm audit, keine Breaking Changes alle 6 Monate.
Aktuelle Architektur
Frontend Core
Privacy & Security
Performance
Vorher vs. Nachher
Geplanter Stack (Vorher)
Aktueller Stack (Nachher)
Was ich gelernt habe
Web-Entwicklung ist weniger über die neuesten Frameworks und mehr über fundamentale Prinzipien: Nutzerdaten respektieren, schnell laden, zugänglich sein. Der Rest ist Implementierungsdetail.
Die drei wichtigsten Erkenntnisse aus diesem Projekt:
Privacy by Design funktioniert besser als nachträgliches Flicken. Wenn du von Anfang an keine externen Services einbaust, musst du dir später keine Gedanken über Datenschutz machen.
Simple beats Complex in 99% der Fälle. Vanilla JS kann alles, was React kann - nur mit weniger Overhead, weniger Problemen und mehr Kontrolle.
Backend-First ist oft die bessere Architektur. Komplexe Frontend-Logik führt zu komplexen Problemen. Einfache Frontends führen zu einfachen Lösungen.
Die wichtigsten Erkenntnisse
What's next?
Die Website funktioniert und macht, was sie soll: Mich und meine Projekte präsentieren, ohne externe Abhängigkeiten und ohne Kompromisse beim Datenschutz.
Nächster Schritt: Progressive Web Apps ohne Framework-Ballast. Service Workers, IndexedDB, und Push Notifications mit purem JavaScript. Weil manchmal ist der einfachste Weg auch der beste Weg.
Das Experiment "Privacy-First Web Development" ist geglückt. Jetzt geht es darum, die Erkenntnisse auf andere Projekte zu übertragen und zu schauen, wie weit man diese Philosophie treiben kann.
Mission accomplished
Portfolio-Website läuft ohne externe Abhängigkeiten, US-Services oder Framework-Overhead. Schnell, sicher, self-hosted.