24 पॉइंट द्वारा GN⁺ 2025-12-29 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • वेब पर JS-निर्भर फीचर्स को HTML/CSS से बदलने के आधुनिक तरीकों का परिचय
  • details·summary, datalist, popover जैसे standard elements का उपयोग करके accordion, autocomplete, modal और offscreen navigation लागू करना
  • यह तरीका download·evaluation·memory usage को कम करके performance और user experience को बेहतर बनाता है
  • हर फीचर के लिए CodePen उदाहरण, MDN docs, browser compatibility जानकारी साथ में दी गई है
  • JS का उपयोग केवल वहीं करना चाहिए जहाँ उसकी वास्तव में ज़रूरत हो, और HTML/CSS की विकसित क्षमताओं का सक्रिय उपयोग करना चाहिए

HTML और CSS से JS फीचर्स का विकल्प

  • लंबे समय तक JavaScript उन फीचर्स के लिए ज़िम्मेदार रहा है जिन्हें HTML और CSS से लागू नहीं किया जा सकता था
    • लेकिन HTML और CSS की क्षमताएँ बढ़ने के साथ, कुछ JS फीचर्स को अब native web technologies से बदला जा सकता है
  • JS को download, decompress, evaluate और memory में बनाए रखना पड़ता है, इसलिए जहाँ संभव हो फीचर्स को HTML/CSS में स्थानांतरित करना अधिक प्रभावी है
  • दिशा यह है कि JS जटिल logic पर फोकस करे, और सरल UI control को HTML/CSS को सौंप दिया जाए

Accordion / expandable content panel

  • details और summary elements से बिना JS के accordion बनाया जा सकता है
    • content को click करके खोला और बंद किया जा सकता है, और open attribute से default state तय होती है
    • एक ही name attribute इस्तेमाल करने पर एक समय में केवल एक panel खुला रहेगा
  • CSS से styling की जा सकती है या JS से open/close state को control भी किया जा सकता है
  • संबंधित सामग्री: MDN details docs, CodePen उदाहरण, browser compatibility table

Autocomplete suggestion input

  • input और datalist के संयोजन से auto-filtering dropdown बनाया जा सकता है
    • टाइप करते समय suggestion list अपने आप filter होती है
    • text के अलावा number, time जैसे कई input types भी समर्थित हैं
  • Firefox अभी केवल text-based input को support करता है, और mobile accessibility की कुछ सीमाएँ हैं
  • संबंधित सामग्री: MDN datalist docs, SitePoint tutorial, browser compatibility table

Modal / popover

  • popover और popovertarget attributes से बिना JS के modal और popover लागू किए जा सकते हैं
    • auto, hint, manual ये तीन modes उपलब्ध हैं
    • auto बाहरी click या ESC से बंद हो जाता है, जबकि manual केवल manually बंद होता है
  • Firefox और iOS में hint mode समर्थित नहीं है
  • संबंधित सामग्री: MDN popover docs, Chrome blog, CodePen उदाहरण, accessibility से जुड़ा वीडियो

Offscreen navigation / content

  • popover फीचर का उपयोग करके offscreen navigation menu बनाया जा सकता है
    • अर्थपूर्ण संरचना के लिए nav element का उपयोग, और CSS translate से उसे स्क्रीन के अंदर-बाहर ले जाना
    • बाहरी click पर यह बंद हो जाता है, और popover="manual" से manual close सेट किया जा सकता है
    • ::backdrop pseudo-element से background को semi-transparent बनाया जा सकता है
  • संबंधित सामग्री: MDN Popover API, Chrome blog, CodePen उदाहरण

निष्कर्ष

  • JS की ताकत को मानते हुए भी, इसे केवल ज़रूरी जगहों पर ही इस्तेमाल करना चाहिए
  • हालिया HTML/CSS प्रगति के कारण JS-रहित कई विकल्प उभरकर आए हैं
  • और अधिक उदाहरण लेखक की ब्लॉग पोस्ट “Replace JS with No-JS or Lo-JS Options” में देखे जा सकते हैं
  • JS को न्यूनतम रखना और performance optimization के ज़रिए user experience बेहतर बनाने पर ज़ोर

5 टिप्पणियां

 
skageektp 2025-12-29

** और ** एलिमेंट्स से बिना JS के accordion इम्प्लीमेंट किया जा सकता है

लगता है जैसे कुछ कंटेंट कट गया है

 
xguru 2025-12-29

