Architektur und SDK-Karte

Die Entscheidung, die zählt

Entscheide zuerst, ob du ein Stream Deck App-Plugin oder einen direkten Hardware-Controller baust. Die Sprachwahl ergibt sich aus dieser Entscheidung.

1. Die Schichten

Stream Deck hardware
        |
        | HID protocol
        |
Official Stream Deck desktop app
        |
        | plugin WebSocket and SDK abstractions
        |
Plugin runtime
        |
        +-- Node.js SDK plugin code
        +-- Native console plugin code
        +-- Property inspector HTML UI

Python-Werkzeuge zur Direktsteuerung sitzen üblicherweise unterhalb der Stream Deck Desktop-App und sprechen über HID mit dem Gerät. Offizielle Plugins sitzen oberhalb der Desktop-App und empfangen Events von Stream Deck.

2. Die Runtime wählen

Runtime	Am besten für	Vorteile	Kompromisse
TypeScript / JavaScript mit @elgato/streamdeck	Normale Plugins, Marketplace, schnelle Iteration	Offizieller Weg, CLI-Scaffold, Hot Reload, Property Inspectors, Packaging	Node-Runtime, SDK-Lebenszyklus folgt Elgatos Anforderungen
Python mit streamdeck	Lokale Automatisierungsstationen, Lab-Dashboards, eigene Frontends	Direkte Gerätesteuerung, exzellentes Scripting, einfacher OS/API-Klebstoff	Nicht das normale Stream Deck Plugin-Packaging-Modell; kann mit dem Zugriff der offiziellen App kollidieren
C#/.NET mit StreamDeckToolkit	Native-artige Plugins, Windows-Integrationen, bestehender .NET-Code	Starke Typisierung, native App-Muster, .NET-Ökosystem	Community-Toolkit, ältere Template-Basis, mehr manuelle SDK-Abstimmung
Rohes WebSocket-Native-Plugin	C++, Go, Rust, eigene Runtimes	Maximale Runtime-Freiheit	Fortgeschrittener Weg, mehr Protokollarbeit, mehr Packaging-Komplexität

3. JavaScript oder TypeScript

Nutze standardmäßig TypeScript. Das offizielle Scaffold ist TypeScript-freundlich, das SDK bietet typisierte Events, und Action-Einstellungen profitieren von echten Typen.

Nutze reines JavaScript nur, wenn:

• das Plugin winzig ist,
• das Team keine TypeScript-Build-Schritte will,
• du ein altes Plugin anpasst,
• Typsicherheit die zusätzliche Projektzeremonie nicht wert ist.

Für neue Plugins gewinnt TypeScript meist, weil Stream Deck Actions schnell ereignisgesteuert werden: Tasten-Events, Dial-Events, Einstellungen, Geräte-Events, UI-Nachrichten und Lifecycle-Hooks.

4. Python

Python ist das richtige Werkzeug, wenn du das Stream Deck zu einem physischen Dashboard für deinen eigenen Prozess machen willst:

• Hausautomatisierung,
• Observability-Panels,
• interne Betriebs-Konsolen,
• Testaufbauten,
• Medien-/Kontrollräume,
• kioskartige lokale Workflows,
• Hardware-Experimente.

Der zentrale Unterschied: Direkte Python-Steuerung besitzt das Rendering. Du zeichnest Bilder, setzt Helligkeit, registrierst Callbacks und entscheidest über jeden Zustandsübergang. Das ist mächtig, aber es ist nicht dasselbe Nutzererlebnis wie das Installieren eines Stream Deck App-Plugins.

5. .NET und native Plugins

C# ergibt Sinn, wenn das Plugin natürlicherweise in eine .NET-Umgebung gehört:

• Windows-APIs,
• bestehende C#-Bibliotheken,
• Enterprise-Desktop-Integrationen,
• lokale Dienste, die bereits in .NET geschrieben sind,
• stark typisierte native App-Workflows.

Elgatos aktuelle offizielle Doku empfiehlt das Node.js SDK für die meisten Plugin-Autoren und beschreibt rohe WebSocket-Plugins als fortgeschritten. Behandle C# als bewusste Entscheidung, nicht als schnellsten Standard.

6. Marketplace-Bereitschaft

Frage	Offizielles TS-Plugin	Python HID-App	C# Native-Plugin
Läuft in der Stream Deck App	Ja	Nein, nicht standardmäßig	Ja, wenn als Plugin umgesetzt
Nutzt manifest.json	Ja	Nein	Ja
Property-Inspector-Unterstützung	Ja	Nein, es sei denn, du baust deine eigene UI	Ja, über Plugin-UI
Als .streamDeckPlugin verpackt	Ja	Nein	Ja
Am besten für Marketplace	Ja	Nein	Möglich, aber schwergewichtiger
Am besten für rein lokale Automatisierung	Gut	Exzellent	Gut

7. Praktische Empfehlung

Starte mit TypeScript, außer die Produktanforderung sagt etwas anderes.

Wechsle zu Python, wenn das Projekt eigentlich kein Plugin ist, sondern eine eigene Controller-Anwendung, die das Deck als Hardware nutzen soll.

Wechsle zu C# oder einer anderen nativen Runtime nur, wenn das Plugin nativen Code oder framework-spezifische Integrationen wiederverwenden muss, die über Node.js schlechter wären.