FigCraft – czyli Figma od nowa, w Ruście i za darmo

Trafiłem dziś na FigCraft (otwiera się w nowej karcie) – wyskoczył mi w feedzie na Facebooku – i przyznam, że opis na stronie brzmiał jak spis życzeń każdego front-endowca, który choć raz musiał przekonywać kogoś w firmie do kolejnej licencji: „Interface design, rebuilt in pure Rust”. Czyli – w dużym skrócie – Figma napisana od zera, jako natywna aplikacja desktopowa. Darmowa, open source, bez konta, bez telemetrii i bez abonamentu.

Ktoś powie: kolejna „alternatywa dla Figmy”, takich już trochę było. I to prawda. Ale tu jest kilka rzeczy, które sprawiły, że nie przewinąłem dalej – a jedna z nich to serwer MCP, czyli możliwość podpięcia agenta AI pod aplikację. A że ostatnio sporo piszę o pracy z Claude Code (choćby w poprzednim wpisie o TinyJS), to było mi z FigCraftem po drodze.

Od razu uczciwie – to jest wpis „na gorąco”. Testowałem na szybko, może ze 2 godziny, na MacBooku Pro M5. Głównie pod jednym kątem: czy FigCraft nadaje się do projektowania interfejsów i layoutów lokalnie, na własne potrzeby – razem z AI. Bez wnikania w każdy szczegół. No to lecimy…

A co to za zwierz?

FigCraft to część większego projektu – ArtCraft, czyli rodziny aplikacji z dopiskiem „Craft” w nazwie. Twórcy zapowiadają cały zestaw darmowych narzędzi, które mają robić to, co pakiet Adobe: PhotoCraft (grafika rastrowa), VectorCraft (ilustracja), FilmCraft (montaż wideo), LightCraft (zdjęcia i RAW-y), DesignCraft (skład) i kilka innych. Wszystkie pisane w Ruście, bez Electrona. Kod leży na GitHubie, w organizacji storytold (otwiera się w nowej karcie).

Sam FigCraft w README opisany jest jako „clean-room reimplementation of Figma” – czyli odtworzenie Figmy od podstaw, bez korzystania z jej kodu. Licencja: MIT albo Apache-2.0, do wyboru.

Co jest w środku? Lista funkcji wygląda zaskakująco poważnie:

• ramki i auto layout – w obu kierunkach, z zawijaniem i gridem, do tego constrainty i siatki
• komponenty i warianty – instancje z nadpisaniami, zestawy komponentów, style i zmienne z trybem jasnym i ciemnym
• wektory – pióro, ołówek, shape builder, operacje boolowskie, obrys o zmiennej grubości
• prototypowanie – połączenia, triggery, animowane przejścia i tryb prezentacji
• Dev Mode – pomiary i generowany kod: CSS, HTML, React, SwiftUI i Compose
• sesje na żywo – host wysyła link, goście edytują ten sam plik w czasie rzeczywistym, z kursorami i czatem

Vue w Dev Mode… nie ma. No cóż, nie można mieć wszystkiego 🙂

Aplikacja działa na macOS (Apple Silicon i Intel), Windowsie (również ARM), Linuksie (Flatpak, AppImage, .deb, .rpm), a nawet na FreeBSD. Jest też wersja w WebAssembly, którą można postawić u siebie na serwerze. Aktualna wersja w chwili pisania to 0.5.1.

Haczyk? Oczywiście, że jest…

I to wypisany wprost na stronie: early alpha. Autorzy w README sami zresztą szacują, że FigCraft jest mniej więcej w 49% drogi do tego, żeby zastąpić Figmę w prawdziwej pracy. Szacunek za szczerość – rzadko który projekt tak otwarcie mówi, że jeszcze nie jest gotowy.

Kilka rzeczy, o których trzeba wiedzieć na starcie:

