LiveView, Svelte के साथ सबसे बेहतर बैठता है

 (blog.sequin.io)
2 पॉइंट द्वारा GN⁺ 2024-04-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Sequin टीम ने React SPA और शुद्ध Phoenix LiveView दोनों इस्तेमाल करने के बाद यह निष्कर्ष निकाला कि LiveSvelte के साथ LiveView और Svelte को जोड़ने वाला तरीका सबसे अधिक उत्पादक है
  • LiveView सर्वर state और DOM incremental updates के साथ SPA के बिना भी समृद्ध UI बना सकता है, लेकिन जैसे ही client state की ज़रूरत पड़ती है, JS module, hook और LiveView state मिलकर सीमाएँ धुंधली कर देते हैं
  • शुद्ध LiveView के LiveView, LiveComponent, Component में lifecycle, props पास करने और communication के तरीके अलग हैं, इसलिए React की तुलना में refactoring और state placement अधिक झंझटपूर्ण हो जाते हैं
  • LiveSvelte एक स्पष्ट दो-तरफ़ा सीमा देता है, जहाँ Elixir props नीचे भेजता है और Svelte live.pushEvent से events ऊपर भेजता है
  • इस संयोजन में routing, business logic और data preparation सर्वर पर रखे जा सकते हैं, जबकि UI state, animation और conditional rendering Svelte संभालता है, जिससे SPA की जटिलता कम की जा सकती है

LiveView द्वारा दिया गया डेवलपमेंट मॉडल

  • पारंपरिक server-rendered app में सर्वर stateful नहीं होता, और हर client request पर पेज render करता है
  • SPA में client पेज composition संभालता है, backend API के जरिए data पढ़ता-लिखता है, और React के useState जैसे तरीकों से client state manage करता है
  • LiveView में सर्वर पेज rendering की ज़िम्मेदारी बनाए रखते हुए भी state बनाए रखता है, frontend actions को handle करता है, और फिर DOM को SPA की तरह incrementally update करता है
  • SPA की जटिलता इस वजह से बढ़ती है कि client-side JS app व्यवहार में एक frontend microservice की तरह काम करने लगता है
    • frontend-विशेष आवश्यकताओं के कारण backend routes और controllers बढ़ जाते हैं
    • एक request onMount, API call, response parsing, router, auth plug, controller, domain function और response-preparation layer से होकर गुजर सकती है
  • LiveView का फायदा यह है कि frontend microservice के बिना भी समृद्ध client experience बनाया जा सकता है
    • table rendering function के पास ही database query की जा सकती है
    • नई row आने पर उसे table में push किया जा सकता है, और LiveView client को update कर देता है
    • हर request पर पूरा state दोबारा बनाने वाली पारंपरिक server rendering के मुकाबले, यह stateful frontend framework के अधिक नज़दीक इंटरैक्शन देता है

शुद्ध LiveView में आने वाली रुकावटें

  • client-side state से बचना संभव नहीं

    • LiveView सर्वर और user के बीच की round-trip latency से बच नहीं सकता
    • animation, tooltip, DOM दिखाना-छिपाना, form field disable करना जैसे काम कई बार client पर ही संभालने पड़ते हैं
    • दो परस्पर निर्भर dropdown वाले form में, अच्छे UX के लिए पहले dropdown के चुने जाते ही दूसरे dropdown को तुरंत disable करना, फिर सर्वर द्वारा नई सूची भरने के बाद उसे फिर enable करना ज़रूरी होता है
    • इस व्यवहार को केवल LiveView से लागू करने के लिए कई concepts साथ चाहिए होते हैं
      • LiveView का JS module पहले dropdown के बदलने पर दूसरे dropdown को disable करता है
      • hook दूसरे dropdown पर event listener register करता है, और backend से दोबारा enable action भेजा जाता है
      • अगर conditional re-enable चाहिए, तो LiveView state भी शामिल हो सकता है
    • जब JS, hook और LiveView state साथ उपयोग होते हैं, तो DOM state का कुछ हिस्सा LiveView के बाहर रहने लगता है, और एक सुसंगत pattern बनाना कठिन हो जाता है

  • React से अलग state boundary

    • React state और action जैसे मुख्य concepts से अधिकांश transitions संभालता है, और DOM state तथा component state के बीच सीमा अपेक्षाकृत स्पष्ट रहती है
    • क्योंकि client action और client state के बीच latency नहीं होती, React state paradigm के भीतर action और transition दोनों संभाल सकता है
    • LiveView की state server-side होती है, इसलिए client action और server state के बीच की latency को ध्यान में रखना पड़ता है
    • input field के उदाहरण में React में character input होने से पहले state path से गुजरता है, और component हर key input पर फिर render होता है
    • LiveView उस मॉडल के अधिक करीब है जहाँ user पहले input field बदलता है, और थोड़ी देर बाद server state को इसका पता चलता है और वह प्रतिक्रिया देता है
    • latency बहुत कम हो तो यह React जैसा दिख सकता है, लेकिन latency बढ़ने पर दोनों मॉडलों का अंतर स्पष्ट हो जाता है

