HN परिचय: ब्राउज़र में 100% लागू किया गया HTMX Playground

 (lassebomh.github.io)
6 पॉइंट द्वारा GN⁺ 2024-01-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बिना installation या local setup के ब्राउज़र के अंदर HTMX experiments तुरंत शुरू करने के लिए एक code sandbox
  • server.js में endpoints और template rendering संभाली जाती है, और HTMX requests को ब्राउज़र के अंदर मौजूद mock server intercept करता है
  • request handling और template का तरीका Django users को परिचित लगेगा, और इसे HTMX के अलावा दूसरी libraries के experiments के लिए भी इस्तेमाल किया जा सकता है
  • sharing “Copy as JSON” से export करने के बाद Gist raw URL को “Load Playground” में डालकर की जाती है
  • page navigation की कमी, सीमित mobile support, और शुरुआती iframe load के कारण on.get("/") state updates खोने की संभावना पर ध्यान देना चाहिए

ब्राउज़र के अंदर चलने वाला HTMX sandbox

  • HTMX Playground एक सरल code sandbox है, जिसमें HTMX को बिना install किए experiment किया जा सकता है
  • यह original htmx.org examples से adapt किए गए examples देता है
  • ब्राउज़र के अंदर backend जैसा flow रखते हुए code लिखा जा सकता है
    • server.js के अंदर endpoints define किए जाते हैं
    • templates को सीधे render किया जा सकता है
    • HTMX से निकलने वाली requests को intercept करने वाला mock server चलता है
  • request handling और template engine Django users को परिचित लगने वाले रूप में हैं
  • project खुद केवल HTMX तक सीमित नहीं है, इसलिए दूसरी libraries भी try की जा सकती हैं
  • code GitHub पर public है

सेविंग, sharing का तरीका और ज्ञात सीमाएँ

  • सेविंग और sharing

    • ऊपर दाईं ओर “Copy as JSON” दबाकर content copy करें
    • copy किए गए content को Gist पर upload करें
    • raw URL को “Load Playground” में enter करें
    • page URL update हो जाए तो उसे share किया जा सकता है

  • सीमाएँ

    • page navigation नहीं है
    • mobile support सीमित है
    • server.js Click to Edit example की तरह state रख सकता है
    • अगर on.get("/") view में state update की जाती है, तो वह update गायब हो सकती है
      • क्योंकि initial page load, स्क्रीन के iframe को update करने से पहले अलग iframe में पहले fetch किया जाता है

  • उपयोग की गई libraries

    • Svelte
    • Ace
    • PollyJS
    • Nunjucks

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

