किसी भी डोमेन की DNS सेटिंग्स खोलिए और आपको रहस्यमय कोड्स की एक पूरी दीवार दिखेगी — A, AAAA, MX, TXT, SRV, CAA, SVCB — और सच में ऐसा लगता है जैसे किसी ने एक पुराने इंजन में बेतरतीब हिस्से जोड़ते-जोड़ते इसे बना दिया हो। और ईमानदारी से कहें तो, असल में यही हुआ है। ये सभी रिकॉर्ड टाइप्स इसलिए बने क्योंकि इंटरनेट किसी ऐसी दीवार से टकराया जिसे मौजूदा रिकॉर्ड्स पार नहीं कर सकते थे, और जब आप यह पूरी कहानी सिलसिलेवार देखते हैं, तो यह सारी गड़बड़ी असल में समझ में आने लगती है।
आपका वेब ऐप शायद ऐसे काम कर रहा है जिन्हें आपने कभी वास्तव में डीबग नहीं किया। यूज़र के कुछ भी क्लिक करने से पहले pages prerender हो रहे हैं, form submissions ऑफलाइन रहते हुए चुपचाप queue में जा रहे हैं, push notifications एक सोए हुए service worker पर आ रही हैं, sessions cryptographically hardware keys से bound हैं — यह सब Chrome के background service APIs के ज़रिए होता है, पूरी तरह अदृश्य रूप से। Chrome DevTools का Background Services पैनल वह जगह है जहाँ आप अंततः यह सब देख पाते हैं।
DevTools खोलें, Application पर क्लिक करें, और बाईं ओर की साइडबार देखें। Cookies, Local Storage, Session Storage, IndexedDB, Cache Storage, Shared Storage, Background Services… यह काफी कुछ है। मैंने सीनियर डेवलपर्स को भी हर चीज़ के लिए localStorage का इस्तेमाल करते देखा है — ऑथ टोकन, शॉपिंग कार्ट, यहाँ तक कि मेगाबाइट्स में API रिस्पॉन्स — सिर्फ इसलिए क्योंकि यह वही है जिसे वे जानते हैं। यह हमेशा गलत नहीं होता, लेकिन यह शायद ही कभी सबसे अच्छा विकल्प होता है। आइए असल में देखें कि इनमें से हर मैकेनिज्म क्या करता है, DevTools में आपको यह कहाँ मिलेगा, और — सबसे ज़रूरी — आपको इसे बाकी छह विकल्पों के बजाय कब चुनना चाहिए जो ठीक बगल में बैठे हैं।
मुझे समझ आता है कि यह सवाल बार-बार क्यों उठता है। एक WebSocket खुला रहता है, याद रखता है कि आप कौन हैं, और सर्वर को बार-बार पूछे बिना ही आपको डेटा भेजने देता है। तो फिर हम एक ही पेज लोड के लिए सौ अलग-अलग HTTP रिक्वेस्ट क्यों भेजते रहते हैं, जब हम सिर्फ एक परसिस्टेंट पाइप खोलकर काम चला सकते हैं? सच कहूं तो यह सवाल जितना समझदार लगता है, उतनी क्रेडिट लोग इसे नहीं देते — और इसका जवाब “क्योंकि HTTP बेहतर है” नहीं है। मामला इससे कहीं ज़्यादा बारीक है।
मैं लगातार सुनता रहा “रियल-टाइम चीज़ों के लिए वेबसॉकेट इस्तेमाल करो” बिना यह समझे कि वायर पर असल में होता क्या है। तो मैंने जाकर RFC पढ़ा, कुछ सर्वर्स को टटोला, और सोचा कि जो कुछ मुझे पता चला वह लिख दूं — जिसमें वह हिस्सा भी शामिल है जिसने मुझे सबसे ज़्यादा उलझाया: क्या वेबसॉकेट अपने आप में एक प्रोटोकॉल है या सिर्फ HTTP के ऊपर कोई चालाक तरकीब?
हर कोई अपने API पर “RESTful” का ठप्पा लगा देता है। कोई भी docs पेज खोलिए, मार्केटिंग कॉपी पढ़िए, और वहाँ यह लिखा मिलेगा — “हमारा साफ-सुथरा, RESTful API।” लेकिन यहाँ असहज करने वाली बात यह है: सख्त परिभाषा के अनुसार, इनमें से लगभग कोई भी असल में RESTful नहीं है। तो असल में आप यह पूछ रहे हैं कि अगर आप कुछ नियम तोड़ देते हैं तो क्या उस शब्द का अब भी कोई मतलब रह जाता है। ईमानदारी से कहूँ तो, यहीं से मामला पेचीदा हो जाता है।
फ्रंटएंड इकोसिस्टम हर साल बदलता है, लेकिन 2025-2026 संरचनात्मक रूप से अलग महसूस हुआ। यह केवल नई लाइब्रेरी नहीं थीं — बुनियादी मानसिक मॉडल बदल गए। हम कैसे hydrate करते हैं, bundle करते हैं, components को structure करते हैं, और reactivity को handle करते हैं — यह सब इस तरह से बदला है जो वास्तव में apps के performance और उन्हें बनाने में लगने वाले समय को प्रभावित करता है। यहाँ वह है जिस पर ध्यान देना उचित है।
CSS centering के साथ पहली लड़ाई कोई नहीं भूलता। आप Google करते हैं, Stack Overflow का snippet paste करते हैं, और आगे बढ़ जाते हैं — यह पूछे बिना कि क्या वह सही तरीका था या बस एक तरीका। 2026 में, div को center करने के कम से कम सात अलग-अलग तरीके हैं, और उनमें से कुछ को तो वर्षों पहले ही दफन हो जाना चाहिए था।
यहाँ वे सभी हैं, सबसे बुरे से सबसे अच्छे तक रैंक किए गए।
हर कुछ वर्षों में CSS में लेआउट करने का “सही” तरीका पूरी तरह बदल जाता है। अगर आपने 2015 से पहले CSS लिखना शुरू किया था, तो शायद हर बार जब कोई clearfix का उल्लेख करता है तो आपको एक हल्का आघात महसूस होता है। आइए मैं आपको बताता हूँ कि हम यहाँ तक कैसे पहुँचे — और 2026 में आपको वास्तव में किस चीज़ का उपयोग करना चाहिए।
टेबल का युग (1990 के दशक – 2000 के दशक के मध्य) HTML टेबल कभी भी लेआउट के लिए नहीं बनाई गई थीं। वे टेबुलर डेटा प्रदर्शित करने के लिए मौजूद थीं। फिर वेब डिज़ाइनरों ने खोजा कि <table>, <tr>, और <td> आपको कुछ ऐसा देते हैं जो CSS अभी तक प्रदान नहीं कर सकती थी: पूर्वानुमानित कॉलम नियंत्रण [1]।
मैंने वर्षों में जितने भी ब्लॉग देखे हैं, वे ज़्यादातर WordPress पर चलते हैं — एक database, PHP, plugins, और हर दूसरे हफ़्ते security patches। मूल रूप से सिर्फ़ text publish करने वाली साइट के लिए बहुत सारे moving parts। Hugo इन सबके बिल्कुल विपरीत है। न database, न runtime। बस plain HTML files जो एक CDN से serve होती हैं, एक सेकंड से भी कम समय में generate होती हैं।
TypeScript अगस्त 2025 में GitHub पर सबसे ज्यादा उपयोग की जाने वाली भाषा बन गई — एक दशक से अधिक समय में पहली बार Python और JavaScript दोनों को पीछे छोड़ते हुए [4]। 78% पेशेवर डेवलपर्स अब TypeScript लिखते हैं [5]। और फिर भी, लगभग किसी भी पुराने कोडबेस, स्टार्टअप MVP, या त्वरित यूटिलिटी स्क्रिप्ट को खोलें और आपको अभी भी सादे .js फाइलें मिलेंगी। यह आलस्य नहीं है। इसके पीछे वास्तविक, संरचनात्मक कारण हैं।
JavaScript में पहले कोड को फ़ाइलों में विभाजित करने का कोई अंतर्निहित तरीका नहीं था — इस सीमा ने प्रतिस्पर्धी मॉड्यूल फॉर्मेट के एक पूरे इकोसिस्टम को जन्म दिया। आज, डेवलपर्स require(), import, .mjs, .cjs, AMD और UMD का सामना करते हैं, अक्सर एक ही प्रोजेक्ट में। यह गाइड हर मॉड्यूल सिस्टम को स्पष्ट करता है, बताता है कि प्रत्येक का उपयोग कब करना है, और आगे का स्पष्ट रास्ता दिखाता है।