तीन component प्रकारों से पैदा होने वाली जटिलता

  • LiveView में LiveViews, LiveComponents, Components नाम के तीन component प्रकार होते हैं
  • LiveViews और LiveComponents, React के stateful components के करीब हैं, जबकि Components functional components के करीब हैं
  • LiveView हमेशा top-level parent component होता है, और उसके नीचे LiveComponents और Components render होते हैं
  • React में useState hook जोड़ने या हटाने से stateful component और functional component के बीच आसानी से आया-जाया जा सकता है
    • दोनों props एक ही तरीके से लेते हैं
    • state को छोड़ दें तो feature set समान है
    • DOM event registration और response handling का तरीका भी एक जैसा है
  • LiveView में इन तीन component प्रकारों का अंतर इतना बड़ा है कि LiveView को LiveComponent में refactor करना असुविधाजनक हो जाता है
    • LiveViews और LiveComponents की rendering और props pass करने की syntax अलग है
    • lifecycle अलग है
    • communication options अलग हैं; LiveViews में send और LiveComponents में send_update उपयोग होता है
    • LiveComponents process नहीं होते, इसलिए वे LiveViews की तरह system के दूसरे हिस्सों से interact नहीं कर सकते

LiveComponent की सीमाएँ

  • LiveView एक Elixir process है, इसलिए इसके पास pid, state और inbox होता है, और यह Elixir/OTP system के अन्य processes की तरह काम कर सकता है
  • LiveView में pub/sub का उपयोग करके system-wide changes subscribe किए जा सकते हैं
  • LiveComponent अपनी process नहीं है, बल्कि LiveView द्वारा invoke किया गया module है
  • parent LiveView process child components का state रखती है, इसलिए child LiveComponents के लिए message routing भी LiveView को ही संभालना पड़ता है
  • अगर LiveComponents को स्वतंत्र state management और action handling क्षमता देनी हो, तो हर एक को process होना चाहिए, लेकिन मौजूदा मॉडल ऐसा नहीं है
  • वास्तविक development में LiveComponent को event या action भेजना चाहें, तब भी अच्छा तरीका नहीं मिलता, और send_update को action delivery के लिए इस्तेमाल करें या state patch के लिए, यह अस्पष्ट हो जाता है
    • यदि इसे state patch के लिए उपयोग करें, तो update clause में mount और update को कैसे अलग करें, यह भी सोचना पड़ता है

LiveSvelte जो boundary बनाता है

  • LiveSvelte LiveView के भीतर Svelte components render करने देता है
  • LiveView के render के अंदर Elixir data structures को frontend के लिए plain map में encode करके Svelte component के props के रूप में दिया जा सकता है
  • Svelte component export let से props लेते हैं, और LiveSvelte द्वारा दिए गए live prop के जरिए LiveView से communicate करते हैं
  • Svelte की तरफ से live.pushEvent के जरिए server को event भेजा जा सकता है
    • उदाहरण में Svelte का reactive block form बदलने पर "form_updated" event सर्वर को भेजता है
    • LiveView handle_event("form_updated", ...) में frontend parameters decode करके changeset update करता है
    • changeset validation errors फिर errors prop के जरिए frontend को वापस भेजी जाती हैं
  • data Elixir से props के रूप में Svelte तक नीचे आता है, और Svelte से websocket events के रूप में LiveView तक ऊपर जाता है
  • LiveView process कभी भी props update करके Svelte component को फिर render करा सकती है

