24. Januar 2026

Mein favorisierter Tech Stack als menschlicher Programmierer im Jahr 2026

Disclaimer: Die im Folgenden genannten Tools, sind Tools, die ich abseits meiner professionellen Arbeit, d.h. in Hobby-Projekten, gerne verwende. Diese Tools sollen keinen heiligen Grahl beschreiben. Lediglich eine Auswahl an Tools, mit denen ich gerne Arbeite und Dinge getan bekomme, oder solche, die ich noch lernen möchte.

Diese Niederschrift wird in Zukunft vielleicht als Skript für ein YouTube Video dienen. Aber bevor ich wieder Anfange zu träumen, muss erstmal diese Niederschrift Realität werden. Also, los gehts!

Frontend

Da ich im beruflichen Kontext primär im Vue Ökosystem gearbeitet habe, fällt meine Wahl auch abseits des Berufs auf Vue bzw. Nuxt. Ich fühle mich in diesem Ökosystem sehr wohl und kann Features schnell auf die Straße bringen. Hier eine Liste von Dingen, die ich regelmäßig nutze:

  • Nuxt: Wie bereits erwähnt, meistens die Basis für meine Projekte
  • nuxt.new: Bietet eine Reihe von Starter Kits und fertigen Templates. Praktisch wenn man wirklich sehr flott etwas auf die Beine stellen möchte. Beispielsweise das fertige Dashboard ist sehr praktisch und basiert auf nuxt/ui
  • @nuxt/ui: Nuxt hauseigene UI Library auf Basis von TailwindCSS, RekaUI und Typescript
  • @nuxt/content: Bei inhaltsgetriebenen Projekten greife ich gerne auf dieses Modul zurück. Markdown-Dateien in denen man Vue Components benutzten kann. Was will man mehr?
  • Die folgenden Tools sind zum Teil in @nuxt/ui enthalten und erleichtern den Umgang mit Bildern, Fonts und Icons
  • Weitere Tools, die die DX in Nuxt einfach zu einem Träumchen machen:
    • @nuxt/test-utils: Der Name spricht für sich.
    • @nuxt/scripts: performanceoptimierte Einbindung von third-party Scripts (Google Tag Manager, YouTube, Google Maps, u.v.m)
    • @nuxt/seo: Ich bin noch nicht dazu gekommen dieses Modul in all seinen Möglichkeiten auszuprobieren, aber es sieht sehr vielversprechend aus.
    • @nuxt/vue-use: eine Menge hilfreicher Composables. Zum großen Teil sind das Wrapper um Browser APIs, die für die Nutzung in Vue/Nuxt optimiert sind, und eben wieder eine schöne DX bringen

Dieser Abschnitt mag den Eindruck erwecken, dass ich ein Vue-/Nuxt-Fanboy bin. Und das stimmt auch irgendwo. Ich mag, dass dieses Ökosystem sehr Community-getrieben ist. Außerdem mochte ich von Anfang an, dass in Vue template, script und style voneinander getrennt sind. So wie ich es aus den guten alten HTML, CSS und JS/jQuery Zeiten kannte. Vielleicht bin ich einfach alt, aber ich denke mit Javascript-Frameworks ist es wie mit Musik: Vieles ist einfach Geschmacksache.

Backend

Da ich meine ersten tiefergehenden Backenderfahrungen mit Express.js gemacht habe, hat dieses Framework definitiv einen Platz in meinem Herzen. Die Art und Weise wie Express.js Dinge löst, fühlt sich für mich "heimisch" an – falls das Sinn ergibt. Wenn ich heute ein Projekt starten würde, wäre die Wahl des Backend-Frameworks für mich nicht so leicht, wie im Frontend. Im folgenden möchte ich, anhand von ein paar Optionen, erläutern warum:

Option 1: Nuxt Full Stack

