Z Framera do Astro: decyzja build vs buy za tą stroną

Większość historii o przebudowach jest zbyt czysta.

Stare narzędzie wygląda na naiwne, nowy stos na nieunikniony, a migracja na prostą linię od “ograniczeń no-code” do “porządnej inżynierii”. Tutaj tak nie było.

Nie przeniosłem tej strony z Framera do Astro, bo Framer był zły. Framer robił to, czego wtedy potrzebowałem: dawał szybkość wizualną. Przeniosłem się, bo zmieniła się rola strony.

Strona przestała być zestawem dopracowanych podstron i stała się małą powierzchnią operacyjną: pozycjonowanie publiczne, proof, aplikacje, pisanie, warianty językowe, redirecty, weryfikacja deployów i workflow, w którym agenci AI mogą wprowadzać zmiany bez zgadywania w wizualnym edytorze.

To zupełnie inna decyzja build vs buy.

3

Języki

Angielski, Polski, Włoski

1

Źródło contentu na stronę

Współdzielone komponenty Astro

MDX

System artykułów

Komponenty wewnątrz długiego tekstu

Decyzja nie dotyczyła kosztów

Leniwa ramka build vs buy to cena.

“Framer kosztuje. Astro jest darmowe. Więc Astro wygrywa.”

To słaby argument. Codebase nigdy nie jest darmowy. Wymaga utrzymania, lokalnego setupu, failujących buildów, aktualizacji zależności, decyzji routingowych i oceny sytuacji. Wizualny builder pobiera subskrypcję, ale usuwa też sporą część powierzchni operacyjnej.

Prawdziwe pytanie brzmiało:

Co muszę kontrolować, a co mogę bezpiecznie wynajmować?

Dla pierwszej wersji strony wynajmowanie warstwy wizualnej miało sens. Wąskim gardłem nie był routing ani architektura artykułów. Wąskim gardłem było szybkie postawienie ostrej publicznej powierzchni.

Dla obecnej wersji wąskie gardło się zmieniło. Potrzebowałem wersjonowanego contentu, MDX, reużywalnych komponentów artykułów, prawdziwych URL-i językowych, przewidywalnych redirectów i repo, które Claude Code i Codex mogą przejrzeć, patchować, zbudować i zweryfikować.

W tym momencie builder nie był już tylko builderem. Był płaszczyzną kontroli.

A ja chciałem mieć płaszczyznę kontroli w kodzie.

Co dał mi Framer

Framer dał szybkość kompozycji.

Jest dobry w tym, do czego został zaprojektowany: pozwala jednej osobie sprawić, żeby strona wyglądała na skończoną bez budowania design systemu od podstaw. Dla osobistej strony to realna wartość. Większość osobistych stron nie potrzebuje frameworka. Potrzebują gustu, skupienia i deadline’u.

Problem pojawia się, gdy strona zaczyna gromadzić wymagania operacyjne:

• długie teksty techniczne;
• ustrukturyzowany indeks artykułów;
• RSS i zachowanie sitemapy;
• kanoniczne URL-e i redirecty;
• ścieżki językowe, które można udostępniać i indeksować;
• code-reviewed zmiany;
• reużywalne komponenty proof;
• deploy preview;
• weryfikacja produkcji;
• utrzymanie wspomagane AI.

Żadna z tych rzeczy nie sprawia, że wizualny builder jest “zły”. Po prostu przesuwają środek ciężkości z wizualnej kompozycji w stronę projektowania systemu.

Kupuj builder

słuszne wcześniej

• Szybka wizualna iteracja
• Niski koszt wejścia
• Mniej infrastruktury do utrzymania
• Dobre dla małej liczby dopracowanych stron
• Najlepsze, gdy edycja nietechniczna jest głównym ograniczeniem

Buduj system

słuszne teraz

• Wersjonowany content i komponenty
• Prawdziwy routing i redirecty
• Artykuły MDX z własnymi prymitywami
• Weryfikacja buildu i deployu
• Lepsza powierzchnia dla agentów AI i code review

Co zmienił Astro

Astro pasowało, bo strona jest w większości statyczna, ale nie prymitywna.

