GPUI do wszystkiego — pożegnanie z Electronem i Tauri

O czym jest ten film

1. Scott Tolinski ogłasza pożegnanie z Electronem, Tauri i aplikacjami desktopowymi opartymi na osadzonej przeglądarce — swoje narzędzia pisze teraz w Ruście z frameworkiem GPUI i nie zamierza wracać.
2. Punktem wyjścia jest krytyka dwóch dotychczasowych podejść: Electron dźwiga z każdą aplikacją własną kopię Chromium, a Tauri korzysta z systemowego WebKita, który na macOS ma ubogi i nieprzewidywalny zestaw funkcji.
3. GPUI pochodzi od zespołu edytora Zed, renderuje bezpośrednio na GPU i działa na macOS, Linuksie i Windowsie (web i mobile — eksperymentalnie).
4. To nie jest warstwa tłumacząca kod na natywne kontrolki — cały interfejs, od zawijania tekstu po cienie, został napisany od zera. W zamian dostaje się pełną kontrolę nad wyglądem.
5. Model programowania przypomina React: komponenty, propsy, stan, funkcja render. Różnica: zamiast JSX-a łańcuchy metod jak w jQuery, a stylowanie wygląda jak Tailwind.
6. Po zmianie stanu trzeba jawnie wywołać notify() — sami decydujemy, co ma się przerysować, co Wes porównuje do ręcznej rewalidacji w Remixie.
7. Nie ma warstwy RPC ani osobnego backendu — logika żyje w tym samym kodzie Rust i wywołujemy funkcje wprost; GPUI to wyłącznie warstwa interfejsu.
8. Biblioteka GPUI Kit — „shadcn dla GPUI” — z tabelami z wirtualizacją, dialogami czy popoverami to według Scotta największe praktyczne odblokowanie.
9. Scott pokazuje własne aplikacje: menedżer projektów rozproszonych po kilku komputerach, automatyzację plików à la Hazel i narzędzie do zarządzania oknami na natywnych Spacesach macOS.
10. Wady są realne: brak natywnych kontrolek, brak CSS grid, brak DOM, młody ekosystem i eksperymentalny mobile — za to agenty AI piszą ten kod zaskakująco dobrze.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Do małych narzędzi desktopowych bierz GPUI zamiast Electrona

Na czym polega: aplikacja w GPUI nie dźwiga kopii Chromium. Aktualizacja narzędzia może ważyć kilka megabajtów zamiast setek — Scott przywołuje DaisyDisk, który zaktualizował się o osiem megabajtów.

Jak stosować: gdy piszesz narzędzie „dla siebie” — porządkowanie plików, rejestrator ekranu, monitor procesów na kilku maszynach — wybierz GPUI i nie każ każdemu pomysłowi zamieniać się w osobną instancję Chromium pracującą w tle.

Na co uważać: do aplikacji webowych i mobilnych GPUI się nie nadaje (przynajmniej na razie) — tam sięgnij po coś innego.

2.Zapomnij o natywnym wyglądzie — projektuj własny

Na czym polega: GPUI nie używa systemowych kontrolek. Efektów w stylu Liquid Glass z macOS trzeba by odtworzyć samodzielnie, na poziomie renderowania na GPU.

Jak stosować: potraktuj to jako zaletę — pełna kontrola nad wyglądem i spójny interfejs na każdej platformie. Wystarczy własny motyw; Scott stylizuje swoje aplikacje na swój system projektowy.

Na co uważać: jeśli wymaganiem jest wygląd „sto procent macowski” albo „sto procent windowsowy”, GPUI nie jest dobrym wyborem.

3.Znasz React i Rust? Wejście jest płaskie

Na czym polega: komponenty definiuje się strukturami z propsami, jest funkcja render, dzieci i stan — koncepcje przeniesione jeden do jednego z Reacta. Reszta to idiomatyczny Rust.

Jak stosować: zacznij od prostego przykładu z dokumentacji (np. licznik) i przerabiaj go na własne komponenty — intuicje z Reacta przenoszą się niemal w całości.

Na co uważać: bez znajomości Rusta (typy, borrow checker) kod może przytłaczać; warto najpierw ogarnąć podstawy języka.

4.notify() daje ręczną kontrolę nad przerysowaniem

Na czym polega: zmiana zmiennej stanu nie odświeża interfejsu automatycznie — trzeba jawnie wywołać notify(). Wes porównuje to do samodzielnego wywołania rewalidacji w Remixie.

