UnHTML gegen Anima: In welche Richtung die Umwandlung wirklich läuft

UnHTML und Anima lösen entgegengesetzte Probleme

UnHTML wandelt eine Webseite in Figma-Ebenen um. Anima wandelt ein Figma-Design in Code um. Zwei verschiedene Aufgaben. Sie werden in einen Topf geworfen, weil beide mit Figma zu tun haben und beide von einer URL ausgehen können, aber die Umwandlung läuft in entgegengesetzte Richtungen innerhalb derselben Pipeline. Wer das verwechselt, wählt das falsche Werkzeug für die eigentliche Aufgabe.

Diese Verwechslung ist wichtiger, als es klingt. Ein Designer, der eine Seite ohne Designdatei übernimmt, braucht die Richtung Webseite zu Figma. Ein Team, das bereits eine Figma-Datei hat und ein funktionierendes Frontend braucht, braucht die Richtung Figma zu Code. Wer nach "anima alternative" oder "unhtml vs anima" sucht, hat meist zuerst das falsche Werkzeug erwischt: hat versucht, Code aus einer Seite zu exportieren, die nie in Figma war, oder hat versucht, eine Webseite in ein Plugin zu importieren, das nur Figma-Dateien liest. Hier ist, was jedes Werkzeug tatsächlich tut, wo sich die beiden Workflows wirklich überschneiden und wo die Preise sie trennen.

Was UnHTML macht

UnHTML nimmt eine aktive Webseite und verwandelt sie in native, editierbare Figma-Ebenen: echte Frames, Text, Bilder, Vektoren und Auto-Layout, abgebildet aus dem eigenen CSS der Seite. Das Ergebnis ist eine Figma-Datei. Nichts daran erzeugt Code.

Es läuft standardmäßig offline, null Netzwerkanfragen in der Standardeinstellung. Das Abrufen externer Ressourcen und das Ausführen von Seiten-Skripten ist eine einzelne Opt-in-Option, standardmäßig deaktiviert, sodass sonst nichts den eigenen Rechner verlässt.

Die Preisgestaltung ist ein einmaliger Kauf, kein Abonnement. Free importiert bis zu 500 Ebenen mit absoluter Positionierung. Pro kostet $39 einmalig pro Editor, entfernt die Ebenengrenze und fügt die Auto-Layout-Umwandlung hinzu. Studio kostet $119 einmalig und deckt fünf Editoren ab.

Der Import ist nicht pixelgenau, und er versucht es auch nicht zu sein. Schriften, die lokal nicht installiert sind, werden ersetzt, standardmäßig durch Inter, und jeder Austausch taucht im Importbericht auf, statt das Design still zu verändern. Komplexe Grids, die sich nicht als Figma-Auto-Layout darstellen lassen, fallen auf absolute Positionierung zurück, statt ein Layout zu erzeugen, das gut aussieht, bis jemand einen Frame in der Größe ändert.

Was es nicht macht: kein Code-Export, kein React, kein HTML-Output. Wenn das Ziel produktionsreifer Frontend-Code ist, ist das nicht das richtige Werkzeug. Es ist auch kein Designwerkzeug zum Erstellen von etwas Neuem. Es ist ein Weg, eine bestehende Seite in ein Format zu bringen, das Figma bearbeiten kann.

Was Anima macht

Animas Kernprodukt läuft in die andere Richtung: Ein Figma-Design geht rein, Code kommt raus. Das Anima-Figma-Plugin exportiert eine Auswahl aus einer bestehenden Figma-Datei nach React, HTML, CSS oder Tailwind, Vue, TypeScript, Next.js und mehr, ausgehend von einer bereits in Figma gebauten Datei. Der Anima Playground bietet denselben Export ausgehend von einem eingefügten Figma-Link, gedacht für schnelle Prototypen und Menschen, die keine Designer sind.

Anima hat außerdem eine Clone-website-Funktion, und das ist der Teil, der die Verwechslung verursacht. Clone website nimmt eine aktive URL, denselben Ausgangspunkt, den UnHTML nutzt, erzeugt aber Code, HTML oder React, keine Figma-Ebenen. Der Einstiegspunkt sieht ähnlich aus, der Ausstiegspunkt ist entgegengesetzt. Wenn das Ziel eine editierbare Figma-Datei ist, führt Clone website nicht dorthin.

Das ist leicht zu übersehen, weil beide Werkzeuge technisch von "einer URL" ausgehen können. Entscheidend ist, was am anderen Ende herauskommt. Animas eigenes Material positioniert das Produkt rund um Teams, die vollständige Anwendungen aus einem bestehenden Figma-Design bauen, nicht rund um das Nachbauen einer Seite, für die es gar keine Figma-Datei gibt. Es ist ein Design-zu-Code-Werkzeug mit einer angeflanschten Website-Klon-Abkürzung, kein Web-zu-Design-Werkzeug.

Wie die Auto-Layout-Umwandlung tatsächlich funktioniert

