The web development world spent the better part of a decade convincing itself that the browser should do the heavy lifti

വെബ് ഡെവലപ്‌മെന്റ് ലോകം ഒരു പതിറ്റാണ്ടോളം തന്നെ വിശ്വസിച്ചിരുന്നത് ബ്രൗസറാണ് പ്രധാന ജോലികൾ ചെയ്യേണ്ടതെന്നാണ്. ഡോക്യുമെന്റുകളിൽ നിന്നും ഫോമുകളിൽ നിന്നും തുടങ്ങി, ക്രമേണ എല്ലാ പ്രവർത്തനങ്ങളും ക്ലയന്റിലേക്ക് മാറ്റപ്പെട്ടു. റൂട്ടിംഗ് (Routing), സ്റ്റേറ്റ് മാനേജ്‌മെന്റ് (State management), ഡാറ്റാ ഫെച്ചിംഗ് (Data fetching), റെൻഡറിംഗ് ലോജിക് (Rendering logic), GraphQL വഴിയുള്ള ഡാറ്റാബേസ് ക്വറി ഓർക്കസ്ട്രേഷൻ എന്നിവയെല്ലാം ഓരോ റിലീസിലും വലുതായിക്കൊണ്ടിരിക്കുന്ന JavaScript ബണ്ടിലുകളിലേക്ക് മാറി. ഫ്രെയിംവർക്കുകൾ വർദ്ധിച്ചു, ബിൽഡ് പൈപ്പ്‌ലൈനുകൾ സങ്കീർണ്ണമായി, ആപ്പുകൾ വേഗത്തിൽ പ്രവർത്തിപ്പിക്കാൻ തുടങ്ങിയത് പിന്നീട് മെഗാബൈറ്റുകൾ കണക്കിന് കോഡ് ഡൗൺലോഡ് ചെയ്ത് പാഴ്സ് ചെയ്ത് എക്സിക്യൂട്ട് ചെയ്താൽ മാത്രം ഒരു പേജ് റെൻഡർ ചെയ്യാൻ കഴിയുന്ന ഒരു ആർക്കിടെക്ചറിലേക്കായി മാറി.

ഈ മാറ്റം യഥാർത്ഥ പ്രശ്നങ്ങൾ പരിഹരിച്ചു. jQuery ഉപയോഗിച്ചുള്ള സെർവർ റെൻഡർ ചെയ്ത പേജുകൾക്ക് ഉപയോക്താക്കൾ പ്രതീക്ഷിക്കുന്ന സ്മൂത്ത് ആയ മാറ്റങ്ങൾ നൽകാൻ പ്രയാസമായിരുന്നു. Single Page Applications നമുക്ക് ഇൻസ്റ്റന്റ് നാവിഗേഷനും, പെർസിസ്റ്റന്റ് സ്റ്റേറ്റും, മികച്ച ഇന്ററാക്ഷനുകളും നൽകി. എന്നാൽ ഇതിന് വലിയൊരു വില നൽകേണ്ടി വന്നു. ടീമുകൾ ഇപ്പോൾ സങ്കീർണ്ണമായ ക്ലയന്റ് സൈഡ് സ്റ്റേറ്റ് സ്റ്റോറുകൾ കൈകാര്യം ചെയ്യേണ്ടി വരുന്നു, വലിയ JavaScript ബണ്ടിലുകൾ നിയന്ത്രിക്കണം, ഡാറ്റാ സിൻക്രണൈസേഷൻ ലെയറുകൾ പരിപാലിക്കണം, ചിലപ്പോൾ ഒരു ഫുൾ ടൈം ജോലിയെപ്പോലെ തോന്നിക്കുന്ന ബിൽഡ് പൈപ്പ്‌ലൈനുകൾ ഡിബഗ് ചെയ്യണം. നമ്മൾ ഒരു കൂട്ടം പ്രശ്നങ്ങൾക്ക് പകരം മറ്റൊരു കൂട്ടം പ്രശ്നങ്ങളാണ് സ്വീകരിച്ചത്, എല്ലാ ആപ്ലിക്കേഷനുകൾക്കും ഈ വില നൽകേണ്ടതുണ്ടോ എന്ന് ഇപ്പോൾ പല ഡെവലപ്പർമാരും ചോദിക്കുന്നു.

