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

இணைய மேம்பாட்டு உலகம் (web development world), பிரவுசர் தான் கடினமான வேலைகளைச் செய்ய வேண்டும் என்று தன்னைத்தானே நம்பி ஒரு தசாப்தத்தின் பெரும்பகுதியைச் செலவிட்டது. நாம் ஆவணங்கள் மற்றும் படிவங்களுடன் (forms) தொடங்கினோம், பின்னர் ஒவ்வொரு சாத்தியமான செயல்பாட்டையும் படிப்படியாக கிளையண்டிற்கு (client) மாற்றினோம். Routing, state management, data fetching, rendering logic, ஏன் GraphQL மூலம் database query orchestration கூட — இவை அனைத்தும் ஒவ்வொரு வெளியீட்டிலும் கனமடையும் JavaScript bundles-களுக்குள் மாற்றப்பட்டன. Frameworks பெருகின, build pipelines ஆழமடைந்தன, மேலும் செயலிகள் வேகமாகவும் சுறுசுறுப்பாகவும் (snappy) இருக்க வேண்டும் என்பதற்காகத் தொடங்கப்பட்ட இந்த முயற்சி, மெகாபைட் கணக்கிலான குறியீடுகள் (code) பதிவிறக்கம் செய்யப்பட்டு, பகுப்பாய்வு செய்யப்பட்டு, செயல்படுத்தப்படும் வரை ஒரு பக்கத்தால் ஒரு பயனுள்ள பிக்சலைக்கூட உருவாக்க முடியாத ஒரு கட்டமைப்பாக (architecture) மாறியது.

அந்த மாற்றம் உண்மையான சிக்கல்களுக்குத் தீர்வாக அமைந்தது. jQuery கலந்த server-rendered பக்கங்கள், பயனர்கள் எதிர்பார்த்த மென்மையான, ஆப் போன்ற (app-like) மாற்றங்களை வழங்குவதில் சிரமப்பட்டன. Single Page Applications நமக்கு உடனடி வழிசெலுத்தல் (navigation), நிலையான நிலை (persistent state) மற்றும் செழுமையான தொடர்புகளை வழங்கின. ஆனால் அதன் விலை அதிகமாக இருந்தது. குழுக்கள் இப்போது சிக்கலான client-side state stores-களை நிர்வகிக்கின்றன, பிரம்மாண்டமான JavaScript bundles-களைக் கையாளுகின்றன, நுணுக்கமான data synchronization layers-களைப் பராமரிக்கின்றன, மேலும் சில நேரங்களில் ஒரு முழுநேர வேலையைப் போலவே உணர்த்தும் build pipelines-களைப் பிழைத்தறிகின்றன (debug). நாம் ஒரு வகை சிக்கல்களுக்குப் பதிலாக மற்றொரு வகை சிக்கல்களைப் பரிமாறிக்கொண்டோம், மேலும் ஒவ்வொரு பயன்பாடும் அந்த விலையைச் செலுத்த வேண்டுமா என்று இப்போது பல டெவலப்பர்கள் கேட்கிறார்கள்.

அந்தக் கேள்விக்கு விடையளிக்க இரண்டு முன்னேற்றங்கள் உதவுகின்றன.

HTMX மற்றும் Hypermedia-வின் வருகை

முதலாவது HTMX. மேலோட்டமாகப் பார்க்கும்போது இது ஒரு சிறிய லைப்ரரி போலத் தோன்றலாம், ஆனால் அதன் கட்டமைப்பு ரீதியான தாக்கம் மிகப்பெரியது. HTMX, HTML-ஐ JavaScript மூலம் நிரப்பப்பட வேண்டிய ஒரு நிலையான ஓடாக (static shell) கருதுவதற்குப் பதிலாக, பயன்பாட்டு தர்க்கத்திற்கான (application logic) இயல்பான வடிவமாக treats செய்கிறது.

