Niyə Astro üzərində qurduq və bu seçim nə açıqlayır

Bu sayt Astro 6 üzərində qurulub. Seçim iki həftəlik müzakirədən sonra qəbul olundu və hər mümkün alternativi açıq dəyərləndirdik. Bu yazı həmin müzakirənin yazılı versiyasıdır — eyni qərarı verməli olan başqaları üçün.

Real müqayisə üç qrup arasında idi

İnternetdə “ən yaxşı framework” siyahıları faydasızdır, çünki framework-lər bir-birinə alternativ olaraq mövcud deyil. Hər biri başqa problemə cavab verir. Bizim üçün üç qrup vardı:

İçərik-mərkəzli statik generatorlar — Astro, Hugo, Eleventy, modern Jekyll
SaaS-vari React framework-ləri — Next.js, Remix, TanStack Start
CMS platformaları — WordPress, Webflow, Framer

Hər qrupun fərqli güclü tərəfləri var. Səhv etməmək üçün əvvəl biz nə qururuq sualına cavab vermək lazım idi.

Saytın əsl xarakteri

Qaynaq.az nə lead capture hunidir, nə də işlədilən tətbiq. Bu sayt:

Editorial — case study və jurnal yazıları əsasdır
Statik — məzmun ayda bir-iki dəfə dəyişir
SEO-həssas — üç dilli, hreflang, JSON-LD, canonical
Şəffaf — kod oxunaqlı, audit edilə bilən, bahalı runtime asılılığı yoxdur
Performance büdcəli — landing JS < 80KB, LCP < 2.0s

Bu siyahıya baxanda Next.js və WordPress hər ikisi lazım olduğundan çoxdur. Webflow və Framer lazım olduğundan azdır, çünki MDX, custom rendering və üç dilli URL strukturu üzərində tam nəzarət istəyirik.

Niyə Next.js olmadı

Next.js gözəl framework-dur. Onu hər həftə başqa layihələrdə istifadə edirik. Lakin bu sayt üçün:

Server runtime lazım deyil. Bizim auditi və formaları Astro Actions və ya ayrıca edge funksiya həll edir. Bütün sayt üçün Node runtime saxlamağa ehtiyac yoxdur.
React komponent budgeti çoxdur. Astro adasaları (islands) ilə yalnız interaktiv olan kiçik fraqmentlərə React (və ya Svelte, Solid) yükləyirik. Qalan səhifə sıfır JS-dir.
Ekosistem güclülüyü zəif tərəfdir. Next.js üçün minlərlə şablon var. Şablonların əksəriyyəti generic SaaS landing-lərdir. Bu sayt üçün şablon istəmirəm — başlanğıc nöqtəsindən “kifayət qədər yaxşı” görünüş gəlsin istəmirəm.
Vendor şərtləri. Next.js getdikcə Vercel-in xüsusiyyətlərinə bağlanır. Sayt portativ qalmalıdır.

Texniki rəqəmlərlə demək lazım gələrsə (bunlar tipik göstəricilərdir, bənchmark deyil): bu saytın əksər səhifələri 15-25KB JS ilə açılır. Eyni saytı Next.js App Router ilə qursaydıq, RSC payload, hydration runtime və framework boilerplate-i nəzərə alanda 80-120KB-dan az ola bilməzdi.

Niyə WordPress olmadı

WordPress çoxlu layihə üçün doğru cavabdır. Bu sayt o layihələrdən deyil. Səbəblər:

Performance büdcəsinə uyğunlaşmır — defolt mövzu və plagin yığını LCP-ni 3-5 saniyə diapazonuna salır. Bunu düzəltmək üçün lazım olan iş Astro yığmaqdan çoxdur.
Təhlükəsizlik səthi böyükdür — plagin yenilənmələri, baza, admin paneli. Statik saytda bu səth sıfırdır.
Versiya idarəsi git deyil — məzmun bazada qalır. Bizim case study və jurnal yazıları MDX faylıdır, kod kimi review olunur, branch-da iterasiya keçir.
Yazma təcrübəsi MDX qədər yaxşı deyil — Gutenberg yaxşılaşıb, lakin redaktor düşüncəsi ilə yazıldıqda terminal və VS Code-da yazmaq daha sürətlidir.

WordPress qoşulduğunuz CMS deyil — sahibliklə gələn sistemdir. Bu sayt üçün CMS lazım yoxdur, çünki müəllif bir nəfərdir və o adam (mən) MDX yaza bilir.

Niyə Webflow / Framer olmadı

İkisi də gözəl alətdir, xüsusilə dizayn iterasiyası üçün. Lakin:

Kod sahibliyi sənindir, lakin generated — export et, üzərinə minlərlə wrapper div, generic class adı tökülmüş HTML alırsan
Hosting-də kilidlənmə — Webflow saytı Webflow-da qalmalıdır (kod export-u mövcuddur, lakin praktiki deyil)
Yazma workflow-u dağıq — uzun jurnal yazısını Webflow CMS-də yazmaq, MDX-də yazmaqla müqayisə edilə bilməz
Anti-template prinsipinə zidd — Webflow-un etos-u şablon-əsaslıdır. Bizim qayda (design-quality.md) tam əksini tələb edir

Bu səbəblərdən, Webflow Qaynaq üçün uyğun deyildi. Müştəri saytları üçün qiymətləndiririk — kontekstə görə həll dəyişir.

Bir kiçik anchor: alət vs. mövqe

