एक कार्यरत डिज़ाइनर के लिए, एक पोर्टफोलियो साइट एक अजीब स्थिति में होती है। इसे शार्प दिखना चाहिए, तुरंत लोड होना चाहिए, और बिल योग्य घंटों (billable hours) को प्रभावित किए बिना अपडेट रहना चाहिए। मेरा पुराना सेटअप Webflow पर था, जो अधिकांश टूल्स की तुलना में ड्रैग-एंड-ड्रॉप बिल्डर्स और प्रोफेशनल आउटपुट के बीच के अंतर को बेहतर तरीके से पाटता था। लेकिन जब £300 के वार्षिक बिल के साथ रिन्यूअल नोटिस आया, तो मुझे एक कठिन सवाल पूछना पड़ा: क्या मैं मूल्य के लिए भुगतान कर रहा था, या सिर्फ सुविधा के लिए?

मैंने इसे शुरुआत से फिर से बनाने का फैसला किया। नया स्टैक Astro और Sanity है। कुछ समय तक इसके साथ रहने के बाद, यहाँ विस्तार से बताया गया है कि क्या काम आया, क्या नहीं आया, और यह मेरे पिछले टूल्स की तुलना में कहाँ फिट बैठता है।

पोर्टफोलियो के लिए Astro क्यों?

ज़्यादातर आधुनिक वेब फ्रेमवर्क पहले JavaScript भेजते हैं और बाकी चीज़ों पर बाद में ध्यान देते हैं। Astro इस धारणा को उलट देता है। यह बिल्ड टाइम पर सादा स्टैटिक HTML जेनरेट करता है और JavaScript को ब्राउज़र पर तभी भेजता है जब किसी विशिष्ट कंपोनेंट को वास्तव में इसकी आवश्यकता होती है। वे इसे आइलैंड्स आर्किटेक्चर (islands architecture) कहते हैं, लेकिन व्यावहारिक परिणाम सरल है: मेरे पोर्टफोलियो पेजों का वजन लगभग शून्य है।

राउटिंग फ़ाइल-आधारित है, इसलिए एक नया पेज बनाना किसी फ़ोल्डर में फ़ाइल डालने जितना आसान लगता है। कंपोनेंट्स एक ऐसे सिंटैक्स का उपयोग करते हैं जो आपको परिचित लगेगा यदि आपने React, Vue, या Svelte का उपयोग किया है। जब भी मैं किसी प्रोजेक्ट केस स्टडी को जोड़ना चाहता हूँ, मुझे किसी नए प्रतिमान (paradigm) को अपनाने की ज़रूरत नहीं पड़ती।

इसके बावजूद, मैं एक जटिल वेब एप्लिकेशन बनाने के लिए Astro का उपयोग नहीं करूँगा। यदि आप ऑथेंटिकेशन सेटअप कर रहे हैं, ग्लोबल स्टेट मैनेज कर रहे हैं, या रियल-टाइम डेटा को हैंडल कर रहे हैं, तो आपको फ्रेमवर्क के साथ संघर्ष करना पड़ेगा। हालाँकि, मार्केटिंग साइटों, ब्लॉग और पोर्टफोलियो के लिए, यह बाधा नहीं बनता। पेज तेज़ महसूस होते हैं क्योंकि वे वास्तव में तेज़ हैं। किसी हेडलाइन या पैराग्राफ को रेंडर करने के लिए इंतज़ार करने वाला कोई हाइड्रेशन ओवरहेड (hydration overhead) नहीं है।

WordPress से Sanity पर जाना

इस रीबिल्ड से पहले, मेरा विकल्प हमेशा Advanced Custom Fields के साथ WordPress होता था। ACF, WordPress को सुपरपावर्स देता है, लेकिन आप अभी भी किसी और के बनाए घर को कॉन्फ़िगर कर रहे होते हैं। Sanity इसके विपरीत काम करता है। आप कोड में एक स्कीमा लिखते हैं जो ठीक से परिभाषित करता है कि आपका कंटेंट मॉडल कैसा दिखेगा, और Sanity आपके निर्णयों के आधार पर एडिटिंग इंटरफ़ेस बनाता है।

मैंने उस नियंत्रण का उपयोग पुन: प्रयोज्य ब्लॉक्स (reusable blocks) से एक सरल पेज बिल्डर बनाने के लिए किया। मैंने एक बार हीरो सेक्शन परिभाषित किया। मैंने एक बार टेस्टिमोनियल कैरोसेल परिभाषित किया। मैंने एक बार कार्ड ग्रिड परिभाषित किया। अब मैं बिना नया कोड लिखे या पेज टेम्पलेट को छुए, उन ब्लॉक्स को किसी भी क्रम में रखकर नए पेज बना सकता हूँ।