• pliki zapisywane są lokalnie, jako archiwa .figcraft – chmury i kont na razie nie ma
• import plików .fig działa w trybie „best effort” i – cytując README – nie był jeszcze sprawdzany na prawdziwych dokumentach z Figmy
• da się za to wczytać plik wyeksportowany przez Figma REST API (JSON), łącznie z prototypami i zmiennymi
• pluginy działają w WebAssembly, a nie w systemie pluginów Figmy – więc ulubione wtyczki trzeba sobie odpuścić
• multiplayer to dopiero „first preview”

Czyli o ile do zabawy i małych projektów wygląda obiecująco, o tyle przenoszenie na to firmowego design systemu to na dziś raczej odważny pomysł.

Instalacja

Poszedłem najprostszą drogą i pobrałem 2 pliki:

• figcraft-0.5.1-macos-universal.dmg – sama aplikacja, 92 MB
• figcraft-cli-0.5.1-macos-universal.zip – narzędzie wiersza poleceń, 76 MB (o nim za chwilę, bo to właśnie przez nie AI rozmawia z FigCraftem)

Można też zainstalować wszystko przez ArtCraft Launcher albo zbudować ze źródeł (cargo run --release -p figcraft), ale do szybkiego testu DMG w zupełności wystarczy. Strona obiecuje, że aplikacja „opens instantly” – i na moim komputerze faktycznie uruchamia się błyskawicznie.

Pierwsze wrażenia

Podobieństwo do Figmy jest wręcz bliźniacze. Układ paneli, narzędzia, nazewnictwo – jeśli ktoś w Figmie pracował, to czuje się tu jak w domu i ręka sama wie, gdzie kliknąć.

Jedno zastrzeżenie: moje doświadczenia z Figmą to przede wszystkim perspektywa front-endowca – praca z gotowym projektem, odczytywanie wymiarów, eksport assetów. Nie jestem projektantem, więc nie brałem na warsztat auto layoutu, wariantów i nadpisań „z ręki” ani importu plików z Figmy. To zostawiam na inny raz – albo dla kogoś, kto w Figmie spędza całe dnie.

Dev Mode, czyli co z tego ma front-endowiec

Generowanie kodu jest dostępne również z CLI (komenda inspect.code), więc sprawdziłem je na tej samej karcie logowania, którą zbudował agent (o tym niżej). Wynik dla Reacta wygląda tak:

export function Logowanie() {
  return (
    <div className="logowanie">
      <p className="zaloguj-si">Zaloguj się</p>
      <p className="witaj-ponownie-na-nowoczesny-frontend-pl">Witaj ponownie na nowoczesny-frontend.pl</p>
      <div className="pole-e-mail">
        <p className="jan-example-com">jan@example.com</p>
      </div>
      <div className="przycisk">
        <p className="zaloguj">Zaloguj</p>
      </div>
    </div>
  );
}

Do tego osobny plik CSS z flexboxem, odstępami, kolorami i fontami – wartości zgadzają się z projektem co do piksela. Ale od razu widać problem z dostępnością: same div i p. Nagłówek nie jest nagłówkiem, pole e-mail nie jest inputem, a przycisk nie jest buttonem. A klasa zaloguj-si? Polskie „ę” po prostu wypadło z nazwy. Trudno mieć o to pretensje do narzędzia graficznego, które nie wie, co ma oznaczać ta czy inna ramka. Ale jako punkt wyjścia do kodu produkcyjnego to się raczej nie nada. Jako ściąga z wartościami CSS – jak najbardziej.

Dostępność

Ciekawostka dla tych, którzy czytają mnie dłużej – w README pojawia się AccessKit, czyli biblioteka do obsługi dostępności w natywnych aplikacjach w Ruście. Przy narzędziach graficznych to rzadkość. Z VoiceOverem jeszcze nie siadałem, ale to na pewno pierwsza rzecz na liście przy kolejnym podejściu.

FigCraft i AI – czyli MCP

I tu dochodzimy do tego, co zainteresowało mnie najbardziej. Każdy element menu, narzędzie i gest w FigCrafcie to jedna z ponad 400 komend – i ten sam rejestr komend jest dostępny dla:

• CLI (figcraft-cli) – renderowanie i eksport plików, uruchamianie skryptów JSON bez okna
• kanału sterującego JSON
• serwera MCP – figcraft-cli mcp, działającego bez okna albo podpiętego pod uruchomioną aplikację (--attach)

Innymi słowy – agent AI może robić w FigCrafcie dokładnie to samo, co ja myszką. Bez scrapowania ekranu i bez kombinowania.

Brzmi pięknie, więc zamiast wierzyć na słowo – sprawdziłem. A konkretnie poprosiłem Claude Code, żeby wziął figcraft-cli w wersji 0.5.1 (osobna paczka, po rozpakowaniu ok. 150 MB, leży u mnie w Aplikacjach obok samego FigCraft.app) i zobaczył, czy da się go używać z poziomu agenta.

Skrypt zamiast myszki

Najprostsza droga to figcraft-cli run – podajemy plik JSON z listą komend, a CLI wykonuje je bez otwierania okna i zapisuje wynik do pliku .figcraft. Kolejne warstwy dostają po prostu kolejne numery (pierwsza strona to 1, pierwsza warstwa to 2), więc w następnych krokach można się do nich odwołać:

[
  {"command": "frame.create", "params": {"name": "Logowanie", "width": 400, "props": {"fill": "#ffffff", "layout": "vertical", "gap": 16, "padding": 32, "cornerRadius": 16, "sizingV": "hug"}}},
  {"command": "node.create", "params": {"type": "text", "parent": 2, "text": "Zaloguj się", "props": {"fontSize": 28, "fontFamily": "Inter", "fontStyle": "Bold"}}}
]

figcraft-cli run login.json --out login.figcraft
figcraft-cli export login.figcraft -o login.png --scale 2

Na każdy krok CLI odpowiada jedną linią JSON-a ({"command":"frame.create","ok":true,"result":{"id":2},"step":0}), więc agent od razu wie, co się udało i jakie id dostała nowa warstwa. Cały skrypt z 8 krokami – ramka z auto layoutem, nagłówek, opis, pole e-mail, przycisk zamieniony w komponent – wykonał się w ok. 60 ms. Efekt:

Polskie znaki na miejscu, auto layout się zgadza, przycisk rozciąga się na całą szerokość. Szału nie ma, ale to jest dokładnie to, co zleciłem – i ani razu nie dotknąłem myszki 🙂

Lista komend jest dostępna przez figcraft-cli commands (z opisem parametrów, a z --json w formie, którą agent łatwo przetrawi). Ciekawostka – na stronie jest „400+”, a w wersji 0.5.1 naliczyłem ich 536. Najwięcej dotyczy tekstu (52), widoku (44) i wektorów (40).

Serwer MCP

Druga droga to figcraft-cli mcp, czyli serwer MCP na stdio. Po podłączeniu wystawia agentowi 18 narzędzi:

• ogólne – list_commands, run_command i batch (kilka komend jako jeden krok cofania, więc jednym undo da się odkręcić całość)
• warstwy – create_node, set_properties, get_node, select
• podgląd – inspect_document, inspect_ui i screenshot
• pliki – open_file, save_file, export
• historia – undo, redo
• „ręce” – pointer, key, type_text, czyli symulowanie myszki i klawiatury

Najbardziej ucieszył mnie screenshot. Pamiętacie wpis o TinyJS? Największym problemem było tam to, że Claude nie widział aplikacji, którą budował. Tutaj agent może w każdej chwili zrobić zrzut swojej pracy, obejrzeć go i poprawić to, co się rozjechało. Sprawdziłem – działa także w trybie bez okna.

Podpięcie do Claude Code to jedna komenda:

claude mcp add figcraft -- /Applications/figcraft-cli-0.5.1-macos-universal/figcraft-cli mcp

Jest też tryb --attach, w którym serwer MCP steruje uruchomioną aplikacją (trzeba ją odpalić z parametrem --control <port>). Na ekranie widać wtedy na żywo, jak agent rysuje.