Jak stosować: mutujesz dane, wołasz notify() — masz pewność, że przerysuje się tylko to, co trzeba. Łatwo uniknąć zbędnych odświeżeń.

Na co uważać: łatwo zapomnieć o wywołaniu i potem szukać odpowiedzi na pytanie „dlaczego ekran się nie aktualizuje”. Pilnuj tego w każdym handlerze zdarzeń.

5.Layout projektuj pod flex — grid (na razie) nie istnieje

Na czym polega: w dokumentacji i przykładach Scott nie znalazł CSS grid; wszystko układa się we flexie, z zagnieżdżeniami.

Jak stosować: wróć do sztuki układania interfejsów sprzed ery gridu, a obliczenia rozmiarów rób programowo — jesteś przecież w kodzie Rust i możesz wszystko zmierzyć.

Na co uważać: skomplikowane dwuwymiarowe siatki będą kosztować więcej zachodu, niż przywykliśmy — zaplanuj layout przed rozpoczęciem pracy.

6.Startuj od GPUI Kit, nie od pustego ekranu

Na czym polega: GPUI Kit to bogata biblioteka komponentów — dialogi, popovery, comboboxy, paginacja, tabele z sortowaniem i wirtualizacją — w duchu shadcn.

Jak stosować: używaj jej jako fundamentu i dopasowuj style do siebie. Komponenty są na tyle neutralne, że nie narzucają wyglądu, a na tyle dopracowane, że od razu wyglądają przyzwoicie.

Na co uważać: biblioteka jest młoda i przypina konkretną wersję GPUI — sprawdzaj zgodność przy aktualizacjach. Nie obsługuje też forka GPUI CE.

7.Logika i interfejs w jednym — bez warstwy RPC

Na czym polega: w Electronu klik zwykle wywołuje funkcję na backendzie przez RPC. W GPUI cała logika jest w tym samym kodzie Rust — funkcję wołasz wprost.

Jak stosować: traktuj GPUI wyłącznie jako warstwę UI nakładaną na istniejącą aplikację w Ruście. Architekturę reszty wybierasz sam.

Na co uważać: to nie jest framework „pełnego stosu” i nie narzuci ci struktury — w większym projekcie musisz sam zadbać o porządek w kodzie.

8.render_once do statyki, render do stanu

Na czym polega: obok zwykłego render jest render_once — dla elementów statycznych, jak odznaki, które nie potrzebują aktualizacji. Duchowy krewny memoizacji i makr Babela, które wyliczały wynik w czasie builda.

Jak stosować: oznaczaj niezmienne fragmenty render_once, żeby nie przerysowywać ich bez potrzeby.

Na co uważać: to wybór semantyczny, a nie optymalizacja raz na zawsze — element nadal można przerysować ręcznie.

9.Testuj przez drzewo dostępności, nie przez DOM

Na czym polega: GPUI nie ma DOM, więc automatyczne testy i agenty muszą korzystać ze sterowania komputerem, a nie przeglądarką. Ratunkiem jest pełne drzewo dostępności, które GPUI udostępnia.

Jak stosować: można spiąć agenta AI z drzewem dostępności tak, żeby klikał i sprawdzał aplikację bez zrzutów ekranu — Scott ma wczesny, ale działający projekt testowy oparty na Jevie.

Na co uważać: wymaga to małej łatki do samego GPUI i jest bardzo młodym rozwiązaniem — licz na zgrzyty przy aktualizacjach wersji.

10.Kod GPUI świetnie piszą agenty AI

Na czym polega: łańcuchy metod bywają rozwlekłe („Tailwind na sterydach”, jak mówi Scott), ale w praktyce ten kod często generują agenty — i robią to dobrze.

Jak stosować: jeśli i tak tworzysz oprogramowanie w trybie vibe codingu, rozwlekłość przestaje boleć. Dołącz skill z dobrymi praktykami Rusta, żeby jakość generowanego kodu była stabilna.

Na co uważać: ekosystem jest młody, więc materiałów do nauki jest mało — agent może zmyślić nieistniejące API. Weryfikuj wyniki przy dokumentacji.

Redakcyjne tłumaczenie

Żegnam Electrona, żegnam Tauri