நடைமுறையில் என்ன மாறுகிறது என்பதை இங்கே பார்ப்போம். பாரம்பரியமாக, கூடுதல் கருத்துகளைப் (comments) பதிவிறக்க ஒரு பயனர் பொத்தானைக் கிளிக் செய்யும்போது, frontend ஒரு fetch request-ஐ அனுப்புகிறது, ஒரு JSON payload-ஐப் பெறுகிறது, அதை ஒரு client-side store-ஆக மாற்றுகிறது, ஒரு component template மூலம் இயக்குகிறது, virtual DOM-ஐ ஒப்பிடுகிறது (diffs), மற்றும் இறுதியாகப் பக்கத்தைப் புதுப்பிக்கிறது (patches). HTMX அந்தச் சங்கிலித் தொடரைச் சுருக்குகிறது. அந்தப் பொத்தானிலேயே, கோரிக்கையை எங்கு அனுப்ப வேண்டும் மற்றும் எந்தப் பக்க உறுப்பை மாற்ற வேண்டும் என்று சொல்லும் பண்புகளை (attributes) கொண்டுள்ளது. சர்வர் ஒரு HTML fragment-ஐத் திருப்பித் தருகிறது — ஒரு div-க்குள் சுற்றப்பட்ட புதிய கருத்துகள் மட்டுமே அதில் இருக்கும். பிரவுசர் அதை மாற்றுகிறது. அங்கு JSON இல்லை, frontend state tree இல்லை, reconciliation algorithm இல்லை, மேலும் UI-ஐ சர்வரோடு ஒத்திசைக்க (sync) எந்த கட்டளை சார்ந்த (imperative) JavaScript-உம் தேவையில்லை.

இது நவீன மேம்பாட்டு முறையை நிராகரிப்பதல்ல. இது தேவையற்ற சுருக்கங்களை (unnecessary abstraction) நிராகரிப்பதாகும். நவீன வசதிகளுடன் (modern ergonomics) இணைக்கப்படும்போது, ஆரம்பகால இணையத்திற்கு ஆற்றல் அளித்த hypermedia என்ற கட்டமைப்பு முறை, இப்போதும் அதிநவீன இடைமுகங்களை ஆதரிக்க முடியும் என்பதை HTMX நிரூபிக்கிறது. படிவங்கள் மற்றும் இணைப்புகள் (links) மட்டுமல்ல, எந்த ஒரு உறுப்பும் கோரிக்கைகளை வழங்க முடியும். எந்தவொரு நிகழ்வும் (event) ஒரு புதுப்பிப்பைத் தூண்ட முடியும். தரவு மற்றும் காட்சி ஆகிய இரண்டிற்கும் சர்வரே உண்மையான ஆதாரமாக (source of truth) remains செய்கிறது.

Chrome-ன் Declarative Partial Updates

இரண்டாவது மாற்றம் புதியது மற்றும் அது பிரவுசருக்குள்ளேயே உள்ளது. Chrome, Declarative Partial Updates அல்லது DPU-வை அறிமுகப்படுத்துகிறது. இந்த அம்சம், தரவுகள் (bytes) வந்து சேரும்போதே, HTML-ஐ stream செய்து பக்கத்தின் குறிப்பிட்ட பகுதிகளுக்கு நேரடியாகச் செருக அனுமதிக்கிறது.

DPU-க்கு முன்னதாக, ஒரு வலைப்பக்கத்தில் நேரலைத் தரவை (live data) stream செய்ய விரும்பினால், நீங்கள் பொதுவாக WebSockets, Server-Sent Events அல்லது கைமுறை DOM manipulation உடன் இணைக்கப்பட்ட long-polling முறைகளைப் பயன்படுத்த வேண்டியிருந்தது. Frontend இணைப்பைப் பராமரிக்க வேண்டும், payload-ஐப் பகுப்பாய்வு செய்ய வேண்டும், மற்றும் மார்க்கப்பைப் (markup) புகுத்த வேண்டிய இடம் மற்றும் முறை குறித்துத் தீர்மானிக்க வேண்டும். DPU இந்தச் செயல்முறையை அறிவிப்பு முறையாக (declarative) மாற்றுவதன் மூலம் சமன்பாட்டை மாற்றுகிறது. டெவலப்பர் ஒரு இலக்கு கொள்கலனை (target container) குறிப்பிடுகிறார், மீதமுள்ளவற்றை பிரவுசர் கவனித்துக் கொள்கிறது: stream-ஐப் பெறுதல், fragment-ஐப் பகுப்பாய்வு செய்தல் மற்றும் முழுப் பதிலும் முடிவடைவதற்கு முன்பே அதைச் சரியான இடத்தில் வைத்தல்.

சர்வர் லாகுகளைக் (server logs) காட்டும் ஒரு கண்காணிப்பு டேஷ்போர்டு அல்லது நிகழ்நேரத்தில் (real time) புதுப்பிக்கப்படும் ஒரு சப்போர்ட் கியூவை (support queue) நினைத்துப் பாருங்கள். DPU மூலம், பேக்எண்ட் (backend) உருவாக்கப்பட்டவுடன் சாதாரண HTML துண்டுகளை (chunks) அனுப்புகிறது. கிளையன்ட் பக்கத்தில் எந்த ஒரு streaming logic-உம் இல்லாமலேயே, பிரவுசர் அவற்றை ஒரு table body அல்லது ஒரு feed container-க்குள் stream செய்கிறது. இந்த ஒருங்கிணைப்பு இயல்பாகவே (natively) நடைபெறுகிறது.