രണ്ട് പുതിയ മാറ്റങ്ങളാണ് ഈ ചോദ്യത്തിന് ഉത്തരം നൽകാൻ സഹായിക്കുന്നത്.

HTMX-ഉം ഹൈപ്പർമീഡിയയുടെ തിരിച്ചുവരവും

ആദ്യത്തേത് HTMX ആണ്. ഉപരിപ്ലവമായി നോക്കിയാൽ ഇതൊരു ചെറിയ ലൈബ്രറിയാണെന്ന് തോന്നാം, പക്ഷേ ഇതിന്റെ ആർക്കിടെക്ചറൽ സ്വാധീനം വലുതാണ്. HTML-നെ JavaScript ഉപയോഗിച്ച് പ്രവർത്തിപ്പിക്കേണ്ട ഒരു സ്റ്റാറ്റിക് ഷെല്ലായി കാണുന്നതിന് പകരം, ആപ്ലിക്കേഷൻ ലോജിക്കിനായുള്ള സ്വാഭാവിക ഫോർമാറ്റായി HTMX കണക്കാക്കുന്നു.

പ്രായോഗികമായി എന്താണ് മാറുന്നത് എന്ന് നോക്കാം. പരമ്പരാഗതമായി, കൂടുതൽ കമന്റുകൾ ലോഡ് ചെയ്യാൻ ഒരു ഉപയോക്താവ് ബട്ടൺ ക്ലിക്ക് ചെയ്യുമ്പോൾ, ഫ്രണ്ട്‌എൻഡ് ഒരു fetch റിക്വസ്റ്റ് അയക്കുന്നു, ഒരു JSON പേലോഡ് സ്വീകരിക്കുന്നു, അത് ക്ലയന്റ് സൈഡ് സ്റ്റോറിലേക്ക് മാറ്റുന്നു, ഒരു കമ്പോണന്റ് ടെംപ്ലേറ്റിലൂടെ പ്രവർത്തിപ്പിക്കുന്നു, virtual DOM വ്യത്യാസങ്ങൾ കണ്ടെത്തുന്നു, ഒടുവിൽ പേജ് അപ്‌ഡേറ്റ് ചെയ്യുന്നു. HTMX ഈ പ്രക്രിയയെ ലഘൂകരിക്കുന്നു. ബട്ടണിൽ തന്നെ റിക്വസ്റ്റ് എങ്ങോട്ട് അയക്കണം എന്നും ഏത് പേജ് എലമെന്റ് മാറ്റണം എന്നും പറയുന്ന അറ്റ്രിബ്യൂട്ടുകൾ അടങ്ങിയിരിക്കുന്നു. സെർവർ ഒരു HTML ഫ്രാഗ്മെന്റ് — ഒരു div-ൽ പൊതിഞ്ഞ പുതിയ കമന്റുകൾ മാത്രം — തിരികെ നൽകുന്നു. ബ്രൗസർ അത് അവിടെ പകരം വെക്കുന്നു. ഇവിടെ JSON ഇല്ല, ഫ്രണ്ട്‌എൻഡ് സ്റ്റേറ്റ് ട്രീ ഇല്ല, റീകൺസിലിയേഷൻ അൽഗോരിതം ഇല്ല, UI സെർവറുമായി സിങ്ക് ചെയ്യാൻ imperative JavaScript-ഉം ആവശ്യമില്ല.

ഇത് ആധുനിക ഡെവലപ്‌മെന്റിനെ തള്ളിക്കളയലല്ല. മറിച്ച് അനാവശ്യമായ അബ്‌സ്‌ട്രാക്ഷനുകളെ (abstraction) ഒഴിവാക്കലാണ്. ആധുനിക രീതികളുമായി ചേർത്താൽ, ആദ്യകാല വെബിനെ നയിച്ച ഹൈപ്പർമീഡിയ ശൈലിക്ക് ഇപ്പോഴും സങ്കീർണ്ണമായ ഇന്റർഫേസുകൾ പിന്തുണയ്ക്കാൻ കഴിയുമെന്ന് HTMX തെളിയിക്കുന്നു. ഫോമുകളും ലിങ്കുകളും മാത്രമല്ല, ഏത് എലമെന്റും റിക്വസ്റ്റുകൾ അയക്കാം. ഏത് ഇവന്റും അപ്‌ഡേറ്റ് ട്രിഗർ ചെയ്യാം. ഡാറ്റയ്ക്കും പ്രസന്റേഷനും സെർവർ തന്നെയായിരിക്കും പ്രധാന ഉറവിടം (source of truth).