Scott: Do widzenia, Electron. Do widzenia, Tauri. Do widzenia, aplikacjom desktopowym na osadzonych przeglądarkach. Jestem webowcem — kocham weba — ale aplikacje desktopowe buduję w Ruście i nie oglądam się za siebie. W tym odcinku opowiemy o GPUI: czym, u licha, jest, jak może stać się przepisem na wymarzony proces tworzenia aplikacji desktopowych i jak bardzo przypomina Reacta. Zobaczymy kod, omówimy biblioteki, pokażę kilka rzeczy, które zbudowałem. Jeśli nie znasz GPUI albo brzmi to intrygująco — ten odcinek jest dla ciebie. Wchodzimy głęboko, bo to jest po prostu świetne.

Nazywam się Scott Tolinski, jestem deweloperem z Denver, a ze mną, jak zawsze, Wes Bos. Co tam, Wes?

Wes: Bardzo mnie ciekawi, co powiesz, bo przez pewien czas byłeś panem Tauri i wiem, że zagłębiasz się w różne rzeczy. To dzieło ludzi z Zeda — to trzeba zaznaczyć — ale wytłumaczy Scott, on zna temat znacznie lepiej. (Informacja dodatkowa: Zed — edytor kodu napisany w Ruście; GPUI powstał właśnie na jego potrzeby.) I tak naprawdę chcę wiedzieć, czy Scottowi to się spodoba, czy to kolejny zachwyt, który przeminie — z Tauri też byłeś podekscytowany, a potem stwierdziłeś: „wiesz co, może jednak nie”.

Scott: Pozwólmy ludziom się zachwycać. Ja się zachwycam.

Wes: I bardzo dobrze, bo tak powstają dobre rzeczy. Wchodzisz głęboko, sprawdzasz, gdzie są granice — i świat staje się lepszy.

Dlaczego Electron i Tauri przestały wystarczać

Scott: Rozwińmy to. Electron używa web view — dokładniej: instancji Chrome’a — a cała reszta dzieje się w TypeScripcie i Node jako „serwerowa” strona aplikacji desktopowej. Argument sprzedażowy Tauri brzmiał: Rust na backendzie, a korzyści płyną z tego, że interfejs działa w systemowym komponencie przeglądarki. Dziś Tauri pozwala wybrać dowolny web view, nawet Chrome’a. Ale systemowy komponent przeglądarki wydawał się głównym atutem: nie trzeba dostarczać przeglądarki razem z każdą aplikacją. Bo na tym Electron tyje — każda aplikacja dźwaga z sobą instancję Chromium, a Chromium potrafi sporo kosztować.

Widzieliśmy zresztą aplikacje, które używają Electrona wzorowo — VS Code. Gdy VS Code działa wolno, zwykle winna jest wtyczka trzeciej strony, nie sam edytor. Więc Electron może działać i może być szybki. Jednak w swoich poszukiwaniach przekonałem się, że systemowy web view nie wystarcza. Zwłaszcza na macOS: zestaw funkcji WebKita dla aplikacji desktopowych jest po prostu słaby.

Wes: WKWebView.

Scott: WKWebView, dokładnie. Ubogi, niedobry dla aplikacji desktopowych i — co gorsza — nieprzewidywalny pod względem tego, kto ma jakie funkcje, bo nie dostarczasz konkretnej wersji. Z Electronem shippingujesz taką wersję Chrome’a, jaką wybierzesz, i masz pewność, że funkcje będą u każdego użytkownika.

Wes: Zresztą większość twórców aplikacji electronowych i tak włącza różne funkcje eksperymentalne albo modyfikuje Chromium, żeby uzyskać to, czego potrzebują — bo przeglądarka ma swoje ograniczenia. Przykład: możliwość renderowania HTML w elemencie canvas. Wielka sprawa — dzięki niej Remotion, edytor wideo w JavaScripcie, może wyrenderować ci gotowy film. Na systemowym web view by się to nie udało, bo tam rządziłby Safari.

Scott: Właśnie, trzeba włączyć HTML in canvas. I tu wchodzi GPUI.

Czym jest GPUI (i dlaczego to nie jest sponsorowany odcinek)

Scott: Wes, przy okazji — czysty przypadek: mam dziś na sobie bluzę Zeda. Nie zrobiłem tego specjalnie, choć wygląda, jakbym był sponsorowany. Nie jesteśmy. Nie dostaliśmy od nich ani złotówki. Bluzę dostałem tylko dlatego, że nagraliśmy odcinek o Zedzie i im się spodobał.