LiveView और Svelte संयोजन की मुख्य विशेषताएँ

  • इस संयोजन का मूल बिंदु यह है कि stateful backend process और stateful frontend component साथ में काम करते हैं
  • तीन गुण इस संयोजन को सहारा देते हैं
    • backend frontend component के props को नियंत्रित करता है
    • frontend और backend दोनों state रखते हैं
    • दोनों पक्षों के पास एक निजी दो-तरफ़ा communication channel होता है, जिसमें दोनों पहल कर सकते हैं
  • पहला गुण LiveView की rendering पद्धति से संभव होता है
    • server re-rendering का परिणाम client पर अपने-आप push होकर लागू हो जाता है
    • server JS parent component की तरह component props update कर सकता है
  • दूसरा गुण इस तथ्य से आता है कि LiveView एक Elixir process है
    • Elixir process state को encapsulate करने का तरीका है
  • तीसरा गुण LiveView द्वारा उपलब्ध कराए गए persistent websocket connection से संभव होता है

SPA से अंतर

  • browser routing पूरी तरह backend पर होने से संरचना सरल हो जाती है
    • सामान्य SPA में browser routes और API routes, दोनों प्रकार के routes बनाए रखने पड़ते हैं
  • backend stateful होता है और वर्तमान route तथा जिस resource पर काम हो रहा है, उसे जानता है
    • हर action को state शुरू से दोबारा बनाने के बजाय backend के अपने state change के रूप में संभाला जा सकता है
  • frontend और backend के बीच communication निजी और tightly coupled होता है
    • किसी एक component को support करने वाले RPC calls के लिए server के public routes नहीं बढ़ाने पड़ते
    • client में pushEvent देखकर पता चलता है कि संबंधित handler उसी Elixir module में है जो इसके साथ काम करता है
  • functionality मुख्यतः दो files में बँट जाती है
    • backend module database query जैसे backend functions को call करता है
    • frontend component और style import करता है
    • frontend-backend round-trip API module, router और controller stack से होकर नहीं गुजरता
  • communication steps भी कम हो जाते हैं
    • backend सिर्फ props update करके frontend changes बता सकता है
    • frontend expiry token, timeout या failure handling handlers के बिना pushEvent भेज सकता है
    • websocket खुला हो तो server चल रहा है, और बंद हो तो LiveView global “disconnected” banner दिखाता है

ज़िम्मेदारियों का विभाजन और code structure

  • इस संरचना में frontend microservice हट जाने जैसा व्यवहार होता है
  • business logic backend में रखी जाती है
    • data कैसे load होगा
    • कौन-सा data लाना है
    • sorting और filtering कैसे होगी
    • validators
  • Svelte frontend code सरल हो जाता है
    • conditional rendering के लिए if/end blocks
    • animations
    • server को भेजने के लिए सरल pushEvent functions
  • सामान्य SPA frontend में server data processing, display data preparation और server-send data preparation के लिए map, reduce, filter logic बहुत बढ़ सकता है
  • LiveSvelte app में यह processing server-side की जा सकती है
    • LiveView data को उसी रूप में तैयार करता है जिसकी Svelte component को ज़रूरत है
    • जटिलता server language, server data structures और server test suite के भीतर रहती है
  • LiveView और Svelte component दो loosely coupled elements से अधिक, एक feature के दो हिस्सों के करीब होते हैं
    • LiveView केवल उसी Svelte component को render करता है
    • वह Svelte component केवल उसी LiveView द्वारा render किया जाता है