Chrome-ന്റെ Declarative Partial Updates

രണ്ടാമത്തെ മാറ്റം പുതിയതാണ്, അത് ബ്രൗസറിനുള്ളിൽ തന്നെ സംഭവിക്കുന്നു. Chrome 'Declarative Partial Updates' അഥവാ DPU അവതരിപ്പിക്കുന്നു. ഈ ഫീച്ചർ ഉപയോഗിച്ച് ബ്രൗസറിന് HTML സ്ട്രീം ചെയ്യാനും പേജിന്റെ നിശ്ചിത ഭാഗങ്ങളിൽ നേരിട്ട് ഉൾപ്പെടുത്താനും സാധിക്കും.

DPU-വിന് മുമ്പ്, ഒരു വെബ് പേജിലേക്ക് ലൈവ് ഡാറ്റ സ്ട്രീം ചെയ്യാൻ WebSockets, Server-Sent Events അല്ലെങ്കിൽ long-polling എന്നിവയും മാനുവൽ DOM manipulation-ഉം ഉപയോഗിക്കേണ്ടി വരുമായിരുന്നു. ഫ്രണ്ട്‌എൻഡ് കണക്ഷൻ മാനേജ് ചെയ്യുകയും, പേലോഡ് പാഴ്സ് ചെയ്യുകയും, മാർക്കപ്പ് എവിടെ എങ്ങനെ ഇൻജക്ട് ചെയ്യണമെന്ന് തീരുമാനിക്കുകയും വേണമായിരുന്നു. DPU ഈ പ്രക്രിയയെ declarative ആക്കുന്നതിലൂടെ മാറ്റം വരുത്തുന്നു. ഡെവലപ്പർ ഒരു ടാർഗെറ്റ് കണ്ടെയ്നർ നിശ്ചയിക്കുന്നു, ബാക്കി കാര്യങ്ങൾ ബ്രൗസർ നോക്കിക്കൊള്ളും: സ്ട്രീം സ്വീകരിക്കുക, ഫ്രാഗ്മെന്റ് പാഴ്സ് ചെയ്യുക, ഫുൾ റെസ്പോൺസ് ലഭിക്കുന്നതിന് മുമ്പ് തന്നെ അത് കൃത്യമായ സ്ഥാനത്ത് എത്തിക്കുക.

സെർവർ ലോഗുകൾ കാണിക്കുന്ന ഒരു മോണിറ്ററിംഗ് ഡാഷ്‌ബോർഡോ അല്ലെങ്കിൽ തത്സമയം അപ്‌ഡേറ്റ് ചെയ്യുന്ന ഒരു സപ്പോർട്ട് ക്യൂവോ സങ്കൽപ്പിക്കുക. DPU ഉപയോഗിച്ച്, ബാക്കെൻഡ് HTML കഷണങ്ങൾ (chunks) നിർമ്മിക്കുമ്പോൾ തന്നെ അയക്കുന്നു. ക്ലയന്റ് സൈഡ് സ്ട്രീമിംഗ് ലോജിക് ഇല്ലാതെ തന്നെ ബ്രൗസർ അവ ഒരു ടേബിളിലേക്കോ ഫീഡിലേക്കോ സ്ട്രീം ചെയ്യുന്നു. ഇത് ബ്രൗസറിൽ തന്നെ സ്വാഭാവികമായി നടക്കുന്നു.

സെർവർ-ഫസ്റ്റ് മോഡൽ (The Server-First Model)

