एका कार्यरत डिझायनरसाठी, पोर्टफोलिओ साइट ही एका विचित्र मधल्या स्थितीत असते. ती दिसायला आकर्षक, लोड व्हायला झटपट आणि कामाच्या तासांवर परिणाम न करता अद्ययावत असणे आवश्यक आहे. माझे जुने सेटअप Webflow वर होते, जे ड्रॅग-अँड-ड्रॉप बिल्डर्स आणि प्रोफेशनल आउटपुट यांच्यातील अंतर इतर साधनांपेक्षा अधिक चांगल्या प्रकारे भरून काढत होते. पण जेव्हा ३०० पाउंडच्या वार्षिक बिलाची सूचना आली, तेव्हा मला एक कठीण प्रश्न विचारावा लागला: मी खरोखर मूल्यासाठी पैसे मोजत होतो की फक्त सोयीसाठी?

मी शून्यापासून पुन्हा तयार करण्याचा निर्णय घेतला. नवीन स्टॅक Astro आणि Sanity आहे. काही काळ याचा वापर केल्यानंतर, नेमके काय काम आले, काय नाही आणि मी पूर्वी वापरलेल्या साधनांच्या तुलनेत हे कुठे बसते, हे मी खाली सांगत आहे.

पोर्टफोलिओसाठी Astro का?

बहुतेक आधुनिक वेब फ्रेमवर्क्स आधी JavaScript पाठवतात आणि नंतर विचार करतात. Astro ही धारणा उलट करते. ते बिल्ड टाइममध्ये साधे स्टॅटिक HTML तयार करते आणि जेव्हा एखाद्या विशिष्ट घटकाला (component) खरोखर गरज असते, तेव्हाच ब्राउझरला JavaScript पाठवते. याला ते islands architecture म्हणतात, पण त्याचा व्यावहारिक परिणाम सोपा आहे: माझ्या पोर्टफोलिओ पेजेसचे वजन नगण्य आहे.

राउटिंग फाईल-आधारित आहे, त्यामुळे नवीन पेज तयार करणे म्हणजे फोल्डरमध्ये फाईल टाकण्याइतके सोपे वाटते. जर तुम्ही React, Vue किंवा Svelte वापरले असेल, तर याचे सिंटॅक्स तुम्हाला परिचयाचे वाटेल. प्रत्येक वेळी एखादा प्रोजेक्ट केस स्टडी जोडायचा असेल तेव्हा मला नवीन संकल्पना शिकावी लागत नाही.

तरीही, मी एखादे जटिल वेब ॲप्लिकेशन तयार करण्यासाठी Astro वापरणार नाही. जर तुम्ही ऑथेंटिकेशन जोडत असाल, ग्लोबल स्टेट मॅनेज करत असाल किंवा रिअल-टाइम डेटा हाताळत असाल, तर तुम्हाला या फ्रेमवर्कशी संघर्ष करावा लागेल. मात्र, मार्केटिंग साइट्स, ब्लॉग आणि पोर्टफोलिओसाठी हे अतिशय उपयुक्त आहे. पेजेस वेगाने लोड होतात कारण ते खरोखरच वेगवान आहेत. हेडलाईन किंवा पॅराग्राफ रेंडर होण्याची वाट पाहण्यासाठी कोणताही hydration overhead नसतो.

WordPress कडून Sanity कडे स्थलांतर

या पुनर्बांधणीपूर्वी, माझा नेहमीचा पर्याय WordPress आणि Advanced Custom Fields हा होता. ACF मुळे WordPress ला अतिरिक्त शक्ती मिळते, पण तरीही तुम्ही दुसऱ्या कोणाचे तरी घर कॉन्फिगर करत असता. Sanity याच्या अगदी उलट काम करते. तुम्ही कोडमध्ये एक schema लिहिता जो तुमचे कंटेंट मॉडेल नेमके कसे दिसेल हे ठरवतो आणि Sanity तुमच्या निर्णयांच्या आधारे एडिटिंग इंटरफेस तयार करते.

मी त्या नियंत्रणाचा वापर करून पुन्हा वापरण्यायोग्य ब्लॉक्सपासून एक साधा पेज बिल्डर तयार केला. मी एकदा hero section परिभाषित केले. एकदा testimonial carousel परिभाषित केले. एकदा card grid परिभाषित केले. आता मी नवीन कोड न लिहिता किंवा पेज टेम्पलेटला स्पर्श न करता, ते ब्लॉक्स कोणत्याही क्रमाने लावून नवीन पेजेस तयार करू शकतो.