Server-First Model

HTMX மற்றும் DPU ஆகிய இரண்டையும் இணைத்தால், சர்வர் நிலையைத் (state) தன்வசம் வைத்துக்கொண்டு UI-ஐ உருவாக்குகிறது, அதே சமயம் பிரவுசர் காட்சிப்படுத்துதல் மற்றும் பயனர் உள்ளீடுகளைக் கையாள்கிறது என்ற ஒரு ஒருங்கிணைந்த கட்டமைப்பைப் பெறலாம். Rails, Laravel, Django, Go templates, அல்லது ASP.NET போன்ற backend frameworks மீண்டும் முதன்மையான இடைமுக அடுக்காக (primary interface layer) மாறுகின்றன. Frontend என்பது ஒரு API-ஐப் பயன்படுத்தும் தனித்தனி பயன்பாடு அல்ல. அது சர்வர் உருவாக்கும் hypermedia இடைமுகமாகும்.

இந்த மாதிரி வியக்கத்தக்க வகையில் பரந்த அளவிலான மென்பொருட்களுக்குப் பொருந்தும். ஒரு பொதுவான SaaS பயன்பாட்டைக் கருத்தில் கொள்ளுங்கள். இது வரிசைப்படுத்தக்கூடிய அட்டவணைகளைக் கொண்ட dashboards ஆகும். இது படிவங்கள் (forms) மற்றும் வடிகட்டிகளைக் (filters) கொண்ட admin panels ஆகும். இது பதிவுகளை (records) ஒரு நிலையிலிருந்து மற்றொரு நிலைக்கு மாற்றும் உள் கருவிகள் (internal tools) ஆகும். இது ஒரு பட்டியலைக் காட்டி, விரிவான பார்வையை (detail view) வெளிப்படுத்தி, பயனரைத் தரவுகளைத் திருத்த அனுமதிக்கும் CRUD workflows ஆகும். ஒரு மொழி மாதிரி (language model) பயனருக்குத் தொடர்ந்து டோக்கன்களை (tokens) அனுப்பும் AI இடைமுகங்கள் கூட இதில் அடங்கும்; அங்கு ஒவ்வொரு டோக்கன் அல்லது பத்தியையும் HTML-க்குள் வைத்து உரையாடல் தொடருடன் இணைக்க முடியும். இவை அனைத்திற்கும், ஒரு கனமான JavaScript client பெரும்பாலும் தேவையில்லாத ஒன்றாகவே இருக்கும்.

இதன் நன்மைகள் உடனடி மற்றும் நடைமுறைக்கு ஏற்றவை. முதல் பயனுள்ள காட்சி (first meaningful paint) HTML ஆகவே கிடைப்பதால், hydration சுழற்சி முடிவடைவதற்காகக் காத்திருக்க வேண்டியதில்லை, இதனால் ஆரம்பப் பக்கப் பதிவுகள் (page loads) வேகமாக இருக்கும். virtual DOM, client-side router மற்றும் state management library போன்றவற்றை அனுப்ப வேண்டிய அவசியம் இல்லாததால், JavaScript payloads குறைகின்றன. தேடுபொறிகள் (search engines) bundles-களை இயக்காமலேயே முழுமையான உள்ளடக்கத்தைப் பார்க்கின்றன, எனவே SEO இயல்பாகவே சிறப்பாகச் செயல்படுகிறது. ஒரே codebase மூலம் routing, business logic மற்றும் rendering ஆகியவற்றைச் செய்வதால் சிக்கல்கள் குறைகின்றன. பிழைத்திருத்தம் (Debugging) எளிதாகிறது. ஏதேனும் தவறு என்று தோன்றினால், நீங்கள் Network tab-ஐப் பார்த்து, சர்வர் சரியாக எந்த HTML-ஐ அனுப்பியது என்பதைத் துல்லியமாகத் தெரிந்துகொள்ளலாம். reverse-engineer செய்ய வேண்டிய தெளிவற்ற client-side state object எதுவும் இருக்காது.

React மற்றும் கனமான Clients பற்றி என்ன?

