प्लेन वैनिला वेब

 (plainvanillaweb.com)
2 पॉइंट द्वारा GN⁺ 2025-05-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • केवल HTML, CSS, JavaScript का उपयोग करने वाली मूल वेब डेवलपमेंट तकनीकों का विवरण
  • build tools और framework के बिना सिर्फ standard web technologies से sites और applications बनाने के तरीके का परिचय
  • web components और आधुनिक CSS features का उपयोग करके structure और styling करने के तरीकों पर चर्चा
  • framework की जटिलता और maintenance के बोझ के बिना सरल development environment और दीर्घकालिक लाभों को लक्ष्य बनाता है
  • पहले से web standards technologies सीख चुके developers को मुख्य target करने वाला tutorial

Plain Vanilla वेब अवलोकन

वेब डेवलपमेंट में build tools और framework के बिना केवल standard web technologies से sites और applications बनाने की प्रमुख तकनीकों का यह एक अवलोकन है

  • editor, browser, web standards का ही उपयोग करने वाले environment का विवरण
  • शुरुआती setup और server-side logic के बिना production deployment संभव करने वाली संरचना का परिचय

शामिल विषय

1. कंपोनेंट्स(Components)

  • web components का उपयोग करके केवल HTML, JavaScript, CSS से उच्च-स्तरीय building blocks को संयोजित करने का तरीका
  • React या Vue जैसे framework component approach का विकल्प प्रस्तुत करने का तरीका

2. स्टाइलिंग(Styling)

  • आधुनिक CSS की शक्ति का उपयोग करके CSS Modules, PostCSS, SASS द्वारा दी जाने वाली सुविधाओं का विकल्प बनाने का तरीका
  • पारंपरिक CSS से आगे बढ़कर structured और modular styling की अवधारणा प्रदान करता है

3. साइट्स(Sites)

  • web components आधारित web projects को व्यवस्थित करने और build tools या server-side के बिना deploy करने का तरीका
  • व्यावहारिक और सरल deployment workflow प्रस्तुत करता है

4. एप्लिकेशंस(Applications)

  • केवल vanilla techniques से single-page web applications बनाने का तरीका
  • routing, state management के तरीकों का विवरण

अनुशंसित पाठक

यह उन developers के लिए है जो पहले से HTML, CSS, JavaScript को कुछ हद तक इस्तेमाल कर सकते हैं

  • वेब डेवलपमेंट शुरू करने वालों के लिए Odin Project या MDN जैसे बुनियादी learning paths की सिफारिश की जाती है

vanilla approach क्यों

आधुनिक frameworks तेज़ी से संरचित और शक्तिशाली features प्रदान करते हैं, लेकिन इनके साथ tools और framework की बढ़ती जटिलता तथा लगातार maintenance का बोझ भी आता है

  • plain vanilla approach अल्पकालिक सुविधा का कुछ हिस्सा छोड़ने के बदले सादगी और लगभग zero-maintenance जैसे दीर्घकालिक लाभ प्रदान करता है
  • आज के browsers का बेहतरीन web standards support इस approach को वास्तव में संभव बनाता है

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

