Baseline: कम JavaScript भेजने का राज़

Baseline: कम JavaScript भेजने का राज़

वो पुराने jQuery वाले दिन याद हैं? आप एक 90KB की फ़ाइल को प्रोजेक्ट में डालते थे और अचानक `$(document).ready()` सब कुछ मक्खन जैसा चिकना बना देता था। फिर हम सब समझदार हुए, bundles को अलग किया, और jQuery को अलविदा कहकर React, Vue और हर छोटी चीज़ के लिए माइक्रो-लाइब्रेरियों की अलमारी ले ली।

लेकिन एक बात है जो मैं खुद को बार-बार करते हुए पकड़ता हूँ: एक 20KB की date formatting library उठा लेना, जबकि जिस ब्राउज़र को मैं target कर रहा हूँ, वह उसी काम के लिए API पहले से देता है। बिल्कुल फ्री। न कोई network request, न version bump, न आगे चलकर maintenance का झंझट।

यहीं पर **Baseline** आता है।

अगर आपने अभी तक नहीं सुना है, तो बता दें कि Baseline एक W3C-backed पहल है। यह हमें एक आसान और universal label देता है: "इस feature को मैं सुरक्षित तरीके से कब इस्तेमाल कर सकता हूँ?" यह वेब डेवलपमेंट के सबसे परेशान करने वाले सवाल का जवाब एक ही शब्द में देता है: **आज**। और जब आपको पता चल जाता है कि web platform पहले से क्या कर सकता है, तो आपके द्वारा ship की जाने वाली JavaScript की मात्रा नाटकीय रूप से घट सकती है। आइए देखें कैसे।

आखिर Baseline है क्या?

Baseline दरअसल सभी प्रमुख ब्राउज़रों—Chrome, Edge, Firefox, Safari, और Opera—के बीच browser support को लेकर एक साझा समझ है। यह बताने के बजाय कि "97% ब्राउज़रों में चलता है", Baseline आपको बताता है कि कोई feature **available** है (मतलब अभी वाले ब्राउज़रों में चलता है) या **newly available** है (अभी-अभी latest versions में आया है)। इसका मकसद है अंदाज़ों और अटकलों को खत्म करना।

इसे ऐसे समझें: "caniuse, लेकिन ज़्यादा friendly फ़ैसले के साथ।" जब कोई feature Baseline बन जाता है, तो मतलब सभी common ब्राउज़र उसे support करते हैं। यही आपकी हरी झंडी है।