இதற்கெல்லாம் React அழிந்துவிட்டது என்றோ அல்லது SPAs ஒரு தவறு என்றோ அர்த்தமல்ல. சிக்கலான, எடிட்டர்-தரம் கொண்ட பயன்பாடுகளுக்கு இன்னும் ஒரு கனமான client தேவைப்படுகிறது. Figma உலாவியின் உள்ளே WebAssembly-ஆக மாற்றப்பட்ட C++ engine-ஐ இயக்குகிறது, ஏனெனில் சர்வர் இடையூறுகள் (server round-trips) வரைவதைத் தடையற்றதாக இருக்க விடாது. Canva client-side geometry மூலம் நொடிக்கு அறுபது பிரேம்களில் (sixty frames per second) canvas-ஐக் கையாள்கிறது. Google Docs மில்லி விநாடிகளில் எடிட்டிங் முரண்பாடுகளைத் தீர்க்க operational transforms-ஐப் பயன்படுத்துகிறது. இந்தத் கருவிகள் அடிப்படையில் ஒரு பிரவுசர் டேப் மூலம் வழங்கப்படும் டெஸ்க்டாப் பயன்பாடுகள் ஆகும். அவை மீண்டும் server-rendered படிவங்களுக்குத் திரும்பப் போவதில்லை.

ஆனால் பெரும்பாலான மென்பொருட்கள் Figma போன்றவை அல்ல. பெரும்பாலான மென்பொருட்கள் நிகழ்நேர கிராபிக்ஸ் எடிட்டர்கள் அல்ல. பெரும்பாலான மென்பொருட்கள் ஒரு அறிக்கையிடல் திரை (reporting screen), ஒரு கட்டமைப்பு பேனல் (configuration panel), ஒரு முன்பதிவு முறை (booking flow) அல்லது ஒரு உள்ளடக்க மேலாண்மை படிவம் (content management form) ஆகும். அந்தப் பரந்த அளவிலான பயன்பாடுகளுக்கு, ஒரு modal-ஐ மாற்றியமைக்க அல்லது பதிவுகளின் பட்டியலைப் பெற நூற்றுக்கணக்கான கிலோபைட் JavaScript framework-ஐ அனுப்புவது ஒருபோதும் அர்த்தமுள்ளதாக இருந்ததில்லை. தொழில்நுட்பக் கட்டமைப்பின் (stack) பொருளாதாரம் மாறிவருகிறது. edge தொழில்நுட்பத்தின் உதவியால் சர்வர் பயனருக்கு நெருக்கமாக இருக்க முடியும் என்பதையும், ஒவ்வொரு பைட்டிற்கும் ஒரு framework-ன் தலையீடு இன்றித் துண்டுகளைப் (fragments) புதுப்பிக்கும் அளவுக்கு பிரவுசர் இப்போது வளர்ந்துவிட்டது என்பதையும் நாம் மீண்டும் கண்டறிந்து வருகிறோம்.

ஊசல் ஒரு சமநிலையைக் கண்டறிகிறது

இணையக் கட்டமைப்பின் வளைவு எளிமையைக் நோக்கித் திரும்புகிறது, ஆனால் இது தொண்ணூறுகளுக்குத் திரும்பும் ஒரு அறியாமையல்ல. பிரவுசர் புத்திசாலியாகி வருகிறது. DPU போன்ற அம்சங்கள் டெவலப்பர்களின் புத்திசாலித்தனத்திற்கு மாற்றாக அமையவில்லை; நாம் கைமுறையாகச் செயல்படுத்திய முறைகளை — streaming, partial updates, targeted DOM insertion — அவை அந்தத் தளத்திலேயே உள்வாங்கிக் கொள்கின்றன. HTMX, frontend-இல் ஒரு சிறிய இயங்குதளத்தை மீண்டும் உருவாக்காமலேயே அந்தச் செயல்பாடுகளை வெளிப்படுத்தத் தேவையான மொழியைக் (vocabulary) கொடுக்கிறது.

நீங்கள் இனி ஒரு எளிய கட்டமைப்புக்கும் (simple architecture) மற்றும் வேகமான பயனர் அனுபவத்திற்கும் (responsive user experience) இடையே ஒன்றைத் தேர்ந்தெடுக்க வேண்டிய அவசியமில்லை. நீங்கள் இரண்டையும் பெற முடியும். சர்வர் இடைமுகத்தை (interface) வழிநடத்தலாம், பிரவுசர் அதை ஒருங்கிணைக்கலாம், மேலும் நீங்கள் எழுதும் JavaScript அடிப்படைத் தேவைகளை (plumbing) விட உண்மையான ஊடாடும் தன்மையில் (interactivity) கவனம் செலுத்தலாம்.

அடுத்த தலைமுறை dashboards, அட்மின் கருவிகள் மற்றும் AI மூலம் இயங்கும் இடைமுகங்களுக்கு, மிகக் குறைந்த வேலைகளைச் செய்யும் client-தான் மிகச் சிறந்ததாக இருக்கலாம்.