मानसिकता में अंतर मायने रखता है। WordPress के साथ, मुझे अक्सर ऐसा महसूस होता था कि मैं एक ऐसे टूल से जूझ रहा हूँ जो एक ब्लॉग बनना चाहता है। Sanity के साथ, मुझे ऐसा महसूस होता है जैसे मैं सॉफ़्टवेयर बना रहा हूँ। कंटेंट शॉर्टकोड के साथ मिले हुए स्टाइल वाले HTML के बजाय, साफ़-सुथरा स्ट्रक्चर्ड डेटा बन जाता है। मेरे प्रोजेक्ट विवरण पोर्टेबल ऑब्जेक्ट्स के रूप में रहते हैं जिन्हें यदि मैं चाहूँ तो किसी मोबाइल ऐप या न्यूज़लेटर में भी भेज सकता हूँ।

एक क्लीन डिप्लॉयमेंट वर्कफ़्लो

मेरा पुराना WordPress वर्कफ़्लो FTP अपलोड्स, स्टेजिंग सबडोमेन और प्लगइन अपडेट्स का एक झमेला था जो हमेशा सबसे खराब समय पर टूटते हुए प्रतीत होते थे। सिर्फ एक टाइपो ठीक करने के लिए भी मेरे पास एक मानसिक चेकलिस्ट रहती थी।

नया वर्कफ़्लो छोटा है:

  • मैं स्थानीय रूप से (locally) बदलाव करता हूँ और उन्हें तुरंत देखता हूँ।
  • जब कोड सही लगे तो मैं उसे GitHub पर कमिट कर देता हूँ।
  • Vercel उस पुश को पकड़ लेता है और साइट को स्वचालित रूप से डिप्लॉय कर देता है।

यहाँ कोई FTP क्लाइंट नहीं है। सिंक करने के लिए कोई स्टेजिंग डेटाबेस नहीं है। रिपॉजिटरी ही सत्य का एकमात्र स्रोत (source of truth) है।

कंटेंट भी उसी तरह काम करता है। जब मैं Sanity के अंदर कोई पोस्ट पब्लिश या अपडेट करता हूँ, तो एक वेबहुक Vercel को साइट को फिर से बनाने (rebuild) के लिए कहता है। स्टैटिक पेज ताज़ा कंटेंट के साथ फिर से जेनरेट हो जाते हैं, और बिना सर्वर को छुए CDN अपडेट हो जाता है। बिना मैन्युअल कॉपी करने, एक्सपोर्ट करने, या यह प्रार्थना करने के कि प्लगइन डेटाबेस माइग्रेशन वास्तव में काम कर गया, सब कुछ सिंक रहता है।

टोकन्स के साथ डिज़ाइन और कोड को एक साथ जोड़ना

इस रीबिल्ड में एक शांत लेकिन बड़ी उपलब्धि एक उचित टोकन सिस्टम सेट करना था। मैं एक सिंगल JSON फ़ाइल रखता हूँ जो साइट के हर रंग, टाइप स्केल और स्पेसिंग वैल्यू को नियंत्रित करती है। वह फ़ाइल बॉस है।

मैं उन वैल्यूज़ को सीधे Figma में लाने के लिए Token Studio का उपयोग करता हूँ। जब मेरी डिज़ाइन फ़ाइल surface-default कहती है, तो वह ठीक उसी नंबर की ओर इशारा कर रही होती है जिसका उपयोग कोड करता है। एक छोटा स्क्रिप्ट बिल्ड टाइम पर JSON को CSS कस्टम प्रॉपर्टीज़ में बदल देता है, ताकि मेरी स्टाइलशीट्स हार्डकोडेड हेक्स कोड के बजाय --color-surface-default जैसे वेरिएबल्स का संदर्भ लें।

व्यावहारिक रूप से यह क्यों मायने रखता है, यहाँ देखें। यदि मुझे एहसास होता है कि मेरा ब्रांड रेड मोबाइल स्क्रीन पर थोड़ा ज़्यादा आक्रामक है, तो मैं JSON फ़ाइल में एक वैल्यू बदल देता हूँ। Figma लाइब्रेरी अपडेट हो जाती है। CSS अपडेट हो जाता है। साइट पर हर जगह वह अपडेट हो जाता है। मुझे grep करने की ज़रूरत नहीं पड़ती