और सबसे अच्छी बात? Baseline उन जगहों पर पहले से मौजूद है, जिन्हें आप शायद पहले ही इस्तेमाल करते हैं। MDN compatibility tables खोलें, कोई feature search करें, और आपको उसके बगल में Baseline badge दिख जाएगा। या [web.dev/baseline](https://web.dev/baseline) पर जाकर देखें कि आज क्या-क्या तैयार है।

यह आपके Bundle Size के लिए क्यों मायने रखता है?

"इसके लिए आपको library चाहिए" और "ब्राउज़र यह कर देता है" के बीच की दूरी हर साल कम होती जा रही है। ब्राउज़र हर साल ऐसी APIs जोड़ते हैं जिनके लिए पहले polyfills, helper libraries और utility functions चाहिए होती थीं। अगर आप अब भी timezone math के लिए `moment-timezone` और `_.debounce()` के लिए `lodash` ship कर रहे हैं, तो आप उस चीज़ के लिए पैसे दे रहे हैं जो platform पहले से देता है—दोनों रूपों में, bytes के रूप में और complexity के रूप में।

चलिए तीन practical उदाहरण देखते हैं, जहाँ Baseline आपका काफी बोझ हल्का कर सकता है।

Scenario 1: 50KB Dependency के बिना Date Formatting

मैंने एक बार एक प्रोजेक्ट पर काम किया था जिसमें सिर्फ dashboard की कुछ तारीखों को format करने के लिए `date-fns` import किया गया था। पूरा ऐप एक static dashboard था। हम "Aug 9, 2026" जैसे strings दिखाने के लिए 16KB की localized date functions ship कर रहे थे।

लेकिन यहाँ एक छोटा प्रयोग है: अभी अपने browser console में जाकर लिखिए:

```js
new Intl.DateTimeFormat('en-US', { dateStyle: 'full' }).format(new Date())
```

बस हो गया। **कोई import नहीं, कोई npm install नहीं, कोई version pinning नहीं।** `Intl` object कई सालों से Baseline feature है। यह locale-specific formatting, time zones, यहाँ तक कि `Intl.RelativeTimeFormat` के साथ date-fns जैसी relative time भी handle करता है।

पूरा bundle हटाना चाहते हैं? अपने date-fns functions को native equivalents से map करें:

- `format` → `Intl.DateTimeFormat`
- `formatDistance` → `Intl.RelativeTimeFormat`
- `parseISO` → `Date.parse()` (या सावधानी से `new Date()`)
- `zonedTimeToUtc` → `Intl` with `timeZone` option

हाँ, edge cases मौजूद हैं, लेकिन 90% प्रोजेक्ट्स के लिए native Intl API काम कर जाती है। और यह Baseline available है, इसलिए हर modern browser इसे handle करता है।

Scenario 2: Lodash की जगह DOM

मैं अब भी कुछ codebases में `lodash.debounce` देखता हूँ। पाँच kilobytes सिर्फ इसलिए कि एक function थोड़ी देर बाद चले। लेकिन browser में यह पहले से built-in है:

```js
function debounce(fn, delay) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
```

या अगर आप मेरी तरह आलसी हैं, तो event listener में एक साधारण `setTimeout` ही ज़्यादातर मामलों के लिए काफी है। इसी तरह `_.throttle`, `_.clamp`, `_.range`—ये सब बस कुछ lines का vanilla JavaScript है।

लेकिन यह और गहरा है। कभी `_.forEach` इस्तेमाल करते थे? Array prototype में `forEach`, `map`, `filter`, `reduce`—सब कुछ Baseline है। Nested properties तक सुरक्षित पहुँचने के लिए `_.get`? Optional chaining 2020 से Baseline feature है। `_.unique`? यह सीधा `Set` है।

DOM खुद भी खजाना है: `classList.toggle()` की जगह `_.toggleClass` काम करता है, `Element.matches()` की जगह `_.is()` selectors, और native `IntersectionObserver` पूरी scroll-spy libraries की जगह ले सकता है। अगली बार जब आप एक dependency जोड़ने वाले हों, तो खुद से पूछिए: "क्या यह सिर्फ उस चीज़ का fancy wrapper है जो `document.querySelectorAll` मुझे पहले से देता है?"

Scenario 3: axios के बिना HTTP Requests

Axios एक शानदार library है, लेकिन 2026 में native `fetch` API Baseline है और लगभग हर use case handle करती है। Streaming? `fetch` में `response.body.getReader()` streaming के लिए है। Authentication? आप headers, credentials, और interceptors एक छोटे से wrapper में set कर सकते हैं। Aborting? वो `AbortController` है, जो Baseline है।

मैंने एक छोटे प्रोजेक्ट में axios को पूरी तरह हटाकर 20-line का helper लिख दिया:

```js
async function request(url, options = {}) {
const res = await fetch(url, {
headers: { 'Content-Type': 'application/json', ...options.headers },
signal: options.signal ?? (options.timeout && AbortSignal.timeout(options.timeout)),
...options,
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}
```

न कोई npm, न node_modules का bloat, न circular dependency warnings। बस fast, native, और reliable।

Baseline की मदद से अपने Dependencies का Audit कैसे करें

समझ गए, अब करना क्या है? यहाँ एक practical process है जो आप आज दोपहर कर सकते हैं।

1. अपनी Runtime Dependencies की List बनाइए

`npm ls --production` चलाएँ या सीधे अपना `package.json` देख लें। जो चीज़ आपका framework या state management library नहीं है, उसे highlight करें। वही छोटी utility packages आपके prime targets हैं।

2. हर एक को Baseline के Against Check करें

अपनी list की हर library के लिए दो सवाल पूछें:

- यह कौन सी problem solve करती है?
- क्या मैं इसे Baseline available वाली web API से solve कर सकता हूँ?

MDN पर feature search करें। अगर हरा "Baseline available" badge दिखे, तो सब ठीक है। अगर "Newly available" दिखे और आप सिर्फ modern browsers target करते हैं, तो भी विचार करने लायक है। अगर लाल "Limited" दिखे, तो अभी library को रखना ही बेहतर है।

एक छोटी टिप: Chrome, Safari या Firefox में developer tools खोलें और API को सीधे test करें। अगर वह बिना किसी flag के चल जाए, तो यह बहुत अच्छा संकेत है।

3. Code में Telltale Signs खोजिए

`import * as _ from 'lodash'`, `from 'date-fns'`, `from 'axios'`, या `from 'jquery'` जैसे patterns search करें। फिर देखें कि वे functions वाकई कितनी बार use हो रहे हैं। कभी-कभी आप पाएँगे कि 200-method वाली library में से आप सिर्फ तीन methods इस्तेमाल कर रहे हैं। यह साफ मौका है।

4. Replace करें और Compare करें

Migration एक समय में एक library का करें। PR अलग रखें ताकि आप bundle size का बदलाव माप सकें। अपने build tool के size report का उपयोग करें या बस devtools में file size देख लें। मैं Lighthouse को पहले और बाद में चलाने की सलाह देता हूँ। "JavaScript execution time" को गिरते देखना बहुत अच्छा एहसास है।

कम JavaScript भेजने का इंसानी पहलू

हमें इसकी परवाह क्यों करनी चाहिए, सिर्फ छोटे bundle की smug satisfaction के लिए? इसलिए क्योंकि JavaScript सबसे expensive resource है जो हम ब्राउज़रों को भेजते हैं। हर byte को download, parse, compile और execute होना पड़ता है। हर बचाई गई API का मतलब है किसी के लिए तेज़ page load—किसी ऐसे व्यक्ति के लिए जिसके पास सस्ता Android phone और लड़खड़ाता 3G connection है। हर किसी के पास MacBook Pro और fiber connection नहीं है।

कम JavaScript ship करने का मतलब आप डेवलपर के लिए कम दिमागी बोझ भी है। हर dependency एक संभावित security vulnerability है, एक संभावित migration headache है, और एक संभावित अजीब bug का स्रोत है जब उसका maintainer संन्यास लेने का फैसला करे। Native APIs को browser vendors maintain करते हैं, यानी वे आने वाले सालों तक updated, documented, और supported रहेंगी।

और एक गहरा फायदा भी है: आप web platform को समझने लगते हैं। जब आप `Intl`, `URL`, `Promise`, `Map`, `Optional Chaining`, और `fetch` को सीधे इस्तेमाल करते हैं, तो आप एक बेहतर web developer बन जाते हैं। आप सिर्फ abstractions के उपभोक्ता नहीं रहते; आप एक builder होते हैं जो लकड़ी के दाने को पहचानता है।

क्या कोई Caveats हैं? हाँ। बेवकूफ़ मत बनिए।

Baseline कोई जादू की छड़ी नहीं है। कुछ advanced APIs अभी भी हर जगह Baseline available होने के लिए बहुत नई हैं। जैसे Popover API या View Transitions API "newly available" हैं, लेकिन सभी ब्राउज़रों में पूरी तरह नहीं आई हैं। यदि आप बड़े audience के लिए public site बना रहे हैं, तो शायद आपको इंतज़ार करना चाहिए या graceful fallback देना चाहिए।

साथ ही, library हटाने का मतलब हमेशा कम code लिखना नहीं होता। कभी-कभी आपको वही व्यवहार पाने के लिए थोड़ा ज़्यादा vanilla JS लिखना पड़ता है। लेकिन यार, अपने लिखे कुछ extra lines उस विशाल utility library से ज़्यादा maintainable हैं जिसे आप पूरी तरह समझते भी नहीं।

और आखिरी बात, "native API zealot" मत बनिए। अगर कोई library आपकी productivity पूरी तरह बदल देती है और जीवन आसान बनाती है, तो उसे इस्तेमाल कीजिए। Baseline का मतलब आपको fancy libraries के लिए शर्मिंदा करना नहीं है। इसका मतलब है आपको informed trade-offs करने में मदद करना। बस जब `crypto.getRandomValues()` 2015 से Baseline है तो `safe-password-generator` मत भेजिए।

Bonus: Baseline से अपडेटेड कैसे रहें

Web platform तेज़ी से बदलता है। यह जानने के लिए कि क्या नया Baseline available हो रहा है, मैं दो काम करता हूँ:

1. हर महीने [web.dev/baseline](https://web.dev/baseline) पर Web Platform Features dashboard देखता हूँ।
2. MDN Baseline news section पढ़ता हूँ, जो हर महीने नए available features की list देता है।

आप WebDX community group का GitHub repo भी follow कर सकते हैं: [github.com/web-platform-dx/baseline](https://github.com/web-platform-dx/baseline)। असली जादू वहीं होता है।

अक्सर पूछे जाने वाले सवाल

"Baseline available" का आखिर मतलब क्या है?

इसका मतलब है कि फीचर सभी प्रमुख ब्राउज़रों—Chrome, Edge, Firefox, Safari, और Opera—के current और recent versions में supported है। आप इसे उन ब्राउज़रों के लिए बिना polyfill या fallback के इस्तेमाल कर सकते हैं।

क्या Baseline और "caniuse.com" एक ही हैं?

नहीं, लेकिन दोनों संबंधित हैं। Caniuse आपको detailed compatibility tables देता है, जिसमें पुराने versions भी शामिल हैं। Baseline उस डेटा को एक सरल "तैयार है या नहीं" label में बदल देता है। यह सुनिश्चित करता है कि जानकारी context-aware है—जो Chrome 120 में काम करता है, ज़रूरी नहीं वह Safari 12 में भी चले।

क्या होगा अगर मुझे IE11 जैसे पुराने ब्राउज़र को support करना पड़े?

IE11 मर चुका है, और उससे पहले भी वह एक exception था। Baseline जानबूझकर IE11 जैसे legacy browsers को बाहर रखता है। यदि आपको ऐसे प्राचीन environments support करने हैं, तो आपको individual tables देखने होंगे और शायद चुनी हुई APIs के लिए polyfills डालने पड़ेंगे। लेकिन 2026 में, यह पूछना सुरक्षित है कि आप अब भी IE11 क्यों support कर रहे हैं—आपके users ने पुरानी तकनीक पकड़े रहने का फैसला किया है, और इसकी कीमत आप चुका रहे हैं।

मैं अपनी टीम को Baseline इस्तेमाल करने के लिए कैसे मनाऊँ?

उन्हें numbers दिखाइए। एक dependency चुनें, bundle size और maintenance cost का अनुमान लगाएँ, और फिर एक quick prototype में native replacement demonstrate करें। मैंने पिछली नौकरी में `lodash` के साथ ऐसा ही किया था, और जब मेरे lead ने diff देखा—5KB की utility जिसकी जगह vanilla JS की दो lines लगीं—तो वे तुरंत मान गए। और उन्हें यह पोस्ट भी भेज दीजिए। 😉

सबसे नीचे की बात

Baseline सिर्फ एक और compatibility tool नहीं है—यह mindset shift है। "इसके लिए कौन सी library लूँ?" पूछने की जगह आप पूछने लगते हैं "मेरे लिए browser पहले से क्या कर सकता है?" जिस पल आप यह shift कर लेते हैं, JavaScript की फूलन पिघलनी शुरू हो जाती है।

आपके users को तेज़ site मिलता है। आपके भविष्य के आपको साफ codebase मिलता है। और web हर किसी के लिए थोड़ा हल्का हो जाता है।

अब जाइए, अपने devtools खोलिए, अपने project का bundle देखिए, और देखिए कि क्या काट सकते हैं। आपका browser शायद पहले से ही जवाब लेकर बैठा है।