Wes: Zresztą coraz częściej po publikacji filmu ktoś pisze: „dostaliście kasę, żeby mówić o Stylex” — open-source’owej bibliotece CSS od Mety. Serio? Po co ktoś miałby nam za to płacić? Choć wiecie co — brawo dla podejrzliwych, bo dostaję mnóstwo wiadomości od ludzi planujących premierę jakiegoś słabego projektu AI. Niedawno ktoś oferował 1500 dolarów za samo podcitowanie posta premierowego. Nie zrobię tego, bo przetestowałem produkt — jest fatalny. Ale są tacy, co by wzięli nowego MacBooka za dwa takie tweety. Miejcie nadzieję, że nasza uczciwość jest dla was warta odrobinę więcej. Nie chcemy, żebyście przestali oglądać, bo komuś sprzedajemy duszę — z jednym wyjątkiem: Sentry. sentry.io/syntax, instalujcie w swoich aplikacjach.

Scott: I to istotne: nie przyjmujemy pieniędzy za mówienie o bibliotekach czy narzędziach. Jedyny nasz związek to Sentry. Bluzę dostałem, ale nie za to mówię o Rust i GPUI.

Sama istota: GPUI to framework interfejsu akcelerowany na GPU. Wieloplatformowy — działa na macOS, Linuksie i Windowsie, a nawet w webie i na mobile, choć o tym za chwilę, bo niekoniecznie jest to coś, co bym robił. Można na to patrzeć jak na alternatywę dla web view: nie używałbyś go razem z Electronem, tylko zamiast Electrona. Dlaczego? Bo jest szybki — natywny od renderowania w Ruście aż po GPU.

Nowa implementacja UI, a nie konwerter na natywne kontrolki

Wes: Żeby każdy wiedział, gdzie to umieścić na swojej mapie: to nie jest coś, co konwertuje kod na natywne komponenty. Nie jest tak, że piszesz GPUI-owe pole tekstowe, a ono zamienia się w odpowiednik ze Swif­ta. Oni dosłownie napisali całość od zera: zaczynasz od pustego kwadratu i budujesz dalej. Sam implementujesz zawijanie tekstu, ramki, cienie — wszystko, bo wymyślili zupełnie nowy sposób robienia interfejsów.

Scott: Dokładnie. I — ośmielę się powiedzieć — wygląda to bardzo „reactowo”, co ucieszy webowych deweloperów. Istotna różnica wobec zwykłego programowania natywnego: tam bierzesz domyślne komponenty systemowe i je przerabiasz, stylujesz; tu używasz GPUI-owej wersji wszystkiego.

Kod, który wygląda jak React

Scott: Jak to działa? Jest funkcja render, podobnie jak w Reakcie, a wszystko robi się metodami i funkcjami. Deklaratywnie jak w React — ale bez JSX-owego zapisu komponentów. Masz na przykład funkcję div z metodą flex dla flexboxa i flex_col dla kolumny. Style wychodzą bardzo „tailwindowe”: w praktyce ustawiasz je inline na poszczególnych divach. I shorthandy w duchu Tailwinda — pomocniki typu text_xl, text_color. I wiesz co, Wes? Kolor tekstu nazywa się text_color, a nie po prostu color. Zawsze mnie to w CSS-ie irytowało.

Wes: No tak, ale color przecież zmienia też kolor ramek i kilku innych rzeczy… ale nieważne, powinno być text_color. Masz rację.

Scott: Przy nauce CSS-a to zawsze było dziwne. Jest też koncepcja dzieci — powtarzam: komponenty, propsy, stan, wszystko znajome z Reacta. Zrobiłem małą aplikację: komponent definiuje się strukturą z propsami, bardzo podobnie do typowanych propsów w Reakcie z Typescriptem. W funkcji render masz divy i przekazujesz propsy do kolejnych komponentów. Render licznika: przycisk z on_click, nasłuch zdarzeń, inkrementacja. To wszystko powinno być znajome. Wielka różnica — a różnic jest sporo — polega na tym, że po zmianie stanu trzeba wywołać notify().

Wes: To jak kontekst z Remixa! Tam też sam wołasz aktualizację: „porobiłem rzeczy, zmutowałem zmienne, teraz chcę przerysować ten konkretny fragment”. Robisz to jawnie. To jest właśnie notify()?

Scott: Dokładnie, Wes. Wstawiłem to z nadzieją, że to powiesz — i się złapałeś. A tak w ogóle: jeśli nie pisałeś w Rust, część tego będzie wyglądać obco i intensywnie. Ale jeśli zna się Rust i Reacta, myśli się: „aha, łapię”. Rustowe smaczki nie zaskoczą, a reactowe koncepty będą się wyraźnie rzucać w oczy.