1 टिप्पणियां

 
GN⁺ 2024-01-09
Hacker News टिप्पणियाँ

  • मैं htmx बनाने वाला हूँ, और इसे बनाने के लिए सच में बहुत आभारी हूँ — यह बहुत शानदार लगा

    • सोच रहा हूँ कि HTMX को server-side बदलावों को न्यूनतम रखते हुए इस्तेमाल करने का कोई तरीका है या नहीं
      मौजूदा पेज में फ़ॉर्म भरकर submit करने पर response पूरा पेज बनकर आता है, लेकिन अगर htmx को यह बताया जा सके कि “पूरा पेज वापस आए, लेकिन सिर्फ़ #my-form को update करो”, तो शायद server में “अगर यह htmx request है” जैसी branching डालने की ज़रूरत न पड़े
      यह उन लोगों के लिए अच्छा होगा जो चाहते हैं कि साइट JavaScript के बिना भी काम करे, और comments, mail subscription, like button जैसी कई सुविधाओं को एक ही backend endpoint से संभाला जा सके
    • जानना चाहता हूँ कि क्या आपने Phoenix LiveView के बारे में सुना है, और क्या यह htmx जैसा ही concept है

  • मैंने सोचा था कि HTMX को गंभीरता से अपनाऊँ, लेकिन चिंता है कि developer pool बहुत छोटा है, इसलिए hiring मुश्किल हो सकती है
    मैं Intershop के isml जैसे Thymeleaf-समान proprietary framework का आदी था, और हाल में dedicated frontend developers को रखना आसान होने की वजह से Angular frontend stack की ओर जाने का सोच रहा था
    htmx जैसा तरीका जटिल हो सकता है, developers spaghetti monster से लड़ना नहीं चाहते, और अगर frontend सिर्फ़ HTML बनाए और backend सब कुछ जोड़कर चलाए, तो backend developer bottleneck बन सकता है
    जानना चाहता हूँ कि HTMX ने इस तरह के pitfalls पर विचार किया है या नहीं, और यह उनसे कैसे निपटता है

    • htmx सीखना बहुत intuitive है, इसलिए अगर कोई सिर्फ़ React सीखकर निकले coding bootcamp graduate नहीं है, बल्कि सच में computer science के विषय जानता है, तो वह ज़्यादा से ज़्यादा एक हफ़्ते में productive हो सकता है
    • इसका जवाब काफ़ी सीधा है: HTMX सीखने में आधा दिन भी नहीं लगता, शायद उससे भी कम
      लेकिन HTMX हर situation का हल नहीं है, और ऐसे समय भी आते हैं जब JavaScript framework वाला single-page app चाहिए होता है
    • Angular का ज़िक्र करने के बाद यह कहना कि htmx जटिल हो सकता है, दिलचस्प है; लगता है complexity को लेकर नज़रिया अलग है
      Angular जैसे frameworks structure देते हैं, लेकिन complexity वहीं रहती है — और शायद काफ़ी ज़्यादा भी हो सकती है
      आख़िरकार ज़रूरत ऐसे frontend developer की होती है जिसे web stack — JavaScript, CSS, HTML, browser APIs — अच्छी तरह आता हो; ऐसा व्यक्ति काम के हिसाब से सही tools और frameworks चुन सकता है, और HTMX जैसी चीज़ बहुत जल्दी सीख लेता है
    • सफलता जितनी convincing कोई चीज़ नहीं होती, और htmx 2023 के JS Rising Stars में framework category में दूसरे स्थान पर था
      https://risingstars.js.org/2023/en#section-framework
      यह React के ठीक पीछे था और Vue, Svelte, Angular से आगे, इसलिए उस हिसाब से भविष्य अच्छा दिखता है। हालांकि उम्मीद है कि शुरुआती उत्साह कम होने पर इसकी ranking नीचे आ सकती है
      htmx काफ़ी simple है, इसलिए ज़्यादातर web developers इसे लगभग एक दिन में सीख सकते हैं, लेकिन इसका development style organization को ऐसे full-stack paradigm की ओर धकेलता है जहाँ developer पूरे feature का मालिक होता है; इसलिए सिर्फ़ developers ही नहीं, PMs और architects को भी mindset shift चाहिए
      एक मुफ़्त online book भी है: https://hypermedia.systems
      documentation (https://htmx.org/docs, पढ़ने में लगभग एक घंटा) के अलावा htmx और hypermedia पर दार्शनिक और व्यावहारिक मुद्दों पर लेख भी हैं: https://htmx.org/essays
      htmx के core ideas बहुत कम हैं, और lazy loading जैसे उपयोगी व्यवहार भी दो attributes से लागू किए जा सकते हैं, इसलिए इसे “extensible” बनाने की कोशिश की गई है: https://htmx.org/examples/lazy-load
      साथ ही इसमें events, event filters जैसे hooks और गहरी functionality भी है, इसलिए अगर आप और गहराई में जाएँ तो मनचाहा behavior implement कर सकते हैं
      spaghetti code हर तरह के software development में हमेशा एक जोखिम है, और मुझे व्यक्तिगत रूप से कभी भरोसा नहीं हुआ कि single-page app libraries उससे बचा लेती हैं
      htmx में बेहतर यह है कि effort को backend पर केंद्रित किया जाए, और server-side environment के tools से application को अच्छी तरह विभाजित किया जाए
      चूँकि htmx आपको कोई भी server technology चुनने देता है, इसलिए application logic को व्यवस्थित करने के लिए आपके पास उन single-page apps की तुलना में ज़्यादा विकल्प और paradigms होते हैं, जहाँ frontend में पहले से बड़ा JavaScript/TypeScript app होने के कारण backend भी उसी दिशा में धकेला जाता है
      htmx किन applications के लिए अच्छा विकल्प है, इसे यहाँ भी समझाने की कोशिश की गई है: https://htmx.org/essays/when-to-use-hypermedia/
      कई मामलों में htmx एक अच्छा tool है, लेकिन आख़िरकार यह सिर्फ़ एक tool है, web development का universal solution नहीं
    • hiring में HTMX अनुभव से ज़्यादा backend capability देखी जाती है
      मतलब आप मूलतः ऐसे backend developer को hire कर रहे हैं जो थोड़ा frontend भी कर सके, इसलिए résumé में HTMX होना ज़रूरी नहीं — JavaScript जैसी basics काफ़ी हैं
      ज़्यादातर web developers इस शर्त पर खरे उतरते हैं

  • मैं MapLibre को Django और htmx के साथ इस्तेमाल कर रहा हूँ, और लगता है कि दूसरों के साथ साझा करने के लिए कोई example डालना चाहिए

    • मैंने भी कुछ ऐसा ही करते हुए https://ratethispad.com बनाया था, और इसे बनाना काफ़ी मज़ेदार था
      कोई इसका इस्तेमाल नहीं करता, लेकिन फिर भी उस project को देखना चाहूँगा
    • मेरे पास सार्वजनिक रूप से साझा करने लायक कुछ नहीं है, लेकिन मैं Django, htmx, SQLAlchemy, Plotly के साथ काम कर रहा हूँ और यह काफ़ी solid लगा
    • अगर आप और official examples migrate करना चाहते हैं, तो link के साथ issue बना दें, उसे repository में जोड़ा जा सकता है

  • मेरी जानकारी में Monaco design के हिसाब से mobile पर काम नहीं करता, इसलिए mobile पर Ace इस्तेमाल किया जाता है
    कम-से-कम आख़िरी बार जब मैंने GitHub issue देखा था, तब तक तो यही था
    [0] https://github.com/Microsoft/monaco-editor/issues/246

    • Monaco mobile पर भी ठीक काम कर रहा था; मैंने अभी https://tsdiagram.com पर इसे आज़माया

  • क्या यह ActiveX भी सपोर्ट करता है?

    • यह सोचकर दुख होता है कि मैं इतना बूढ़ा हो गया हूँ कि यह मज़ाक समझ सकता हूँ
    • इससे HP Quality Center याद आ गया
      शुरुआती versions में पूरा UI ActiveX था, और DLL install करने वाली progress bars से भरा हुआ दिखता था

  • Service Worker का इस्तेमाल करके ऐसा कुछ बनाया जा सकता है, और दूसरे tabs में कई pages खोलकर उन्हें browse करने की सुविधा भी दी जा सकती है
    यह शायद इतना मुश्किल नहीं होगा, और page generation के लिए pure JavaScript या यूज़र जो चाहें, वह इस्तेमाल किया जा सकता है

  • यह Svelte में बना है, तो MPA शुद्धतावादी और उनके pitchforks कहाँ गए?

    • मैं MPA शुद्धतावादी हूँ, लेकिन यह भी पूरी तरह मानता हूँ कि कुछ application categories ऐसी हैं जहाँ single-page apps सबसे बेहतर विकल्प होते हैं

  • मुझे htmx का concept पसंद है, इसलिए आज मैंने इसकी किताब पढ़ना शुरू किया, लेकिन जब भी लगता है कि कभी native mobile apps को भी support करना पड़ेगा, तो इसे इस्तेमाल करने में हिचक होती है
    उस स्थिति में शायद सिर्फ frontend ही नहीं, backend का बड़ा हिस्सा भी फिर से लिखना पड़ेगा
    मुझे hyperview.org के बारे में पता है, लेकिन जिन use cases में मेरी दिलचस्पी है, उनके लिए React Native apps पर्याप्त नहीं हैं

  • सोच रहा हूँ कि क्या कोई Service Worker के अंदर परिभाषित virtual server और HTML/HTMX request-response तरीके से offline apps बना रहा है

    • अच्छा सवाल है
      मुझे htmx पसंद है, लेकिन जिन स्थितियों में offline भी काम करना ज़रूरी था, वहाँ मैं इसे इस्तेमाल नहीं कर पाया
      अगर server code को worker के अंदर वैसे का वैसा चलाया जा सके, तो यह कमाल का hack होगा
    • मैं htmx के लिए एक server/backend बना रहा हूँ जो browser के साथ-साथ local service के रूप में चलता है
      सिद्धांततः कोई भी self-hostable server stack इसके लिए काम कर सकता है
      लक्ष्य एक single binary बनाना है जिसमें external services पर कोई dependency न हो, और मैं Go का इस्तेमाल कर रहा हूँ
      self-updating local service, replicated database जैसे components का अच्छा-खासा हिस्सा पहले से तैयार है, और कई operating systems व architectures के लिए cross-compilation भी आसान है
      हर चीज़ को browser में ठूँसने के विकल्प के बजाय, अगर अलग process चलाया जा सकता हो तो यह तरीका काफ़ी व्यावहारिक लगता है
      बस अच्छा होता अगर Go में भी Deno जैसी permission management होती
    • एक वास्तविक example है: https://github.com/jon49/htmx-todomvc
      मैं अपने सभी personal apps में यही pattern इस्तेमाल करता हूँ, बस एक छोटा-सा htmx-जैसा library इस्तेमाल करता हूँ जो मैंने खुद बनाई है
      इसे HTMX में बदलना भी शायद इतना मुश्किल नहीं होगा

  • सोचता हूँ कि HATEOAS को desktop या mobile apps की तरफ़ ले जाना अच्छा विचार होगा या नहीं, लेकिन यह एक दिलचस्प प्रयोग हो सकता है

    • अगर native mobile की बात कर रहे हैं, तो मैंने लगभग 2013 में native code में HATEOAS इस्तेमाल किया था
      यह काम तो करता है, लेकिन web जितना लचीला नहीं है, और हर linkable screen को कड़े black-box तरीके से develop करना पड़ता है
      कोशिश करना दिलचस्प था, लेकिन production में इसकी कितनी कीमत है, इस पर भरोसा नहीं है
    • मैंने HATEOAS को सिर्फ एक abstract concept के रूप में देखा है, लेकिन कभी किसी वास्तविक UI में यह महसूस नहीं किया कि “वाह, user interaction सच में बेहतर हो गया”
      REST ने SOAP monsters को सरल बनाया, इसलिए वह स्वागतयोग्य था, लेकिन उसके साथ काफ़ी dogma भी आया
      मैं REST का मूल उद्देश्य समझता हूँ, क्योंकि यह उपयोगकर्ता के लिए स्वाभाविक concepts, data और service architecture को align करता है
      लेकिन HATEOAS ऐसा ज़्यादा लगता है मानो architecture meetings में और dogma व दिखावा जोड़ने का नतीजा हो, बजाय इसके कि यह इस बात पर केंद्रित हो कि model की वजह से user experience बेहतर होता है या नहीं
      मैं जानना चाहता हूँ कि क्या कोई ऐसा UI example है जो दिखाए कि HATEOAS को guiding principle क्यों होना चाहिए
      मूल रूप से हर page में “अगला क्या करना है” की ओर जाने वाला एक link होता है, और HATEOAS ऐसा लगता है जैसे वही state model REST service calls में लाने का एक चमकदार तरीका हो
    • मुझे तो पहले यही जिज्ञासा है कि HATEOAS अपने-आप में अच्छा विचार भी है या नहीं
    • यहाँ है: https://hyperview.org/