PHP
Für viele Web-Anwendungen immer noch eine sehr vernünftige Wahl: ausgereift, breit einsetzbar und in guten Händen deutlich besser als sein Ruf.
Software Intelligence
Sie ist Werkzeugwahl. Und die sollte besser zum Problem passen als zur Lieblingsmeinung des Entwicklers.
Wir wählen Technologien nicht danach aus, was gerade auf Konferenzen gut klingt, sondern danach, was sich für eine Aufgabe sauber bauen, betreiben und später noch weiterentwickeln lässt.

Kalifornien / Mensch-Computer-Interaktion
Douglas Engelbart
„SRI Douglas Engelbart 1968“ von SRI International, 1968
Quelle: Wikimedia Commons · Lizenz: CC BY-SA 3.0 · Bildnachweis
Bearbeitung: Änderungen: freigestellt, vergrößert. Die Bearbeitung steht unter derselben Lizenz, CC BY-SA 3.0. Bearbeitet von Today is Life.
Douglas Engelbart interessierte sich nicht dafür, Computer einfach nur schneller zu machen. Seine Frage war größer: Wie können Computer Menschen dabei helfen, besser zu denken und zusammenzuarbeiten? 1968 zeigte er in einer legendären Präsentation Dinge, die damals fast wie Science-Fiction wirkten: Maussteuerung, Hypertext, Fenster, gemeinsame Dokumentbearbeitung und Videokonferenzen. Das Entscheidende war für Engelbart nie das einzelne Tool. Entscheidend war, ob Technologie die Fähigkeiten von Menschen erweitert. Eine ziemlich gute Regel für KI: Nicht das beeindruckendste Werkzeug gewinnt. Sondern das, mit dem Menschen tatsächlich besser arbeiten.
Man kann über Technologien erstaunlich religiös werden.
Dann wird aus einer Programmiersprache eine Identität, aus einem Framework eine Weltanschauung und aus jeder Architekturentscheidung fast schon eine Frage des Charakters. Ich halte das für wenig hilfreich.
Unternehmen kaufen am Ende keine Ideologie. Sie brauchen Software, die ihre Aufgabe erfüllt, ihre Prozesse aushält und nicht in sich zusammenfällt, sobald die erste neue Anforderung auftaucht.
Genau deshalb wählen wir Technologie pragmatisch. Nicht beliebig. Aber pragmatisch.
Uns interessiert, womit sich ein Problem sauber lösen lässt. Was ein Team gut beherrschen kann. Was in drei Jahren noch wartbar ist. Was zu bestehenden Systemen passt. Und was auch dann noch vernünftig bleibt, wenn aus einer schönen Idee irgendwann ein reales Produkt mit echten Nutzern, echten Daten und echten Folgen wird.
Das ist meistens weniger glamourös als Tech-Debatten im Internet. In Projekten ist es aber fast immer die bessere Wahl.
Im Backend entscheidet sich oft, ob ein System nur hübsch aussieht oder im Betrieb wirklich läuft. Dort laufen Daten zusammen, dort sitzen Geschäftslogik, Berechtigungen, Integrationen und die Teile des Systems, die später niemand sieht, aber alle spüren.
Wir arbeiten hier bewusst mit Technologien, die sich in realen Projekten bewährt haben. Sie sind nicht neu, aber zuverlässig, gut verständlich und in der Praxis vernünftig einsetzbar. Je nach Aufgabe greifen wir zu klassischen Web-Stacks, zu stärker API-getriebenen Architekturen oder zu Python dort, wo Daten, Automatisierung oder KI tatsächlich dazugehören.
Für viele Web-Anwendungen immer noch eine sehr vernünftige Wahl: ausgereift, breit einsetzbar und in guten Händen deutlich besser als sein Ruf.
Unser bevorzugtes PHP-Framework für Anwendungen, bei denen Produktivität, Klarheit und Wartbarkeit zusammenkommen sollen.
Stark, wenn Projekte mehr Struktur, mehr Individualität oder sehr spezifische Architekturentscheidungen verlangen.
Nach wie vor sinnvoll bei bestimmten Bestands- und Performance-Projekten, gerade wenn Geschwindigkeit und klare Strukturen gefragt sind.
Sinnvoll dort, wo Datenverarbeitung, Automatisierung, KI oder analytische Logik stärker ins Zentrum rücken.
Praktisch für eventgetriebene Dienste, Integrationen und Anwendungen, bei denen JavaScript oder TypeScript auch auf der Serverseite sinnvoll ist.
Interessant für Dienste, bei denen Performance, Sicherheit und saubere Kontrolle über Ressourcen besonders wichtig sind.
Im Frontend wird Software unmittelbar erfahrbar. Dort merkt man schnell, ob ein System mit Menschen arbeitet oder gegen sie.
Deshalb interessiert uns hier nicht nur, was modern aussieht, sondern was Interaktion klarer macht, was sich sauber mit dem Backend verbindet und was sich langfristig pflegen lässt. Nicht jede Anwendung braucht dieselbe Komplexität. Mal ist ein reaktives Framework richtig, mal reicht ein leichteres Werkzeug völlig aus. Auch hier gilt: Das Werkzeug folgt der Aufgabe.
Für uns oft ein guter Mittelweg aus Klarheit, Geschwindigkeit und angenehmer Entwicklung in produktiven Frontends.
Eine gute Wahl, wenn Projekte mehr Freiheit brauchen oder bestehende Ökosysteme und Teams bereits stark darauf ausgerichtet sind.
Hilfreich, wenn Interaktivität direkt aus dem HTML heraus sinnvoll lösbar ist und man bewusst weniger JavaScript-Komplexität will.
Hilfreich für leichtere Interaktionen in serverseitig gerenderten Anwendungen, wenn ein großes Frontend-Framework schlicht zu viel wäre.
Praktisch, wenn man Oberflächen systematisch und konsistent entwickeln will, ohne sich in wachsendem CSS-Chaos zu verlieren.
Die Grundfrage hinter dem Bereich: wann Software mehr ist als bloß funktionierender Code.
Eigene Produkte sind der ehrlichste Ort, um Architektur, Nutzbarkeit und technische Entscheidungen zu testen.
Der größere Zusammenhang: wie wir über Systeme, Software und digitale Prozesse insgesamt nachdenken.