शुद्ध LiveView की तुलना में क्या बदलता है

  • LiveSvelte तरीका frontend की state और state transitions को स्वीकार करता है
  • frontend और backend के बीच boundary स्पष्ट हो जाती है
  • Svelte के mature component paradigm का लाभ लिया जा सकता है
  • वह JavaScript framework ecosystem भी इस्तेमाल किया जा सकता है, जिस तक केवल शुद्ध LiveView से पहुँचना कठिन है
    • Svelte animation primitives देता है
  • अधिक ज़िम्मेदारी frontend पर ले जाकर उस अटपटे बीच के क्षेत्र की भावना कम हो जाती है

Svelte चुनने का कारण और LiveView की भूमिका

  • LiveSvelte चुनने का कारण यह था कि React के लिए इसी स्तर का परिपक्व LiveView library उपलब्ध नहीं था
  • Svelte को default state और reactivity के मामले में हल्का और तेज़ frontend framework माना जाता है
  • क्योंकि state management का बड़ा हिस्सा LiveView संभालता है, Svelte की तरफ state management सरल बना रहता है
  • Svelte की template features भी React की तुलना में अधिक पसंद की गईं
    • ternary operator की जगह if/else उपयोग किया जा सकता है
    • conditional attribute setting का उपयोग किया जा सकता है
  • Svelte 5 के runes से उम्मीद है कि Svelte को सीखना और उसके बारे में reasoning करना और आसान होगा
  • LiveView frontend component render करने, incremental updates करने, stateful backend process बनाए रखने और websocket API देने वाले backend-for-frontend के रूप में सबसे अधिक चमकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-05