Scott: Przy okazji, dla ludzi z świata Reacta i HTML-a, którzy sklejają wszystko łańcuchami metod: to jest Tailwindowa proliferacja klas na koksie.

Wes: Powiedzmy: na sterydach.

Scott: Bo to jedna metoda na wiersz, chainowanie prawie jak w jQuery. Więc pliki robią się długie. Dla mnie to drugorzędny problem, bo ten kod często piszą agenty — i radzą sobie z nim dobrze.

Ile CSS-a udaje się odtworzyć

Wes: Przerobili większość tego, czego oczekujemy od CSS? Widziałem flex, padding, ramki, kolor tekstu, focus. Zrobili po prostu wszystko, co potrzebne?

Scott: Na razie robiłem wszystko, czego chciałem: cienie, przezroczystości, tekstury, tła, powtarzające się wzory. Na pewno kiedyś wpadnę na krawędź, przy bardziej szalonych pomysłach. Animacje są — w dokumentacji jest przykład obracającego się SVG, są też animacje spring. Moim zdaniem, pod kątem tego, co chcę osiągać w CSS, zestaw jest bardzo kompletny. Czy wszystko z CSS? Nie wyobrażam sobie.

Wes: A flexbox i grid? Bo to jest właśnie rzecz w React Native — nie ma tam CSS grid i wszystko robi się we flexboxie.

Scott: Gdzie jest grid… szukam w dokumentacji… Wiesz co, potrzebowałbym wielkiej dokumentacji referencyjnej, a tu są głównie przykłady. Ja wszystko robiłem we flexie.

Wes: Ja też wszędzie widzę flex, grid nie widzę. To jakieś ograniczenie. Ale przed erą CSS grid wszystko robiliśmy we flexie — i jakoś dawało się żyć. Da radę zbudować sporo, choć przy czymś w rodzaju subgridu człowiek powie „no, trochę kuleje”. Z drugiej strony jesteś w kodzie Rust — możesz dużo rzeczy policzyć programowo, mierzyć wymiary i tak dalej. A właściwie… da się implementować własne rzeczy? Chcesz sobie zrobić ozdobną ramkę?

Scott: Wes, wiedziałem, że zadasz mi pytania, na których mnie złapiesz. Aplikacje, które zbudowałem — zaraz je pokażę — są bardzo „waniliowe” w wyglądzie. Stylowałem je do pewnego stopnia, ale ozdobnych ramek nie próbowałem.

Logika bez pośredników

Wes: Dobra, kolejne pytanie. To obsługuje layout, style, zdarzenia — widzieliśmy klikanie — i obsługuje stan. Ale w którym miejscu kończy się UI? Jest jakiś backend, czy cała logika siedzi razem? Np. chcesz przetworzyć wideo, gdy ktoś kliknie. W świecie Electrona wywołujesz funkcję, która mieszka na backendzie — jakiś RPC, dispatch, backend odpala zadanie. Jak to wygląda w GPUI?

Scott: Wygląda tak, że nie musisz nic nigdzie wysyłać, bo wszystko jest już w kodzie Rust. Chcesz wywołać funkcję, która coś robi — jesteś na miejscu.

Wes: Czyli eliminujesz całą warstwę RPC.

Scott: Tak. A poza tym GPUI to tylko warstwa UI — jak z niej skorzystasz, to twoja sprawa. Nakładasz ją na istniejącą aplikację w Ruście i sam wybierasz architekturę. Electron w tym sensie jest bardziej narzucający.

render i render_once

Scott: Coś, co uznałem za ciekawe, Wes: są dwa rodzaje renderu. Zwykły render oraz render_once — ten drugi nadaje się do rzeczy statycznych, jak odznaki, które nie potrzebują aktualizacji. Czy w Reakcie nie było czegoś takiego… PureComponent? Albo memoizacja?

Wes: Zmemoizowany komponent też przecież można przerysować… A, było coś w Babelu — prekomputowanie w czasie builda. Babel macros, tak się to nazywało. Zero logiki, w buildzie wyliczasz, jaki HTML ma zostać wyrenderowany.