दृष्टिकोनातील फरक महत्त्वाचा आहे. WordPress सोबत काम करताना मला अनेकदा असे वाटायचे की मी अशा साधनाशी झुंज देत आहे ज्याला फक्त एक ब्लॉग बनायचे आहे. Sanity सोबत, मला असे वाटते की मी सॉफ्टवेअर तयार करत आहे. कंटेंट हे स्टाईल केलेल्या HTML ऐवजी स्वच्छ structured data बनते. माझे प्रोजेक्ट वर्णन पोर्टेबल ऑब्जेक्ट्स म्हणून राहतात, जे मला हवे असल्यास मी मोबाईल ॲप किंवा न्यूजलेटरमध्ये देखील वापरू शकतो.

एक स्वच्छ deployment workflow

माझा जुना WordPress workflow हा FTP अपलोड्स, स्टेजिंग सबडोमेन्स आणि प्लगइन अपडेट्सचा गोंधळ होता, जे नेहमीच चुकीच्या वेळी बिघडत असत. केवळ एखादी स्पेलिंग चूक सुधारण्यासाठी देखील मला मनातल्या मनात एक चेकलिस्ट ठेवावी लागायची.

नवीन workflow अगदी सोपा आहे:

  • मी स्थानिक पातळीवर (locally) बदल करतो आणि ते त्वरित पाहतो.
  • जेव्हा कोड योग्य वाटतो, तेव्हा मी तो GitHub वर commit करतो.
  • Vercel तो push स्वीकारते आणि साइट आपोआप deploy करते.

येथे कोणताही FTP क्लायंट नाही. सिंक करण्यासाठी कोणताही staging database नाही. Repository हाच सत्याचा एकमेव स्रोत (source of truth) आहे.

कंटेंट देखील त्याच पद्धतीने काम करतो. जेव्हा मी Sanity मध्ये एखादी पोस्ट प्रकाशित करतो किंवा अपडेट करतो, तेव्हा एक webhook Vercel ला साइट पुन्हा rebuild करण्यास सांगतो. स्टॅटिक पेजेस नवीन कंटेंटसह पुन्हा तयार होतात आणि मी सर्व्हरला स्पर्श न करता CDN अपडेट होते. मॅन्युअल कॉपीइंग, एक्सपोर्टिंग किंवा प्लगइन डेटाबेस मायग्रेशन खरोखर काम करेल की नाही याची प्रार्थना न करता सर्व काही सिंकमध्ये राहते.

टोकन्सद्वारे डिझाइन आणि कोड एकत्र जोडणे

या पुनर्बांधणीतील एक शांत पण महत्त्वाचा breakthrough म्हणजे योग्य token system सेट करणे. मी एक सिंगल JSON फाईल ठेवतो ज्यामध्ये साइटमधील प्रत्येक रंग, type scale आणि spacing value असते. ती फाईल मुख्य नियंत्रक असते.

मी तेच व्हॅल्यूज थेट Figma मध्ये आणण्यासाठी Token Studio वापरतो. जेव्हा माझी डिझाइन फाईल surface-default म्हणते, तेव्हा ती कोडमध्ये वापरल्या जाणाऱ्या अगदी त्याच नंबरकडे निर्देश करत असते. एक छोटा स्क्रिप्ट बिल्ड टाइममध्ये JSON चे रूपांतर CSS custom properties मध्ये करते, ज्यामुळे माझ्या stylesheets मध्ये हार्डकोडेड hex codes ऐवजी --color-surface-default सारख्या व्हेरिएबल्सचा संदर्भ दिला जातो.

व्यवहारात हे का महत्त्वाचे आहे ते येथे दिले आहे. जर मला जाणवले की माझा brand red मोबाईल स्क्रीनवर थोडा जास्त तीव्र (aggressive) वाटत आहे, तर मी JSON फाईलमध्ये फक्त एक व्हॅल्यू बदलतो. Figma लायब्ररी अपडेट होते. CSS अपडेट होते. साइटवरील प्रत्येक ठिकाणी ते अपडेट होते. मला grep करण्याची गरज पडत नाही.