Prosty stack na stronę WWW i wdrożenia z agentami AI [stan na 2026]

Web Development, ,
HTML i Pico CSS publikowane na CDN bez node_modules i kroku build

W skrócie: HTML + Pico CSS + Git + CDN.

Dla strony wizytówki często nie potrzeba Astro, Reacta, CMS-a, Node.js, bazy danych ani procesu budowania.

Jeżeli strona zawiera ofertę, kontakt, zdjęcia i kilka podstron, czysty HTML może być gotowym produktem.

HTML jako gotowy artefakt

index.html jest kodem źródłowym i plikiem dostarczanym użytkownikowi.

Zamiast: source → dependencies → framework → bundler → build → dist → deployment

mamy: HTML → CDN → użytkownik

To 0-build architecture.

Nie ma npm install, package.json, bundlera ani artefaktów powstających podczas builda. Commit może zawierać dokładnie te pliki, które trafiają na hosting.

Mniej kroków to mniej miejsc awarii.

Pico CSS: mniej klas, więcej HTML

Pico CSS pozwala oprzeć wygląd strony na semantycznym HTML.

Zamiast:

<div class="wrapper">
  <div class="container">
    <div class="content">
      <div class="hero">
        ...
      </div>
    </div>
  </div>
</div>

można pisać:

<header>
  <nav>...</nav>
</header>

<main>
  <article>
    <h1>Nasza oferta</h1>
    <p>...</p>
  </article>
</main>

<footer>
  <p>Kontakt</p>
</footer>

Pico Class-less idzie jeszcze dalej: podstawowe elementy HTML mogą być stylowane bez dokładania klas.

HTML opisuje strukturę i znaczenie. CSS odpowiada za wygląd.

Historia zatacza koło

Moje pierwsze strony około 20 lat temu były pisane bezpośrednio w HTML. Potem przyszły CSS, JavaScript, PHP, Python, CMS-y, frameworki i coraz większe toolchainy.

Rozwiązywały realne problemy, ale zwiększały liczbę warstw.

Agenci AI zmieniają ten kompromis.

Agent może szybko zmienić nawigację w kilku plikach, dodać podstronę, poprawić metadata, structured data czy linkowanie. Przy małej stronie nie zawsze potrzebujemy CMS-a lub systemu komponentów tylko po to, żeby ograniczyć ręczną pracę.

HTML → CSS → JS → backend → CMS → frameworki → AI → prosty HTML

Nie jest to powrót do ograniczeń dawnych stron. To świadome usunięcie warstw, których dany projekt nie potrzebuje.

0-build architecture

Brak procesu budowania daje kilka konkretnych korzyści:

  • brak zależności build-time,
  • brak aktualizacji bundlera,
  • brak problemów z wersją Node.js,
  • brak różnicy między kodem źródłowym a wynikiem builda,
  • prostszy CI/CD,
  • prostszy rollback,
  • łatwiejszy debugging,
  • mniejszy supply-chain attack surface.

Deployment może sprowadzać się do:

git push → upload/sync → CDN

Jeżeli hosting integruje się z repozytorium, może być jeszcze prostszy.

Mniej complexity pomaga niezawodności

Każda dodatkowa warstwa jest kolejnym elementem, który może zawieść.

Framework, runtime, dependency, bundler, plugin, baza danych i CMS mają własne wersje, konfigurację oraz cykl aktualizacji.

Usunięcie niepotrzebnych elementów nie gwarantuje SLA. Zmniejsza jednak liczbę zależności i potencjalnych punktów awarii.

Dla prostej strony statycznej łatwiej skupić się na tym, co rzeczywiście wpływa na dostępność:

  • DNS,
  • CDN/hosting,
  • cache,
  • poprawność plików,
  • monitoring dostępności.

Nie trzeba diagnozować bazy, backendu, runtime’u i procesu buildowania, jeżeli ich nie ma.

Najłatwiejszy komponent do utrzymania to komponent, którego nie potrzebujemy.

Dobry stack dla agentów AI

HTML i CSS są bezpośrednim wejściem dla agenta.

Mniej abstrakcji oznacza:

  • mniej plików do analizy,
  • mniej tokenów,
  • mniej zależności między plikami,
  • krótsze diffy,
  • łatwiejsze review,
  • mniejsze ryzyko zmiany niezwiązanej z zadaniem.

Agent może skupić się na rezultacie: treści, HTML, SEO, GEO, dostępności i wydajności.

Nie musi najpierw poznawać architektury frameworka.

SEO i GEO bez frameworka

Framework nie jest wymagany do kontroli nad:

  • <title>,
  • meta description,
  • canonical,
  • strukturą nagłówków,
  • linkowaniem wewnętrznym,
  • structured data,
  • robots.txt,
  • sitemap.xml,
  • semantycznym HTML.

Prosta struktura pomaga również agentom analizującym stronę. Treść nie jest ukryta za rozbudowanym drzewem komponentów.

JavaScript: domyślnie zero

Strona wizytówka często nie potrzebuje własnego JavaScriptu.

Tekst, oferta, zdjęcia, telefon, adres i nawigacja mogą działać bez niego.

Jeżeli konkretna funkcja wymaga JavaScriptu, dodajmy JavaScript dla tej funkcji.

Nie trzeba zmieniać całej strony w aplikację.

0 KB własnego JS jest lepsze niż 20 KB, jeżeli rezultat jest taki sam.

Minimalna struktura

/
├── index.html
├── oferta.html
├── kontakt.html
├── css/
│   └── pico.min.css
├── images/
├── robots.txt
└── sitemap.xml

To może być cała produkcyjna strona.

Bez runtime’u. Bez bazy. Bez CMS-a. Bez builda.

Kiedy przejść na Astro?

Prosty HTML przestaje być prosty, gdy zaczynamy ręcznie powielać dużą ilość kodu.

Astro warto rozważyć, gdy pojawiają się:

  • dziesiątki lub setki artykułów,
  • wspólne komponenty powtarzane na wielu stronach,
  • wiele layoutów,
  • generowanie stron z danych,
  • rozbudowana wielojęzyczność.

Framework powinien usuwać istniejącą złożoność, a nie dodawać ją na zapas.

Podsumowanie

Dla małej strony WWW punktem startowym może być:

HTML + Pico CSS + Git + CDN.

Dopiero konkretna potrzeba powinna uzasadniać kolejną technologię.

Mniej warstw oznacza mniej aktualizacji, mniej zależności, prostszy deployment i mniej potencjalnych punktów awarii.

Zaoszczędzony czas można przeznaczyć na rzeczy, które użytkownik faktycznie widzi: treść, ofertę, szybkość, dostępność, SEO i GEO.

Prostota nie jest ograniczeniem. W małym projekcie jest cechą architektury.

Dokumentacja