मैंने इसे संशोधित कर दिया है~!

 
shakespeares 2025-12-29

सीमाएँ तो साफ़ दिखती हैं, और जिस पल AI सक्रिय हो गया.. क्या ऐसी refactoring करने की ज़रूरत होगी? JS content blocking जैसी बातों को ध्यान में रखा गया है क्या?

 
GN⁺ 2025-12-29
Hacker News की राय
  • यह अफ़सोस रहा कि सभी examples को inline नहीं रखा गया
    CodePen links की जगह HTML alternatives के examples सीधे पेज पर डाले होते तो बात कहीं ज़्यादा convincing लगती
    • पूरी तरह सहमत हूँ। अक्सर FooMaker v1.0 जैसी किसी चीज़ पर क्लिक करो तो सामान्य usage examples नहीं मिलते, बस अजीब exception cases ही दिखते हैं
    • मुझे पहले लगा यह 25 साल पुरानी पोस्ट है। Dithered GIF पूरी तरह retro vibe दे रहा है
    • मुझे भी inline examples न होने से झुंझलाहट हुई, लेकिन अगर यह guest blog post है तो कुछ हद तक समझा जा सकता है
  • <details> / <summary> tags की potential सच में कमाल की है
    इनसे लगभग सब कुछ किया जा सकता है, लेकिन ज़्यादातर component libraries इन्हें नज़रअंदाज़ करती हैं
    aria attributes की भी ज़रूरत नहीं पड़ती और accessibility भी built-in मिलती है
    • पहले cmd+f search से बंद details के अंदर का text नहीं मिलता था, यह कमी थी, लेकिन अब hidden="until-found" attribute और events से इसे संभाला जा सकता है
    • लेकिन animation handling अब भी मुश्किल है। display transition के लिए browser में built-in support नहीं है
    • ctrl+f से search करने पर details अपने-आप खुल जाने वाला feature भी है
    • <details> GitHub जैसी Markdown-आधारित sites पर भी काम करता है। लंबे logs को fold करके साफ़-सुथरे ढंग से पोस्ट किया जा सकता है
    • इसे pure CSS से भी बनाया जा सकता है। उदाहरण के लिए Go101 docs में “+” दबाकर expand किया जा सकता है। और tab panel demo भी है। यह Modern CSS की ताकत दिखाता है
  • असली बात “no JavaScript” नहीं है, बल्कि यह है कि HTML पहले से ही भूल चुके features (forms, dialog, validation, navigation आदि) संभालता है
    किताब “You Don’t Need JavaScript” लिखते समय मुझे लगा कि JS अक्सर नए features जोड़ने से ज़्यादा platform की मौजूदा capabilities को supplement करता है
    • काश ऐसी किताबें और हों। सिर्फ framework सीखने वाली नहीं, बल्कि problem-solving centered किताबों की ज़रूरत है
    • पहले browser support कमज़ोर था, इसलिए developers ने workarounds बनाए, और वही standard जैसे जम गए। हाल में CSS features तेज़ी से आ रहे हैं, इसलिए masonry layout भी experimental stage में पहुँच गया है
  • HTML की ज़्यादातर features शानदार हैं, लेकिन <input> और <datalist> real-world use के लिए कमज़ोर हैं
    users typo tolerance, helper text, mobile UX जैसी चीज़ें उम्मीद करते हैं, लेकिन datalist इन्हें पूरा नहीं कर पाता
    • datalist में display text और actual value को अलग न कर पाना सबसे बड़ी दिक्कत है
    • ज़्यादातर मामलों में select ज़्यादा उपयुक्त है, लेकिन select में search feature नहीं है
    • default styling बहुत भद्दी और बेडौल है
    • Android पर dropdown दिखता ही नहीं
    • हर device पर व्यवहार अलग है, इसलिए आख़िर में JS जोड़ना ही पड़ता है। सिर्फ HTML से compatibility hell में फँस जाते हैं
  • हाल में मैंने कई frontend interviews दिए, लेकिन अब भी सिर्फ React-केंद्रित JS skills ही आंकी जाती हैं
    HTML के semantic use या accessibility पर लगभग कोई ध्यान नहीं देता
    • अगर team React इस्तेमाल करती है, तो DOM API सीधे इस्तेमाल करने वाला इंसान team fit में बाहर हो सकता है
    • अलग CSS file इस्तेमाल करने से component कहीं ज़्यादा साफ़ रहते हैं। Tailwind बुरा नहीं है, लेकिन interview में मैं इसे इस्तेमाल नहीं करना चाहूँगा
    • HN के बाहर HTML purism में दिलचस्पी रखने वाले लोग लगभग नहीं हैं
  • सिर्फ CodePen links देना और examples सीधे पेज पर न रखना खटकता है
    “सिर्फ HTML से बनाते हैं” जैसी पोस्ट में external service पर निर्भर रहना विरोधाभासी लगता है
    • मुझे व्यक्तिगत रूप से यह ठीक लगता है। CodePen में bookmarking और syntax highlighting सुविधाजनक हैं। लेकिन link rot का ख़तरा है
    • फिर भी inline examples और CodePen links दोनों देने चाहिए थे
    • HTML पर ज़ोर देते हुए 2MB का CodePen UI load कराना UX के लिहाज़ से विडंबनापूर्ण है
  • Customizable select feature जल्द आने वाला है, इसे लेकर उत्सुक हूँ
    यह WHATWG stage 3 में है, और JS-आधारित dropdown की nightmare implementation की जगह ले सकता है
    Chrome blog post देखें
  • Pure HTML परिचित और आरामदेह है, लेकिन आज की functional web apps बनाने में इसकी सीमाएँ हैं
    HTMX या Phoenix LiveView जैसे alternatives भी आज़माए, लेकिन वे भी पूरी तरह समाधान नहीं हैं
    आख़िरकार लगता है कि modern JS को स्वीकार करना ही व्यावहारिक है
    • थोड़ा-सा JS भी सिर्फ HTML की तुलना में बहुत आगे ले जाता है। आज की web में JS के अति-उपयोग से usability deterioration गंभीर हो गया है
    • लगता है HTMX को ज़रूरत से ज़्यादा complex समझा जा रहा है। server state के आधार पर hx-select / hx-target का इस्तेमाल करें तो चीज़ें सरल रह सकती हैं
    • <marquee> tag shopping sites में horizontal scrolling के लिए अच्छा था, लेकिन अब उसे JS से ज़बरदस्ती बनाया जाता है। काश HTML और UI patterns को native support देता
    • React में marquee effect बनाने की कोशिश में मैंने बहुत tokens बर्बाद किए। वह perfect loop भी नहीं था, बस animation trick थी
    • अगर Elixir और Phoenix इस्तेमाल कर रहे हैं, तो Gleam पर भी विचार किया जा सकता है। यह JS में compile होता है
  • HTML और JS अलग-अलग मक़सद वाले tools हैं
    complex web apps के लिए JS ज़रूरी है, लेकिन बहुत-से क्षेत्र ऐसे हैं जो सिर्फ HTML से भी संभव हैं
    • Google Earth जैसी चीज़ों के लिए तो JS ज़रूरी है, लेकिन Gmail स्तर की चीज़ें HTML से भी संभव हैं। browser vendors के trends और hype HTML के विकास में रुकावट बन रहे हैं
    • htmx, JS का पूरक है। असली बात JSON की जगह structured hypertext का आदान-प्रदान है। मैंने वास्तव में htmx + थोड़ा JS लेकर काफ़ी complex apps जल्दी बनाए हैं
    • HTML को और features built-in देने चाहिए। जैसे HTTP verbs support, input controls में सुधार आदि
    • बहुत-सी JS-heavy sites को वास्तव में htmx से काफ़ी हद तक बदला जा सकता है। tool selection अक्सर आदत का मामला होता है
  • “accordion या navigation menu को JS से manage करने की ज़रूरत नहीं” — इस बात से सहमत हूँ
    लेकिन अब JS data collection और ad tracking का केंद्रीय tool बन चुका है
    सोचता हूँ कि JS के बिना भी big tech उसी स्तर की surveillance और ad services बना पाएगी या नहीं
    आख़िर में JS के प्रति नाराज़गी सिर्फ तकनीकी मुद्दा नहीं, बल्कि ad ecosystem पर अविश्वास से भी आती है
 
labeldock 2025-12-29

ऐसी कोशिशें कभी-कभी मुझे इस पर सोचने का मौका देती हैं कि क्या मैं overengineering कर रहा हूँ, लेकिन समृद्ध requirements वाले real-world काम के नज़रिए से देखें तो यह लगभग किसी करतब दिखाने जैसा है।