Bildplatzhalter
Diagramm oder Collage: Logos/Architektur Node, TS, React, Go, Desktop — reines Dekor, kein Anspruch auf Vollständigkeit.
industrie-technologie-stack-hero.webp
Industrie / Technologie
Unser Stack — bis ins Detail, wenn Sie Bytes mitrechnen
Für IT-Leitung, Integratoren und technikaffine Geschäftsführung: Hier steht, mit welchen Laufzeiten, Sprachen und Frameworks wir bauen — und warum diese Kombination für Web, APIs und Desktop zusammenpasst.
Kurzüberblick: Node.js und TypeScript auf der JavaScript-Seite, React mit React Router 7 (die Nachfolge-Linie von Remix), Tailwind CSS für UI, Go für performante Backends und Dienste, Wails, wenn eine Anwendung nativ auf dem Desktop laufen soll, aber weiterhin mit Web-Technologie im Frontend gebaut wird.
Schichtenmodell in einem Satz
Der Browser oder der Wails-Webview rendert React (deklarative UI, Virtual DOM bzw. Concurrent Features). Darunter liegt ein Node.js-basiertes Tooling für Bundling, Typprüfung und — bei Web-Projekten — häufig serverseitiges Rendering oder Datenloader über React Router 7. Geschäftslogik, die Latenz, Parallelität oder Binärprotokolle braucht, packen wir in Go-Dienste (HTTP/JSON, gRPC, MQTT, eigene Worker). Wails kapselt dieselbe Idee für den Desktop: Go als Host-Prozess, Web-Stack als UI-Schicht.
Node.js
Node.js ist die Laufzeitumgebung, die Googles V8-JavaScript-Engine außerhalb des Browsers nutzt: ein Ereignis-Schleifen-Modell (libuv), nicht-blockierendes I/O, einheitliche Sprache zwischen Tooling und — je nach Projekt — Servercode.
Für uns ist Node.js vor allem die Basis für Build und Entwicklererfahrung: Paketauflösung über npm oder pnpm, Transpilierung von TypeScript, Hot Reload, Testläufe, Bundler (z. B. Vite). Wenn ein Dienst in Node.js läuft, profitieren wir von der großen Ökosystem-Bibliothek für alles, was „schnell prototypisieren oder anbinden“ heißt — bei Lastprofilen mit extrem vielen gleichzeitigen Verbindungen oder harter CPU-Arbeit verlagern wir die Last bewusst nach Go.
Praktisch heißt das: Node.js liefert die JavaScript-Seite
der Lieferkette (von package.json
bis zum produktiven Bundle). Die Frage „Node oder Go für diesen
Endpunkt?“ entscheiden wir nach Profil: I/O-lastig und
DOM-nah → oft im SSR-Layer; CPU, Binärprotokolle, strikte
Parallelität → Go.
TypeScript
TypeScript ist Obermenge von ECMAScript mit statischem Typsystem (structural typing), das zu JavaScript transpiliert. Für Teams und langlebige Kundenprojekte zahlt sich das aus in: früheren Fehlern im Editor statt zur Laufzeit, besserer Refaktorisierbarkeit, klareren Schnittstellen zwischen Modulen und expliziten Datenmodellen für API-Requests und -Responses.
Wir nutzen TypeScript durchgängig im React-Code und in Node-basierten Skripten. Typen für Loader-Daten (React Router), für Komponenten-Props und für geteilte DTOs reduzieren die Diskrepanz zwischen „was der Server sendet“ und „was die UI erwartet“ — besonders wertvoll, sobald mehrere Menschen am selben Produkt arbeiten oder Schnittstellen sich weiterentwickeln.
React
React modelliert UI als Funktion von Zustand:
Komponenten, Hooks (useState,
useEffect,
useMemo
…), Concurrent Rendering und eine Ökosystem-Flut an Bibliotheken
für Tabellen, Charts, Formulare und Barrierefreiheit.
Für interne Tools und Dashboards ist React für uns der Standard für interaktive Oberflächen: große Datenmengen in virtuellen Listen, feingranulare Updates ohne vollständigen Seitenreload, Wiederverwendung von Bausteinen über Projekte hinweg. Die Bundle-Größe behalten wir im Blick (Code Splitting, lazy routes), damit auch schwächere Clients im Betrieb nicht „Megabyte pro Klick“ zahlen.
React Router 7 — und Remix
Remix war ein Vollstack-Framework für React mit klarem Modell für Loader (Daten vor dem Rendern), Actions (Formulare und Mutationen serverseitig), Fehlergrenzen und Web-API-Nähe. Diese Ideen sind in React Router 7 aufgegangen: ein gemeinsames Routing- und Daten-Framework, das wir für neue Projekte einsetzen, wenn wir „klassisches“ Remix-2-Muster mit dem aktuellen React-Router-Ökosystem verbinden wollen.
Was das technisch bedeutet
- Route-bezogene Daten: Server- oder Client-Loader liefern serialisierbare Daten an die Route; die UI rendert mit definiertem Lade- und Fehlerzustand — weniger „useEffect-Fetch-Spaghetti“.
- Mutationspfad: Actions kapseln POST/PUT-Logik nah an der Route; CSRF- und Formularstrategien sind planbar statt ad hoc.
- SSR und Hydration (projektabhängig): erste HTML-Antwort kann sinnvoll sein für SEO oder schnelles First Paint; danach übernimmt die hydratisierte React-App.
- Deployment: je nach Hosting laufen Node-Worker oder statische Pre-Render-Pipelines — die Grenze zu rein statischen Sites (wie mit Astro) ist bewusst; für schwere interaktive Anwendungen bleiben wir beim React-Router-7-Stack.
Kurz: React Router 7 ist bei uns das Gerüst für Navigation, Datenzugriff und Server-Client-Grenze in React-Apps — mit dem Remix-Erbe im Rücken, ohne Marketingbegriffe statt Architektur.
Bildplatzhalter
Optional: Sequenzdiagramm Loader → API (Go) → JSON → React-Komponente, oder Screenshot eines Dashboards.
industrie-technologie-react-router.webp
Tailwind CSS
Tailwind CSS ist ein utility-first CSS-Framework:
vordefinierte Klassen für Abstände, Typografie, Flex/Grid,
Farben, Zustände (hover:,
focus-visible:),
Dark Mode und Breakpoints. Der Build-Schritt (PostCSS/JIT)
entfernt ungenutzte Klassen — die Auslieferung bleibt schlank,
wenn man das Theme diszipliniert hält.
Für uns bedeutet das: schnelle Iteration im UI, konsistente Design-Tokens über Projekte, weniger Kontextwechsel zwischen TSX und separaten Stylesheets. Komplexe Animationen oder sehr spezielle Komponentenbibliotheken ergänzen wir bei Bedarf; der Großteil der Oberfläche bleibt in Tailwind lesbar und diffbar im Git.
Go (Golang) fürs Backend
Go ist eine kompilerte Sprache mit statischer
Typisierung, Garbage Collection, eingebauter
Goroutine-Parallelität (M:N-Scheduling auf
Betriebssystem-Threads) und einem Standardlibrary-Fokus auf
Netzwerk (net/http),
TLS, JSON und Zeitformatierung.
Typische Einsatzgebiete bei uns: REST- oder JSON-RPC-APIs, MQTT- oder WebSocket-Consumer, Import- und Transformationsjobs (CSV, XML, proprietäre Binärformate), Authentisierungsschichten vor Legacy-Systemen, Healthchecks und kleine Microservices, die mit wenig RAM stabil unter Last laufen. Ein einzelnes statisch gelinktes Binary vereinfacht Deployment auf Linux-Servern oder in Containern.
Die Grenze zu Node.js: Wenn die Domäne hohe Parallelität, strikte Latenzbudgets oder CPU-lastige Verarbeitung ist, neigen wir zu Go. Wenn die Domäne „schnell anbinden, viele NPM-Pakete, DOM-nah“ ist, bleibt mehr in der JS-Welt. Beides im selben Produkt ist üblich: React spricht HTTP mit Go — sauber getrennt über OpenAPI oder handgeschriebene Typen auf beiden Seiten.
Wails für Desktop
Wails (v2) verbindet einen Go-Prozess als Host mit einer Web-Frontend-Schicht (HTML/CSS/JS oder gebündeltes React), die in der nativen Webview läuft: WebView2 unter Windows, WebKit unter macOS, WebKitGTK unter Linux.
Vorteil für Kunden im Mittelstand: eine installierbare Desktop-Anwendung (Icon, Dateizuordnungen, lokale Dateien, System-Tray), ohne dass zwei getrennte Teams „Electron-Frontend“ und „Go-Service“ künstlich trennen müssen — der Go-Teil kann Berechtigungen, lokale Datenbanken und OS-APIs kapseln, das Frontend bleibt der bekannte React-Stack.
Technisch relevant: IPC zwischen Webview und Go (bindungsgenerierte Methoden), Build-Pipelines, die Frontend-Assets einpacken, und die Frage, ob Updates in-app oder über Ihre Softwareverteilung laufen. Speicher- und Prozess-Footprint liegen typischerweise unter reinen Chromium-Embeddings — wer jedes Megabyte RAM im Terminal zählt, bekommt hier ein ehrliches Profil.
Fazit
Das ist kein „Technologie-Shopping“, sondern ein abgestimmtes Set: TypeScript und React für nachvollziehbare, wartbare Oberflächen; React Router 7 für klare Daten- und Routenstruktur; Node.js als pragmatische JS-Laufzeit für Tooling und ggf. SSR; Go, wenn Dienste robust und ressourcenschonend laufen sollen; Wails, wenn dieselbe Logik vom Browser auf den Schreibtisch muss. Wenn Sie ein anderes Hosting, Compliance-Level oder bestehende APIs mitbringen, passen wir die Architektur an — der Stack ist das Werkzeug, nicht das Dogma.
Passen Schnittstellen, Betrieb oder Sicherheitsvorgaben zu diesem Stack? Sprechen wir darüber.