Das Figma-Plugin-Ökosystem ist groß. Es gibt Plugins für Token-Export, Code-Annotation, Style Guides, Accessibility-Checks und Code-Generierung. Wenn jemand "Figma-zu-Code-Tool" sagt, meinen sie fast immer ein Plugin. figmascope ist kein Plugin. Hier ist, warum das wichtig ist — und wann nicht.
Das Plugin-Modell
Figma-Plugins laufen in einem sandboxed iframe innerhalb der Figma Desktop- oder Web-App. Sie erhalten Zugang zur Figma Plugin API — eine JavaScript-Schnittstelle, die den Node-Baum der aktuellen Datei, Styles, Komponenten und Variablen offenlegt. Das Plugin kann diese Daten lesen, transformieren und Ergebnisse zurück in die Datei schreiben oder Dateien über Figmas Save-Dialog in das lokale System des Benutzers exportieren.
Die Plugin-API ist reich. Man kann jeden Node traversieren, berechnete Styles lesen, auf Komponentendefinitionen zugreifen, Variablen abfragen und sogar Netzwerkanfragen aus der Plugin-UI-Ebene machen. Für die meisten "Design-Daten lesen und etwas damit tun"-Aufgaben ist die Plugin-API ausreichend.
Plugins werden über den Figma Community Store oder als private Team-Plugins verteilt. Benutzer installieren sie über die Figma-Oberfläche. Updates kommen über Figmas Plugin-Hosting. Das Entwicklerkonto, das das Plugin veröffentlicht hat, kann Updates pushen; Benutzer erhalten sie beim nächsten Start des Plugins.
Beliebte Figma-zu-Code-Plugins: Locofy (behandelt im Locofy-Vergleich), Tokens Studio (Design-Token-Sync), Figma to Code (Open Source Flutter/SwiftUI/Jetpack Compose), und Dutzende spezialisierter Tools.
Plugin-Einschränkungen
Läuft nur innerhalb von Figma. Um ein Plugin auszuführen, muss man Figma öffnen, die Datei öffnen, das Plugin öffnen und den Export auslösen. Das Plugin kann nicht von einem Terminal, einem CI-Job, einem Skript oder einem anderen Kontext außerhalb der Figma-App aufgerufen werden. Es gibt keine CLI. Es gibt keine API, die man aufrufen kann. Der gesamte Ausführungskontext ist die Figma-UI.
Nur Laufzeit-Ausführung. Plugins laufen nicht im Hintergrund. Sie laufen, wenn ein Mensch sie öffnet und auf die Schaltfläche klickt. Geplante Exporte, automatisierte Pipelines und programmatische Integration sind durch das Plugin-Modell nicht möglich.
Plugin-Store-Gatekeeper. Das Veröffentlichen eines öffentlichen Figma-Plugins erfordert Figmas Überprüfung und Genehmigung. Updates erfordern eine erneute Überprüfung. Wenn Figma seine Review-Richtlinien ändert oder entscheidet, dass ein Plugin im Widerspruch zu seinen Interessen steht, kann das Plugin entfernt oder eingeschränkt werden. Private Team-Plugins umgehen den Store, laufen aber trotzdem in Figmas Sandbox und hängen von Figmas Plugin-Infrastruktur ab.
Ressourcenbeschränkungen. Die Plugin-Sandbox ist in Speicher und Ausführungszeit begrenzt. Große Figma-Dateien mit komplexen Hierarchien können Timeouts verursachen oder das Plugin zum Absturz bringen. Die Plugin-UI läuft in einem iframe mit eingeschränktem Zugriff — kein Zugriff auf das lokale Dateisystem außer über Figmas Export-Dialog, kein beliebiger Netzwerkzugriff vom Haupt-Thread.
Plattformübergreifende Inkonsistenzen. Die Figma-Desktop-App und die Web-App haben in einigen Edge Cases leicht unterschiedliches Plugin-API-Verhalten. Plugins, die in einer einwandfrei funktionieren, können in der anderen Eigenheiten aufweisen.
Installations-Reibung bei Team-Distribution. Jeder Entwickler, der das Plugin ausführen muss, installiert es separat. Versionskonsistenz im Team hängt von Figmas automatischem Update-Mechanismus ab. Wenn man eine bestimmte Version pinnen muss, ist das nicht einfach.
figmascopes externer Ansatz
figmascope berührt das Plugin-System überhaupt nicht. Es läuft in einem Standard-Browser-Tab — jeder Browser, keine Figma-App erforderlich — und ruft die Figma REST API direkt über ein vom Benutzer bereitgestelltes Personal Access Token auf. Das PAT wird nur im Speicher gehalten und nie an einen Server gesendet.
Die Figma REST API ist dieselbe Datenquelle, aus der auch die Plugin-API schöpft, aber extern zugänglich. figmascope holt das Datei-JSON, verarbeitet den Node-Baum clientseitig (alle Berechnungen finden im eigenen Browser statt) und produziert das Kontext-Bundle. Die API-Aufrufe gehen direkt vom Browser zu Figmas Servern. figmascopes eigene Infrastruktur ist nicht im Datenpfad.
Das hat mehrere Konsequenzen:
Keine Installation. Tab öffnen, Figma-URL und PAT einfügen, Export klicken. Nichts zu installieren, kein Konto zu erstellen, kein Plugin im Community Store zu suchen. Jeder mit einem Browser kann es verwenden — einschließlich Entwickler, die keine Figma-Benutzer sind und die App nicht installiert haben.
Prinzipiell skriptfähig. Da figmascope auf der REST API aufgebaut ist, können dieselben Aufrufe programmatisch reproduziert werden. Die MIT-Codebasis ist zur Inspektion offen. Wenn man ein Skript bauen möchte, das ein Bundle von der Kommandozeile ohne Browser exportiert, zeigt die figmascope-Quelle genau, wie die API aufzurufen und die Antwort zu verarbeiten ist.
Prinzipiell CI/CD-kompatibel. Eine headless Export-Pipeline ist erreichbar: Figma-REST-API-Aufrufe, dieselbe IR-Verarbeitungslogik, dasselbe Bundle-Format. figmascopes Browser-App läuft nicht direkt in CI (es ist ein Browser-Tool), aber der architektonische Ansatz — REST API, deterministische Verarbeitung, einfacher Datei-Output — ist by Design CI-freundlich. Nichts am Modell erfordert eine GUI.
Keine Plugin-Store-Abhängigkeit. figmascope wird auf einer Domain gehostet, ist Open Source auf GitHub. Es hängt nicht von Figmas Plugin-Infrastruktur oder Überprüfungsprozess ab. Figma kann es nicht aus einem Store entfernen. Wenn die Domain ausfällt, kann man es lokal aus dem Repo ausführen — es ist vollständig statisches HTML/JS.
Keine Figma-App erforderlich. Ein Entwickler kann Kontext für eine Figma-Datei exportieren, die er nie in der Figma-App geöffnet hat, nur mit einer geteilten Figma-URL und einem PAT. Das ist wichtig für Workflows, bei denen Ingenieure Figma nicht direkt verwenden, aber die Design-Spezifikation benötigen.
Was Plugins besser machen
Faire Einschätzung. Plugins haben echte Vorteile, die der externe API-Ansatz nicht repliziert.
In-Canvas-Annotation. Plugins können zurück in die Figma-Datei schreiben — Annotationen hinzufügen, Komponenteneigenschaften setzen, Frames als fertig markieren, Kommentare posten. figmascope ist nur lesend. Wenn ein Tool benötigt wird, das Design-seitige Arbeit innerhalb von Figma leistet, braucht man ein Plugin.
Lebendiger Canvas-Kontext. Ein Plugin weiß, was ausgewählt ist. Es kann auf Selektionsänderungen reagieren, Node-Updates beobachten und auf laufende Design-Arbeit reagieren. figmascope nimmt einen Snapshot. Es hat keinen Live-Canvas-Zugriff.
Team-Distribution via Figma-Org. Wenn das gesamte Team auf einem Figma-Org-Plan ist, ist das Pushen eines privaten Plugins an das Team einfach. Alle haben es in ihrer Figma-Instanz. Für team-übergreifende Distribution innerhalb einer Org wird das Plugin-Modell gut unterstützt.
Reichhaltigere Interaktion in der Figma-UI. Ein Plugin kann benutzerdefinierte UI in einem Panel rendern, auf Benutzerinteraktionen reagieren und sofortiges Feedback im bestehenden Workflow des Designers geben. figmascopes Interface ist ein separater Browser-Tab — ein Kontextwechsel.
Vergleich
| Dimension | Figma Plugins (allgemein) | figmascope |
|---|---|---|
| Läuft innerhalb von Figma | Ja — sandboxed iframe | Nein — externer Browser-Tab |
| Erfordert Figma App/Konto | Ja | Nur ein PAT (funktioniert mit kostenlosem Figma-Konto) |
| Installation erforderlich | Ja — Figma Community oder Team-Installation | Nein — im Browser öffnen |
| Skriptfähig / automatisierbar | Nein — nur GUI-Ausführung | Ja prinzipiell — REST-API-basiert |
| CI/CD-kompatibel | Nein | Architektur ist CI-freundlich |
| Zurückschreiben nach Figma | Ja — kann Nodes erstellen/aktualisieren | Nein — nur lesend |
| In-Canvas-Annotation | Ja | Nein |
| Live-Canvas-Selektionskontext | Ja | Nein — nur Snapshot |
| Durch Plugin-Store-Review beschränkt | Ja (öffentliche Plugins) | Nein |
| Datenschutz | Abhängig vom Plugin — kann Daten an Plugin-Anbieter senden | Alle Verarbeitung im Browser; PAT verlässt nie das Gerät |
| Output-Format | Variiert — JSON, Code-Dateien, Annotationen, Clipboard | Strukturiertes Bundle: CONTEXT.md, tokens.json, screens/*.json, *.png |
| Agenten-optimiertes IR | Selten — die meisten Plugins zielen auf menschlichen Konsum | Ja — stack/overlay/absolute/leaf mit componentId und stringRef |
| Versionskontrollierbarer Output | Abhängig vom Plugin | Ja — Bundle ist diffbares JSON + Markdown |
| Open Source | Einige Plugins sind es; viele nicht | Ja — MIT |
Der Datenschutzaspekt
Wenn ein Figma-Plugin Netzwerkanfragen macht, können Design-Daten den Browser verlassen und zu den Servern des Plugin-Anbieters gelangen. Man vertraut der Datenschutzrichtlinie und Infrastruktur des Plugins. Für viele Teams ist das akzeptabel. Für manche — Enterprise-Teams mit NDA-bedeckten Designs, Agenturen, die mit sensiblen Kundendateien arbeiten — ist es ein bedeutendes Anliegen.
figmascopes externer Ansatz ist anders. Alle Verarbeitung findet im eigenen Browser-Tab statt. Die REST-API-Aufrufe gehen vom Browser zu Figmas Servern (dieselben Aufrufe, die der Browser macht, wenn man Figma normal verwendet). figmascopes eigene Server sind nicht im Pfad. Design-Daten gehen nirgendwo hin außer zur Figma-API. Das PAT ist im Speicher und wird beim Schließen des Tabs gelöscht.
Das ist ein struktureller Vorteil des externen Browser-Ansatzes gegenüber Plugins, die von einem Backend-Anbieter abhängen.
Wann welches wählen
Ein Figma-Plugin verwenden wenn: man zurück in die Datei annotieren oder schreiben muss, man In-Canvas-Interaktion als Teil eines Designer-Workflows möchte, das Team vollständig auf Figma ist und die Distribution via den Plugin-Mechanismus bequem ist, oder das benötigte Plugin spezifische In-Figma-UI hat, die der REST-API-Ansatz nicht replizieren kann.
figmascope verwenden wenn: man ein portables, versionskontrolliertes Kontext-Bundle für KI-Agenten-Codegen braucht, man keine Installation und keine Store-Abhängigkeit möchte, Datenschutz wichtig ist und keine Design-Daten an einen Drittanbieter-Plugin-Anbieter gesendet werden sollen, der Output im git-Repo neben dem Code leben soll, oder der Export-Prozess erklärbar und reproduzierbar sein soll.
Für die meisten Produktions-UI-Codegen-Workflows mit KI-Agenten fügt das Plugin-Modell Reibung hinzu, die es nicht zurückgewinnen kann. Das Plugin läuft in Figma. Der Agent läuft im Editor. Die Design-Spezifikation von einem zum anderen durch ein Plugin zu bringen erfordert entweder manuelles Kopieren-Einfügen oder ein Plugin, das auf die Festplatte schreibt — und dann hat man eine opake Datei aus einer opaken Pipeline. figmascopes Output ist inspizierbar, strukturiert und explizit für diesen Agenten-Handoff designed.