Ten tryb też sprawdziłem. Po uruchomieniu aplikacji z --control 47800 w terminalu pojawia się komunikat „FigCraft control server listening on 127.0.0.1:47800” – kanał nasłuchuje wyłącznie lokalnie, więc nikt z sieci się pod niego nie podepnie. Agent zbudował tę samą kartę logowania warstwa po warstwie, a ja patrzyłem, jak w panelu warstw pojawiają się kolejne elementy. Pojedyncze wywołanie create_node trwało 13–37 ms, a screenshot z window: true zwrócił zrzut całego okna aplikacji (1440×900) – czyli agent widzi nie tylko projekt, ale też panele i zaznaczenie. Działają również undo i redo – zmiany agenta trafiają do zwykłej historii dokumentu.

„Wyrysuj panel rejestracji”

Karta logowania to jednak prosta rzecz. Chciałem zobaczyć, co agent zrobi, gdy dostanie zadanie bardziej po ludzku – bez listy pól, bez kolorów, bez wymiarów. Całe polecenie brzmiało: „wyrysuj panel rejestracji”. Tylko tyle i aż tyle.

Claude Code nie zaczął od rysowania, tylko od napisania sobie kilku pomocniczych funkcji – „pole z etykietą”, „pionowy stos”, „tekst” – i dopiero z nich złożył cały ekran. Trochę jak programista, który, zanim zacznie kopiować ten sam kawałek kodu 4 razy, robi z niego komponent 🙂 Z drobnym zastrzeżeniem: w tej sesji narzędzia MCP nie były jeszcze wczytane, więc agent rozmawiał przez krótki skrypt w Pythonie z serwerem MCP podpiętym pod uruchomioną aplikację, wysyłając te same wywołania (create_node, select, screenshot), które normalnie wysłałby bezpośrednio.

Co wyszło? Karta „Rejestracja” postawiona obok karty logowania, z auto layoutem (wysokość dopasowana do treści – 650 px), zaokrągleniem i cieniem. W środku:

• nagłówek „Załóż konto” z podtytułem
• 4 pola z etykietami: imię i nazwisko, e-mail, hasło (z podpowiedzią „Minimum 8 znaków, w tym cyfra”) i powtórzenie hasła
• checkbox z akceptacją regulaminu
• zielony przycisk „Utwórz konto” – w tym samym kolorze co przycisk logowania
• stopka „Masz już konto? Zaloguj się”

Na plus – porządek w warstwach. Każde pole to osobna ramka nazwana po polsku („Pole – Hasło”, a w niej „Input”), są „Przycisk”, „Zgoda” i „Stopka”. Kto choć raz dostał plik, w którym warstwy nazywały się „Frame 4728” i „Rectangle 12 copy 3”, ten doceni… Agent trzymał się też stylu karty logowania – ten sam font, ta sama zieleń, te same zaokrąglenia – mimo że nikt mu tego nie kazał.

Bez potknięć się nie obyło. Pierwsza próba wyłożyła się już na pierwszej warstwie – agent podał przesunięcie cienia jako obiekt {x, y}, a FigCraft oczekuje pary [x, y]. Komunikat był na tyle konkretny („expected a tuple of size 2”), że wystarczyła jedna poprawka i druga próba przeszła w całości. Na szczęście błędne wywołanie niczego nie utworzyło, więc nie trzeba było sprzątać połowicznie narysowanej karty.

Czy to jest projekt gotowy do wdrożenia? Nie. Pola to wciąż zwykłe ramki, a nie komponenty z wariantami (błąd, focus, wyłączone), checkbox to prostokąt, a o kontraście szarego tekstu podpowiedzi warto byłoby jeszcze porozmawiać. Ale jako szkic na start, zrobiony z 3 słów polecenia – jestem pod wrażeniem.

Na co uważać?

Jedna pułapka wyszła od razu. Gdy agent podał w parametrze parent napis zamiast liczby (próbował po swojemu odwołać się do wyniku poprzedniego kroku), FigCraft go… po prostu zignorował. Warstwa wylądowała bezpośrednio na stronie, a CLI zwrócił "ok": true. Za to nieistniejące id (parent: 999) czy nieznana komenda kończą się porządnym błędem i kodem wyjścia 1 – i wtedy nic nie jest zapisywane. Czyli agentowi warto kazać sprawdzać wynik przez info albo inspect_document, a nie tylko patrzeć na ok.

