Bu sayt qanday qurilgan: nega React emas, Django va oddiy JavaScript

Dasturchi o‘ziga shaxsiy sayt qurmoqchi bo‘lsa, bugun deyarli avtomatik tarzda React yoki Next.js tanlaydi. Bu shu qadar odat bo‘lib ketganki, boshqa yo‘lni tanlash o‘zini oqlab berishni talab qiladi. Men aynan shu boshqa yo‘ldan bordim: bu sayt React'siz, umuman SPA'siz, hatto Node'siz qurilgan. Uning ostida Django monolit, git'da yashaydigan markdown fayllar va bir hovuch kutubxonasiz JavaScript turadi. Nega shunday qilganimni tushuntiraman, chunki bu qaror o‘jarlikdan emas, aniq hisobdan chiqqan.

Boshlang‘ich qaror: bu sayt hujjatmi yoki ilova#

Har texnologiya tanlovi bitta savoldan boshlanishi kerak: men aslida nima qurayapman? Bu saytning yaqin yillardagi asosiy vazifasi — maqolalar, darsliklar va ularning qidiruv tizimlarida topilishi. Ya'ni bu, mohiyatan, to‘qson foiz hujjat va o‘n foiz interaktivlik.

Hujjat uchun esa SPA noto‘g‘ri tool. Sabab shundaki, brauzerda JavaScript bilan chiziladigan sahifa qidiruv tizimlari uchun qiyin: yo topilishni yo‘qotasiz, yo buni tuzatish uchun serverda qayta chizish qatlamini (masalan Next.js) qo‘shib, murakkablikni ikki barobar oshirasiz. Serverda tayyor chizilgan HTML esa bu muammoni umuman tug‘dirmaydi: Google tayyor sahifani o‘qiydi, birinchi bayt tez keladi, JavaScript esa deyarli ishtirok etmaydi.

Nimalar tanlangani va nega#

Stack quyidagicha yig‘ilgan. Asosi — Django, uning uzoq qo‘llab-quvvatlanadigan versiyasi. Auth, ORM, migratsiyalar, admin panel — bularning hammasi framework bilan birga keladi va kelajakda sayt kurs-platformaga o‘sganda ham framework almashtirish kerak bo‘lmaydi. Uslublar uchun Tailwind ishlatilgan, lekin uning alohida binary ko‘rinishida — shu tufayli butun Node ekotizimini serverga o‘rnatish shart emas. Baza sifatida PostgreSQL tanlangan va lokal ishlab chiqish birinchi kundan shunda ketadi.

Rejada HTMX bor edi — ishga tushmadi#

Bu yerda rejamdan chetga chiqqan joyni ochiq aytib qo‘yay, chunki u qaror qabul qilish haqidagi eng foydali qism bo‘lib chiqdi.

Boshida frontend uchun HTMX va ozgina Alpine.js rejalashtirilgan edi — strategiya hujjatimda hozir ham shunday yozib qo‘yilgan. Mantiq to‘g‘ri ko‘rinardi: server HTML chizadi, HTMX esa uni sahifani yangilamasdan almashtiradi.

Keyin interaktivlik kerak bo‘lgan joylarni sanab chiqdim va ro‘yxat kutganimdan ancha qisqa bo‘ldi: mavzu almashtirgich, layk tugmasi, maqola kartalaridagi "o‘qib bo‘ldim" belgisi va /writing/ ro‘yxatidagi qidiruv bilan filtrlar. Hammasi shu. Mavzu almashtirgichi o‘n yetti qator kod chiqdi, layk tugmasi qirq to‘qqiz qator. Bularning hech biri uchun kutubxona kerak emas ekan — va kutubxona qo‘shish har bir sahifaga yangi so‘rov, yangi versiya va yangi bog‘liqlik qo‘shgan bo‘lardi.

Shuning uchun bugun saytda HTMX yo‘q. Uning o‘rnida o‘n uchta kichik fayl, jami ikki mingdan sal ko‘proq qator oddiy JavaScript turibdi — va ular HTMX'ning falsafasiga amal qiladi: har bir narsa avval oddiy HTML form yoki havola sifatida ishlaydi, JavaScript esa faqat ustiga qulaylik qo‘shadi. JavaScript o‘chib qolsa, layk tugmasi ham, filtrlar ham baribir ishlayveradi, shunchaki sahifa to‘liq yangilanadi.