HTMX-ഉം DPU-വും സംയോജിപ്പിക്കുമ്പോൾ, സെർവർ സ്റ്റേറ്റ് നിയന്ത്രിക്കുകയും UI നിർമ്മിക്കുകയും ചെയ്യുന്ന, എന്നാൽ ബ്രൗസർ ഡിസ്‌പ്ലേയും യൂസർ ഇൻപുട്ടും കൈകാര്യം ചെയ്യുന്ന ഒരു മികച്ച ആർക്കിടെക്ചർ ലഭിക്കുന്നു. Rails, Laravel, Django, Go templates, അല്ലെങ്കിൽ ASP.NET പോലുള്ള ബാക്കെൻഡ് ഫ്രെയിംവർക്കുകൾ വീണ്ടും പ്രധാന ഇന്റർഫേസ് ലെയറുകളായി മാറുന്നു. ഫ്രണ്ട്‌എൻഡ് എന്നത് ഒരു API ഉപയോഗിക്കുന്ന വെവ്വേറെ ആപ്ലിക്കേഷനല്ല, മറിച്ച് സെർവർ നിർമ്മിക്കുന്ന ഹൈപ്പർമീഡിയ ഇന്റർഫേസാണ്.

ഈ മോഡൽ സോഫ്റ്റ്‌വെയറിന്റെ വിപുലമായ ഒരു വിഭാഗത്തിന് അനുയോജ്യമാണ്. ഒരു സാധാരണ SaaS ആപ്ലിക്കേഷനെ തന്നെ പരിഗണിക്കുക. ക്രമീകരിക്കാൻ കഴിയുന്ന ടേബിളുകളുള്ള ഡാഷ്‌ബോർഡുകൾ, ഫോമുകളും ഫിൽട്ടറുകളുമുള്ള അഡ്മിൻ പാനലുകൾ, റെക്കോർഡുകളെ ഒരവസ്ഥയിൽ നിന്ന് മറ്റൊന്നിലേക്ക് മാറ്റുന്ന ഇന്റേണൽ ടൂളുകൾ, ഒരു ലിസ്റ്റ് കാണിക്കുകയും വിശദാംശങ്ങൾ വെളിപ്പെടുത്തുകയും ഫീൽഡുകൾ എഡിറ്റ് ചെയ്യാൻ ഉപയോക്താവിനെ അനുവദിക്കുകയും ചെയ്യുന്ന CRUD വർക്ക്ഫ്ലോകൾ എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു. ഒരു ലാംഗ്വേജ് മോഡൽ ടോക്കണുകൾ ഉപയോക്താവിന് സ്ട്രീം ചെയ്യുന്ന AI ഇന്റർഫേസുകൾ പോലും ഇതിൽ പെടുന്നു; ഇവിടെ ഓരോ ടോക്കണോ പാരഗ്രാഫോയും HTML ഉപയോഗിച്ച് പൊതിയാനും സംഭാഷണത്തിൽ ചേർക്കാനും സാധിക്കും. ഇവയ്‌ക്കെല്ലാം, ഒരു വലിയ JavaScript ക്ലയന്റ് ഉപയോഗിക്കുന്നത് പലപ്പോഴും അനാവശ്യമാണ്.

ഇതിന്റെ ഗുണങ്ങൾ പെട്ടെന്നുള്ളതും പ്രായോഗികവുമാണ്. ആദ്യത്തെ മിനിമം പേജ് ലോഡ് (meaningful paint) ഒരു ഹൈഡ്രേഷൻ സൈക്കിൾ പൂർത്തിയാക്കിയ ശേഷമല്ല, മറിച്ച് HTML ആയി തന്നെ ലഭിക്കുന്നതുകൊണ്ട് പേജ് ലോഡിംഗ് വേഗത്തിലാകുന്നു. ഇവിടെ ഒരു virtual DOM, ക്ലയന്റ് സൈഡ് റൂട്ടർ, അല്ലെങ്കിൽ സ്റ്റേറ്റ് മാനേജ്‌മെന്റ് ലൈബ്രറി എന്നിവ ആവശ്യമില്ലാത്തതിനാൽ JavaScript പേലോഡുകൾ കുറയുന്നു. സെർച്ച് എഞ്ചിനുകൾക്ക് ബണ്ടിലുകൾ എക്സിക്യൂട്ട് ചെയ്യാതെ തന്നെ പൂർണ്ണമായ ഉള്ളടക്കം കാണാൻ കഴിയുന്നതിനാൽ SEO തനിയെ പ്രവർത്തിക്കുന്നു. റൂട്ടിംഗ്, ബിസിനസ് ലോജിക്, റെൻഡറിംഗ് എന്നിവ ഒരൊറ്റ കോഡ്ബേസ് കൈകാര്യം ചെയ്യുന്നതിനാൽ സങ്കീർണ്ണത കുറയുന്നു. ഡിബഗ്ഗിംഗ് എളുപ്പമാകുന്നു. എന്തെങ്കിലും തെറ്റാണെന്ന് തോന്നിയാൽ, നിങ്ങൾക്ക് Network ടാബ് പരിശോധിച്ചാൽ സെർവർ അയച്ച കൃത്യമായ HTML കാണാൻ സാധിക്കും. റിവേഴ്സ് എഞ്ചിനീയറിംഗ് നടത്തേണ്ട അവ്യക്തമായ ക്ലയന്റ് സൈഡ് സ്റ്റേറ്റ് ഒബ്ജക്റ്റുകൾ ഇവിടെയില്ല.

