Hotwire: HTML over the Wire तकनीक

 (hotwired.dev)
2 पॉइंट द्वारा GN⁺ 2024-06-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Hotwire, JSON की जगह HTML भेजकर आधुनिक web app बनाने का एक तरीका है, जो बहुत अधिक JavaScript के बिना तेज़ initial load और responsiveness हासिल करने का लक्ष्य रखता है
  • क्योंकि rendering को server templates में ही रखा जाता है, इसलिए इस्तेमाल की जाने वाली language से स्वतंत्र रहते हुए development flow को सरल बनाए रखा जा सकता है
  • 37signals ने HEY के लिए जो frameworks बनाए, वे मिलकर web से लेकर कई platforms तक फैला हुआ Hotwire ecosystem बनाते हैं
  • इसका मुख्य component Turbo है, जो page transitions, form submissions, component splitting और WebSocket-आधारित partial updates को JavaScript लिखे बिना संभालता है
  • Turbo से पूरी न होने वाली custom interactions को Stimulus पूरा करता है, और Hotwire Native मौजूदा web app के आधार पर native mobile app बनाने देता है

सर्वर पर HTML render करके भेजने का तरीका

  • Hotwire HTML-over-the-wire तरीके से आधुनिक web applications बनाने का एक वैकल्पिक approach है
  • यह JSON की जगह HTML को network पर भेजता है, जिससे बहुत अधिक JavaScript के बिना application बनाए जा सकते हैं
  • इसका लक्ष्य तेज़ first page load, server-side template rendering को बनाए रखना, और अधिक सरल व उत्पादक development experience देना है
  • यह पारंपरिक single-page applications से अपेक्षित speed और responsiveness को छोड़े बिना आगे बढ़ने का तरीका है
  • HTML-over-the-wire को अपने tools बनाने के लिए reference approach की तरह इस्तेमाल किया जा सकता है, या 37signals द्वारा HEY के लिए बनाए गए Hotwire frameworks को वैसे ही इस्तेमाल किया जा सकता है

Turbo, Stimulus, Hotwire Native की भूमिकाएँ

  • Turbo Hotwire का मुख्य component है
    • यह page transitions और form submissions को तेज़ी से संभालने के लिए पूरक techniques देता है
    • यह complex pages को components में बाँटता है, और WebSocket के ज़रिए partial page updates को stream करता है
    • ये सुविधाएँ JavaScript लिखे बिना मिलती हैं
  • Stimulus तब उपयोग होता है जब केवल Turbo से काम न चले और custom code की ज़रूरत हो
    • Turbo आम तौर पर उन interactions में से कम-से-कम 80% संभाल लेता है, जिनके लिए पारंपरिक रूप से JavaScript की ज़रूरत पड़ती थी
    • Stimulus state और connections को HTML-केंद्रित तरीके से संभालने देता है
  • Hotwire Native native mobile app बनाने के लिए web-first framework है
    • यह मौजूदा web app का उपयोग करके mobile app बनाने के लिए ज़रूरी tools देता है

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