Nie potrzebuję pełnego frameworka aplikacyjnego do publicznego portfolio i systemu pisania. Potrzebuję solidnego routingu plikowego, komponentów, kolekcji contentu, MDX i outputu, który Cloudflare Pages może serwować tanio i niezawodnie.

Astro daje mi ten kształt bez zmuszania strony do bycia aplikacją po stronie klienta.

Pozycjonowanie strona główna, o mnie, projekty

System contentu MDX, RSS, sitemap

Warstwa deployu GitHub, Cloudflare Pages

Workflow agentów patch, build, verify

Ważne nie jest to, że Astro jest modne. Ważne jest to, że Astro uczyniło stronę czytelną.

Routy żyją w src/pages. Współdzielony content stron żyje w src/components/pages. Artykuły żyją w src/content/insights. Design tokeny żyją w CSS. Build albo przechodzi, albo nie.

To jest typ struktury, wewnątrz której agent potrafi pracować.

MDX to miejsce, gdzie strona kumuluje wartość

Zwykły Markdown wystarczyłby do prostych postów. Nie wystarczył do tego typu pisania, które chcę, żeby ta strona dźwigała.

Artykuły to nie tylko eseje. Często potrzebują:

• diagramów;
• porównań;
• calloutów;
• statystyk;
• przepływów procesów;
• screenshotów;
• sekcji tak/nie;
• kart proof;
• bloków CTA.

Jeśli każdy artykuł ręcznie buduje ten markup, strona staje się cmentarzem jednorazowego HTML. Jeśli komponenty są dostępne wewnątrz MDX, system artykułów staje się małym produktem wydawniczym.

To jest dźwignia.

Praktyczny rezultat jest prosty: mogę napisać artykuł o systemie i wstawić te same prymitywy, których używam do wyjaśniania produktów i workflow gdzie indziej.

Decyzja i18n: celowo nudna

Strona jest teraz w angielskim, polskim i włoskim. Implementacja i18n nie jest piękną platformą internacjonalizacji. To praktyczny system na obecną skalę.

Są dwa wzorce:

1. Strona główna używa typowanego słownika w src/i18n/translations.ts.
2. Główne strony używają współdzielonych komponentów Astro z atrybutami data-en, data-pl i data-it, przełączanych małym skryptem na podstawie URL.

Każda zlokalizowana strona ma prawdziwy route: /pl/about/, /it/apps/ i tak dalej. Angielskie strony bazowe pozostają kanoniczne.

Kluczowa decyzja: język oparty na URL, nie na localStorage. Udostępniony link powinien nieść ze sobą język. Wyszukiwarki powinny widzieć warianty językowe jako prawdziwe strony. Użytkownicy nie powinni zależeć od tego, jaki stan akurat trzyma ich przeglądarka.

Do

• Używaj prawdziwych URL-i językowych dla stron, które ludzie udostępniają
• Trzymaj copy strony w jednym współdzielonym komponencie Astro
• Akceptuj odrobinę szumu w markupie, gdy pozwala to uniknąć większego frameworka
• Nazwij punkt, w którym wzorzec przestaje się skalować

Don't

• Duplikuj strony root i lokalizowane ręcznie
• Dodawaj i18next, bo architektura chce wyglądać na dojrzałą
• Ukrywaj stan języka w localStorage i udawaj, że linki są przenośne
• Tłumacz insights zanim pojawi się prawdziwy powód wydawniczy

Czy podejście oparte na atrybutach jest eleganckie? Niespecjalnie.

Czy jest poprawne dla mniej więcej kilkunastu publicznych stron z trzema wariantami językowymi i jednym właścicielem? Tak.

To jest ta część, którą ludzie pomijają w dyskusjach o architekturze. Prostszy system ze znaną krawędzią jest często lepszy niż bardziej formalny system, który dodaje proces zanim ten proces istnieje.

Dług, który zaakceptowałem

W tej przebudowie jest dług. Zaakceptowałem go świadomie.

Warstwa i18n ma dwa wzorce. Copy strony głównej żyje w typowanym słowniku. Copy stron żyje we współdzielonych komponentach z atrybutami data-*. Insights są tylko po angielsku. Mapa komponentów MDX jest manualna. Nie ma CMS-a. Edycja nietechniczna oznacza otwarcie repo.