React-ഉം ഹെവി ക്ലയന്റുകളും എങ്ങനെ?

ഇതൊന്നും React മരിച്ചു എന്നോ SPAs തെറ്റായ തീരുമാനമാണെന്നോ അർത്ഥമാക്കുന്നില്ല. സങ്കീർണ്ണമായ, എഡിറ്റർ നിലവാരത്തിലുള്ള ആപ്ലിക്കേഷനുകൾക്ക് ഇപ്പോഴും ഒരു വലിയ ക്ലയന്റ് ആവശ്യമാണ്. Figma ബ്രൗസറിനുള്ളിൽ WebAssembly-ലേക്ക് കംപൈൽ ചെയ്ത ഒരു C++ എൻജിൻ പ്രവർത്തിപ്പിക്കുന്നു, കാരണം സെർവർ റൗണ്ട്-ട്രിപ്പുകൾ വരയ്ക്കുന്നത് അസാധ്യമാക്കും. Canva ക്ലയന്റ് സൈഡ് ജിയോമെട്ര kullanarak സെക്കൻഡിൽ അറുപത് ഫ്രെയിമുകളുടെ വേഗതയിൽ കാൻവാസ് കൈകാര്യം ചെയ്യുന്നു. Google Docs മിതസൂചകമായ സമയത്തിനുള്ളിൽ എഡിറ്റിംഗ് സംഘർഷങ്ങൾ പരിഹരിക്കാൻ operational transforms ഉപയോഗിക്കുന്നു. ഈ ടൂളുകൾ അടിസ്ഥാനപരമായി ഒരു ബ്രൗസർ ടാബിലൂടെ ലഭ്യമാകുന്ന ഡെസ്ക്ടോപ്പ് ആപ്ലിക്കേഷനുകളാണ്. അവ ഒരിക്കലും സെർവർ റെൻഡർ ചെയ്ത ഫോമുകളിലേക്ക് മടങ്ങില്ല.

എന്നാൽ മിക്ക സോഫ്റ്റ്‌വെയറുകളും Figma പോലെയല്ല. മിക്ക സോഫ്റ്റ്‌വെയറുകളും റിയൽ-ടൈം ഗ്രാഫിക്സ് എഡിറ്ററുകളല്ല. മിക്ക സോഫ്റ്റ്‌വെയറുകളും ഒരു റിപ്പോർട്ടിംഗ് സ്ക്രീൻ, ഒരു കോൺഫിഗറേഷൻ പാനൽ, ഒരു ബുക്കിംഗ് ഫ്ലോ അല്ലെങ്കിൽ ഒരു കണ്ടന്റ് മാനേജ്‌മെന്റ് ഫോം എന്നിവയാണ്. ഇത്തരം ആപ്ലിക്കേഷനുകളുടെ വലിയൊരു വിഭാഗത്തിന്, വെറുമൊരു മോഡൽ ടോഗിൾ ചെയ്യാനോ റെക്കോർഡുകളുടെ ലിസ്റ്റ് എടുക്കാനോ വേണ്ടി നൂറുകണക്കിന് കിലോബൈറ്റ് JavaScript ഫ്രെയിംവർക്ക് ഉപയോഗിക്കുന്നത് ഒരിക്കലും അർത്ഥശൂന്യമായിരുന്നു. സ്റ്റാക്കിന്റെ സാമ്പത്തിക വശങ്ങൾ മാറിക്കൊണ്ടിരിക്കുകയാണ്. എഡ്ജ് (edge) സാങ്കേതികവിദ്യയുടെ സഹായത്താൽ സെർവറിന് ഉപയോക്താവിനോട് കൂടുതൽ അടുത്ത് നിൽക്കാൻ കഴിയുമെന്നും, ഓരോ ബൈറ്റും നിയന്ത്രിക്കാൻ ഒരു ഫ്രെയിംവർക്കിന്റെ ആവശ്യമില്ലാതെ തന്നെ ബ്രൗസറിന് ഭാഗികമായ അപ്‌ഡേറ്റുകൾ നടത്താൻ പ്രാപ്തമാണെന്നും നമ്മൾ വീണ്ടും തിരിച്ചറിയുന്നു.

