ജോലി ചെയ്യുന്ന ഒരു ഡിസൈനറെ സംബന്ധിച്ചിടത്തോളം, ഒരു പോർട്ട്ഫോളിയോ സൈറ്റ് എന്നത് അല്പം സങ്കീർണ്ണമായ ഒരു ഇടമാണ്. അത് കാണാൻ മികച്ചതാകണം, പെട്ടെന്ന് ലോഡ് ആകണം, കൂടാതെ ജോലി സമയത്തെ ബാധിക്കാതെ തന്നെ എപ്പോഴും പുതുമ നിലനിർത്തുകയും വേണം. എന്റെ പഴയ സെറ്റപ്പ് Webflow-ൽ ആയിരുന്നു, അത് ഡ്രാഗ്-ആൻഡ്-ഡ്രോപ്പ് ബിൽഡറുകൾക്കും പ്രൊഫഷണൽ ഔട്ട്പുട്ടിനും ഇടയിലുള്ള വിടവ് മറ്റ് ടൂളുകളേക്കാൾ നന്നായി നികത്തിയിരുന്നു. എന്നാൽ £300 വാർഷിക ബില്ല് വന്നപ്പോൾ ഞാൻ ഒരു കഠിനമായ ചോദ്യം സ്വയം ചോദിച്ചു: ഞാൻ നൽകുന്നത് മൂല്യത്തിനാണോ അതോ വെറും സൗകര്യത്തിനാണോ?
ഞാൻ എല്ലാം പൂജ്യത്തിൽ നിന്ന് വീണ്ടും നിർമ്മിക്കാൻ തീരുമാനിച്ചു. പുതിയ സ്റ്റാക്ക് Astro-യും Sanity-യുമാണ്. കുറച്ചു കാലം ഇത് ഉപയോഗിച്ചതിന് ശേഷം, എന്തൊക്കെയാണ് ഫലപ്രദമായതെന്നും എന്തൊക്കെ പരാജയപ്പെട്ടതെന്നും, പഴയ ടൂളുകളുമായി താരതമ്യം ചെയ്യുമ്പോൾ ഇതിന്റെ സ്ഥാനം എവിടെയാണെന്നും താഴെ വിവരിക്കുന്നു.
എന്തുകൊണ്ട് ഒരു പോർട്ട്ഫോളിയോയ്ക്ക് Astro?
മിക്ക ആധുനിക വെബ് ഫ്രെയിംവർക്കുകളും ആദ്യം ജാവാസ്ക്രിപ്റ്റ് നൽകുകയും പിന്നീട് മറ്റ് കാര്യങ്ങൾ ശ്രദ്ധിക്കുകയും ചെയ്യുന്നവയാണ്. എന്നാൽ Astro ഈ രീതിയെ തിരുത്തുന്നു. ഇത് ബിൽഡ് സമയത്ത് ലളിതമായ സ്റ്റാറ്റിക് HTML നിർമ്മിക്കുന്നു, കൂടാതെ ഒരു പ്രത്യേക കമ്പോണന്റിന് അത്യാവശ്യമാണെങ്കിൽ മാത്രം ജാവാസ്ക്രിപ്റ്റ് ബ്രൗസറിലേക്ക് അയക്കുന്നു. ഇതിനെ 'islands architecture' എന്ന് വിളിക്കുന്നു, എന്നാൽ ഇതിന്റെ പ്രായോഗിക ഫലം ലളിതമാണ്: എന്റെ പോർട്ട്ഫോളിയോ പേജുകളുടെ വലിപ്പം വളരെ കുറവാണ്.
ഇതിലെ റൂട്ടിംഗ് (Routing) ഫയൽ അധിഷ്ഠിതമാണ്, അതിനാൽ ഒരു പുതിയ പേജ് നിർമ്മിക്കുന്നത് ഒരു ഫോൾഡറിലേക്ക് ഒരു ഫയൽ ഇടുന്നതുപോലെ എളുപ്പമാണ്. നിങ്ങൾ React, Vue, അല്ലെങ്കിൽ Svelte എന്നിവ ഉപയോഗിച്ചിട്ടുണ്ടെങ്കിൽ കമ്പോണന്റുകളുടെ സിന്റാക്സ് നിങ്ങൾക്ക് പരിചിതമായിരിക്കും. ഓരോ തവണ ഒരു പ്രോജക്റ്റ് കേസ് സ്റ്റഡി ചേർക്കാൻ ശ്രമിക്കുമ്പോഴും എനിക്ക് പുതിയൊരു രീതി പഠിക്കേണ്ടി വരുന്നില്ല.
എന്നിരുന്നാലും, സങ്കീർണ്ണമായ ഒരു വെബ് ആപ്ലിക്കേഷൻ നിർമ്മിക്കാൻ ഞാൻ Astro ഉപയോഗിക്കില്ല. നിങ്ങൾ ഓതന്റിക്കേഷൻ (authentication) സെറ്റ് ചെയ്യുകയോ, ഗ്ലോബൽ സ്റ്റേറ്റ് (global state) കൈകാര്യം ചെയ്യുകയോ, അല്ലെങ്കിൽ റിയൽ-ടൈം ഡാറ്റ കൈകാര്യം ചെയ്യുകയോ ആണെങ്കിൽ, ഫ്രെയിംവർക്കുമായി നിങ്ങൾ ഏറെ കഷ്ടപ്പെടേണ്ടി വരും. എന്നാൽ മാർക്കറ്റിംഗ് സൈറ്റുകൾക്കും ബ്ലോഗുകൾക്കും പോർട്ട്ഫോളിയോകൾക്കും ഇത് വളരെ അനുയോജ്യമാണ്. പേജുകൾ വളരെ വേഗത്തിൽ പ്രവർത്തിക്കുന്നു, കാരണം അവ യഥാർത്ഥത്തിൽ വേഗതയുള്ളവയാണ്. ഒരു ഹെഡ്ലൈനോ പാരഗ്രാഫോ റെൻഡർ ചെയ്യാൻ കാത്തുനിൽക്കേണ്ടി വരുന്ന 'hydration overhead' ഇതിലില്ല.
WordPress-ൽ നിന്ന് Sanity-ലേക്ക് മാറുന്നു
ഈ പുനർനിർമ്മാണത്തിന് മുമ്പ്, എന്റെ ആശ്രയം എപ്പോഴും Advanced Custom Fields (ACF) ഉപയോഗിച്ചുള്ള WordPress ആയിരുന്നു. ACF WordPress-ന് വലിയ കഴിവുകൾ നൽകുന്നുണ്ടെങ്കിലും, നിങ്ങൾ ഇപ്പോഴും മറ്റൊരാൾ നിർമ്മിച്ച ഒരു വീട് ക്രമീകരിക്കുകയാണ് ചെയ്യുന്നത്. Sanity ഇതിന് വിപരീതമായി പ്രവർത്തിക്കുന്നു. നിങ്ങളുടെ കണ്ടന്റ് മോഡൽ എങ്ങനെയായിരിക്കണമെന്ന് നിർവചിക്കുന്ന ഒരു സ്കീമ (schema) നിങ്ങൾ കോഡിലൂടെ എഴുതുന്നു, അതിനുശേഷം Sanity നിങ്ങളുടെ തീരുമാനങ്ങൾക്കനുസരിച്ച് എഡിറ്റിംഗ് ഇന്റർഫേസ് നിർമ്മിക്കുന്നു.
വീണ്ടും ഉപയോഗിക്കാവുന്ന ബ്ലോക്കുകൾ ഉപയോഗിച്ച് ഒരു ലളിതമായ പേജ് ബിൽഡർ നിർമ്മിക്കാൻ ഞാൻ ആ നിയന്ത്രണം ഉപയോഗിച്ചു. ഞാൻ ഒരു ഹീറോ സെക്ഷൻ (hero section) ഒരിക്കൽ നിർമ്മിച്ചു. ഒരു ടെസ്റ്റിമോണിയൽ കറൗസൽ (testimonial carousel) ഒരിക്കൽ നിർമ്മിച്ചു. ഒരു കാർഡ് ഗ്രിഡ് (card grid) ഒരിക്കൽ നിർമ്മിച്ചു. ഇപ്പോൾ പുതിയ കോഡുകൾ എഴുതുകയോ പേജ് ടെംപ്ലേറ്റ് മാറ്റുകയോ ചെയ്യാതെ തന്നെ ഈ ബ്ലോക്കുകൾ ക്രമീകരിച്ചുകൊണ്ട് എനിക്ക് പുതിയ പേജുകൾ നിർമ്മിക്കാം.
ഈ മാറ്റം വളരെ പ്രധാനമാണ്. WordPress ഉപയോഗിക്കുമ്പോൾ, ഒരു ബ്ലോഗ് ആകാൻ ആഗ്രഹിക്കുന്ന ഒരു ടൂളിനോട് ഞാൻ പോരാടുകയാണെന്ന് എനിക്ക് പലപ്പോഴും തോന്നിയിട്ടുണ്ട്. എന്നാൽ Sanity ഉപയോഗിക്കുമ്പോൾ, ഞാൻ ഒരു സോഫ്റ്റ്വെയർ നിർമ്മിക്കുകയാണെന്ന് എനിക്ക് തോന്നുന്നു. കണ്ടന്റ് എന്നത് ഷോർട്ട്കോഡുകൾ (shortcodes) കലർന്ന സ്റ്റൈൽ ചെയ്ത HTML-ന് പകരം വൃത്തിയുള്ള സ്ട്രക്ചർഡ് ഡാറ്റയായി മാറുന്നു. എന്റെ പ്രോജക്റ്റ് വിവരണങ്ങൾ എവിടെയും ഉപയോഗിക്കാൻ കഴിയുന്ന ഒബ്ജക്റ്റുകളായി മാറുന്നു; വേണമെങ്കിൽ എനിക്ക് അവ ഒരു മൊബൈൽ ആപ്പിലേക്കോ ന്യൂസ്ലെറ്ററിലേക്കോ മാറ്റാം.
വൃത്തിയുള്ള ഒരു ഡിപ്ലോയ്മെന്റ് വർക്ക്ഫ്ലോ (Deployment workflow)
എന്റെ പഴയ WordPress വർക്ക്ഫ്ലോ FTP അപ്ലോഡുകൾ, സ്റ്റേജിംഗ് സബ്ഡൊമെയ്നുകൾ, ഏറ്റവും മോശം സമയത്ത് തകരാറിലാകുന്ന പ്ലഗിൻ അപ്ഡേറ്റുകൾ എന്നിവയാൽ നിറഞ്ഞതായിരുന്നു. ഒരു ചെറിയ തെറ്റ് തിരുത്തി പ്രസിദ്ധീകരിക്കാൻ പോലും എനിക്ക് ഒരു ചെക്ക്ലിസ്റ്റ് തന്നെ വേണമായിരുന്നു.
പുതിയ വർക്ക്ഫ്ലോ വളരെ ലളിതമാണ്:
- ഞാൻ മാറ്റങ്ങൾ ലോക്കലായി ചെയ്യുന്നു, അവ ഉടൻ തന്നെ കാണാനും സാധിക്കുന്നു.
- കോഡ് ശരിയാണെന്ന് തോന്നുമ്പോൾ ഞാൻ അത് GitHub-ലേക്ക് കമിറ്റ് (commit) ചെയ്യുന്നു.
- Vercel ആ മാറ്റങ്ങൾ സ്വീകരിക്കുകയും സൈറ്റ് സ്വയമേവ ഡിപ്ലോയ് ചെയ്യുകയും ചെയ്യുന്നു.
ഇവിടെ FTP ക്ലയന്റുകളോ സിങ്ക് ചെയ്യേണ്ട സ്റ്റേജിംഗ് ഡാറ്റാബേസുകളോ ഇല്ല. റെപ്പോസിറ്ററി (repository) ആണ് യഥാർത്ഥ ഉറവിടം.
കണ്ടന്റും ഇതേപോലെ പ്രവർത്തിക്കുന്നു. ഞാൻ Sanity-യിൽ ഒരു പോസ്റ്റ് പ്രസിദ്ധീകരിക്കുകയോ അപ്ഡേറ്റ് ചെയ്യുകയോ ചെയ്യുമ്പോൾ, ഒരു വെബ്ഹുക്ക് (webhook) വഴി സൈറ്റ് വീണ്ടും ബിൽഡ് ചെയ്യാൻ Vercel-നോട് ആവശ്യപ്പെടുന്നു. പുതിയ കണ്ടന്റോടെ സ്റ്റാറ്റിക് പേജുകൾ വീണ്ടും നിർമ്മിക്കപ്പെടുന്നു, കൂടാതെ ഒരു സെർവറും തൊടാതെ തന്നെ CDN അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നു. മാനുവലായി കോപ്പി ചെയ്യുകയോ എക്സ്പോർട്ട് ചെയ്യുകയോ ചെയ്യേണ്ടതില്ല, പ്ലഗിൻ ഡാറ്റാബേസ് മൈഗ്രേഷൻ ശരിയാകുമോ എന്ന് പേടിക്കേണ്ട കാര്യവുമില്ല.
ടോക്കണുകൾ ഉപയോഗിച്ച് ഡിസൈനും കോഡും തമ്മിൽ ബന്ധിപ്പിക്കുന്നു
ഈ പുനർനിർമ്മാണത്തിലെ ഏറ്റവും വലിയ നേട്ടങ്ങളിലൊന്ന് കൃത്യമായ ഒരു ടോക്കൺ സിസ്റ്റം (token system) സജ്ജീകരിച്ചതാണ്. സൈറ്റിലെ എല്ലാ നിറങ്ങളും, ടൈപ്പ് സ്കെയിലുകളും (type scale), സ്പേസിംഗ് മൂല്യങ്ങളും ഉൾക്കൊള്ളുന്ന ഒരു സിംഗിൾ JSON ഫയൽ ഞാൻ സൂക്ഷിക്കുന്നു. ആ ഫയലാണ് എല്ലാം നിയന്ത്രിക്കുന്നത്.
ആ മൂല്യങ്ങൾ നേരിട്ട് Figma-ലേക്ക് കൊണ്ടുവരാൻ ഞാൻ Token Studio ഉപയോഗിക്കുന്നു. എന്റെ ഡിസൈൻ ഫയലിൽ surface-default എന്ന് കാണിക്കുമ്പോൾ, അത് കോഡിൽ ഉപയോഗിക്കുന്ന അതേ മൂല്യത്തിലേക്കാണ് വിരൽ ചൂണ്ടുന്നത്. ഒരു ചെറിയ സ്ക്രിപ്റ്റ് ബിൽഡ് സമയത്ത് ആ JSON-നെ CSS custom properties ആയി മാറ്റുന്നു, അതിനാൽ എന്റെ സ്റ്റൈൽ ഷീറ്റുകൾ ഹാർഡ്കോഡ് ചെയ്ത ഹെക്സ് കോഡുകൾക്ക് (hex codes) പകരം --color-surface-default പോലുള്ള വേരിയബിളുകൾ ഉപയോഗിക്കുന്നു.
ഇത് പ്രായോഗികമായി എങ്ങനെ സഹായിക്കുന്നു എന്ന് നോക്കാം. എന്റെ ബ്രാൻഡ് റെഡ് (brand red) മൊബൈൽ സ്ക്രീനുകളിൽ അല്പം കൂടുതലാണെന്ന് എനിക്ക് തോന്നിയാൽ, ഞാൻ JSON ഫയലിലെ ഒരു മൂല്യം മാത്രം മാറ്റുന്നു. Figma ലൈബ്രറി അപ്ഡേറ്റ് ആകുന്നു. CSS അപ്ഡേറ്റ് ആകുന്നു. സൈറ്റിലെ എല്ലാ ഭാഗങ്ങളിലും ആ മാറ്റം വരുന്നു. എനിക്ക് ഓരോ സ്ഥലത്തും പോയി മാറ്റം വരുത്തേണ്ടതില്ല.