2026లో మొదటి నుండి ఒక కస్టమ్ బ్లాగ్ను నిర్మించడం అనేది ఒక స్పష్టమైన నిర్ణయం. చాలా మంది రచయితలు కేవలం ఒక హోస్టెడ్ ప్లాట్ఫామ్ను ఎంచుకుని ముందుకు వెళ్తారు. నేను నా టెక్ బ్లాగ్ను Astroతో తిరిగి నిర్మించాలని నిర్ణయించుకున్నాను, ఎందుకంటే నేను స్టాక్ యొక్క ప్రతి పొరను (layer) స్వయంగా నియంత్రించాలని మరియు ఒక స్టాటిక్ సైట్ను కేవలం భిన్నంగా కాకుండా, నిజంగా వేగంగా మార్చే పద్ధతులను నేర్చుకోవాలని అనుకున్నాను. దీని ఫలితంగా జపనీస్ మరియు ఇంగ్లీష్ కంటెంట్ను అందించే ఒక ద్విభాషా (bilingual) సైట్ రూపొందించబడింది, ఇది డిఫాల్ట్గా సున్నా JavaScriptను పంపిస్తుంది మరియు సందర్శకుని బ్రౌజర్పై కాకుండా, సంక్లిష్టతను అంతా నా మెషీన్పైనే ఉంచుతుంది.
ఇది విజయవంతం కావడానికి కారణమైన ఐదు పద్ధతులు ఇక్కడ ఉన్నాయి.
Zodతో Content Collections
Astro యొక్క Content Collections కేవలం Markdown ఫైళ్లను ఫోల్డర్లుగా అమర్చడమే కాకుండా, మీ కంటెంట్ మరియు మీ కోడ్ మధ్య ఒక ఒప్పందాన్ని (contract) అమలు చేస్తాయి. నేను ప్రతి ఆర్టికల్ కలెక్షన్కు ఒక Zod schemaను అనుసంధానించాను, దీని అర్థం ఒకే ఒక్క పేజీ రెండర్ కావడానికి ముందే బిల్డ్ స్టెప్ ఫ్రంటాటర్ (frontmatter)ను ధృవీకరిస్తుంది.
ఈ schema language అనే ఫీల్డ్ను కోరుతుంది, ఇది ja లేదా en అనే రెండు విలువలను మాత్రమే అనుమతిస్తుంది. పాఠకుడు ఏ భాషను పొందుతారనే దానిపై ఎటువంటి సందేహం ఉండదు. నేను అనువాదాలను (translations) ఒకదానితో ఒకటి అనుసంధానించడానికి pair అనే ఫీల్డ్ను కూడా జోడించాను. నేను జపనీస్లో Astro గురించి ఒక పోస్ట్ను ప్రచురించి, తర్వాత దానిని ఇంగ్లీష్లోకి అనువదిస్తే, రెండు ఫైళ్లు ఒకే pair IDని పంచుకుంటాయి. దీనివల్ల లాంగ్వేజ్ స్విచ్చర్ను నిర్మించడం చాలా సులభం అవుతుంది, ఎందుకంటే ఆ సంబంధం ఫైల్ పేర్ల నుండి ఊహించబడదు, డేటాలోనే స్పష్టంగా ఉంటుంది.
తేదీలు Markdown frontmatter నుండి స్ట్రింగ్స్గా వస్తాయి, కాబట్టి schema వాటిని ఆటోమేటిక్గా నిజమైన Date ఆబ్జెక్ట్లుగా మారుస్తుంది. దీనివల్ల నా పేజీ టెంప్లేట్ల లోపల స్ట్రింగ్-మాంగ్లింగ్ (string-mangling) లాజిక్ అవసరం ఉండదు. అయితే, అత్యంత ముఖ్యమైన ప్రయోజనం దాని ఫెయిల్యూర్ మోడ్ (failure mode). ఒకవేళ ఏదైనా ఫైల్లో అవసరమైన ఫీల్డ్ లేకపోయినా లేదా తప్పు భాషా కోడ్ను ఉపయోగించినా, బిల్డ్ వెంటనే స్పష్టమైన ఎర్రర్తో ఆగిపోతుంది. డిప్లాయ్మెంట్ తర్వాత విరిగిపోయిన లేఅవుట్ లేదా సైలెంట్ 404 ఎర్రర్ను కనుగొనే బదులు, నేను దానిని నా టెర్మినల్లోనే సరిచేసుకోగలను.
Article Conversion Pipeline
నేను మొదటి రోజు నుండి ప్రతి పోస్ట్ను ఈ కొత్త ఫార్మాట్లో రాయలేదు. సంవత్సరాల కొద్దీ కంటెంట్ Zenn మరియు Dev.to లలో ఉంది, ప్రతి ప్లాట్ఫామ్కు దాని స్వంత ప్రత్యేకతలు మరియు సొంత సింటాక్స్ ఉన్నాయి. కాపీ-పేస్ట్ చేసి మాన్యువల్గా సరిచేయడం కంటే, ఆర్టికల్స్ యొక్క పూర్తి బ్యాచ్లను స్టాండర్డ్ Markdownలోకి మార్చే ఒక TypeScript స్క్రిప్ట్ను నేను రాశాను.
Zenn టిప్స్ మరియు వార్నింగ్ల కోసం కస్టమ్ కాల్అవుట్ (callout) సింటాక్స్ను ఉపయోగిస్తుంది. నా స్క్రిప్ట్ వాటిని సెమాంటిక్ HTML aside ట్యాగ్లుగా మారుస్తుంది, తద్వారా అవి సైట్ అంతటా స్థిరంగా కనిపిస్తాయి. Dev.to ఎంబెడ్స్ మరియు ప్రత్యేక బ్లాక్ల కోసం Liquid ట్యాగ్లపై ఆధారపడుతుంది. ఆ పైప్లైన్ వాటిని ఎక్కడైనా పనిచేసే సాధారణ Markdown లింక్లుగా మారుస్తుంది.
కొన్ని పోస్ట్లలో కేవలం అసలు ప్లాట్ఫామ్కు మాత్రమే ఉద్దేశించిన అసైడ్స్ (asides) ఉంటాయి, ఉదాహరణకు Medium పేవాల్స్ (paywalls) గురించి డిస్క్లైమర్ లేదా Zenn-నిర్దిష్ట ఇమేజ్ పాత్. మైగ్రేషన్ సమయంలో కన్వర్టర్ వాటిని తొలగించడానికి వీలుగా నేను వాటిని HTML కామెంట్స్లో ఉంచుతాను. స్క్రిప్ట్ ఫైళ్లను లైన్ బై లైన్ ప్రాసెస్ చేస్తుంది, కానీ కోడ్ బౌండరీలను గౌరవిస్తుంది. అది ఒక ఫెన్స్డ్ కోడ్ బ్లాక్ (fenced code block)ను గుర్తించినప్పుడు, ట్రాన్స్ఫర్మేషన్ రూల్స్ను పూర్తిగా వదిలేస్తుంది. ఒక టెక్ బ్లాగ్ యొక్క ముఖ్య ఉద్దేశ్యాన్ని దెబ్బతీసేలా సింటాక్స్ శాంపిల్ను పాడు చేయడం సరికాదు, కాబట్టి లైన్-బై-లైన్ పార్సర్ కోడ్ బ్లాక్లను తాకలేని జోన్లుగా (untouchable zones) పరిగణిస్తుంది.
ఇప్పుడు ఒకే కమాండ్తో, ఏ ఒక్క లింక్ లేదా కాల్అవుట్ను దెబ్బతీయకుండా సంవత్సరాల కొద్దీ రాసిన కంటెంట్ను తిరిగి ప్రచురించవచ్చు.
Build-Time OGP Image Generation
సోషల్ షేరింగ్ ఇమేజ్లు సాధారణంగా చివరి నిమిషంలో ఆలోచించే విషయాలు. మీరు వాటిని మాన్యువల్గా డిజైన్ చేస్తారు లేదా కార్డ్లను ఆన్-డిమాండ్ జనరేట్ చేసే భారీ రన్టైమ్ సర్వీస్ను ఇన్స్టాల్ చేస్తారు. నాకు ఈ రెండూ వద్దు. ఈ సైట్లోని ప్రతి Open Graph ఇమేజ్ బిల్డ్ సమయంలోనే ఉత్పత్తి చేయబడుతుంది, తద్వారా సందర్శకులు ఒక స్టాటిక్ PNGని సూచించే తేలికపాటి img ట్యాగ్ను మాత్రమే పొందుతారు.
నేను Satoriని ఉపయోగిస్తాను, ఇది JSX మార్కప్ను తీసుకుని దానిని SVGగా రెండర్ చేస్తుంది. దీని అవుట్పుట్ స్పష్టంగా, ఊహించదగినదిగా మరియు టెంప్లేట్ చేయడానికి సులభంగా ఉంటుంది. అసలైన ఆప్టిమైజేషన్ ఫాంట్ హ్యాండ్లింగ్ నుండి వచ్చింది. పూర్తి జపనీస్ వెబ్ ఫాంట్ సులభంగా ఐదు మెగాబైట్ల కంటే ఎక్కువగా ఉండవచ్చు. దానిని బిల్డ్ సమయంలో లోడ్ చేయడం లేదా బ్రౌజర్ను దానిని ఫెచ్ చేయమని అడగడం అనేది అర్థరహితం.
దానికి బదులుగా, నేను Google Fonts subsettingని ఉపయోగిస్తాను. స్క్రిప్ట్ ఒక నిర్దిష్ట పోస్ట్ యొక్క టైటిల్ టెక్స్ట్ను పరిశీలించి, ఆ స్ట్రింగ్ను రెండర్ చేయడానికి అవసరమైన ఖచ్చితమైన గ్లిఫ్ సెట్ను (glyph set) మాత్రమే అభ్యర్థిస్తుంది. ఒక హెడ్లైన్ నలభై ప్రత్యేక జపనీస్ అక్షరాలను ఉపయోగిస్తే, కేవలం ఆ నలభై అక్షరాలు మాత్రమే నెట్వర్క్ ద్వారా ప్రయాణిస్తాయి. దీనివల్ల బిల్డ్ వేగంగా ఉంటుంది మరియు సబ్సెట్ ఖచ్చితంగా ఉండటం వల్ల రెండర్ చేయబడిన ఇమేజ్లో ఎప్పుడూ విరిగిపోయిన టోఫు బ్లాక్లు (tofu blocks) కనిపించవు. రన్టైమ్ అదృష్టం మీద ఏదీ వదిలివేయబడదు.
Tailwind Tokens ద్వారా Dark Mode
ప్రతి ఎలిమెంట్ను dark: యుటిలిటీ క్లాస్లతో అలంకరించడానికి నేను నిరాకరించాను. ఆ విధానం సరిగ్గా స్కేల్ అవ్వదు మరియు మీ మార్కప్ను అనవసరమైన నాయిస్తో నింపేస్తుంది. నేను కలర్ టోకెన్లను (color tokens) తిరిగి నిర్వచించాను, తద్వారా యాక్టివ్ థీమ్ను బట్టి ఒకే క్లాస్ పేరు వేర్వేరు విలువలను కలిగి ఉంటుంది.
నేను ప్రతి సర్ఫేస్ మరియు టెక్స్ట్ కలర్ కోసం CSS custom properties ఉపయోగిస్తాను. Light modeలో, --color-white అనేది #ffffffకి మ్యాప్ అవుతుంది. Dark modeలో, అదే వేరియబుల్ పేరు నలుపుకు దగ్గరగా ఉండే విలువను సూచిస్తుంది. నా HTML పూర్తిగా స్వతంత్రంగా (agnostic) ఉంటుంది. ఒక కార్డ్ సమయం గురించి పట్టించుకోకుండా bg-ui-surface మరియు text-ui-primaryలను ఉపయోగించవచ్చు. Theme switch రూట్ (root) వద్ద వేరియబుల్ నిర్వచనాలను మారుస్తుంది, మరియు మొత్తం ఇంటర్ఫేస్ వెంటనే స్పందిస్తుంది.
ఈ విధానంలో ఉన్న ఒకే ఒక్క రిస్క్ ఏమిటంటే, stylesheets లోడ్ కావడానికి ముందు కాంతివంతమైన కంటెంట్ మెరిసిపోవడం (flash of light content). దీనిని డాక్యుమెంట్ headలో ఒక చిన్న inline script ద్వారా పరిష్కరించాను. ఇది మొదటి పెయింట్ (first paint) కంటే ముందే రన్ అవుతుంది, localStorage మరియు సిస్టమ్ ప్రిఫరెన్స్ను తనిఖీ చేస్తుంది, మరియు వెంటనే సరైన data attributeని సెట్ చేస్తుంది. ఈ స్క్రిప్ట్ రెండరింగ్ను కేవలం కొన్ని మిల్లీసెకన్ల పాటు మాత్రమే ఆపుతుంది కాబట్టి, డార్క్ మోడ్ ప్రారంభం కావడానికి ముందు సందర్శకుడు ఒక్కసారిగా తెల్లని కాంతిని (jarring white burst) చూడరు.
Island Architecture మరియు Zero-JS
ఒక పేజీ అనేది static HTMLగా ప్రారంభం కావాలనేదే Astro యొక్క ప్రధాన ఉద్దేశ్యం. ఇంటరాక్షన్ నిజంగా అవసరమైనప్పుడు మాత్రమే JavaScript ప్రవేశిస్తుంది. నేను దానిని సీరియస్గా తీసుకున్నాను.
గ్లోబల్ మెనూ మరియు theme toggle కోసం నేను Reactను నివారించాను. ఈ రెండింటినీ ఒకే మాడ్యూల్లో ఉండే స్వల్ప vanilla JavaScriptతో నిర్వహిస్తాను. ఇందులో hydration overhead, virtual DOM diffing లేదా డౌన్లోడ్ చేయడానికి ఎలాంటి framework runtime ఉండదు.
టెక్స్ట్ నుండి డయాగ్రామ్లను రెండర్ చేయడానికి నేను ఉపయోగించే ఏకైక భారీ లైబ్రరీ Mermaid.js. దానిని గ్లోబల్గా ఇంపోర్ట్ చేసే బదులు, నేను దానిని ఒక Intersection Observer లోపల ఉంచాను. ఈ observer డయాగ్రామ్ కంటైనర్లను గమనిస్తుంది. వినియోగదారు ఒక డయాగ్రామ్ నుండి కొన్ని వందల పిక్సెల్ల లోపు స్క్రోల్ చేసినప్పుడు, స్క్రిప్ట్ డైనమిక్గా Mermaid మాడ్యూల్ను ఇంజెక్ట్ చేసి డయాగ్రామ్ను రెండర్ చేస్తుంది. ఒక పోస్ట్లో డయాగ్రామ్లు లేకపోతే, ఆ లైబ్రరీ నెట్వర్క్ను అసలు తాకదు. ప్రారంభ పేజీ లోడ్ తేలికగా ఉంటుంది, మరియు పాఠకుడు నిజంగా చూసే దాని కోసం మాత్రమే బ్రౌజర్ వనరులను ఉపయోగిస్తుంది.
Build-First Mindset
ప్రతి ప్యాటర్న్లోనూ ఉండే ఒకే ఒక సూత్రం సరళమైనది: బిల్డ్ సమయంలో మీరు పనిని చేయగలిగితే, అక్కడే చేయండి. సైట్ డిప్లాయ్ కావడానికి ముందే Zodతో మీ డేటాను ధృవీకరించండి (validate). రిక్వెస్ట్ సమయంలో కాకుండా, ముందే ప్రాప్రైటరీ ప్లాట్ఫారమ్ సింటాక్స్ను మార్చండి. సర్వర్ను నడపడానికి బదులుగా, సోషల్ ఇమేజ్లను static ఫైల్లుగా రెండర్ చేయండి. ప్రతి క్లయింట్కు లాజిక్ను పంపే బదులు, టోకెన్ల ద్వారా theme కలర్లను పరిష్కరించండి. వినియోగదారుకు నిజంగా అవసరమయ్యే వరకు భారీ JavaScriptను వాయిదా వేయండి (defer).
సంక్లిష్టతను (complexity) బిల్డ్ దశకు మళ్లించడం వల్ల runtime అంచనా వేయదగినదిగా, payload చిన్నదిగా మరియు నిర్వహణ భారం (maintenance burden) తక్కువగా ఉంటుంది. సైట్ వేగంగా ఉండటానికి కారణం ఏదో ఒక ట్రిక్ మాత్రమే కాదు, సందర్శకుని బ్రౌజర్లో జరిగే పనులు చాలా తక్కువగా ఉండటం వల్ల. 2026లో static architectureను ఎంచుకోవడం వల్ల కలిగే నిజమైన ప్రయోజనం ఇదే.