Scott: Tak dawno temu, że zapomniałem. A obok jest zwykły render: komponent ma stan, stan się zmienia, notify() prosi o update — działa jak Remix czy React, jak można się spodziewać. Więc jeśli patrzysz na to i myślisz: „super, teraz będę musiał przerabiać każdą rzecz z Reacta od zera” — spokojnie.

GPUI Kit — komponenty w duchu shadcn

Scott: Jest bowiem coś takiego jak GPUI Kit i to dla mnie najlepsza rzecz w tym całym świecie. To biblioteka komponentów: akordeony, alerty, dialogi, dymki, odznaki, karuzele… wszystko, czego można potrzebować. Czuć to jak „shadcn dla GPUI”. Używam jej z powodzeniem w każdym projekcie na GPUI — jako bazy do stylowania, bo daje prymitywy naprawdę przyjemne i rozszerzalne. Niezaprojektowane na siłę, a wystarczająco dopracowane, żeby wyglądały dobrze. Inputy, paginacja, popover, combobox, command — wszystkie klocki, których oczekujesz w aplikacji.

Co zabawne, Wes, te komponenty wyglądają bardzo podobnie do mojego Graffity UI — czyli mam mnóstwo pomysłów na stylowanie. Posadzę dziś agenta i przeniosę wszystko.

Wes: Słusznie. A jedna rzecz, którą pokochałem: data table z wirtualizacją od razu w zestawie. Sortowanie, tabele — po prostu działają i są wygodne. Zanim poznałem GPUI Kit, myślałem: „no dobra, teraz będę budował każdy komponent sam”. To jest właśnie największe odblokowanie, bo tego jest mnóstwo i wszystko jest naprawdę dobre. Jak czegoś potrzebuję — mam pod ręką.

Wtrącenie: fork GPUI CE i pęknięta społeczność

Scott: Przy okazji wspomnę o czymś, czego nie omawiamy w tym odcinku: GPUI CE, czyli edycja społecznościowa. Społeczność wokół GPUI jest w tej chwili nieco rozbita, bo część ludzi uważa, że zespół Zeda dodaje do frameworka wyłącznie to, co przydaje się jemu samemu. Istnieje więc fork zbierający dodatkowe zmiany. Jak podaje użytkownik Cameron Campbell, CE ma fajne funkcje, których nie ma GPUI: deklaratywne przejścia stylów, wygładzanie narożników (tzw. squircle’e), rozmycia, rozmycie tła, gradienty na cieniach i ramkach. Brzmi świetnie. Podkreślę jednak, że opiekun GPUI Kit nie zamierza wspierać CE — nawet flagą — bo GPUI Kit przypina konkretną wersję GPUI. Cytując jego słowa: „Nigdy nie byłem optymistą co do tych projektów. Tworzą problemy, zamiast je rozwiązywać. Nie warto na nich tracić czasu. Tylko projekty zweryfikowane przez rzeczywiste aplikacje wytworzą trwały popyt i będą napędzać rozwój frameworka. GPUI ma Zeda, GPUI Component ma Longbridge. Te frameworki nie wzięły się z powietrza — powstały z potrzeb realnych projektów, dlatego odniosły sukces. Tak jak wtedy, gdy wybrałem GPUI, pociąga mnie sposób pracy zespołu Zeda i jego filozofia projektowa. Na razie GPUI rozwija się wolniej przez potrzeby Zeda, ale ciągle się poprawia.” Czy te argumenty są przekonujące — ludzie się spierają. To rozmowa, której tu nie prowadzimy, bo ja trzymam się GPUI wraz z GPUI Kit. Chciałem tylko uporządkować sytuację dla zainteresowanych.

Aplikacje, które zbudowałem: Gendo

Scott: Pokażę kilka swoich aplikacji. Jedna nazywa się Gendo i pokazuje każdy projekt na moim Macu i MacBooku Pro. Szkoda tylko, że nie mogę tu powiększyć czcionki. Na przykład battle mode — aplikacja z naszego turnieju CSS. Okazuje się, że mam jej trzy kopie: dwie na MacBooku Pro i jedną na Macu mini. W aplikacji widzę status każdej z nich, mogę je przenosić między maszynami, uruchamiać, otwierać. Buduję to dla siebie, bo mam kilka komputerów pędzących po kilka procesów deweloperskich i coraz trudniej śledzić wersje: która jest aktualna, co gdzie leży. Chcę z tego zrobić system — łącznie z zarządzaniem domenami Caddy. Aplikacja łączy się z każdym komputerem w sieci. Po prostu małe osobiste oprogramowanie.