1 टिप्पणियां

 
GN⁺ 2024-06-03
Hacker News की राय

  • इस फीचर का कम marketed वर्ज़न htmx है: https://htmx.org/
    एक JavaScript फ़ाइल से ऐसी functionality संभव कर देता है, और मैंने इसे ज़्यादातर Go backend के साथ इस्तेमाल होते देखा है, लेकिन यह काफी flexible लगता है। करीब एक साल से इसे कभी आज़माने की सोच रहा था

    • कम-से-कम Hacker News के लिहाज़ से, मुझे लगता है htmx को कहीं ज़्यादा exposure मिला है
      सिर्फ पिछले एक साल में HN submissions सैकड़ों में हैं 0, और 1000 points से ऊपर जाने वाली पोस्ट भी थीं। इसके उलट Hotwire के पिछले एक साल में 30 से भी कम submissions हैं 1, और उनमें सबसे popular यही लेख है
    • मुझे समझ नहीं आता कि htmx को कम marketed कैसे कहा जा सकता है। Hotwire के बारे में पहली बार सुन रहा हूँ, लेकिन htmx हर जगह बहुत ज़्यादा दिखता है
      YouTube पर ज़रा सा देखने भर से programmer influencers htmx को अपने face thumbnails के साथ लगातार push करते दिखते हैं
    • https://unpoly.com का भी ज़िक्र किया जा सकता है, जिसमें दूसरे features भी शामिल हैं
    • HTMX शायद किसी भी framework से ज़्यादा अच्छी तरह marketed है
      Twitter भी बहुत active है, The Primeagen के YouTube channel पर भी अक्सर आता है, और काफी popular है
    • कम marketed? ऐसा लगता है जैसे हर social platform पर htmx की बाढ़ आई हुई है

  • अगर PHP/Laravel में कुछ ऐसा ही खोज रहे हैं, तो Livewire की ज़ोरदार सिफारिश करूँगा: https://laravel-livewire.com/
    ज़्यादा complex projects के लिए मैं अब भी React इस्तेमाल करता हूँ, लेकिन reactive UI elements बनाए रखते हुए सब कुछ Blade/PHP में लिख पाना हमेशा refreshing लगता है। मुझे याद है कि ऐसा package भी देखा था जो ज़रूरत पड़ने पर Livewire के अंदर React/Vue components render करने देता है: https://minglejs.unitedbycode.com/. existing packages खींचकर इस्तेमाल करने की ज़रूरत पड़े तो यह एक दिलचस्प escape hatch लगता है

  • पहले मैं Hotwire/Livewire को लेकर काफी negative था, लेकिन अब इन्हें context के हिसाब से tools मानता हूँ
    wire पर partial templates भेजना hypermedia approach है, बस आजकल हम hypermedia apps अच्छी तरह नहीं बनाते। htmx और RTF का REST paper दोबारा पढ़ते-पढ़ते मैं यहाँ तक पहुँचा हूँ, और मैं hypermedia को intrinsically superior architecture नहीं मानता, लेकिन यह कई options में एक legitimate peer है, और इसका धीरे-धीरे ही सही, evolve होते रहना अच्छा है

  • React/Vue/Svelte के rabbit hole में गिरे बिना PWA बनाने के सबसे आसान तरीकों में से एक के करीब है
    मैंने वे भी इस्तेमाल किए हैं और उन्हें बेहतरीन मानता हूँ, लेकिन htmx की तुलना में वे technology-centric से ज़्यादा developer-experience-centric लगते हैं। दोनों के बीच competition आखिरकार इस बात पर टिकेगी कि कौन से backend framework के साथ बेहतर integrate होता है

    • अगर mobile app सिर्फ WebView है तो ऐसा हो सकता है। वरना mobile app के लिए REST API और HTML fragments deliver करने वाले Hotwire/Livewire request handlers, दोनों maintain करने होंगे
      व्यक्तिगत रूप से, मैं PWA को client-side problem मानता हूँ; server dependency जोड़ने के बजाय इसे client side पर handle करना चाहिए
    • मुझे जानना है कि यह तरीका बताए गए alternatives की तुलना में कम rabbit hole क्यों है

  • जब यह पहली बार आया था, उसके ज़्यादा करीब 2020 की HN discussion यहाँ है: https://news.ycombinator.com/item?id=25507942

  • ऐसा लगता है जैसे बात लगभग एक पूरा चक्कर लगाकर वापस आ गई है। याद है कि 2005 या 2006 के आसपास हम click को intercept करके parameters जोड़ते थे, सिर्फ rendered HTML fragment वापस लेते थे और .innerHTML से body replace कर देते थे

    • 2000s की शुरुआत में AJAX आने से पहले, Adam Rifkin ने अपने startup KnowNow का demo दिखाया था, और उस समय बिना refresh हुए web page का खुद अपडेट होना चौंकाने वाला था
      तरीका यह था कि HTTP request को लगातार खुला रखा जाए और server कभी-कभी updates भेजे, और वे updates भी HTML ही होते थे। उस समय शायद DOM manipulation भी नहीं कर पाते थे, इसलिए सचमुच यह unclosed tags वाला page रहा होगा
    • इसे एक पूरा चक्कर कहना नहीं, बल्कि यह कहना ज्यादा सही है कि अलग-अलग web UI paradigms अपना scope बढ़ा रहे हैं
      Server-rendering frameworks client interactions को आसान बना रहे हैं, और React RSC के जरिए server rendering को आसान बना रहा है। अगर web app में बहुत ज्यादा interaction है, तो SPA अब भी फायदेमंद है
    • Hotwire या इसी तरह की library ऊपर आती है तो हर बार ऐसी बातें सुनने को मिलती हैं, लेकिन हकीकत में AJAX-based simple CRUD कभी गायब नहीं हुआ
      SPA projects बहुत सारे हैं, लेकिन वे दुनिया की हर website को explain नहीं करते
    • https://animasci.com/ पर भी मिलता-जुलता तरीका इस्तेमाल हो रहा है
      Pagination ऐसे implement की गई है कि scroll नीचे करने और “Show more” दबाने पर server से अगला page HTML fragment के रूप में request किया जाता है, उसे invisible iframe में load किया जाता है, और load पूरा होने पर current page में जोड़ दिया जाता है
    • 2000s के आखिरी वर्षों में मुझे Wicket काफी पसंद था और JavaScript नापसंद थी, लेकिन server पर UI state और templates manage करना team environment में performance और scalability के लिहाज से आसानी से trap बन जाता था
      इस बीच web, JavaScript और TypeScript काफी बेहतर हो गए हैं, इसलिए इस approach को लेकर फिर से excited होना मुश्किल है

  • बहुत ज्यादा interactive frontend की जरूरत वाले web apps पर मैंने ज्यादा काम नहीं किया है, लेकिन e-commerce stores और internal Rails apps में Turbo और Stimulus ने नए developers को सीखने वाली चीजों की मात्रा काफी कम कर दी

    • stack को simple रखा जाए तो यह वैसे भी इतना मुश्किल नहीं था
      उदाहरण के लिए, एक Django project में proven KnockoutJS से office tool पूरा और तेजी से बना लिया था, और यह कुछ हद तक HTMX की spirit से भी मिलता है। अभी शुरुआती stage में मौजूद Arrow.JS भी ऐसा ही है। Complexity, खासकर UI वाली complexity, ज्यादातर खुद बनाई हुई थी; पुराने तरीके बिल्कुल पुराने नहीं पड़े हैं, बल्कि वापस आ रहे हैं। युवा developers की एक पीढ़ी ऐसी है जिसने industry के उस सबसे मूर्खतापूर्ण दौर में शुरुआत की, जब उन्हें यह यकीन दिलाया जा रहा था कि हर web application को जरूरत से ज्यादा complex और झेलने लायक न रहने वाले ढेर में बदलना ही चाहिए
    • Stimulus इस्तेमाल करने के अनुभव से कहूं तो Stimulus बेहद खराब था और मैं इसे फिर कभी इस्तेमाल नहीं करूंगा। Hotwire ठीक था

  • Hey को launch के समय से paid user के तौर पर इस्तेमाल कर रहा हूं, और अगर Hey webapp experience Hotwire का best case है, तो मैं इससे दूर ही रहना चाहूंगा
    धीमे connection पर यह खराब है। हो सकता है developer ने loading states या error states न डाले हों, complexity बहुत ज्यादा हो, या Hey का bug हो। पता नहीं, लेकिन अच्छा नहीं है
    medium से high latency पर इसका behavior unpredictable या bug जैसा लगता है। खाली boxes खुलते हैं, links उम्मीद के मुताबिक काम नहीं करते, और कई actions को तेजी से लगातार करने पर वे intuitive तरीके से cancel नहीं होते। बस सब कुछ mismatch सा लगता है
    SPA चाहे जितना भी खराब हो, यह UI के native और natural महसूस होने की दिशा से एक कदम दूर लगता है

  • यह लेख अभी फिर से इसलिए चर्चा में आया क्योंकि पिछले हफ्ते किसी ने post किया था कि Hey modal खोलने में धीमा है: https://x.com/noahflk/status/1795758603577545035
    Hey को DHH ने बनाया है, और DHH ने Hotwire और Rails भी बनाए हैं। इसके बाद DHH की यह प्रतिक्रिया कि original video restricted network पर शूट किया गया था, यह प्रतिक्रिया कि अगर modal load होने में समय लगता है तो Hotwire network पर बहुत ज्यादा निर्भर है, Rails/Hotwire का बचाव, और इस approach का विरोध—सब मिलकर बड़ी बहस बन गए। पिछले हफ्ते Twitter पर यह बड़ा topic था

    • DHH का यह कहना सही था कि original video restricted network पर शूट किया गया था
      लेखक ने भी लिखा था कि “demo के लिए जानबूझकर धीमा किया गया” था: https://x.com/noahflk/status/1795855075526471915। उसने कहा कि मकसद “SF में अच्छे MacBook और gigabit internet” इस्तेमाल करने वाले व्यक्ति का experience दिखाना नहीं था, बल्कि धीमे mobile internet और सस्ते laptop का इस्तेमाल करने वाले व्यक्ति की बात करना था। यह point भी आया कि Google Calendar SPA इससे कहीं ज्यादा धीमा है, और विकल्प सिर्फ “SF gigabit internet” और “heavily throttled 3G” ही नहीं हैं। Original post बहुत misleading था, और असल में लगभग झूठ जैसा था
    • DHH के direct reply का link: https://x.com/dhh/status/1796163806650868149
    • करीब 1 साल पहले जब मैंने Hey देखा था, तो Pacific के दूसरी तरफ से भी यह काफी responsive लगा था
      खासकर page structure प्रभावशाली था। उदाहरण के लिए, context menu overlay में details/summary/anchor combination को progressive enhancement तरीके से लागू किया गया था, और JavaScript बंद होने या assets load न होने पर भी simple layout में menu content graceful तरीके से आ जाता था। इसके अलावा Web API का सोच-समझकर इस्तेमाल कई जगह था, और client code भी लगभग obfuscate नहीं था और source maps लगे हुए थे, ऐसा याद है। मैं DHH का fan नहीं हूं और उस हफ्ते के drama को follow करने का इरादा भी नहीं, लेकिन इस बार लगा कि 37signals ने सही काम किया
    • यह पहले ही fix कर दिया गया है। Update यहां देखा जा सकता है: https://x.com/dhh/status/1797370923391357143

  • इसी idea को और minimal तरीके से implement करने वाला Swap JS मैंने 2 साल पहले बनाया था: https://github.com/josephernest/Swap
    इसे कुछ projects में इस्तेमाल किया है और यह अच्छे से काम करता है