FigmaToCode: vom Figma-Frame zu HTML, Tailwind, Flutter und SwiftUI
Projektüberblick: Generieren Sie reaktionsfähige Seiten und Apps auf HTML, Tailwind, Flutter und SwiftUI.
Auf einen Blick
- Was ist das?
- Ein GPL-3.0-Plugin in TypeScript, das Figma-Auswahlen deterministisch in HTML-, Tailwind-, Flutter- und SwiftUI-Code umwandelt, vollständig in der Plugin-Sandbox, ohne KI-Modell, Account oder Netzwerkzugriff.
- Für wen ist es gedacht?
- FigmaToCode passt zu Frontend- und Flutter-Teams, die aus einer Figma-Auswahl ein bearbeitbares visuelles Gerüst wollen, ohne Designdaten an einen Cloud-Dienst zu schicken, und die bereit sind, Logik, Zustand und Barrierefreiheit selbst zu ergänzen. Es passt nicht, wer semantische Erkenntnisse oder ganze Produktionsanwendungen erwartet, denn das Plugin erfindet bewusst nichts.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 43 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 17. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
FigmaToCode als deterministische Brücke zwischen Frame und Code
Zwischen einem fertigen visuellen Design und einer echten Implementierung liegt unproduktive Handarbeit: Abstände ablesen, Farben übertragen, Layout nachbauen. FigmaToCode von bernaferrari setzt genau an dieser Stelle an. Man wählt einen Frame, eine Komponente oder eine kleinere Ebenengruppe aus und erhält ein lesbares visuelles Gerüst, das sich kopieren, verfeinern oder als Starterprojekt herunterladen lässt. Nach Repository-Metadaten zählt das Projekt 5.158 Sterne, es ist in TypeScript geschrieben und steht unter GPL-3.0.
Der technische Kern ist eine bewusste Absage an die übliche Kategorie: Der Generator ist deterministisch und läuft vollständig in der Plugin-Sandbox von Figma. Er ruft laut README kein KI-Modell auf, durchsucht kein Repository und sendet die Auswahl an keinen externen Dienst. Das macht ihn für schnelle Übergaben ebenso brauchbar wie für Teams, bei denen die externe Verarbeitung von Designdaten nicht erlaubt ist. Beide Modi von Figma werden abgedeckt, das reguläre Plugin läuft in Figma Design, die Codegen-Ausgaben stehen zusätzlich im Dev Mode bereit.
Ausgabeziele: HTML, Tailwind 3 und 4, Flutter und SwiftUI
Vier Hauptziele deckt das Plugin ab, jeweils mit mehreren Ausgabeformen. Das HTML-Ziel liefert HTML, React (JSX), Svelte und styled-components. Das Tailwind-CSS-Ziel erzeugt HTML, React (JSX) und Twig und unterstützt laut README sowohl Tailwind 3 als auch Tailwind 4. Flutter kann als vollständige App, als zustandsloses Widget oder als Snippet ausgegeben werden, SwiftUI als Preview, als View-Struct oder als Snippet.
Über den Einzelcode hinaus verpackt das Plugin generierten Code und lokale Bild-Assets in herunterladbare Starter: für das Web Vite, Next.js oder statisches HTML, für Flutter Quellcode samt pubspec.yaml, Assets und Einrichtungsanweisungen, für SwiftUI Quellcode mit Asset-Katalog. Das README stellt klar, dass diese Exporte bewusst klein und abhängigkeitsarm gehalten sind, Ausgangspunkte, keine generierten Produktionsanwendungen. Diese Grenzziehung ist ehrlich und wichtig: Wer ein Starterprojekt entpackt, bekommt eine Struktur zum Weiterbauen, keine fertige Applikation.
Datenschutzmodell: manifest.json mit allowedDomains none
Die Datenschutzbehauptung des Plugins ist ausnahmsweise maschinenprüfbar. Die manifest.json auf Repository-Ebene ist die Konfiguration, die Figma für das veröffentlichte Plugin verwendet, und sie enthält laut README zwei durchsetzbare Grenzen: permissions ist leer, und networkAccess.allowedDomains steht auf none. Das heißt konkret, die veröffentlichte Plugin-Konfiguration erlaubt keine Netzwerkdomänen und fordert keine Berechtigungen an.
Der Datenfluss bleibt demnach im Prozess: Ausgewählte Knoten werden über die Figma-Plugin-API gelesen, im Speicher normalisiert, von frameworkspezifischem TypeScript konvertiert und an die Plugin-Oberfläche zurückgegeben. Keine Telemetrie, kein Design-Upload, kein externes Modell, kein separates Konto. Das README rahmt die Aussage bewusst eng: Figma selbst ist ein vernetztes Produkt und behandelt Dateien nach dem eigenen Plan und den Richtlinien des Nutzers, das Plugin fügt den ausgewählten Designdaten nur kein weiteres Netzwerkziel hinzu. Diese Ehrlichkeit schützt vor falschen Schlussfolgerungen, ein Datenschutzaudit muss Figma selbst weiterhin einschließen.
Compiler-Pipeline: Read, Normalize, Optimize, Generate, Explain
Das README beschreibt den Generator eher als kleinen Compiler denn als Screenshot-zu-Code-Dienst, und die fünf Schritte zeigen warum. Read inspiziert die ausgewählten Figma-Knoten samt Layout- und Stil-Metadaten. Normalize überführt sie in einen internen Baum, ohne das Quelldokument zu verändern. Optimize löst Eltern-Kind-Beziehungen, Auto Layout, Ausrichtung, Größen und Positionierung auf. Generate reicht den normalisierten Baum an das gewählte Backend für HTML, Tailwind, Flutter oder SwiftUI weiter, Explain gibt Code, Vorschaudaten, extrahierte Assets und Konvertierungswarnungen zurück.
Der letzte Schritt ist praktisch bedeutsam: Wenn sich ein Detail nicht sauber übersetzen lässt, meldet das Plugin eine Warnung, statt ein exaktes Ergebnis vorzutäuschen. Weil die Regeln öffentlicher TypeScript-Code sind, lässt sich die Konvertierung nach README prüfen, testen und verbessern, ohne von einer gehosteten API abzuhängen. Für Eigenentwickler nennt das README Node.js 24 oder neuer und pnpm 11, den Einstieg mit pnpm install im Repository-Root und pnpm dev, das Plugin-Watcher und die Website unter http://localhost:3000 startet, gezielt am Plugin arbeitet man mit pnpm --filter plugin dev.
Feinsteuerung: Tailwind-Token-Rundung, Base64 und SVG-Einbettung
Die Optionen erscheinen nur, wenn sie zum gewählten Ziel passen, was die Oberfläche klein hält. Dazu gehören: Figma-Ebenennamen in generierte Klassennamen übernehmen, exakte Werte behalten oder Abstände und Farben auf nahe Tailwind-Token runden, Tailwind-4-Syntax erzeugen und ein eigenes Klassenpräfix setzen, Figma-Farbvariablen in unterstützten Ausgaben verwenden, Bilder in HTML als Base64 einbetten, unterstützte Vektorformen für die Web-Ausgabe als SVG einbetten, und zwischen Datei-, Komponenten- und Snippet-Modus wechseln.
Die Rundungsoption verdient besondere Aufmerksamkeit, weil sie über die Wartbarkeit entscheidet. Exakte Pixelwerte ergeben Design-Treue, aber ein Stylesheet voller Einzelpixelwerte, die Token-Rundung ordnet die Ausgabe in das bestehende Designsystem ein, kann dabei aber von der Vorlage abweichen. Die Oberfläche ergänzt eine visuelle Vorschau mit hellem und dunklem Hintergrund, Konvertierungswarnungen, extrahierte Farben und Verläufe sowie Code-Kopieren und Projekt-Download. Das README empfiehlt kleinere Auswahlen, weil sie bessere Komponentengrenzen erzeugen, ein wiederverwendbarer Abschnitt statt einer ganzen Seite.
Bewusste Grenzen: keine Anwendungslogik, keine erfundene Barrierefreiheit
Das README zieht die Grenzen des Plugins selbst und nennt sie bewusst. Kein KI-Eingriff heißt: Das Plugin erfindet keine Semantiken, Interaktionen oder promptbasierten Neugestaltungen. Keine Codebasis-Verbindung heißt: Es durchsucht kein Repository, bildet keine bestehenden Komponenten ab, importiert keine Anwendung in Figma, synchronisiert keine Dateien und schiebt keine späteren Designänderungen in den Code. Keine Anwendungslogik heißt: State Management, Datenladen, Navigation, Backend-Verhalten und Geschäftsregeln werden nicht abgeleitet.
Auch die Barrierefreiheit wird dem Plugin nicht unterstellt: Semantiken, Labels, Tastaturverhalten, dynamische Typen und responsive Breakpoints brauchen weiterhin menschliche Prüfung. Zielabhängige Details existieren ebenfalls, Vektorunterstützung ist im Web optional und in nativen Zielen begrenzt, Sterne, Polygone, Linien, Verläufe und Effekte haben nicht immer ein Pendant in der Ziel-API. Große Auswahlen kosten mehr Speicher und Zeit, fokussierte Auswahlen sind zuverlässiger. Ein Figma-Dokument beschreibt visuelle Struktur, nicht die Absicht einer Anwendung, und das Plugin bestreitet das Gegenteil nirgends.
Alternative: KI-basierte Screenshot-Dienste gegen die deterministische Konvertierung
Die naheliegende Alternative ist eine KI-basierte Umwandlung, die aus einem Screenshot oder Design Code erzeugt und dabei Semantik, Komponentennamen oder sogar Frameworkwechsel vorschlägt. Der Unterschied ist ein Tauschhandel: Solche Dienste liefern offen interpretierende Ergebnisse und brauchen typischerweise Uploads, Accounts oder Generationenkontingente, FigmaToCode liefert ein vorhersagbares Ergebnis aus den echten Knotendaten, ohne Netzwerk und ohne Kontingent.
Für Teams mit strengen Datenschutzregeln fällt dieser Tausch eindeutig aus, die deterministische Variante ist die einzige, die die manifest-Grenze von none in jedem Audit übersteht. Wer dagegen aus einem groben Mockup semantische Vorschläge will, ist mit einem KI-Dienst besser bedient, denn das Plugin erfindet nichts. Für an der Repository-Struktur interessierte Entwickler liegt das Backend unter packages/backend für Knotenverarbeitung und Codegeneratoren, die gemeinsame React-Oberfläche unter packages/plugin-ui, der Figma-Controller unter apps/plugin und die öffentliche Website mit der Datenschutzseite unter apps/web.
Redaktionelles Fazit
FigmaToCode passt zu Frontend- und Flutter-Teams, die aus einer Figma-Auswahl ein bearbeitbares visuelles Gerüst wollen, ohne Designdaten an einen Cloud-Dienst zu schicken, und die bereit sind, Logik, Zustand und Barrierefreiheit selbst zu ergänzen. Es passt nicht, wer semantische Erkenntnisse oder ganze Produktionsanwendungen erwartet, denn das Plugin erfindet bewusst nichts. Vor dem ersten Export lohnt ein Blick in die manifest.json im Repository, um die Netzwerkgrenze selbst zu prüfen, und ein Probelauf mit einer kleinen, wiederverwendbaren Auswahl, um die Konvertierungswarnungen in der eigenen Designstruktur zu sichten.
Community-Notizen