Małe narzędzia to sens tego frameworku

Wes: Mam pytanie, bo ludzie na pewno zapytają: po co właściwie? Odpowiedź o Chrome jako żarłoku już padła, te aplikacje są duże…

Scott: To jest idealne środowisko dla malutkich narzędzi, gdy nie chcesz zmuszać nikogo do pobierania gigantycznej instancji. Właśnie zaktualizowałem DaisyDisk — moją aplikację do skanowania dysku, bo wiecznie kończy mi się miejsce i muszę wiedzieć, gdzie ono ucieka. DaisyDisk zaktualizował się o osiem megabajtów. Osiem! Kiedy ostatnio pobrałeś aplikację ważącą osiem megabajtów? To jest malutkie.

Wes: A gdzieś tam pewnie istnieje electronowa wersja DaisyDiska ważąca 267 megów — i przy każdej aktualizacji ta masa siada na dysku. Nie mówiąc o RAM-ie i zasobach, które takie cuda pochłaniają w tle.

Scott: W pełni się zgadzam. Chcę, żeby mała aplikacja desktopowa była smukła, lekka i szybka. Nie chcę, żeby przy każdym błysku pomysłu w tle pracowała osobna instancja Chromium. GPUI pozwala w kilka chwil przejść od „musiałbym tak mieć” do „nie muszę” — a efekt i tak wygląda dobrze i działa żwawo. Przerabiam właśnie swój rejestrator wideo, żeby był jak najchudszy — przeniesienie go na GPUI będzie strzałem w dziesiątkę.

File Bro — automatyzacje plików

Scott: Kolejna rzecz: File Bro — automatyzacje plików à la Hazel. (Informacja dodatkowa: Hazel — aplikacja na macOS, która według reguł automatycznie porządkuje i przenosi pliki.) Zasada typu: „jeśli zrzut ekranu ma taką nazwę, przenieś go tam”. Będę używał Jeva — no, już używam, ale będę jeszcze intensywniej — do ustawiania automatyzacji. (Informacja dodatkowa: Jev — agent AI, którym Scott steruje komputerem.) Znów: coś, co ma działać, ale ma być ładne i szybkie. Sprawdzanie duplikatów plików, scalanie plików — to akurat dane testowe. I uwaga: File Bro był pierwotnie na Electronie. Teraz całe sprawdzanie duplikatów i głęboka analiza plików robią się bezpośrednio w Ruście, w samej aplikacji. Bardzo mi to leży. Idealny przypadek użycia: małe, osobiste narzędzie.

Pan Space — okna i Spacesy

Scott: Buduję też bibliotekę do zarządzania oknami, bo robię po prostu za dużo rzeczy. Pan Space. Gdy wyszedł AeroSpace — świetny menedżer okien, który blokuje wszystko w siatkę — automatyczne przypinanie okien okazało mi się w codziennym użyciu dość irytujące. Chciałem czegoś w stylu: „skrót — przypnij do lewej, przypnij do prawej”. Raycast robi to bardzo dobrze, ale chciałem też wysyłać okna do różnych Spacesów: mam okno, wysyłam je na pulpit numer dwa albo trzeci, albo automatycznie dopasowuję wszystkie okna tak, żeby zmieściły się na ekranie naraz. W Raycaście nie zbuduję tego po swojemu ani nie wygeneruję własnych layoutów. Więc napisałem własną aplikację — na natywnych Spacesach macOS. Mogę wysłać okno na inny pulpit. Cały zgrabne. Co ciekawe, agenty też mogą tego używać: mogę polecić agentowi przeniesienie okna, a on wie, jak to zrobić. I jeszcze jedno, Wes: w tej aplikacji GPUI służy mi wyłącznie jako menu ustawień. Ta część nie musi być otwarta, żeby aplikacja działała. Czyli GPUI nadaje się i na całe programy, i na ładne menu ustawień.

Wes: O!

Scott: No, fajne.

Wady: wygląd, DOM, młodość ekosystemu

Wes: A wady? Jedną właśnie pokazałeś — nie mogłeś powiększyć czcionki. W przeglądarce dostajesz to za darmo; tu trzeba samemu podpiąć skalowanie. Pewnie się da, ale trzeba to spiąć. Coś jeszcze?

