Cum am construit un blog tehnic cu Next.js 16 și de ce Learning in Public funcționează

Cum am construit propriul blog tehnic și de ce „Learning in Public” mi-a schimbat modul de a învăța

Am ajuns la concluzia asta după ce am recitit pentru a treia oară același thread pe Twitter, am salvat același articol în Notion și am continuat să uit jumătate din el în două săptămâni.

Problema nu era că nu învățam. Problema era că nu rămânea nimic.

În ultimii ani am consumat sute de articole, tutoriale și videoclipuri despre programare. Dar de fiecare dată apărea aceeași situație: citeam ceva interesant, îl înțelegeam pe moment, iar după câteva săptămâni informația dispărea aproape complet.

Atunci am descoperit un principiu simplu care mi-a schimbat perspectiva asupra învățării.

Learning in Public: ideea care a schimbat totul

Prima dată am întâlnit conceptul de Learning in Public la Swyx, un developer pe care îl urmăresc de câțiva ani.

Ideea este surprinzător de simplă: tot ceea ce înveți, publici.

Nu aștepți să devii expert. Nu aștepți să ai o perspectivă revoluționară. Nu aștepți să fii „pregătit”.

Pur și simplu scrii despre ceea ce ai descoperit și despre procesul prin care ai ajuns la acea concluzie.

La început, ideea mi s-a părut puțin naivă.

De ce ar citi cineva un articol scris de mine când există documentație oficială, cursuri cu zeci de mii de studenți și tutoriale realizate de oameni cu mult mai multă experiență?

Cu timpul am înțeles răspunsul.

Vocea contează mai mult decât autoritatea.

Uneori este mai util să citești explicația unei persoane care tocmai a rezolvat o problemă decât să parcurgi o documentație perfectă, dar impersonală. În plus, procesul de a explica ceva altora te obligă să înțelegi acel lucru la un nivel mult mai profund.

Nu poți explica bine ceva ce nu ai înțeles cu adevărat.

De ce am decis să construiesc un blog

În loc să pornesc pur și simplu un blog, am decis să îl construiesc de la zero.

Am vrut ca blogul să fie și un proiect tehnic, nu doar un loc unde public articole.

Într-un fel, era deja Learning in Public în practică: construirea unui blog despre dezvoltare software folosind tehnologii despre care urma să scriu.

Pe lângă componenta educațională, proiectul mi-a oferit ocazia să explorez tehnologii noi, să experimentez cu arhitecturi moderne și să documentez întregul proces.

Alegerea stack-ului tehnic

Primele întrebări au fost practice:

• Unde stochez articolele?
• Cum le public?
• Cum arată pe mobil?
• Cum sunt indexate de Google?
• Cum gestionez mai multe limbi?

Next.js 16 și App Router

Am ales Next.js 16 ca fundament al proiectului.

Nu este o alegere neobișnuită, dar în prezent reprezintă una dintre cele mai mature soluții pentru aplicații React aflate în producție.

Una dintre schimbările importante aduse de versiunile recente este faptul că Server Components sunt implicite.

Acest lucru înseamnă că toate componentele care nu necesită interactivitate sunt randate pe server și livrează HTML gata procesat către utilizator.

Pentru un blog, avantajele sunt evidente:

• încărcare mai rapidă;
• SEO mai bun;
• mai puțin JavaScript trimis către browser;
• structură mai simplă a aplicației.

Articolele sunt generate static, iar metadatele SEO sunt create dinamic pentru fiecare pagină folosind API-urile native ale framework-ului.

Tailwind CSS 4

O surpriză plăcută a fost Tailwind CSS 4.

Noua versiune schimbă destul de mult modul de configurare. Nu mai există fișierul clasic tailwind.config.js, iar tema aplicației este definită direct în CSS prin intermediul directivei @theme.

Această abordare transformă design tokens în variabile CSS native și simplifică implementarea temelor, inclusiv a modului întunecat.

Pe parcurs am descoperit și o lecție importantă:

În Tailwind v4, toate utilitarele sunt plasate în @layer utilities. Dacă adaugi CSS personalizat în afara unui layer, acel CSS poate avea prioritate mai mare și poate suprascrie complet clasele Tailwind.