Design system bloga – czyli coś na poważnie

Karta logowania i panel rejestracji to była rozgrzewka. Skoro agent potrafi rysować, to czemu nie dać mu czegoś, co faktycznie mi się przyda? Ten blog stoi na Nuxt UI z własną paletą kolorów, ale design systemu w żadnym narzędziu graficznym nigdy nie miał – wszystko żyje w kodzie. Polecenie brzmiało więc: zrób katalog w docs, umieść w nim plik projektowy FigCraft i odwzoruj design system serwisu – „tak prawilnie – od tokenów po komponenty”.

Najpierw kod, potem rysowanie

Claude Code zaczął od tego, od czego powinien zacząć każdy, kto przenosi design system – od przeczytania źródeł. A źródeł prawdy jest tu kilka:

• app/assets/css/main.css – moja paleta brand (fiolet w oklch), fonty, nadpisane tokeny --ui-* i gradient z logo
• app/app.config.ts – czyli informacja, że primary to brand, a neutral to zinc
• Nuxt UI – tokeny semantyczne (--ui-text-muted, --ui-bg-elevated…) dla trybu jasnego i ciemnego oraz rozmiary i warianty komponentów
• Tailwind – pozostałe palety i skala odstępów

I tu pierwsza decyzja, która bardzo mi się spodobała. Zamiast przepisać kolory ręcznie do pliku, agent napisał generator (pnpm design:build), który za każdym razem czyta tokeny z kodu i buduje plik FigCraft od zera. Zmienię kolor w CSS-ie, odpalę skrypt i design system jest aktualny. Plik .figcraft jest więc tak naprawdę artefaktem builda, a nie czymś, co ktoś edytuje ręcznie i co po pół roku rozjeżdża się z produkcją. Kto pracował z design systemem w Figmie, ten wie, że to jest największa bolączka…

Generator uruchamia figcraft-cli mcp bez okna i rozmawia z nim przez MCP – dokładnie tym samym protokołem, który opisałem wyżej. Cały plik to ok. 4650 wywołań, które wykonują się w mniej więcej 1 sekundę. Tak, dobrze czytacie.

Co jest w środku?

• 157 zmiennych w 5 kolekcjach – paleta bazowa, tokeny semantyczne z trybami Light i Dark, promienie, odstępy i wymiary układu. Każda zmienna ma w „code syntax” nazwę z kodu, np. var(--ui-text-muted), więc w Dev Mode od razu widać, czego użyć w CSS-ie
• 22 style – 20 tekstowych (od tytułu wpisu po blok kodu) i 2 cienie
• 25 ikon Lucide – tych samych, których używa Nuxt UI
• 26 komponentów ze 154 wariantami – od przycisków, badge’y i pól formularza, przez callouty i karty wpisów, po nagłówek, stopkę i baner cookies
• 2 przykładowe ekrany – lista wpisów i wpis, każdy w wersji jasnej i ciemnej

Na stronie z kolorami generator od razu wylicza kontrast WCAG dla każdego tokenu tekstu – w obu trybach. Ciekawostka: wyliczone wartości zgadzają się co do setnych części z komentarzami w main.css (brand-600 na białym tle: 5,75:1). Przy okazji wyszło czarno na białym, że text/dimmed w jasnym motywie ma tylko 2,62:1 – więc nadaje się wyłącznie na placeholdery, a nie na treść.

Komponenty mają właściwości nazwane dokładnie tak jak propsy w kodzie. Przycisk to color × variant × size, czyli 2 kolory używane na blogu, 6 wariantów i 5 rozmiarów – razem 60 kombinacji. Patrząc na instancję w projekcie, od razu wiadomo, co wpisać w szablonie: <UButton color="neutral" variant="soft" size="sm">.