Scott: Największa wada: nienatywne elementy interfejsu. Jeśli chcesz, żeby aplikacja wyglądała „na sto procent macowsko” z Liquid Glass, a na Windows — windowsowo, to nie jest framework dla ciebie, bo Liquid Glass musiałbyś reimplementować na GPU. (Informacja dodatkowa: Liquid Glass — najnowszy język projektowy Apple, oparty na szklistych, półprzezroczystych efektach.) Dla jednych to wada, dla drugich zaleta — może właśnie chcesz pełnej kontroli nad wyglądem. Ten motyw, który mam, jest właściwie w twoim stylu.

Wes: Trochę wygląda jak Cobalt2.

Scott: Ja osobiście chcę kontroli — niekoniecznie chcę aplikacji z wykrojnika „standardowy Mac”. Ale tak czy owak: nie używasz natywnych elementów UI. Po drugie: nie ma DOM. Choć istnieje projekt uruchamiający aplikacje GPUI w webie, robi to przez WASM — wątpię, żeby używał prawdziwego DOM; bez warstwy translacji nie wydaje mi się to możliwe. GPUI po prostu renderuje przez WebAssembly. Z drugiej strony, Wes — w tych aplikacjach jest pełne drzewo dostępności. Korzystam z niego w rzeczy, którą zbudowałem z Jevem. Po trzecie: to młody świat. GPUI Kit to najlepsza z kilku bibliotek komponentów, ale wciąż wcześnie — mniej zasobów, mniej materiałów. Za to AI pisze ten kod całkiem nieźle; używam skilla z dobrymi praktykami Rusta, żeby mój model robił to porządnie — podlinkuję. I wreszcie: to nie jest platforma „napisz raz, wdrażaj wszędzie”. Nie wyciśniesz z tego naraz natywnej aplikacji w stylu React Native, aplikacji webowej i desktopowej — jesteś dość mocno przywiązany do jednego toru. Ja używam tego głównie do natywnych aplikacji desktopowych.

Testowanie przez drzewo dostępności

Scott: I w tej samej konwencji co brak DOM: jeśli chcesz, żeby AI testowało twoje aplikacje, patrzysz na computer use, a nie na sterowanie przeglądarką. Stworzyłem jednak projekt testów GPUI sterowany Jevem. Wymaga małej łatki do GPUI i odrobiny w Twoim harnesie, ale korzysta z Jeva i drzewa dostępności, żeby klikać i sprawdzać aplikację — bez zrzutów ekranu. Podlinkuję. Bardzo wczesne, ale u mnie działa. Mały projekt.

Mobile i web

Scott: Wspominałem o mobile: istnieje GPUI Mobile. Wygląda na to, że działa — ale jest eksperymentalne. Na iOS renderujesz wszystko przez Metal z użyciem WGPU. To nie jest warstwa konwersji jak w React Native, ale ludziom to działa; są dokumentacja i przykłady. Nie dostajesz całego natywnego dobra iOS, ale działa.

Wes: Domyślam się, że trzeba zbudować mnóstwo mostków — jak w React Native, gdy chcesz cokolwiek natywnego: mapy, NFC, choćby systemowy wybór plików. To ostatnie doprowadza mnie do szału w nienatywnych aplikacjach: otwierasz okno wyboru pliku, a tam goła lista wszystkich folderów. Ani moich skrótów, ani ulubionych — nie da się znaleźć tego, czego szukasz. Jest w tym trade-off, ale mostki do natywnego Swifta na pewno da się napisać.

Scott: Da się. Czy użyłbym tego do natywnej aplikacji mobilnej? Nie. Do aplikacji webowej? Nie. Ale używam tego bez przerwy do osobistego oprogramowania i aplikacji desktopowych — do rzeczy, na które nie chcę trzymać na komputerze kolejnego electronowego kolosa za kilkaset megabajtów. Myślę, że wielu ludzi rozpozna w tym fajny przypadek użycia. A jeszcze jedno: agenty są dobre w Rust — przynajmniej w moim doświadczeniu naprawdę dobrze sobie radzą. Jeśli więc piszesz osobiste narzędzia desktopowe w trybie vibe codingu (Informacja dodatkowa: vibe coding — tworzenie oprogramowania głównie przez polecanie agentowi AI, bez wchodzenia w szczegóły implementacji) — mówiąc do mnie: GPUI jest drogą.

Wes: Pięknie. Dzięki za pouczenie widowni. Dajcie znać w komentarzach, czy chcecie używać GPUI, czy planujecie — i co o nim myślicie. Chętnie przeczytamy. Cześć!

Scott: Cześć!