Eine einfache und schlanke Lösung: die von Nuxt mitgelieferte Serverschicht nutzen. Eine App, ein Deployment. Ich denke für kleinere Projekte passt das und wenn man Lust hat seine eigene Batterie an Tools wie Drizzle und zod zu integrieren. Das kann Spaß machen, aber manchmal möchte man einfach eine vollständige Werkzeugkiste haben. Was mich zu Option 2 bringt

Option 2: ein battle tested Backend-Framework wie Symfony

Ende letzten Jahres habe ich Symfony zum ersten Mal genutzt. Ich wollte mit dem Rewrite meiner Buchhaltungsapp beginnen und habe zunächst ein Datenbankschema in ChartDB (selfhosted in meinem Homelab) entworfen. Auf Basis von diesem Entwuf habe ich das Schema über die Symfony CLI erstellt. Als ich damit fertig war, und festgestellt habe, dass alleine dadurch schon alle CRUD Operationen zur Verfügung stehen war ich komplett geflasht. Danach habe ich das Frontend auf Basis von Nuxts Dashboard Template KI-getrieben umgesetzt. Und hatte nach etwa 2 Tagen fast die komplette App fertig. Es war wirklich wenig Arbeit in Symfony notwendig. Das hat sich irgendwie gut angefühlt.

Option 3: Leichtgewicht Hono

Hono ist für mich eine Art moderneres Express.js. Einfache Syntax. No batteries included, d.h. man muss vieles selber mitbringen. Dafür aber viele gute Guides, Helpers und Middlewares in der Dokumentation. Und die Möglichkeit es in jeglicher Javascript Runtime und on the edge zu deployen. Hono habe ich auch für den Rewrite meiner Buchhaltungsapp genutzt. Ich wollte die PDF Generierung von der REST API trennen, und da mir Express.js etwas staubig erschient, viel die Wahl, auch aus oben genannten Gründen, auf Hono.

In Zukunft kann ich mir vorstellen mir auch Tools wie FastAPI, Laravel oder Go näher anzuschauen. Obwohl ich Java im Studium gelernt habe und auch mochte, werde ich es vermutlich nie in privaten Projekten einsetzen, da es sich auch immer recht schwerfällig angefühlt hat.

Was noch?

Da ich in der Lage sein möchte, alle meine Projekte lokal in meinem Homelab zu deployen, fiel die Wahl bei einem Storagesystem auf MinIO. Das Schöne an MinIO ist, dass es S3-kompatibel ist und sich somit die gesammelten Erfahrungen auf den AWS Kontext übertragen lassen.

Bei der Auswahl der Datenbank habe ich mich vor einiger Zeit für Postgres entschieden, aus dem einfachen Grund, dass ich eine relationale Datenbank nutzen wollte, und Postgres mit eine der meistgenutzten ist. In meiner Erfahrung ist das gute an einer relationalen Datenbank, dass man sich viel mehr Gedanken über die Struktur seiner Daten machen muss, und man sich somit zwingend Gedanken über Anforderungen und zukünftige Features macht.

DevOps

In meinem Homelab versuche ich viele Dinge einfach zu halten. D.h. manche Projekte ziehe ich mir einfach aus GitHub auf den Server, baue sie und lasse sie laufen. Hin und wieder kommt auch schonmal ein deploy.sh Bash-Skript zum Einsatz, welches dann Frontend und Backend zieht, baut und startet. Um Einheitlichkeit zu gewährleisten versuche ich alle Apps in Docker Containern abzubilden. Im Falle dieser Website, nutze ich GitHub Actions. Der Prozess sieht so aus, dass zunächst das Image gebaut und komprimiert wird, per SSH auf einen VPS übertragen und dort entpackt wird. Zu guter Letzt wird der alte Container gelöscht und der neue hochgefahren.

Das war ein grober Überblick über meine technologischen Vorlieben. Einige Themen wie Testing und Monitoring habe ich jetzt erstmal außen vorgelassen. Gegebenenfalls werde ich diesen Artikel über den Lauf des Jahres ausarbeiten oder daraus eine kleine Reihe machen. Aber für's Erste, soll das hier reichen.

Zurück