To jest dług.

Ale dług nie jest automatycznie problemem. Problemem jest nienazwany dług. Dług, którego nikt nie widzi, nikt nie wyceni i nikt nie wie, jak go rozwinąć.

Ten dług jest widoczny i ograniczony.

Obecna architektura jest uczciwa co do skali:

Jak AI zmieniło decyzję o budowie

Agenci AI zmienili rachunek, ale nie w leniwy sposób “AI zbudowało mi stronę”.

Użyteczna zmiana polega na tym, że kodem stało się łatwiej operować.

Claude Code potrafi zaimplementować większą partię, gdy kierunek jest udokumentowany. Codex potrafi przejrzeć repo, zrobić skupione patche, odpalić npm run build, sprawdzić output i zweryfikować produkcję. Oba narzędzia działają lepiej, gdy system to tekst, pliki, komponenty i testy.

Wizualny builder może być szybki dla człowieka. Codebase jest bardziej inspekcyjny dla agenta.

To miało tu znaczenie, bo strona nie miała się zamrozić po launchu. Powinna dalej wchłaniać artykuły, proof, komponenty, linki do aplikacji, edycje stron i weryfikacje deployów.

Ludzki osąd gust, zakres, akceptacja

Kontekst repo docs, komponenty, content

Patch agenta edycja, build, weryfikacja

Weryfikacja produkcji custom domain jest prawdą

Rola człowieka nie zniknęła. Stała się ważniejsza.

Gdy agenci produkują szybciej, słaby kierunek generuje więcej słabego outputu. Zadaniem jest utrzymywanie warstwy oceny w ryzach: co należy do strony, co wyciąć, co brzmi jak ja, co jest dowodem, a co jest tylko dekoracyjną strukturą.

Kiedy nie wybrałbym tego stosu

Nie wybrałbym tej architektury dla każdej strony.

Zostałbym we Framerze, Webflow lub innym builderze, gdy:

• głównym zadaniem są wizualne strony kampanijne;
• zespół edycyjny jest nietechniczny;
• strony muszą być komponowane szybko przez marketing bez repo;
• nie ma systemu publikacji długich tekstów technicznych;
• kontrola routów i historia źródła nie są istotne;
• strona lepiej korzysta z szybkości projektowania niż kontroli inżynieryjnej.

Wybrałbym cięższy framework lub CMS, gdy:

• jest wielu redaktorów;
• każdy artykuł wymaga wielu przetłumaczonych wersji;
• workflow contentu wymaga stanów recenzji i uprawnień;
• strony są generowane z dużych ustrukturyzowanych zbiorów danych;
• zachowanie uwierzytelnionego użytkownika staje się centralne;
• prędkość redakcyjna przerasta Git.

Astro jest dobrym środkiem dla tej strony, bo strona jest wystarczająco statyczna, żeby zostać prostą, i wystarczająco ustrukturyzowana, żeby potrzebować kodu.

Reguła operatora

Oto reguła, którą bym powtórzył:

Kupuj szybkość, gdy powierzchnia jest produktem. Buduj kontrolę, gdy system za powierzchnią jest produktem.

Framer kupił szybkość dla pierwszej wersji. Astro kupiło kontrolę dla obecnej wersji.

Przejście nie było odrzuceniem wizualnych builderów. Było uznaniem, że strona zmieniła pracę.

Publiczna strona jest teraz tylko widoczną warstwą. Pod nią siedzi właściwy system: MDX, komponenty, routy, i18n, weryfikacje deployów, dostęp crawlerów, weryfikacja produkcji i workflow, w którym agenci mogą wprowadzać zmiany bez psucia kształtu strony.

Ten system warto posiadać.

Dług wewnątrz niego też warto nazwać.

To jest uczciwa wersja migracji.

---

Powiązane: Jak przebudowałem portfolio z Astro i Cloudflare Pages · Migracja na Cloudflare: co dostajesz poza hostingiem · GTM Tools: Build vs Buy Decision Framework for Operators