Der Grund, warum eine Umwandlung von Webseite zu Figma überhaupt tragfähig ist, liegt daran, wie stark Figmas Auto-Layout-Engine inzwischen CSS widerspiegelt. Figmas eigene Anleitung zum Einsatz von Auto-Layout mit CSS-Flexbox im Hinterkopf beschreibt Padding, Gap und die Größenbestimmung von Fill-Container nach dem CSS-Border-Box-Modell. Ein Element mit Padding bekommt weiterhin den benötigten Platz, statt gestaucht zu werden, und Kindelemente, die auf Fill-Container gesetzt sind, verteilen den Platz nach ihrer Inhaltsfläche statt nach ihrer eigenen Größe, genau wie Border-Box-Größenbestimmung in CSS funktioniert.

Auch das Spacing passt zusammen. Figmas Auto-Spacing-Werte Between, Evenly und Around entsprechen direkt den CSS-Werten space-between, space-evenly und space-around. Die CSS-Eigenschaft gap selbst ist eine Kurzform für row-gap und column-gap in Flex- und Grid-Containern, und genau diese Eigenschaft, direkt aus dem Stylesheet der Seite gelesen, wird in den Gap-Wert eines Figma-Frames übersetzt.

Wo sich ein Layout nicht originalgetreu reproduzieren lässt, komplexe Grids, unübliche Stapelungen, greift als Rückfallebene die absolute Positionierung, statt eine Struktur zu erraten. Eine bewusste Grenze, kein Fehler: eine ehrliche Rückfalllösung schlägt ein Layout, das richtig aussieht und in dem Moment kaputtgeht, in dem jemand es anfasst.

Diese Grenze erklärt auch, warum die beiden Werkzeuge ihre Rollen nicht einfach tauschen können. Animas Plugin liest die eigenen Auto-Layout-Einstellungen eines Figma-Frames aus und schreibt sie als Flexbox-CSS, eine Übersetzung, die funktioniert, weil Figma das Layout bereits strukturiert und einsehbar speichert. Die andere Richtung zu gehen bedeutet, das berechnete CSS einer bereits gerenderten Seite zu lesen und zu rekonstruieren, welche Auto-Layout-Einstellungen es reproduzieren würden. Strukturierte Daten zu lesen und CSS zu schreiben ist ein enger begrenztes Problem, als die gerenderten Stile einer aktiven Seite zu lesen und ihre Struktur daraus zu rekonstruieren. Ein Teil des Grunds, warum daraus zwei getrennte Produkte wurden statt eines, das beides kann.

Preis: Einmalzahlung gegen Abonnement

Animas Preisseite legt die täglichen Obergrenzen der kostenlosen Stufe und die Enterprise-Untergrenze offen, veröffentlicht aber zum Zeitpunkt dieser Recherche keinen festen Preis pro Sitzplatz für einen Standard-Bezahlplan. Diese Zahl bleibt unverifiziert, statt geraten zu werden.

Die praktische Aufteilung: Wer eine Seite gelegentlich importiert, zahlt mit UnHTML einmal und ist fertig. Ein Team, das kontinuierlich Code exportiert, trägt ein Abonnement, das mit der Nutzung skaliert, unabhängig davon, welchen konkreten Plan es wählt.

Wann man tatsächlich beide nutzen würde

Die beiden Workflows lassen sich nur in einer Richtung verketten. Eine bestehende Seite mit UnHTML nach Figma importieren, dort neu gestalten, dann die fertige Figma-Datei an Anima übergeben, um die neu gestaltete Version als Code zu exportieren. Ein echter, gängiger Weg: zerlegen, neu gestalten, veröffentlichen. Ein Team, das eine alte Seite neu aufbaut, oder das die Seite eines Wettbewerbers zerlegt, um zu sehen, wie sie gebaut ist, bekommt einen editierbaren Ausgangspunkt, ohne jeden Frame von Hand neu zu zeichnen, und übergibt das Ergebnis dann an das Code-Export-Werkzeug, das das Frontend-Team bereits nutzt.

Den anderen Weg zu gehen, von Figma zu Code und zurück zu Figma, ergibt keinen Sinn. Das importiert nur wieder, was schon existierte. Wenn ein Design bereits in Figma lebt, gibt es nichts, was UnHTML umwandeln könnte, und ein Import gegen eine Seite laufen zu lassen, die aus genau dieser Figma-Datei gerendert wurde, würde nur eine Kopie einer Datei rekonstruieren, die das Team bereits hat.

Die Richtung ist die ganze Antwort

UnHTML und Anima konkurrieren nicht um dieselbe Aufgabe. Das eine verwandelt eine Webseite in eine editierbare Figma-Datei, das andere verwandelt eine Figma-Datei in Code. Wähle das erste, wenn das Ziel Figma ist. Wähle das zweite, wenn das Ziel versandfertiger Code ist. Die meisten Projekte, die beides brauchen, werden sie in dieser Reihenfolge nutzen, nicht als Alternativen zueinander.