Kelajakda kurs va laboratoriya sahifalari qo‘shilganda HTMX yana kun tartibiga chiqishi mumkin. Lekin uni "reja shunday edi" degani uchun bugun qo‘shib qo‘yish — aynan men qochmoqchi bo‘lgan ortiqcha qatlam bo‘lardi.

Va yana bitta o‘zgarish: production'dagi baza#

Xuddi shunday hikoya baza bilan ham bo‘ldi. Kod PostgreSQL uchun yozilgan, lokalda ham Postgres ishlaydi. Lekin serverda hozir SQLite turibdi, va buning sababi oddiy: kontent git'da yashaydi, bazaga esa deyarli hech narsa yozilmaydi — tashrif hisoblagichi va layklar, xolos. Bitta jarayon, bitta fayl, bitta zaxira nusxasi. Ehtiyoj o‘sganda Postgres'ga o‘tish bir DATABASE_URL ni almashtirish masalasi, chunki Django ikkalasini ham bir xil ko‘radi.

Ikkala holatda ham xulosa bitta: reja qog‘ozda qanchalik to‘g‘ri ko‘rinmasin, haqiqiy ehtiyojni faqat qurish paytida ko‘rasiz.

Maqolalar nega bazada emas#

Va eng qiziq qaror — maqolalar. Ular bazada emas, oddiy markdown fayllar ko‘rinishida git'da yashaydi.

Yolg‘iz muallif uchun admin panel orqali maqola yozish aslida ortiqcha qatlam. Markdown va git esa buning o‘rniga bir talay narsani bepul beradi: har o‘zgarishning tarixi, ikki versiya orasidagi farqni ko‘rish, pull-request orqali tahrir qilish va tabiiy zaxira. Har faylning boshida kichik konfiguratsiya bloki turadi va u kontentning modelini belgilaydi:

---
title: "Maqola sarlavhasi"
type: tutorial        # article | tutorial | writeup | research
date: 2026-08-14
summary: "Ro'yxat sahifasida va qidiruv natijasida ko'rinadigan bir-ikki jumla."
topics: [django, security]
difficulty: o'rta     # boshlang'ich | o'rta | murakkab
cover: /static/img/covers/maqola-sarlavhasi.svg
---

Sayt bu fayllarni o‘qiydi, keshlaydi va turlari hamda mavzulari bo‘yicha filtrlaydi. Natijada yangi "bo‘lim" ochish uchun yangi sahifa yozish shart emas — bu shunchaki yangi filtr bo‘lib qoladi.

Modul chegaralari — kelajakni o‘ylab#

Kod apps/core, apps/content kabi modullarga bo‘lingan va ular bitta qoidaga bo‘ysunadi: modullar bir-birining ichki qismiga to‘g‘ridan-to‘g‘ri murojaat qilmaydi. Bu qat'iylik hozir ortiqcha tuyulishi mumkin, lekin uning sababi kelajakda. Bugungi modul chegarasi ertaga alohida servis chegarasiga aylanishi mumkin: kurs-platforma yoki laboratoriya tizimi ajralib chiqqanda, bu qayta yozish emas, shunchaki ko‘chirish bo‘ladi.

Xulosa#

Texnologiya tanlashda gap eng "zo‘r"ini topishda emas. Har bir tanlovning o‘z yutug‘i va o‘z narxi bor, siz esa qaysi narxni to‘lashga rozi ekaningizni hal qilasiz. Yolg‘iz ishlaydigan dasturchi uchun eng qimmat narsa — vaqt va diqqat. Uni ikkita til, ikkita alohida loyiha va murakkab yig‘ish jarayoniga bo‘lib tashlash — o‘sha qimmat narsani bekorga sovurish bo‘lardi. Django'ni tanlashim ham, HTMX'dan voz kechishim ham aynan shu hisobdan chiqqan: kamroq harakatlanuvchi qism, ko‘proq e'tibor esa asl ishga, ya'ni kontentga qoladi.