Este unul dintre acele detalii pe care le afli doar după câteva ore de debugging.

Sanity v3 ca Headless CMS

Alegerea care mi-a luat cel mai mult timp a fost sistemul de gestionare a conținutului.

Varianta simplă era să stochez articolele ca fișiere Markdown în repository.

Funcționează. Este gratuită. Este ușor de înțeles.

Dar apar rapid limitările:

• fiecare articol nou necesită commit;
• editarea de pe telefon devine incomodă;
• gestionarea imaginilor este limitată;
• colaborarea este dificilă.

De aceea am ales Sanity v3.

Editorul vizual rulează direct în aplicație, conținutul poate fi interogat prin GROQ, iar imaginile sunt servite prin CDN cu optimizări automate și transformări la cerere.

Pentru un blog modern, diferența de experiență este considerabilă.

Internaționalizare cu next-intl

Blogul este disponibil în trei limbi:

• Română
• Engleză
• Rusă

Decizia nu a fost luată din dorința de a avea „mai multe limbi”, ci din dorința de a ajunge la o audiență mai largă.

Mulți dezvoltatori din regiune consumă conținut în toate cele trei limbi, iar suportul multilingv oferă flexibilitate atât pentru utilizatori, cât și pentru motoarele de căutare.

Cu next-intl, fiecare limbă are propriul URL și propriile traduceri, iar experiența utilizatorului rămâne naturală.

De ce am ales Feature-Sliced Design

Probabil partea asupra căreia am petrecut cel mai mult timp înainte să scriu prima linie de cod a fost arhitectura.

Am ales Feature-Sliced Design (FSD).

FSD organizează aplicația în straturi cu responsabilități clare:

Shared

Conține componente și utilitare complet generice, fără logică de business.

Entities

Conține modelele de date principale:

• Post
• Author
• Category

Aici se află tipurile TypeScript și interogările pentru date.

Features

Conține funcționalitățile interactive:

• formular de contact;
• schimbarea limbii;
• dark mode;
• alte acțiuni ale utilizatorului.

Widgets

Conține blocuri mari de interfață compuse din entități și funcționalități:

• Navbar;
• Footer;
• liste de articole;
• secțiuni complexe ale paginii.

De ce contează arhitectura chiar și într-un proiect personal

Atunci când lucrezi singur, nu ai code review.

Nu există un coleg care să îți spună că ai pus logica în locul greșit sau că ai creat o dependență circulară.

În astfel de situații, arhitectura devine un mecanism de disciplină.

Regulile dintre straturi fac greșelile evidente și previn degradarea codului pe măsură ce proiectul crește.

În plus, dacă în viitor voi adăuga:

• newsletter;
• secțiune de proiecte;
• sistem de comentarii;
• alte tipuri de conținut;

fiecare funcționalitate va avea deja un loc clar în structură.

Ce urmează

Imediat după publicarea acestui articol urmează:

• deploy pe Vercel;
• configurarea domeniului;
• verificarea metadatelor pentru toate limbile.

Pe termen scurt vreau să adaug:

• sitemap generat automat;
• structured data JSON-LD;
• suport complet pentru hreflang;
• optimizări SEO suplimentare.

Toate sunt implementări relativ mici, dar cu impact real asupra indexării.

Conținutul rămâne partea cea mai importantă

Totuși, indiferent cât de bine este construit un blog, fără conținut nu are valoare.

Arhitectura, framework-urile și optimizările SEO sunt doar infrastructură.

Adevărata provocare începe odată cu publicarea constantă a articolelor.

Scopul meu nu este să construiesc un blog perfect.

Scopul este să construiesc un blog care crește odată cu mine.

Fiecare articol reprezintă o dovadă că am înțeles suficient de bine un subiect încât să îl pot explica altcuiva.

Iar uneori, chiar în timpul scrierii, descoperi că încă nu îl înțelegi atât de bine pe cât credeai.

Paradoxal, tocmai acele momente sunt cele mai valoroase.

Pentru că atunci învățarea începe cu adevărat.