പെൻഡുലം ഒരു സന്തുലിതാവസ്ഥ കണ്ടെത്തുന്നു

വെബ് ആർക്കിടെക്ചറിന്റെ ഗതി ലാളിത്യത്തിലേക്ക് തിരിഞ്ഞുകൊണ്ടിരിക്കുകയാണ്, എന്നാൽ ഇത് തൊണ്ണൂറ്റഴാം വർഷങ്ങളിലേക്കുള്ള ഒരു മടക്കയാത്രയല്ല. ബ്രൗസർ കൂടുതൽ സ്മാർട്ട് ആയിക്കൊണ്ടിരിക്കുകയാണ്. DPU പോലുള്ള ഫീച്ചറുകൾ ഡെവലപ്പർമാരുടെ സർഗ്ഗാത്മകതയെ ഇല്ലാതാക്കുകയല്ല ചെയ്യുന്നത്; മറിച്ച് സ്ട്രീമിംഗ്, പാർഷ്യൽ അപ്‌ഡേറ്റുകൾ, ടാർഗെറ്റഡ് DOM ഇൻസെർഷൻ എന്നിങ്ങനെ നമ്മൾ കൈകൊണ്ട് നടപ്പിലാക്കിയിരുന്ന രീതികളെ ആ പ്ലാറ്റ്‌ഫോമിനുള്ളിൽ തന്നെ ഉൾക്കൊള്ളുകയാണ് ചെയ്യുന്നത്. ഫ്രണ്ട് എൻഡിൽ ഒരു ചെറിയ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം വീണ്ടും നിർമ്മിക്കാതെ തന്നെ ആ പെരുമാറ്റങ്ങൾ പ്രകടിപ്പിക്കാനുള്ള ഭാഷ HTMX നമുക്ക് നൽകുന്നു.

ലളിതമായ ഒരു ആർക്കിടെക്ചറും മികച്ച യൂസർ എക്സ്പീരിയൻസും തമ്മിൽ ഇനി നിങ്ങൾ തിരഞ്ഞെടുക്കേണ്ടതില്ല. നിങ്ങൾക്ക് രണ്ടും ഒരേപോലെ ലഭിക്കാം. സെർവർ ഇന്റർഫേസ് നിയന്ത്രിക്കാം, ബ്രൗസർ അത് അസംബിൾ ചെയ്യാം, നിങ്ങൾ എഴുതുന്ന JavaScript പ്ലംബിംഗിന് (അടിസ്ഥാന കാര്യങ്ങൾക്കായി) പകരം യഥാർത്ഥ ഇന്ററാക്റ്റിവിറ്റിയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാം.

അടുത്ത തലമുറയിലെ ഡാഷ്‌ബോർഡുകൾക്കും അഡ്മിൻ ടൂളുകൾക്കും AI അധിഷ്ഠിത ഇന്റർഫേസുകൾക്കും വേണ്ടി, ഏറ്റവും കുറഞ്ഞ കാര്യങ്ങൾ മാത്രം ചെയ്യുന്ന ക്ലയന്റായിരിക്കാം ഏറ്റവും ബുദ്ധിപരമായ തിരഞ്ഞെടുപ്പ്.