A teraz wisienka na torcie. Ekrany są złożone wyłącznie z instancji komponentów, a wszystkie kolory są podpięte do tokenów semantycznych. Wersja ciemna to więc ta sama ramka z przełączonym trybem kolekcji Theme – bez ruszania ani jednej warstwy. Dokładnie tak, jak działa to na stronie.

I muszę przyznać – efekt jest naprawdę dobry. Claude doskonale zebrał istniejący design system i odwzorował go w FigCrafcie: od tokenów, przez komponenty, aż po gotowe widoki, które wyglądają jak blog na produkcji. Taki trochę reverse engineering – zwykle design system powstaje najpierw w narzędziu graficznym, a potem trafia do kodu. Tu poszło dokładnie odwrotnie 🙂

Czego FigCraft (jeszcze) nie umie?

Przy tak dużym pliku wyszło sporo ograniczeń – i to jest chyba najcenniejsza część tego eksperymentu:

• brak oklch – kolory z Tailwinda v4 i moja paleta są w oklch, a FigCraft przyjmuje tylko hex. Generator konwertuje je więc do sRGB sam
• brak Inter Medium – wbudowany Inter ma tylko Regular, Italic, SemiBold i Bold, więc wszystko, co na stronie jest font-medium, w pliku jest pogrubione mocniej. JetBrains Mono też nie ma, kod jest składany fontem Liberation Mono
• przezroczystości – bg-primary/10 z Tailwinda nie da się zapisać jako alias zmiennej z inną przezroczystością, więc te tokeny są wyliczone osobno dla każdego trybu
• obrys z jednej strony – komentarz autora ma na stronie grubszą, fioletową lewą krawędź. W FigCrafcie różne grubości boków działają tylko bez zaokrąglonych rogów, więc skończyło się na pasku 4 px przypiętym do krawędzi
• format gradientu nie jest nigdzie opisany w liście komend. Agent poradził sobie sprytnie – zaimportował SVG z gradientem i podejrzał, jak FigCraft zapisał go u siebie

Do tego kilka wpadek po stronie generatora, wyłapanych dopiero po obejrzeniu podglądów. Na przykład właściwość tekstowa współdzielona przez warianty nadpisywała treść komentarzy, a blok kodu w ekranie wpisu zwinął się do wąskiej kolumny. I tu znowu przydał się eksport do PNG – agent po każdym przebiegu oglądał wygenerowane strony, wyłapywał to, co się rozjechało, poprawiał skrypt i generował plik od nowa.

Czy warto?

Jak zwykle odpowiedź brzmi – to zależy. Jeśli ktoś pracuje w zespole z rozbudowanym design systemem w Figmie, to FigCraft go nie zastąpi – i autorzy sami to przyznają. Ale jeśli szukasz darmowego narzędzia do makiet i prototypów, które działa offline, nie wymaga konta i da się nim sterować z poziomu agenta AI – warto mieć go na oku.

A mój werdykt na szybko? To bardzo interesujący projekt. Darmowy, lokalny, bez konta i bez chmury, a do tego ze świetną integracją z Claude. Właśnie ta ostatnia rzecz zrobiła na mnie największe wrażenie – agent nie tylko rysuje, ale też widzi, co narysował, i sam poprawia własne błędy.

Oczywiście widać, że to wczesna wersja i sporo jest do dopracowania. Część funkcji może jeszcze nie działać, a u mnie przy otwieraniu pliku wyskakuje jakiś błąd – choć plik ostatecznie się wczytuje. Ale to raczej powód, żeby FigCrafta śledzić i testować kolejne wersje, a nie żeby go skreślać.

Co dalej?

Na pewno będę dalej eksplorował współpracę FigCrafta z Claude. Najbardziej ciekawi mnie zabawa design systemem w obie strony – nie tylko „design system → projekt”, jak w tym wpisie, ale też odwrotnie: „projekt → design system”, czyli wyciąganie tokenów i komponentów z gotowego projektu z powrotem do kodu.

A Wy – próbowaliście już FigCrafta albo innych aplikacji z rodziny ArtCraft? Dajcie znać w komentarzach, chętnie porównam wrażenia 🙂