Webflow / Framer kiçik komandaların təcrübəsi yaxşıdır. Lakin alət bir şeydir, mövqe başqa şey. Webflow saytı tipik olaraq Webflow şablonlarının vizual qrammatikası ilə danışır. Bu, alətə görə deyil — istifadə mədəniyyətinə görədir. Astro üzərində statik HTML/CSS yazmaq bizi avtomatik olaraq daha “yaradıcı” etmir, lakin defolt görünüş ilə başlamır. Hər şey sıfır səthdən qurulur.

Astro nə verdi

Praktiki cəhətdən:

Sıfır JS-li statik səhifələr defolt olaraq. Yalnız ada (island) kimi qeyd etdiyimiz komponentlər hidrasiya olunur.
MDX birinci sinif vətəndaşdır — collection schema (src/content.config.ts) ilə tipli, validasiyalı.
Content collections + Zod — yazıların frontmatter strukturu derleme zamanı yoxlanılır. Səhv yazılmış topic dərhal build-i sındırır.
i18n marshrutlaşdırması — /az/, /en/, /ru/ strukturu native dəstəklənir.
Build sürəti — bu sayt üçün build tipik olaraq 3-7 saniyədir (yenə də: tipik göstərici, layihə miqyasından asılıdır).
Framework-agnostik adalar — gərək olsa React komponent yan-yana Solid komponent ilə yaşaya bilər.
Az boilerplate — yeni səhifə əlavə etmək = bir .astro və ya .mdx faylı yaratmaq. Marshrutlaşdırma fayl strukturuna bağlıdır, ayrıca konfiqurasiya yoxdur.

Editorial səth üçün bu xüsusiyyətlərin hər biri sürtünməni azaldır. Növbəti jurnal yazısını yazmaq xüsusi bir merge prosesi tələb etmir — fayl yarat, frontmatter yaz, push et. Yazı məqalə kimi düşünülür, deployment kimi yox.

Qəbul etdiyimiz ödənclər

Astro hər şeyi həll etmir. Açıq saxlamaq lazım olan tərəflər:

OOTB interaktivlik az — kompleks tətbiq səhifəsi qurursan, Astro səhv seçimdir. Adalar layeri faydalıdır, lakin tam SPA təcrübəsi üçün Next, Remix, TanStack Start daha doğru cavabdır.
Plagin ekosistemi balacadır — Next.js qədər hazır kitabxana yoxdur. Bizim üçün bu dezavantaj deyil (anti-template), lakin başqaları üçün vacib ola bilər.
Server-side state mənzərəsi gəncdir — Astro Actions, DB inteqrasiyaları formalaşmaqda olan səthdir. Audit pipeline backend-i üçün biz ayrıca edge funksiya seçəcəyik, Astro daxilində qurmayacağıq.
Real-time funksiyalar mövcud deyil — chat, live update, kompleks form state — hər biri başqa kitabxana ilə əlavə olunmalıdır.

Stack seçməzdən əvvəl üç sual

Başqasına məsləhət vermək lazım olduqda, bu üç sualı soruşuram:

Səhifələrinin neçə faizi həqiqətən interaktivdir? Cavab “20%-dən az”dırsa, statik generatora baxın. Cavab “50%-dən çox”dursa, React framework-una baxın.
Məzmun haradan gəlir? Müəllif bir nəfərdirsə və texniki çevikdirsə, MDX. Onlarla qeyri-texniki redaktor varsa, CMS (Sanity, Strapi, və ya WordPress).
Performance büdcəsi nə qədər ciddi? Landing 80KB altında lazımdırsa, statik-əvvəl yanaşma şərtdir. 200KB qəbul ediləndirsə, daha geniş seçim aralığınız var.

Bu üç sualın cavabı stack-i 80% təyin edir. Qalan 20% komandanın təcrübəsi və hosting tərcihləridir.

Astro nə vaxt səhv seçimdir

Şəffaf olmaq üçün üç tipik halı sadalayıram, harada Astro-nu özüm seçmərəm:

Real-time dashboard — istifadəçi üçün canlı məlumat, WebSocket bağlantı, kompleks filter state. Burada Next.js və ya Remix daha doğru cavabdır.
Authenticated SaaS — login, role-based UI, kompleks form-lar, bir neçə paralel data axını. Astro adaları bu işi həll edə bilər, lakin sürtünmə artır. Native React framework rahatlıq verir.
Komanda React mütəxəssislərindən ibarətdir — texniki çeviklik konteksti vacibdir. React komandasına Astro öyrətmək qısamüddətli xərcdir; uzunmüddətli faydası varsa, edirik. Yoxsa, komandanın artıq bildiyi alətdə qalın.

Bu məqamlar məsləhət xidmətində əhəmiyyətlidir. Müştəriyə “bu sayt Astro-dadır, sizinki də olsun” demək — səhv yanaşmadır. Sizin layihəniz başqa cavab tələb edə bilər.

Stack seçimi nə açıqlayır

Texniki seçim heç vaxt yalnız texnika deyil. Hər seçim sayt nə üçündür sualına cavab verir.

Next.js seçən studiya saytın konversiya hunisi olduğunu deyir. WordPress seçən studiya çoxlu insan içərik yenilədiyini deyir. Webflow seçən studiya dizayner doğrudan dəyişiklik etməlidir deyir.

Astro seçən studiya — bu halda Qaynaq — saytın redaksiya orqanı olduğunu, kodun versiya idarə edildiyini, müəllifin texnik olduğunu, performance-ın seçim deyil, şərt olduğunu deyir.

Stack-iniz brend mövqenizi əks etdirsin. Bu, kiçik məsələ deyil.

Sual və ya müzakirə üçün: salam@qaynaq.com.