1 टिप्पणियां

 
GN⁺ 2025-05-12
Hacker News राय

  • अब मैं "vanilla या framework" बहस से आगे बढ़कर इस नज़रिए से सोचता हूँ कि 'क्या इसके लिए सच में वेबसाइट की ज़रूरत है?'
    वेब ऐप, खासकर B2B SaaS क्षेत्र में, क्या वास्तव में वेब की ज़रूरत है—इस पर शक करना शुरू करें तो पता चलता है कि browser को छुए बिना भी बिज़नेस को काफ़ी आगे तक ले जाया जा सकता है
    वेबसाइट और ऐप बनाने में मैंने जो ज़्यादातर समय लगाया, वह managed UI/UX पर था—यानी admin database fields बदलकर application को customer expectations के मुताबिक चलाए
    कई मामलों में, बिज़नेस को सिर्फ config templates (जैसे Excel files) दे देना और नतीजों को सीधे SQL tables में insert/merge करना कहीं ज़्यादा तेज़, आसान और कम फालतू काम वाला होता है
    वेब सिर्फ UI/UX का एक ही तरीका देता है। email या plain text files कभी-कभी इससे ज़्यादा flexible होते हैं

    • अक्सर देखता हूँ कि digital-first consulting कंपनियाँ B2B क्षेत्र में बेवजह fancy web apps बनाती हैं और इसी वजह से फुर्तीली नहीं रह पातीं
      खासकर government agencies जैसे खरीदार ठीक से समझे बिना अक्सर ज़्यादा पैसे दे देते हैं
      procurement संभालने वालों को क्या चाहिए, इस बारे में ज़्यादा शिक्षा की ज़रूरत है
    • मैं online cremation urns बेचता हूँ। मेरी साइट पर सिर्फ email link है। shopping cart नहीं है
      असल cremation urn stores में cart नहीं होता, तो virtual store में क्यों हो
      जब मैंने online specialized woodworking tools खरीदे, तब भी मैंने बस form भरा और invoice के साथ parts पा लिए; चाहूँ तो पहले payment न करूँ, यह भी ठीक था
      online और offline, commerce के कई तरह के तरीके होते हैं, और अगर दिलचस्प ढंग से जीने वाले लोगों को ध्यान से देखें तो यह हर जगह दिख जाता है
    • ऐसे internal tools जो लगभग CRUD से आगे नहीं जाते, उनमें वेब सबसे ज़्यादा तब काम आता है जब कोई external consultant उसे एक बार में बनाकर दे, या in-house team उसे हमेशा maintain न कर सके
      अगर थोड़ा-बहुत maintenance skill हो, तो Excel template + simple custom script वाला तरीका कहीं ज़्यादा flexible हो जाता है
      अगर end users वैसे भी raw data संभालने के स्तर के users हैं, तो यह बहुत प्रभावी है
    • SaaS से पहले B2B दुनिया 100% ऐसे ही चलती थी
      और आज भी B2B का 99% हिस्सा इसी तरह चलता है

  • मैं frameworks के ख़िलाफ़ नहीं हूँ। बस मुझे लगता है कि कई बार उनकी ज़रूरत नहीं होती
    एक line code लिखने से पहले ही 100KB JS क्यों जोड़ना पड़े, यह मुझे हमेशा अजीब लगा
    मैंने अपनी टीम के साथ https://restofworld.org बिना किसी framework के बनाया
    survey, outreach और email feedback—सबमें usability और reading experience को लेकर बहुत positive प्रतिक्रिया मिली
    बाद में framework इस्तेमाल कर सकते हैं, लेकिन अभी तक plain vanilla JS ही बहुत अच्छा फिट बैठता है

    • यह comment इस तरह की चर्चा में बार-बार दिखने वाली disconnect का अच्छा उदाहरण है
      एक तरफ वे लोग हैं जो 30+ लोगों की टीमों में बड़े web apps बनाते हैं, और अगर आप कहें कि framework के बिना बनाया है, तो वे तुरंत बड़े scale की ज़रूरी functionality को लेकर सवाल उठाते हैं
      लेकिन जवाब यह होता है कि उन features की ज़रूरत ही नहीं है, क्योंकि यह blog जैसे इस्तेमाल का मामला है, इसलिए शुरू से framework की ज़रूरत नहीं थी
      उल्टा, जिन लोगों को बहुत बड़े web app का अनुभव नहीं है, वे सोचते हैं: "लोग frameworks इस्तेमाल ही क्यों करते हैं?"
      वेब सच में बहुत तरह के software का मिश्रण है।
      इसलिए frameworks पर बात करते समय साफ़ बताना चाहिए कि किस तरह के software की बात हो रही है
      इस मामले में, यह एक WordPress blog है
    • पेज शानदार है और loading भी अच्छी है, लेकिन इसका TFA(मूल लेख) में बताए गए तरीके से कोई संबंध नहीं है
      यह WordPress नाम का एक बड़ा framework इस्तेमाल करता है, बस output को statically render कर रहा है
      TFA का मतलब है बिना किसी build tool के, सिर्फ modern web standards का इस्तेमाल। यानी सिर्फ editor, browser और web standards
    • "एक line code लिखे बिना 100KB JS क्यों जोड़ूँ"
      जिन enterprise apps पर मैंने काम किया, उनमें 100KB की चिंता करने की बिल्कुल ज़रूरत नहीं थी
      वे ज़्यादातर multi-team द्वारा बनाए गए बड़े apps थे, और React वगैरह इस्तेमाल करते थे
      Lob/B2B में initial page load की किसी को परवाह नहीं होती
      users हर दिन app इस्तेमाल करते हैं, और ज़्यादातर static assets सीधे browser cache से मिल जाते हैं
      अगर Next.js जैसा smart framework हो, तो routes के हिसाब से content immutable chunks में बँटा रहता है
      initial render static HTML होता है, इसलिए user को hydration दिखता भी नहीं
    • साइट अच्छी है। कुछ अच्छे लेख भी मिले
      लेकिन vanilla vs framework बहस में ऐसे examples हमेशा news/article sites ही होते हैं, जो complex app नहीं हैं, इसलिए मुझे लगता है कि "मैं तो शुरू से framework इस्तेमाल ही नहीं करता"
      आख़िरकार असली उदाहरण के लिए ज़्यादा interactive apps चाहिए
      आजकल मैं frameworks और consistent patterns का इस्तेमाल करना पसंद करता हूँ, और बाकी dependencies कम से कम रखता हूँ
    • इस architecture का एक फ़ायदा यह है कि browser का back/forward history navigation बहुत तेज़ होता है
      iPhone पर पीछे जाने पर पूरा page फिर से load होना इतना आम हो गया था कि यही सामान्य लगने लगा था
    • बधाई! मेरा मानना है usability सबसे ऊपर है
      लेकिन developers मज़े के लिए loading screens, hydrating components, ज़रूरत से ज़्यादा animations और परेशान करने वाले modals पर अटक जाते हैं
    • पता नहीं यह frameworks न इस्तेमाल करने की वजह से है या नहीं, लेकिन back/forward navigation में URL तुरंत बदल जाता है, पर page update नहीं होता और वही article खुला रह जाता है
      और infinite scroll, scrollbar की position से मैं कहाँ हूँ यह समझना मुश्किल बना देता है, इसलिए usability के लिए नुकसानदेह है
    • Rest of World ऑस्ट्रेलिया में भी बहुत तेज़ चलता है, और पहली बार देखा ऐसा शानदार news site है।
      इसे बनाने में आपकी भागीदारी काबिल-ए-तारीफ़ है
    • यह WordPress से static pages generate करने की खूबसूरती है
    • ज़्यादातर frameworks को 100KB JS की ज़रूरत नहीं होती
      Mithril जैसे framework में सारी functionality 10KB gzipped में हो सकती है
    • vanilla examples की दिक्कत यह है कि pages अक्सर बहुत ज़्यादा simple होते हैं और UX भी बहुत basic होता है
      अगर आप सोचें कि search वाला reactive table, labels/validation/errors वाला ठीक-ठाक form जैसी interactive चीज़ें खुद implement करनी हैं, जबकि Svelte UI library और 25KB overhead के साथ एक tested, well-made solution मिल सकता है, तो फिर खुद क्यों बनाएँ
    • main image ही 200KB से बड़ी है, तो 100KB बहस का कोई मतलब नहीं
      और WordPress भी एक framework है
      framework इस्तेमाल करने से चीज़ें धीमी नहीं हो जातीं। WordPress हो या कुछ और
    • यह modern web की bloated हालत का अच्छा उदाहरण है
      बहुत ज़्यादा तेज़ है
    • सच में बहुत तेज़!
    • Rest of World मुझे बहुत पसंद है
    • "100KB JS क्यों जोड़ना चाहिए"
      developer productivity के लिए (कम-से-कम सिद्धांत में)।
      असल में, कई बार उतना फ़ायदा नहीं होता
    • साइट सच में बहुत तेज़ है। पहले भी इस तरह की journalism देखी है
      जानना चाहूँगा कि इस approach की कोई गंभीर कमी सामने आई थी या नहीं
    • क्या? यह तो असंभव है
    • किसी को 100KB की परवाह नहीं

  • मैं लगभग 2,000 users के लिए एक system बना रहा हूँ, और उन्हें reactive UI से बिल्कुल फ़र्क नहीं पड़ता
    monolith बनाइए, page refresh की चिंता मत कीजिए, बस काम पूरा होने पर ध्यान दीजिए—यही सबसे अच्छा है

    • इसके जवाब में, कई पुराने desktop apps आख़िरकार वेब पर ले जाए गए
      उसकी बड़ी वजह तकनीकी नहीं थी, बल्कि native apps की deployment बहुत महँगी थी
      वेब apps की deployment का सस्ता standard देता है, लेकिन UI technology अब भी बहुत कमज़ोर है
      पहले X11, Java, Flash जैसी कई आधी-अधूरी कोशिशें हुईं, और उम्मीद है कि कभी web apps बनाना ज़्यादा सहज होगा
    • सिर्फ CSS के @view-transition से भी smooth transitions मिल सकते हैं
      https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
    • आज के समय के लिए यह बहुत ही सुस्त राय है
      ज़्यादातर software, 120 साल पुराने mechanical devices से भी ज़्यादा धीमे और कम responsive हैं
    • सिर्फ CSS और JS से भी बेहद simple refresh dynamics आसानी से बनाए जा सकते हैं
      कोई npm package लाने की ज़रूरत नहीं
    • React और server के बीच separation भी बिखरा हुआ है
      backend express/node पर है, पूरा codebase साथ में है, लेकिन dev में server React के default server से चलता है, और production deploy में अलग तरह से, इसलिए अजीब build/operations setup बन जाता है और dev server की सुविधा (hot reload वगैरह) का फायदा फीका पड़ जाता है
    • मैंने SPA को MPA से ज़्यादा टूटा हुआ देखा है
      Reddit, X(Twitter) जैसी बड़ी कंपनियों के SPA भी mobile पर बहुत unstable रहे
      अगर आपका scale Twitter जैसा नहीं है, या आप API-based platform नहीं बना रहे, तो मुझे नहीं लगता कि SPA पर अड़े रहने की ज़रूरत है
      अरबों डॉलर की कंपनियाँ भी इसे ठीक से नहीं बना पाईं—तो यह सोचकर चलना कि मैं उनसे बेहतर कर लूँगा, ख़तरनाक आत्मविश्वास है
    • vanilla approach की एक ताकत यह है कि मौजूदा SSR sites को भी बढ़ाया जा सकता है
      सब कुछ React में फाड़कर दोबारा बनाने की ज़रूरत नहीं
      मूल लेखक जिन advanced SPA-like features की बात कर रहा है, वे optional हैं
    • practical users को शायद फ़र्क न पड़े, लेकिन जो users बस लगातार click करते जाते हैं, वे main feed पर लौटने के लिए wait करने के बजाय back button दबा देंगे, और कई बार वह timing CDN से latest framework लाने से भी तेज़ होती है
    • अगर page refresh सच में बहुत तेज़ हो, तभी मैं इस राय से सहमत हूँ
    • मैं पूछना चाहूँगा कि आपको कैसे पता कि users सच में page refresh की बिल्कुल परवाह नहीं करते
      क्या आपने उन लोगों का भी अध्ययन किया जो बीच में छोड़कर चले गए?

  • मैं ऐसी दुनिया में जीना चाहता हूँ
    मैं framework से पहले के दौर से आता हूँ, और तब चीज़ें अभी काफ़ी immature थीं, और सिर्फ jQuery जानने वाले लोग भी बहुत थे
    अब मुझे लगता है कि post-query selector frameworks की लागत के मुकाबले उनका लाभ उतना बड़ा नहीं है (testing frameworks अलग बात हैं, वे बहुत अच्छे हैं)
    हम React नाम की framework jail में फँस गए हैं, और सारी असफलताएँ spaghetti-जैसी complexity का नतीजा हैं
    state machines hardcoding से उलझ जाती हैं, और translated/minified/transpiled output समझना मुश्किल हो जाता है
    source maps भी maintenance complexity की एक और layer हैं
    मैं मानता हूँ frameworks किसी वजह से बने, लेकिन यह मानना मुश्किल है कि नए engineers के लिए vanilla JS की तुलना में frameworks सीखते जाना आसान है

    • मैंने भी वह पुराना दौर देखा है, और सबसे बड़ी समस्या यह थी कि हमने document format के ऊपर app ecosystem खड़ा करने का फैसला कर लिया
      HTML बस text rendering को थोड़ा आसान बनाने के लिए बना markup था, और HTTP भी कुछ ऐसा ही था
      पहले text-to-markup ratio ऊँचा होना चाहिए था, लेकिन अब यह पूरी तरह उलट गया है
      फिर भी हमने मान लिया कि पूरा app development इसी पर चढ़ाना भविष्य है, और React के अंदर भी देखें तो दशकों भर की hacks और tricks हैं
      पहले यह कुछ ऐसा था जैसे Excel+VB से apps बनाना, या PDF+PostScript के मेल से app बनाने की कोशिश करना—काफ़ी बेतुका
      इसी वजह से कई MB JS का इस्तेमाल अब बहुत ज़्यादा लगता है
    • मेरे लिए आजकल का killer app responsiveness है
      जब data बदलते ही UI तुरंत प्रतिक्रिया दे, यही सबसे अहम है; अगर इसके लिए manually listeners बनाऊँ, diff updates करूँ, और events cleanup करूँ, तो यह लगभग manual memory management जैसा महसूस होता है
      jQuery के ज़माने में ऐसा ही था, और ग़लतियाँ भी बहुत होती थीं
      अगर components के आधार पर declarative views के साथ modularization vanilla JS में संभव हो जाए, तो मैं लौटने को तैयार हूँ, लेकिन अभी मुझे यह बिल्कुल व्यावहारिक नहीं लगता
      कुछ निर्णायक चीज़ की कमी है
    • मुझे भी कभी-कभी समझ नहीं आता कि यह KISS principle वगैरह के लिए nostalgia है या नहीं
      React और Angular, ES2015 से पहले निश्चित ही मायने रखते थे
      उसके बाद मैं frontend frameworks के लगातार बदलते रुझानों से थक गया
      React के भीतर भी component styles और state management के तरीके बदलते रहते हैं
    • अगर आप सैकड़ों मिलियन views वाली service चलाते हैं, तो मेरी कल्पना में उसका वास्तविक ढाँचा static site के काफ़ी क़रीब होगा

  • मैं अभी भी Web Components को लेकर आश्वस्त नहीं हूँ
    खासकर @scoped, import {type:css} जैसी हाल की सुविधाओं के बावजूद, मुझे लगता है कि elements को statically render करके फिर modern JS से dynamically update करना ज़्यादा सार्थक है
    मैं ज़्यादातर Web Components approaches को लेकर सशंकित हूँ, और मानता हूँ कि React/Svelte जैसे frameworks के बाहर innovation जारी रहना चाहिए
    मुझे कभी नहीं लगा कि Web Components मेरे द्वारा चलाए जाने वाले कई sites के लिए उपयोगी हैं

    • Web Components मेरी समस्या हल नहीं करते, उल्टा नई समस्याएँ जोड़ते हैं
      Shadow DOM की बात हर page पर कई बार उठती है, लेकिन ज़्यादातर वे समस्याएँ खुद उसे अपनाने से पैदा होती हैं
      मेरे app-specific components के लिए Shadow DOM की ज़रूरत ही नहीं
    • "static elements render + modern JS से dynamic updates"
      जानना चाहूँगा कि backend में Web Components के साथ यह कैसे handle किया जाता है
    • Web Components एक साफ़ abstraction boundary देते हैं
      आप अपने tags में अतिरिक्त methods जोड़ सकते हैं, और update logic को component के भीतर encapsulate कर सकते हैं
    • मेरा मानना है कि हमें फिर से Unobtrusive JS की तरफ लौटना चाहिए
      हल्की libraries या खुद लिखे जा सकने वाले तरीकों की ज़रूरत है
      HTMX कुछ मामलों में अच्छा है, लेकिन फिर भी script tag की तरह व्यवहार करता है; URL/method जैसी चीज़ें HTML में साफ़ रहें और hx-target जैसी चीज़ें सिर्फ JS में data- attributes से दी जाएँ, तो काफ़ी है
      मैं नहीं चाहता कि HTMX की वे सारी features भी साथ आएँ जिनका मैं इस्तेमाल नहीं करता

  • मैं Web Components को वैसा विकल्प नहीं मानता जिसे दूसरे frameworks में component कहा जाता है
    आप attributes में complex values (Object, Array आदि) नहीं दे सकते, boilerplate बहुत ज़्यादा है, और इसमें reactivity भी नहीं है
    मैं signals[1] वाले तरीके से vanilla JS-जैसा coding करता हूँ
    हर W3C standard सही जवाब नहीं होता; XHTML की विफलता को याद रखना चाहिए
    [1] https://wrnrlr.github.io/prelude/

  • http://youmightnotneedjs.com

  • यह approach शायद उन लोगों के लिए अच्छी है जो शौक़ में web pages बनाते हैं
    frameworks का उद्देश्य standardization, best practices को design में समाहित करना, और development जल्दी शुरू करवाना है
    वेबसाइट में अपने-आप में कोई intrinsic value नहीं होती; असली बात यह है कि उसकी content/utility को कितनी दक्षता से दिखाया जाए और समय पर सही तरह से बनाया जाए
    इस मायने में frameworks वर्तमान और भविष्य की लागत कम करते हैं

    • यही 'official narrative' है, लेकिन व्यवहार में यह हमेशा सही नहीं होता
      बड़ी कंपनियों में असल निर्णय अक्सर trends, conventions और लोकप्रिय frameworks को लेकर defensive mindset से प्रभावित होते हैं; बढ़ती complexity से productivity में गिरावट को track नहीं किया जाता, और कई बार ग़लत फ़ैसले भी व्यक्ति/टीम के incentives से मेल खाते हैं
      यानी "यह तो rational choice ही होगी" कहकर framework चुनने को सही नहीं ठहराया जा सकता
    • मैंने React और उससे जुड़े frameworks पर बने कई projects देखे हैं जो बिल्कुल अच्छी तरह manage नहीं हुए
      सिर्फ framework इस्तेमाल कर लेने से best practices अपने-आप लागू नहीं हो जातीं; उल्टा, चीज़ें और bloated, और slow systems में बदल सकती हैं

  • यह सच में शानदार material है
    मेरा मानना है कि अगर आप web बनाते हैं, तो foundational technologies के सिद्धांत समझना और web platform का पूरा लाभ उठाना ज़रूरी है
    उसके ऊपर build system/framework इस्तेमाल करना है या नहीं, यह trade-offs समझकर स्वतंत्र रूप से चुना जा सकता है
    व्यक्तिगत रूप से मुझे Remix(/React-router v7+) पसंद है, क्योंकि इसकी सोच web standards से मिलती है
    यानी कम development में ज़्यादा हासिल किया जा सकता है, जैसे server data changes को सिर्फ HTML form से भी संभव बनाना
    और https://every-layout.dev भी recommend करूँगा। इससे सिर्फ browser-native CSS से high-performance, accessible और flexible layouts की कई techniques सीखी जा सकती हैं
    मैं खुद 1998 से professional web development में हूँ

  • पिछले हफ़्ते मैंने पूरी तरह vanilla से एक छोटा project बनाया, और वह बहुत अच्छा चल रहा है
    यह Mastodon के लिए long-thread writing web tool है
    बनाते समय बार-बार मन में आता रहा, "क्या framework के बिना मैं कुछ ग़लत कर रहा हूँ?"
    ऐसा माहौल है कि बाकी सब लोग framework की उम्मीद करते हैं
    Splinter, splinter.almonit.club, जिसे देखना हो देख सकता है