Hacker News की रायें

  • मल्टीप्लेयर गेम्स में अक्सर इस्तेमाल होने वाला पैटर्न मूल रूप से क्लाइंट और सर्वर दोनों तरफ वही कोड चलाना है
    क्लाइंट कोड सर्वर की state का अनुमान लगाकर पहले चल जाता है, और जब सर्वर state आती है तो क्लाइंट state को overwrite कर देता है
    गेम्स में क्लाइंट अपने input के नतीजे का काफी अच्छा अनुमान लगा सकता है, लेकिन दूसरे players के input नहीं जानता, इसलिए “prediction” शब्द ठीक बैठता है
    लेकिन यह तरीका dropdown को enable/disable करने या loading spinner जैसे मामलों में official server state का इंतज़ार करते हुए तुरंत react करने के लिए भी इस्तेमाल किया जा सकता है
    particle system या ragdoll जैसी बहुत-सी client state ऐसी भी होती हैं जिन्हें सर्वर पर चलाने की ज़रूरत ही नहीं होती, और अगर लगातार server connection मौजूद है तो reactive paradigm में भी इसके न चलने की कोई वजह नहीं दिखती

    • https://territoriez.io/ में ठीक यही तरीका इस्तेमाल किया गया था
      यह https://generals.io/ का clone है और LiveSvelte से बनाया गया है
      असल में यह board game है और प्रति सेकंड 2 ticks पर चलता है, इसलिए prediction feature की ज़रूरत नहीं, लेकिन server update से पहले game state दिखाने वाले optimistic updates इस्तेमाल करता है
      अगर server के साथ sync नहीं बैठता, तो server game state को overwrite कर देता है
      game logic पूरी तरह Elixir में है, और prediction को सही ढंग से करने के लिए server और client को logic share करना होगा
      वरना logic दो बार लिखना पड़ेगा, और वह तबाही की तरफ जाने वाला रास्ता है
      मैंने इसकी पड़ताल नहीं की, लेकिन एक संभावित समाधान यह है कि पूरी game logic gleam(https://gleam.run/) में लिखी जाए
      Gleam, Elixir के साथ compatible है और JavaScript में भी compile हो सकता है, इसलिए सिद्धांततः वही code server और client पर चलाया जा सकता है
      हालांकि “बस सब कुछ js में लिख दो” कहना भी काफी हद तक सही बात है, और शायद मैं भी सहमत हो जाऊं
      फिर भी इससे मिलने वाला फायदा BEAM और real-time distributed systems के लिए अच्छी सुविधाओं का इस्तेमाल कर पाना है, जो frontend को छोड़ दें तो multiplayer games के लिए बिल्कुल फिट हैं
    • Overwatch जैसे games खेलते समय, जहां ragdoll physics को locally non-deterministically simulate किया जाता है, तो मन करता है कि काश यह ठीक से किया गया होता
      कोई मरकर जब corpse उड़ जाता है या किसी मज़ेदार pose में फंस जाता है, तो कोई और उसे देख ही नहीं पाता, और replay में भी हर client अलग तरह से render करता है, इसलिए उसे फिर से नहीं देखा जा सकता
      अगर real-time recording में capture न हो तो वह हमेशा के लिए गायब हो जाता है
      Overwatch जैसे कभी-कभी बेहद हास्यास्पद game में यह अफसोसजनक है कि कोई और उसे साथ में नहीं देख पाता
    • fighting games इस तरह की low-latency conflict resolution समस्या को चरम तक ले जाते हैं, और real-time event streams को adjust करने वाली “netcode” techniques का अपना अलग subfield है
      https://arstechnica.com/gaming/2019/10/explaining-how-fighti... इसकी शानदार व्याख्या है, और संबंधित चर्चा https://news.ycombinator.com/item?id=34399790 और https://news.ycombinator.com/item?id=26289933 पर है
      MMO जैसी server persistence जुड़ जाए तो input/output bottleneck पर भी साथ में विचार करना पड़ता है
      https://prdeving.wordpress.com/2023/09/29/mmo-architecture-s... उस नजरिए से दिलचस्प लेख है, और चर्चा https://news.ycombinator.com/item?id=37702632 पर है
    • क्या यह बस optimistic updates नहीं है? client-side logic में यह बहुत पहले से आम तरीका नहीं रहा है क्या
    • इसे सावधानी से इस्तेमाल करना चाहिए
      उदाहरण के लिए, कोई live/interactive form page के derived data को update करते हुए ऐसा दिखे कि सब ठीक चल रहा है, लेकिन बाद में server error या network problem की वजह से सब rollback हो जाए, तो मुश्किल होगी
      इससे भी बुरा, user यह जाने बिना page बंद कर सकता है या कहीं और navigate कर सकता है

  • मुझे LiveView + Svelte combination पसंद है
    ElixirConf 2022 में मैंने दोनों को जोड़ने का तरीका present किया था, लेकिन live_svelte contributors ने इसे सच में usable बनाया
    मेरा मानना है कि rich user experience वाले apps में हमेशा client-side state की ज़रूरत होती है
    खासकर New York में रहते हुए, चलते-फिरते network connection को guaranteed नहीं माना जा सकता
    लेख में शामिल न की गई एक powerful capability यह है कि Phoenix के pubsub का इस्तेमाल करके दूसरे servers पर हुई server-side state changes को भी सभी clients तक reactively push किया जा सकता है
    medium से ऊपर traffic संभालना हो तो कई web servers रखना काफी आम है

    • mobile networks में भी कुल मिलाकर latency ज्यादा होती है, और client पर local-first caching system की अक्सर ज़रूरत पड़ती है
      अगर आप LiveView जैसा user experience चाहते हैं लेकिन unstable network भी झेलना चाहते हैं, तो मैंने Triplit[1] में Svelte 5 bindings जोड़े हैं
      client side पर queries लिखकर websocket के जरिए server के साथ sync किया जा सकता है
      Elixir developers के लिए यह बहुत आकर्षक न हो सकता है, लेकिन अगर Svelte केंद्र में है तो Triplit एक अच्छा विकल्प है
      [1] https://www.triplit.dev/docs/frameworks/svelte
    • network intermittently कटने की स्थिति में LiveView page offline होने पर कितना usable रहता है?

  • जब नई row आए तो उसे बस table में push करके LiveView को client update करने देना—ऐसे तरीके से उन business apps में बचना बेहतर है जहाँ rows interactive होती हैं
    cognitive delay की वजह से user के गलत item पर click करने, गलत customer को email भेजने, या गलत transaction refund करने की संभावना बढ़ जाती है
    बेहतर user experience एक fixed banner है, जैसे “Data बदल गया है। refresh करने के लिए यहाँ click करें”
    अगर जल्दी हो, तो नई rows को append-only तरीके से render करें और scroll position बदलने न दें

    • अगर नई line को धीरे-धीरे animation से डालें, और नया data आते समय clicks disable कर दें, तो यह तरीका भी चल सकता है

  • BeaconCMS में Svelte और LiveView को साथ इस्तेमाल कर रहे हैं
    client पर UI को ज्यादा fine-grained control करने के अच्छे use cases निश्चित रूप से हैं, लेकिन team को हर चीज़ पर Svelte + LiveView पूरी तरह लागू करने में सावधानी रखनी चाहिए
    Phoenix में भी LiveView हमेशा जवाब नहीं होता, कभी-कभी normal rendered page ही काफी होता है
    हर चीज़ को all-or-nothing के रूप में नहीं चुनना चाहिए
    लेख में जैसा कहा गया है, “LiveView way” से बाहर जाने लायक अच्छे use cases हैं
    अगर round-trip time 1,000ms है तो दूसरी चीज़ों पर भी विचार करना होगा, लेकिन cost जैसी वजहों से कुछ teams geographically पास server नहीं रख पातीं, इसलिए client-side state management समाधान हो सकता है

  • client state manage करने के बजाय client और server दोनों की state manage करने की बात है?
    एक और API न बनानी पड़े, यह फायदा हो सकता है, लेकिन यह सुधार जैसा नहीं लगता

    • web application की state इतनी simple नहीं होती
      हमेशा कुछ state होती है जिसे client को track करना होता है और कुछ state जिसे server को track करना होता है, और इसके ऊपर in-memory ही रहने वाली temporary state और sessions के बीच बनी रहने वाली state overlap करती है
      इसे manage करने के तरीके लगभग अनंत हैं, और JavaScript में “कुछ भी करो, कोई सही जवाब नहीं” जैसी स्थिति होने से framework द्वारा तय तरीका अपनाना पड़ता है या ad-hoc यानी chaos से काम चलाना पड़ता है
      आखिरी complex single-page app में, जिस पर मैंने काम किया था, client से हर page load पर synchronization कराया था
      हर local state या asset के साथ date-based hash लगा था, और अगर वह server की value से अलग होता तो server updated version भेज देता था
      चाहे simple variable हो, बड़ा JSON object हो, या पूरा image/audio blob—सब पर यही लागू था
      अगर client कोई ऐसा काम करता जिसके लिए server state change चाहिए, तो वह state update WebSocket से भेजता था, और app का 99% हिस्सा WebSocket-based था
      कोई खास framework या pattern इस्तेमाल नहीं किया; code लिखते समय अगर लगता “इसे server को track करना चाहिए”, तो नई state server को message के रूप में भेज देते और page load पर sync करना है या नहीं, यह server तय करता
      इस तरह के state management में मेरे हिसाब से यह लगभग सबसे simple mechanism है
      WebSocket state management में सचमुच बहुत मदद करता है
    • आखिर में लगता है कि इस paradigm का कोई न कोई रूप जीतेगा
      वास्तविक applications को client और server दोनों तरफ state चाहिए होती है
      server client पर भरोसा नहीं कर सकता, इसलिए उसके पास authoritative state होनी चाहिए, लेकिन client को भी round-trip के बिना user interaction पर react करके re-render कर पाना चाहिए
    • कुछ चीज़ों को पूरी तरह client-side पर संभालना बेहतर experience देता है
      सब कुछ ऐसे न करें, बस जब बात बनती हो तभी इस्तेमाल करें
      एक और बात जो पसंद है वह यह कि Heex की जगह Svelte को template language की तरह इस्तेमाल कर सकते हैं
    • यह नई generation द्वारा ColdFusion, Web Forms, JSF, PHP, Spring, Rails को फिर से खोजने जैसा है
    • यह दूसरे software ecosystems में होने वाली optimization से अलग नहीं है
      जरूरत न हो तो करने की वजह नहीं है, और जरूरत पड़ने की वजह performance और user experience होती है
      अगर web application में user interactions बहुत हैं, इसलिए client JavaScript चाहिए, और experiments बहुत हैं इसलिए हर request पर bundle बदलता है, तो client को भेजे जाने वाले JavaScript की मात्रा घटाने के लिए logic को server और client में बाँटना चाहेंगे
      वरना application जिन सभी संभावित cases से मिल सकता है, उन सबको समेटे MB-sized JavaScript bundle मिलेगा
      Photoshop के web version जैसी app में, जहाँ users initial loading time समझते हैं, यह ठीक हो सकता है, लेकिन Stripe या Gmail जैसी apps में, जहाँ तुरंत load होने की उम्मीद होती है, page की initial delay घटाना चाहेंगे
      सब कुछ server पर भी ले जा सकते हैं, लेकिन GitHub ने जैसा झेला, तुरंत प्रतिक्रिया माँगने वाले user actions server round-trip पर निर्भर हो जाते हैं और page interactivity खराब होती है
      तब speed of light और server distribution समस्या बन जाते हैं
      async import जैसी चीज़ों से bundle को lazy-load भी कर सकते हैं, लेकिन lazy-loaded JavaScript अपने data को fetch करने के लिए फिर request भेजता है और waterfall problem पैदा होती है
      जब ये सारी समस्याएँ सामने आती हैं, तो आखिर में client और server के बीच logic/state sharing वाली complex समस्या को आसान बनाने वाला समाधान ढूँढना पड़ता है

  • इस approach में “server user के कितना पास हो सकता है, इसकी सीमा है” वाली बात सचमुच speed-of-light limit है
    अगला कदम server को WebAssembly में compile करके client को भेजना है
    तब real server response का इंतजार करते समय optimistic रूप से response render किया जा सकता है
    सुनने में थोड़ा पागलपन लगता है, लेकिन एक real project में यह कर चुके हैं और यह जादू जैसा था

    • persistence का क्या? backend का core purpose तो वही मानता हूँ
      client पर server चलाने से भी वह हल नहीं होता, और आखिर में persistence की network latency बनी ही रहती है
      अंततः जीतनी वाली server state भी वही persistence है
    • overengineering जैसा लगता है
      बिना खास वजह के भी बहुत-सी overengineering असल में implement हो जाती है
    • बस Service Worker क्यों नहीं इस्तेमाल कर सकते?
    • क्या और details share कर सकते हैं?
    • यह modern multiplayer games में होने वाली client-side prediction से काफी मिलता-जुलता लगता है

  • LiveSvelte बनाया है, इसलिए अगर कोई सवाल हो तो बताइए

    • अगर LiveSvelte इस्तेमाल करें, तब भी JS Hooks इस्तेमाल करने की कोई वजह होगी?

  • कुल मिलाकर, मैं हमेशा इसी मॉडल से ऐप बनाना चाहता था
    इवेंट-ओरिएंटेड, सर्वर के साथ दो-तरफा real-time updates, क्रमबद्ध events, local/remote state—कुछ इसी तरह
    मुझे LiveView के बारे में पता नहीं था और मैंने Erlang परिवार की भाषाएँ भी कभी नहीं इस्तेमाल कीं, लेकिन यह निश्चित रूप से कुछ सही पकड़ रहा है
    पारंपरिक request-response मॉडल consistency और stale data से जुड़ी समस्याएँ सूक्ष्म रूप से और अक्सर पैदा करता है
    अगर पिछले 10 साल functional programming concepts को mainstream languages में मिलाने का दौर थे, तो अच्छा होगा कि अगले 10 साल stateful message-oriented programming को mainstream full-stack में मिलाने की दिशा में जाएँ

    • JavaScript(http://liveviewjs.com), Go(https://github.com/canopyclimate/golive), Java(https://github.com/floodfx/undead), Python(https://github.com/ogrodnek/pyview) में लिखे LiveView backends मौजूद हैं
      संदर्भ के लिए, पहले तीन मैंने बनाए हैं या बनाने में मदद की है
    • asdf से erlang/BEAM/OTP और elixir इंस्टॉल किए जा सकते हैं, और अगर आपको tools इस्तेमाल करने का थोड़ा अनुभव है तो इसमें कुछ ही मिनट लगेंगे
      guide follow करते हुए थोड़ा हाथ आज़माएँ, तो करीब दो घंटे के भीतर browser में चलने वाला एक बेसिक Phoenix chat app खड़ा कर पाएँगे
    • “stateful message-oriented, या reactive programming को mainstream full-stack में integrate करना” Rails द्वारा शब्द को फिर से परिभाषित करने से पहले MVC भी कहलाता था

  • यह अच्छा समाधान है
    अपने ऐप में मैं LiveView के साथ reusable Stimulus controllers इस्तेमाल कर रहा हूँ, और यह भी smoothly काम करता है
    कुल मिलाकर LiveView के साथ development मज़ेदार है, लेकिन real scenarios में जितना ज़्यादा इस्तेमाल करता हूँ, Hotwire जैसे stateless HTTP frameworks के फायदे भी उतने ही महसूस होते हैं
    वे ज़्यादा performant और reconnect के मामले में मजबूत लगते हैं, और reliability के लिए user के पास ज़्यादा servers deploy करने की जरूरत भी कम होती है

    • जब Stimulus/Turbo पहली बार announce हुए थे, तो मुझे काफी उम्मीद थी कि वे लेखक द्वारा बताए गए issues हल करने में मदद करेंगे
      लेकिन Stimulus client पर state बनाए रखने का कोई elegant तरीका नहीं देता
      यह कुछ ऐसा है कि “Stimulus application की state DOM attributes के रूप में रहती है”, इसलिए यह vanilla JS या jQuery से बेहतर नहीं है
      मैंने असली project में Stimulus इस्तेमाल नहीं किया है, इसलिए संभव है कि values और change callbacks का अनुभव मेरी शुरुआती सोच से बेहतर हो
    • मैं भी Stimulus और LiveView साथ में इस्तेमाल करता हूँ
      इस combination में complexity का स्तर बिल्कुल सही है, और Svelte को LiveView के साथ इस्तेमाल करने पर लगता है कि वह ऐसी कई चीज़ों से भी निपट रहा है जो शुरू से समस्या ही नहीं थीं
      ज़रूरत vanilla JS या उसके ऊपर एक thin layer की है, पूरे framework की नहीं
      वैसे भी बहुत JavaScript लिखने की जरूरत नहीं पड़ती
      production में चल रहे ऐप का JS 200 lines से ज़्यादा नहीं है, और कुछ Stimulus controllers शायद हटाए भी जा सकते हैं
      LiveView इतना अच्छा है
      मैंने एक Stimulus-LiveView hook adapter भी काफी hacky तरीके से बनाया, ताकि Stimulus controllers सीधे LiveView process को events भेज सकें
      और अगर LiveView ने fly.io-style Kool-Aid बहुत ज़्यादा नहीं पी है, तो उसे geographically distributed servers की अनिवार्य जरूरत नहीं होती
      यह disconnects को भी शानदार तरीके से handle करता है
      zero-downtime updates support करने के लिए मुझे अलग से कुछ भी नहीं करना पड़ा
      client का WebSocket connection खोना, नए version से reconnect करना और state restore करना—यह सब default रूप से अपने आप handle हो जाता है
      और क्या चाहिए?

  • हमारी कंपनी को LiveView और Alpine साथ इस्तेमाल करने से बड़ा फायदा मिला है, खासकर क्योंकि client पर eval allow नहीं कर सकते, इसलिए हम CSP mode इस्तेमाल करते हैं
    जब मैंने पहली बार LiveSvelte देखा था, तो वह बहुत नया और कम validated लगा था, और strict CSP environment में कुछ unresolved impacts भी थे
    अब यह काफी उपयोगी हो गया लगता है, यह देखकर खुशी है
    हमारे pattern को मोटे तौर पर LiveAlpine कहा जा सकता है
    अगर component को HTML चाहिए तो HTML Component इस्तेमाल करते हैं, और server-side state हो तो Live Component इस्तेमाल करते हैं
    अगर client-side behavior या state चाहिए तो Alpine component भी define करते हैं
    अगर server पर client events receive करने हों या HTTP requests करनी हों तो Phoenix Hook भी define करते हैं