`<br>` टैग के नज़रिए से वेब के 30 साल

 (artmann.co)
28 पॉइंट द्वारा GN⁺ 2025-12-17 | 6 टिप्पणियां | WhatsApp पर शेयर करें
  • 1990s के static web से लेकर 2010s के JavaScript-केंद्रित web और 2020s के AI युग के web तक के बदलावों को ट्रैक करते हुए, यह लेख बताता है कि web development कैसे evolve हुआ है
  • <br> टैग और FTP से शुरू हुआ web, PHP·MySQL से गुजरते हुए तेज़ी से ऐसा platform बना जिसे कोई भी बना सकता था
  • 2000s में Rails, Git, Heroku के बाद web development को structured·automated·collaboration-केंद्रित industry के रूप में फिर से संगठित किया गया, जिसने cloud और mobile युग की नींव रखी
  • 2010s में React, build chain, Docker और Node ecosystem के उभार ने web को दस्तावेज़ नहीं बल्कि एक वास्तविक application platform के रूप में स्थापित कर दिया
  • 2020s में ChatGPT और Copilot ने code लिखने का तरीका बदल दिया, और AI developer productivity को कई गुना बढ़ाने वाला नया turning point बना
  • ये सभी बदलाव, complexity की कीमत पर, web के जन-लोकतंत्रीकरण की प्रक्रिया में बदल गए, जिसने अधिक लोगों को और बड़ी चीज़ें बनाने में सक्षम बनाया

The Static Web - static web का युग

"View Source was how you learned"

  • 1990s के उत्तरार्ध (late 90s) में web एक ऐसी frontier था जिसके बारे में किसी को नहीं पता था कि यह क्या बनेगा, और यही अनिश्चितता उसकी सबसे बड़ी आकर्षण थी
  • personal websites की शुरुआत किसी company या organization से नहीं, बल्कि व्यक्तिगत server और folder स्तर से होती थी
    • Unix server पर रखा गया personal directory, HTML files और सिर्फ एक FTP client होने भर से इंटरनेट पर अपनी जगह बनाई जा सकती थी
    • Notepad जैसे साधारण text editor से लिखकर तुरंत publish करना संभव था
  • उस दौर का web censor और approval process से मुक्त रचनात्मक space था
    • खाना पकाने, dinosaur, गानों जैसे interest-based विषयों पर खुली पोस्टिंग
    • "इस हफ़्ते मुझे जो दिलचस्प लगा" उसे तुरंत पोस्ट कर देने वाली संरचना
  • सीखने का तरीका पूरी तरह खुद देखकर और वैसा ही करके सीखने वाला था
    • YouTube tutorials या Stack Overflow मौजूद नहीं थे
    • किसी दूसरी site को समझना हो तो right-click → View Source ही मूल learning tool था
    • और गहराई से सीखना हो तो असली कागज़ी किताबें पढ़नी पड़ती थीं
  • Core Java जैसी सैकड़ों पन्नों वाली technical books को साथ रखकर, code और किताब के बीच आते-जाते हुए सीखना आम बात थी
    • यह धीमा था, लेकिन ऐसा learning experience देता था जिसमें ज्ञान लंबे समय तक टिकता था
  • HTML में structure और style आपस में मिले-जुले थे
    • <table>, <font>, <center> टैग एक साथ layout और style दोनों संभालते थे
    • 1x1 transparent GIF (spacer GIF) से spacing ठीक की जाती थी
    • यह खुरदरा और inefficient था, लेकिन काम करता था
  • CSS मौजूद तो था, लेकिन व्यावहारिक रूप से mainstream नहीं था
    • ज़्यादातर styling inline attributes या HTML tags के भीतर ही की जाती थी
    • layout nested tables से बनाया जाता था
  • dynamic features के लिए entry barrier बहुत ऊँचा था
    • guestbook, visitor counter जैसी basic features के लिए भी CGI scripts चाहिए होती थीं
    • इन्हें Perl या C में लिखना पड़ता था, और सिर्फ एक URL parameter संभालने के लिए भी बहुत code चाहिए होता था
    • इसी complexity ने dynamic web के प्रसार को काफ़ी हद तक सीमित कर दिया
  • common layout की समस्या का लगभग कोई समाधान नहीं था
    • header·navigation·footer को हर HTML file में copy/paste करना पड़ता था
    • बदलाव होने पर सभी files को संशोधित करना पड़ता था
    • <iframe> से common elements डालने का तरीका भी था, लेकिन उसके side effects काफ़ी थे
  • browser compatibility तब भी एक गंभीर समस्या थी
    • Netscape Navigator (1994) और Internet Explorer (1995) अलग-अलग rendering results देते थे
    • किसी खास browser और resolution के लिए चेतावनी लिखना वास्तव में ज़रूरी होता था
  • इसके बावजूद उस दौर के web में जबरदस्त आकर्षण था
    • print या broadcast equipment के बिना भी दुनिया भर में कुछ publish किया जा सकता था
    • web ने पहली बार अभिव्यक्ति के साधनों का लोकतंत्रीकरण संभव किया
  • GeoCities (1994), Angelfire (1996) जैसी free hosting services ने लाखों लोगों को रचनात्मक space दिया
    • web ring के ज़रिए fan sites और communities आपस में जुड़ती थीं
    • अव्यवस्थित, लेकिन जीवंत ecosystem बन रहा था
  • कंपनियों में अभी "web team" जैसी कोई स्पष्ट अवधारणा लगभग नहीं थी
    • अगर website होती भी थी, तो ज़्यादातर उसे वही बनाता था जिसे "computer की समझ" हो
    • web developer के एक पेशे के रूप में स्थापित होने से ठीक पहले का यह चरण था
  • tools आदिम थे और sites भद्दी दिखती थीं, लेकिन
    • ऐसी जगह जहाँ कोई भी बना और साझा कर सके — यह मूल विचार इसी दौर में जड़ें जमा गया
  • <br> टैग और जुनून के सहारे टिका यह युग, बाद की पूरी web evolution का शुरुआती बिंदु बना

LAMP स्टैक और Web 2.0

"Everything was PHP and MySQL"

  • 2000 का dot-com bubble crash होने के बाद भी वेब बढ़ता रहा, और यह दौर कुछ बनाना चाहने वाले लोगों के लिए entry barrier के तेज़ी से घटने वाला turning point बना
  • static web दौर की सबसे बड़ी breakthrough PHP(1995) थी
    • CGI के लिए C या Perl में सैकड़ों लाइनें लिखने वाले दौर से, URL parameters को $_GET['name'] की एक लाइन से पढ़ पाने का अनुभव एक निर्णायक बदलाव था
    • compile, memory management, और जटिल error messages के बिना सिर्फ save करके refresh करने से चीज़ें चलने लगती थीं
    • XAMPP(2002) ने Apache·MySQL·PHP को एक साथ install करना संभव बनाया और local development environment सेटअप को क्रांतिकारी रूप से आसान कर दिया
    • PHP ने static web दौर की layout reuse की समस्या को पहली बार सही मायने में हल किया
      • include 'header.php' की एक लाइन से common header·footer manage किए जा सकते थे
      • एक बार edit करने पर पूरी site बदल जाने का अनुभव बेहद रोमांचक था
    • भाषाई कमियों के बावजूद PHP की ताकत accessibility थी
      • HTML और logic आपस में घुलमिल जाते थे, function naming consistent नहीं थी, और security API कमजोर थी
      • फिर भी इसे weekend में सीखकर असली service बनाई जा सकती थी
      • shared hosting($5/माह), cPanel(1996), और phpMyAdmin(1998) के default उपलब्ध होने से online entry barrier इतिहास में सबसे नीचे आ गई
  • PHP के साथ लगभग एक सेट की तरह जुड़ा database था MySQL(1995)
    • लगभग सभी tutorial·hosting·CMS MySQL को आधार मानकर बने थे
    • functionality के लिहाज़ से यह काफी था, लेकिन international text handling में यह लगातार दर्द देता था
    • default encoding latin1 थी, और UTF-8 को सही तरह इस्तेमाल करने के लिए
      • database settings, connection encoding, और HTML charset declaration — सबको सही तरह match करना पड़ता था
    • “ä की जगह ä” वाली समस्या इस दौर के प्रतीकात्मक trauma के रूप में रह गई
  • WordPress(2003) ने वेब की प्रकृति ही बदल दी
    • coding जाने बिना भी 5 मिनट install के बाद तुरंत publish किया जा सकता था
    • सिर्फ theme चुनकर और पोस्ट लिखकर site चलाई जा सकती थी
    • इसने website creation के जनसामान्यीकरण को वास्तविक रूप दिया
    • non-technical users के लिए WordPress एक मुक्ति जैसा था
      • blogger, छोटे कारोबारी, artist, और restaurant तक — हर कोई अपनी website रख सकता था
      • “ब्लॉगर” नाम की एक नई पहचान उभरी
      • WordPress admin screen इतनी फैली कि उसे ही “website editor” समझा जाने लगा
    • developers के लिए WordPress लगभग एक universal tool बन गया
      • blog, portfolio, corporate site, community, और e-commerce तक — सब WordPress
      • WooCommerce(2011) के साथ इसने e-commerce को भी समेट लिया
      • तेज़ implementation की कीमत पर plugin बिखराव और theme customization आधारित technical debt जमा होती गई
  • वेब की संभावनाओं को बुनियादी रूप से फिर से परिभाषित करने वाली घटना थी Gmail(2004) का लॉन्च
    • जब Hotmail और Yahoo Mail कुछ MB storage देते थे
    • 1GB free storage एक चौंका देने वाला आंकड़ा था
    • “delete मत करो, search करो” वाला संदेश उपयोग के एक नए तरीके का प्रस्ताव था
    • Gmail का असली innovation storage नहीं बल्कि experience था
      • page refresh के बिना mail पढ़ने·लिखने·बदलने वाला interface
      • AJAX(XMLHttpRequest) आधारित asynchronous communication का व्यापक उपयोग
      • इसने साबित किया कि वेब सिर्फ document नहीं बल्कि application भी हो सकता है
  • Google Maps(2005) ने इस संभावना को एक कदम और आगे बढ़ाया
    • click और drag से map को move करना
    • background में tile load होने वाला natural interaction
    • इसी समय Web 2.0 शब्द सचमुच जम गया
    • बिना refresh वाला UI, rounded corners, gradients, और shadows वेब की default language बन गए
  • media और social क्षेत्र में भी निर्णायक बदलाव जारी रहे
    • video क्षेत्र में YouTube(2005) ने पूरा परिदृश्य बदल दिया
      • RealPlayer·QuickTime·Windows Media Player जैसे plugin hell का अंत
      • यह Flash आधारित था, लेकिन “click करते ही तुरंत play” होने वाला अनुभव देता था
      • video अब तकनीकी समस्या नहीं बल्कि अभिव्यक्ति का माध्यम बन गया
    • Twitter(2006) ने 140-character microblogging के साथ संचार का नया तरीका पेश किया
    • Facebook(2006) के आम users के लिए खुलने के साथ social network mainstream में आ गया
    • वेब consumption media से participatory platform में बदल गया
      • एक ऐसी संरचना बनी जिसमें कोई भी publisher और creator बन सकता था
  • इन सारे बदलावों के बावजूद JavaScript अब भी कष्टदायक था
    • browsers के बीच DOM·event·AJAX implementation differences और IE6 compatibility समस्याओं के कारण endless debugging होती थी
    • jQuery(2006) ने इस अव्यवस्था का लगभग अंत कर दिया
      • $('#el').hide() हर browser में एक जैसा काम करता था
      • $.ajax() ने asynchronous communication को आसान बनाया
      • कई developers के लिए jQuery ही JavaScript बन गया था
        • साथ ही यह browser behavior को सीधे समझने से बचाने वाले buffer की तरह भी काम करता था
    • इस दौर की समस्याओं को बाद में जाकर समस्या के रूप में पहचाना गया
      • SQL Injection और XSS tutorial स्तर पर ही व्यापक थे
      • user input को सीधे query में जोड़ने वाला code आम बात थी
  • version control में Subversion(2000) मुख्यधारा था
    • commit भारी लगते थे और branch से बचा जाता था
    • final_final_REAL जैसे folder नाम रोज़मर्रा की बात थे
  • execution environment के standardization का अभाव
    • local में Windows + XAMPP
    • server में Linux + अलग PHP version
    • “works on my machine” बार-बार दोहराया जाता था
  • package manager की अवधारणा भी नहीं थी
    • JS के लिए ZIP download करके /js folder में manual management
    • PHP libraries file copy के आधार पर इस्तेमाल होती थीं
  • team structure और development process बहुत अनौपचारिक थे
    • PM·EM की भूमिका लगभग नहीं थी
    • code review नहीं था
    • FTP upload के बाद सीधे production में लागू
    • outage होने पर production server पर तुरंत edit
  • इसके बावजूद इस दौर की ऊर्जा बहुत प्रबल थी
    • PHP और सस्ती hosting के साथ हर कोई deploy कर सकता था
    • AJAX के साथ “real app” बनाया जा सकता है — यह एहसास फैल रहा था
    • social platforms के साथ हर किसी के पास audience हो सकती थी
  • वेब development के professionalization और structuring की बस शुरुआत हो रही थी
    • Ruby on Rails(2004) ने “Convention over Configuration” के साथ अधिक structured अगले दौर का संकेत दिया
  • इस दौर के developers LAMP stack, jQuery plugins, और
    • “अगली बड़ी service बनाएंगे” वाली उम्मीद के बीच वेब बना रहे थे

फ्रेमवर्क युद्ध

"Rails ने सब कुछ बदल दिया, फिर सबने उसकी नकल की"

  • 2000 के दशक के उत्तरार्ध (late 2000s) में वेब एप्लिकेशन का आकार बढ़ने लगा, और मौजूदा PHP स्क्रिप्ट व मैनुअल-केंद्रित संरचना अपनी सीमाओं तक पहुँच गई

  • इस दौर के समाधान के रूप में फ्रेमवर्क-केंद्रित डेवलपमेंट मॉडल उभरा, और इस प्रवाह को निर्णायक रूप देने वाला था Ruby on Rails(2004)

    • RoR का वास्तविक प्रभाव 2007–2008 के आसपास से गंभीर रूप से दिखना शुरू हुआ
    • “Convention over Configuration” दर्शन के तहत फ़ाइल संरचना, naming और connection का तरीका फ्रेमवर्क खुद तय करता था
    • डेवलपरों को बस नियमों का पालन करना होता था, और इसे बंधन नहीं बल्कि गति देने वाली आज़ादी के रूप में देखा गया

  • Rails ने बाद में वेब डेवलपमेंट की बुनियादी व्याकरण बन जाने वाले कई कॉन्सेप्ट एक साथ पेश किए

    • डेटाबेस बदलावों को code के रूप में मैनेज करने वाली migration
    • SQL पर निर्भरता को काफी कम करने वाला ORM
    • testing को डिफ़ॉल्ट रूप से शामिल करने वाला डेवलपमेंट फ़्लो
    • MVC(Model–View–Controller) संरचना का व्यावहारिक मानकीकरण
    • MVC का विचार 1970 के दशक के Smalltalk से आया था, लेकिन Rails के ज़रिए यह वेब डेवलपमेंट का बुनियादी रूप बन गया
    • Rails की सफलता के बाद लगभग हर language ecosystem ने इस फ़ॉर्मूले को अपनाया
      • Django(2005) ने Python में, और Laravel(2011) ने PHP में Rails-शैली की संरचना को स्थापित किया
      • CakePHP(2005) और CodeIgniter(2006) भी इसी प्रवाह के ऊपर विकसित हुए
    • प्रोडक्टिविटी में बढ़ोतरी कोई अतिशयोक्ति नहीं थी
      • एक अकेला डेवलपर वीकेंड में उतना बना सकता था, जितना पहले टीम-स्तर का काम माना जाता था
      • startup माहौल में तेज़ी से experiment और iteration के लिए यह बेहतरीन टूल साबित हुआ
    • वास्तव में कई प्रमुख सेवाएँ Rails पर बढ़ीं
      • Basecamp(2004), Twitter(2006), GitHub(2008), Shopify(2006), Airbnb(2008)
      • Rails जल्द ही startup speed के प्रतीक की तरह देखा जाने लगा

  • फ्रेमवर्क ने प्रोडक्टिविटी बढ़ाई, लेकिन deployment अब भी bottleneck था

    • PHP युग में deployment के लिए FTP upload आम था, और एक गलती से पूरी सेवा बिगड़ सकती थी
    • बेहतर स्थिति में भी SSH + SVN pull + Apache restart जैसे काम मैनुअली करने पड़ते थे
    • release directory अलग करना, symbolic link बदलना जैसी प्रक्रियाएँ पूरी तरह custom और fragile थीं

  • इस समस्या को बुनियादी रूप से बदलने वाला था Heroku(2007), जो 2009–2010 के आसपास से तेज़ी से फैलने लगा

    • git push heroku main की एक लाइन से deployment पूरा हो जाने का अनुभव दिया
    • server configuration, web server restart और scaling को platform खुद संभालता था
    • Heroku ने बाद में PaaS(Platform as a Service) कहलाने वाले कॉन्सेप्ट को व्यवहारिक रूप से स्थापित किया
      • डेवलपर का रोल infrastructure से हटकर सिर्फ code पर फ़ोकस करने वाला हो गया
      • Twelve-Factor App(2011) सिद्धांतों को लोकप्रिय बनाते हुए stateless process, environment variable-आधारित configuration और log streaming जैसी cloud-friendly सोच को फैलाया

  • इसी समय collaboration के तरीक़े में बड़ा बदलाव भी साथ-साथ हुआ

    • Git(2005) ने distributed version control model पेश किया, जिससे लोकल में स्वतंत्र commit·branch·merge संभव हुआ, और branch cost लगभग शून्य होने से experiment और rollback रोज़मर्रा का काम बन गया
    • पुराना Subversion(2000) केंद्रीकृत संरचना पर आधारित था, जिसमें branch भारी होती थी और merge डर की चीज़ माना जाता था, इसलिए कई टीमें trunk-केंद्रित डेवलपमेंट पर निर्भर थीं
    • Git टूल-स्तर की क्रांति था, लेकिन GitHub(2008) ने public repository discovery, fork-आधारित डेवलपमेंट और Pull Request-केंद्रित collaboration को जोड़कर इसे संस्कृति बना दिया
    • GitHub ने code review संस्कृति को मानकीकृत किया
      • PR merge होने से पहले किसी न किसी को code देखना ही होता था
      • यह प्रवाह कंपनी के अंदरूनी डेवलपमेंट तक फैल गया
      • वह दौर खत्म हुआ जब code सीधे production में चला जाता था
    • open source योगदान का तरीका mailing list पर patch भेजने से बदलकर बटन क्लिक करके PR submit करने वाला हो गया, जिससे भागीदारी की बाधा बहुत कम हुई

  • इस दौर के उत्तरार्ध में वेब की पहचान को हिलाने वाले बदलाव भी आए

    • iPhone(2007) और App Store(2008) के लॉन्च के साथ native app तेज़ी से उभरे
    • उस समय mobile web बहुत खराब था। desktop साइट को छोटा करके किसी तरह देखने का अनुभव, साथ में horizontal scroll और बार-बार zoom in/out
      • कुछ ने m.example.com जैसी अलग mobile साइटें बनाईं, लेकिन उनकी सीमाएँ स्पष्ट थीं
    • native app तेज़ थे, offline support देते थे, push notification देते थे, और “There’s an app for that” जैसे नारे के साथ भविष्य जैसे लगते थे
    • वेब डेवलपर पहचान के संकट से जूझने लगे: क्या वेब पर बने रहना चाहिए? क्या Objective-C सीखना चाहिए? क्या वेब गायब हो जाएगा?

  • इस उलझन के जवाब के रूप में Responsive Web Design(2010) आया

    • Ethan Marcotte(2010) ने CSS media query का उपयोग करके screen size के अनुसार layout बदलने का तरीका पेश किया, और mobile व desktop को एक codebase में जोड़ने की दिशा दिखाई
    • शुरुआत में टूल्स की अपरिपक्वता और अतिरिक्त काम के बोझ के कारण इसका प्रसार धीमा था, लेकिन वेब को किस दिशा में जाना है, यह साफ़ हो गया

  • Bootstrap(2011) वह मोड़ था जिसने responsive web को वास्तविक मैदान में उपयोगी बनाया

    • Twitter के internal tool के रूप में शुरू होकर इसने grid system, default typography और form style एक साथ दिए, जिससे बिना designer वाले डेवलपर भी तुरंत उपयोगी UI बना सके
    • नतीजतन वेब धीरे-धीरे एक जैसा दिखने लगा, लेकिन कई डेवलपरों के लिए Bootstrap पहला component library और design system अनुभव बना
    • यह प्रवाह आगे चलकर Material Design(2014) जैसे व्यवस्थित design system के प्रसार तक पहुँचा

  • infrastructure भी इसी समय तेज़ी से बदल रहा था

    • physical server पहले से खरीदने या किराए पर लेने वाले मॉडल से virtual server(VPS)-केंद्रित संरचना की ओर बदलाव हुआ, और ज़रूरत पड़ने पर server resource बनाना संभव हुआ
    • AWS(2006) सबसे पहले आया, लेकिन उसकी जटिलता और enterprise-केंद्रित प्रकृति के कारण व्यक्तिगत डेवलपरों के लिए वह भारी था
    • DigitalOcean(2011) ने $5 droplet, intuitive UI और तेज़ server provisioning अनुभव के साथ infrastructure की पहुँच काफी आसान कर दी, जिससे व्यक्तिगत डेवलपरों को भी बड़े उद्यमों जैसी लचीलापन मिल सका

  • फ़ाइल स्टोरेज की समस्या को Amazon S3(2006) ने लगभग व्यावहारिक रूप से हल कर दिया

    • इसने server की संख्या से स्वतंत्र रूप से scale होने वाला storage और upload के बाद तुरंत URL लौटाने वाला सरल मॉडल दिया
    • user upload, backup और multi-server environment में file management की समस्याएँ एक साथ सुलझ गईं

  • Node.js(2009) ने वेब डेवलपरों को एक और झटका दिया

    • Chrome V8 इंजन के आधार पर server पर JavaScript चलाना संभव हुआ, जिससे frontend डेवलपरों को यह आकर्षक विकल्प लगा, जबकि backend डेवलपेरों की ओर से संदेहपूर्ण प्रतिक्रिया आई
    • non-blocking I/O model ने real-time application में ताकत दिखाई, और अधिकतर tutorial का निष्कर्ष chat app उदाहरण पर जाकर रुकता था
    • इस समय Node अभी production mainstream कम और जिज्ञासा का विषय ज़्यादा था, वास्तविक सेवाएँ अब भी Rails·Django·PHP केंद्रित थीं, और npm ecosystem भी शुरुआती चरण में था
    • लेकिन बाद में Node का असली प्रभाव server से ज़्यादा build tool और development environment के execution base के रूप में पहले सामने आया

  • database क्षेत्र में NoSQL प्रवाह उभरा

    • MongoDB(2009) ने document-आधारित data model, schema flexibility और JSON-friendly संरचना के कारण ध्यान खींचा
    • तेज़ prototyping, scalability और JavaScript stack के साथ तालमेल में इसकी ताकत थी, लेकिन यह हर सेवा के लिए उपयुक्त नहीं था
    • “शायद कभी scale करना पड़े” इस वजह से इसे चुन लिया जाता था, और फिर कुछ हज़ार users के स्तर पर transaction limits का अहसास होने वाले मामले भी आम थे

  • startup ecosystem इस दौर में गंभीर विकास चरण में प्रवेश कर गया

    • Marc Andreessen(2011) के “Software is eating the world” घोषणा और Lean Startup(2011) methodology के प्रसार के साथ MVP → measurement → iteration cycle स्थापित हो गया

  • टूल्स की परिपक्वता के साथ छोटे-से-छोटे टीमों की प्रतिस्पर्धात्मक क्षमता वास्तव में काम करने लगी

  • डेवलपमेंट प्रोसेस भी बदला

    • Agile Manifesto(2001) और Scrum के लोकप्रिय होने के साथ stand-up, sprint और retrospective लगभग मानक की तरह अपनाए गए
    • कई टीमें ऐसी भी उभरीं जिनमें सिद्धांतों से ज़्यादा सिर्फ़ औपचारिकताएँ ही बचीं
    • code review और automated testing सिफारिश से आगे बढ़कर बुनियादी अपेक्षा बन गए, और CI सिस्टम हर commit पर tests चलाने लगे, जिससे software development का पेशेवरकरण और विशेषज्ञता तेज़ हुई

  • हालांकि आज जिन भूमिकाओं को स्वाभाविक माना जाता है, वे तब तक पूरी तरह स्थापित नहीं हुई थीं

    • 2012 के मानक से engineer manager, product manager, और व्यवस्थित backlog या ticket management के बिना काम करने वाली टीमें आम थीं
    • छोटी टीमें और सपाट organizational structure सामान्य थे, और “senior developer” का सिर्फ़ 3 साल के अनुभव वाला होना भी असामान्य नहीं था

  • 2013 के आसपास वेब पूरी तरह अलग रूप ले चुका था

    • शक्तिशाली frameworks, आसान deployment, social code collaboration, mobile support, सस्ता infrastructure, और JavaScript का व्यापक प्रसार एक साथ स्थापित हो चुके थे
    • mobile crisis को पार कर चुका वेब उल्टे और मज़बूत हो गया, और अगले चरण यानी JavaScript के सब कुछ अपने नियंत्रण में लेने के युग के लिए तैयार हो चुका था

JavaScript पुनर्जागरण

"Everything is a SPA now"

  • 2013 के आसपास, वेब पहले ही Gmail·Google Maps जैसे उदाहरणों के ज़रिए यह साबित कर चुका था कि वह “वास्तविक applications” संभाल सकता है, लेकिन पारंपरिक jQuery + server rendering तरीका धीरे-धीरे अपनी सीमाओं से टकराने लगा :contentReference[oaicite:0]{index=0}
  • मुख्य समस्या state management थी
    • जिस संरचना में server HTML बनाता है और jQuery से interaction जोड़ा जाता है, उसमें data और UI को कई जगहों पर एकसमान बनाए रखना तेज़ी से कठिन हो जाता था
    • comment, count, notification badge की तरह जब एक ही state कई UI में दिखनी होती, तो code उलझकर spaghetti structure में बदल जाता
  • इसके जवाब में आम निष्कर्ष यह था कि rendering पूरी तरह client पर ले जाई जाए
    • server की भूमिका घटकर JSON लौटाने वाले API तक सीमित हो गई
    • browser में JavaScript पूरे UI को संभालने वाली SPA(Single Page Application) संरचना उभरकर सामने आई
  • शुरुआती SPA frameworks इसी दौर में आए
    • Backbone.js(2010) ने model और view की अवधारणा के साथ न्यूनतम संरचना दी
    • Angular(2010) ने two-way data binding और dependency injection लाकर enterprise-style approach अपनाने की कोशिश की
    • Ember.js(2011) ने routing·data·template सबको शामिल करते हुए “JavaScript का Rails” बनने के लक्ष्य के साथ कड़े नियम पेश किए
    • ये frameworks एक बड़ा कदम थे, लेकिन साझा रूप से वे DOM और data synchronization की complexity की समस्या को पूरी तरह हल नहीं कर पाए
      • खासकर two-way binding update flow को ट्रैक करना कठिन बना देती थी और debugging की लागत बढ़ाती थी
  • मोड़ का बिंदु React(2013) के आगमन से आया
    • जब Facebook ने इसे open source के रूप में जारी किया, तब JSX syntax को separation of concerns को उल्टा कर देने जैसा माना गया और इसने असहजता पैदा की
    • लेकिन React ने DOM को सीधे manipulate करने के बजाय, state के अनुसार UI के परिणाम को declaratively लिखने का नया सोचने का तरीका पेश किया
    • React का मूल declarative model और Virtual DOM था
      • state बदलने पर React केवल न्यूनतम DOM changes की गणना करके उन्हें लागू करता था
      • developer DOM manipulation की चिंता किए बिना state management पर ध्यान दे सकता था
    • component की अवधारणा भी निर्णायक थी
      • Button, UserAvatar, CommentList जैसी छोटी इकाइयों को मिलाकर UI बनाया जाता था
      • हर component को स्वतंत्र रूप से सोचा और दोबारा इस्तेमाल किया जा सकता था
    • React धीरे-धीरे फैला और लगभग 2015 तक मुख्यधारा में स्थापित हो गया
      • Vue.js(2014) ने समान अवधारणाएँ अधिक परिचित syntax के साथ दीं और एक विकल्प के रूप में उभरा
      • framework war एक नए चरण में प्रवेश कर गई
  • SPA के प्रसार का मतलब JavaScript की मात्रा में विस्फोटक वृद्धि था
    • समस्या यह थी कि developer जिस JavaScript का इस्तेमाल करना चाहते थे और browser जिस JavaScript को समझता था, वे अलग थे
  • ES6 / ES2015(2015) ने arrow function, class, module, promise जैसी बड़े पैमाने की language improvements पेश कीं
    • callback hell और var self = this pattern के गायब होने से JavaScript पहली बार सचमुच एक आधुनिक भाषा जैसा महसूस होने लगा
  • लेकिन browser support पीछे था, इसलिए इसे ज्यों का त्यों deploy करना संभव नहीं था
  • Babel(2014) ने नवीनतम JavaScript को ES5 में बदलने वाले transpiler के रूप में इस समस्या को हल किया
    • इसकी कीमत यह रही कि JavaScript development में build step एक अनिवार्य तत्व बन गया
    • file बदलकर सिर्फ refresh कर लेने वाले युग का अंत हो गया
  • इस प्रक्रिया में Node.js(2009) ने server के रूप में नहीं, बल्कि development tool runtime environment के रूप में हर developer machine पर कब्ज़ा कर लिया
    • backend में Node का इस्तेमाल न भी हो, तब भी build tools के कारण Node install करना अनिवार्य हो गया
  • build tool chain भी तेज़ी से विकसित हुई
    • Grunt(2012) ने task runner के रूप में जटिल build steps को config files से manage किया
    • Gulp(2013) ने code-based pipeline के ज़रिए इसे सरल बनाने की कोशिश की, लेकिन यह फिर भी जटिल रहा
  • निर्णायक बदलाव Webpack(2014) था
    • यह सिर्फ task runner नहीं, बल्कि dependency graph को समझने वाला module bundler था
    • JavaScript, CSS, image, font तक सबको module की तरह माना गया
    • code splitting, hot module replacement जैसी अवधारणाएँ पेश की गईं
    • इसकी ताकत की कीमत इसकी कुख्यात configuration थी
      • Webpack config एक meme बन गया, और हर team में “इसे समझने वाला एक व्यक्ति” मौजूद होता था
      • उसके चले जाने पर config एक ऐसी विरासत बन जाती थी जिसे छूने से भी डर लगे
  • साथ ही npm ecosystem में विस्फोटक वृद्धि हुई
    • library को सीधे download करने के तरीके से npm install केंद्रित मॉडल की ओर बदलाव हुआ
    • moment, lodash, यहाँ तक कि left-pad जैसी बेहद छोटी utility भी package के रूप में आने लगी
    • left-pad घटना(2016) ने ecosystem की नाज़ुकता उजागर की
      • सिर्फ 11 पंक्तियों वाले package के हटते ही हज़ारों project builds एक साथ fail हो गए
      • React और Babel तक install न हो पाने की स्थिति में पहुँच गए
      • npm ने अभूतपूर्व तरीके से package को force restore करके स्थिति संभाली
    • सुविधा बनी रही, लेकिन dependency hell की वास्तविकता को सबने पहचान लिया
  • 2016 में, complexity अपने चरम पर पहुँच गई
    • व्यंग्यात्मक लेख “How it feels to learn JavaScript in 2016” व्यापक रूप से फैला
    • एक साधारण web page बनाने के लिए React, Webpack, Babel, Redux जैसे अनगिनत tools की ज़रूरत पड़ने से थकान की भावना फैल गई
    • ecosystem का बदलाव इतना तेज़ था कि सीखी हुई knowledge जल्दी पुरानी हो जाती थी
    • फिर भी नतीजे साफ़ थे
      • ऐसे interactive web applications बनाना संभव हो गया जो पहले असंभव थे
      • complexity को ambition की लागत के रूप में स्वीकार किया गया
  • दूसरी ओर Docker(2013) ने बिल्कुल अलग समस्या हल करनी शुरू की
    • “works on my machine” समस्या को container के ज़रिए हल किया गया
    • Dockerfile से runtime environment को define करके उसे कहीं भी एक जैसा चलाया जा सकता था
    • शुरुआती दौर में Mac environment की performance issues और networking confusion के कारण इसे अपनाना आसान नहीं था
      • Docker Compose, Docker Swarm, और बाद में Kubernetes(2014) के आने से orchestration war शुरू हो गई
      • लगभग 2017 तक, इतना तो स्पष्ट हो गया कि भविष्य containers का है
  • इसके साथ microservices ट्रेंड भी फैल गया
    • इसने service separation और independent deployment के फायदे दिए
    • लेकिन बदले में service discovery, load balancing, distributed tracing जैसी नई complexities आईं
    • कई teams को बाद में एहसास हुआ कि उन्होंने monolith की complexity को distributed systems की complexity से बदल दिया है
  • इस दौर में web applications की परिपक्वता स्पष्ट रूप से बढ़ी
    • Slack(2013) ने तेज़ और searchable collaboration tool के रूप में email की जगह ली
    • Figma(2016) ने browser-based collaborative design tool के रूप में desktop apps के क्षेत्र में प्रवेश किया
    • Notion(2016) आदि के साथ मिलकर इसने साबित किया कि web desktop-grade software लागू कर सकता है
    • ये उदाहरण React·Webpack·build chain की complexity को सही ठहराने का आधार बने
  • संगठनात्मक संरचना भी परिपक्व चरण में पहुँची
    • 2016 के आसपास, product manager और engineering manager मानक भूमिकाओं के रूप में स्थापित हो गए
    • शुरुआती flat team structure धीरे-धीरे process-centered organization में बदल गई
    • Scrum और agile rituals व्यापक हुए, और team के अनुसार वे कभी tool बने, कभी औपचारिकता
  • 2017 में, ecosystem धीरे-धीरे स्थिरता के चरण में दाखिल हुआ
    • React व्यवहारतः विजेता बन चुका था
    • ES6 बुनियादी syntax बन गया था
    • Webpack और Docker दर्दनाक होने के बावजूद standards के रूप में स्वीकार किए गए
  • अगला चरण पहले ही संकेत दे चुका था
    • TypeScript का उभार
    • Next.js जैसे meta-frameworks
    • अधिक सरल deployment experience
  • लेकिन उसकी एक ही शर्त थी
    • केवल वे developers जिन्होंने इस JavaScript पुनर्जागरण की अराजकता को पार किया था, अगले चरण तक बढ़ सके

TypeScript का युग

"Types are good, actually"

  • JavaScript renaissance के बाद tools की बेतरतीब बढ़ोतरी थमने लगी और ecosystem maturity phase में प्रवेश करने लगा; इसी संक्रमण बिंदु पर TypeScript ने अपनी जगह बनाई
  • TypeScript(2012) ने JavaScript में static types जोड़े, लेकिन शुरुआत में dynamic language की philosophy और build step के अतिरिक्त बोझ के कारण इसे लंबे समय तक नज़रअंदाज़ किया गया
    • जैसे-जैसे application का आकार बढ़ा, dynamic typing की सीमाएं और स्पष्ट होती गईं
      • function signature बदलने के बाद call sites को ट्रैक करने की लागत बढ़ना
      • object shape समझना मुश्किल होने से code readability की समस्या
      • साधारण typo के production outage तक पहुंचने के दोहराए गए मामले
    • 2017–2018 के आसपास TypeScript adoption तेज़ी से फैलने लगा
      • auto-completion और static analysis के ज़रिए refactoring की reliability सुनिश्चित हुई
      • interfaces ने code के साथ sync रहने वाले enforced documentation की भूमिका निभाई
    • प्रमुख frameworks द्वारा अपनाया जाना turning point साबित हुआ
      • Angular ने TypeScript-first strategy अपनाई
      • React type definitions के mature होने और Vue 3 के TypeScript-आधारित rewrite के साथ इसे de facto standard माना जाने लगा
      • 2020 के आसपास pure JavaScript में नए projects लगभग चुने ही नहीं जाने लगे
    • TypeScript ने codebase की accessibility को काफी बेहतर बनाया
      • नए जुड़ने वाले लोग केवल type definitions पढ़कर भी domain model समझ सकते थे
      • implicit knowledge पर निर्भरता घटने से team scaling की लागत कम हुई
  • VS Code(2015) के साथ इसका संयोजन development experience को निर्णायक रूप से बदल गया
    • intelligent auto-completion, inline error display, और भरोसेमंद refactoring उपलब्ध हुए
    • Sublime Text और Atom का प्रभाव धीरे-धीरे घटने लगा
  • React के ऊपर abstraction की एक और layer बनने लगी
    • React, एक UI library के रूप में, routing·data fetching·SSR के लिए कोई default solution नहीं देता था
  • Next.js ने file-based routing, server-side rendering, API routes, और automatic code splitting को default रूप में देने वाले meta framework के तौर पर इस खाली जगह को भरा
    • Nuxt, Remix, SvelteKit, Gatsby जैसे कई जवाबी frameworks भी सामने आए
    • React ecosystem में Next.js de facto default choice बन गया
  • meta framework के फैलाव से पिछले दौर की tooling fragmentation fatigue काफी हद तक कम हुई
    • webpack·Babel configuration को खुद जोड़ने-बनाने की प्रक्रिया default settings में समाहित हो गई
  • deployment environment भी तेज़ी से सरल हुआ
    • Vercel और Netlify ने केवल GitHub connection से automatic deployment और preview environments उपलब्ध कराए
    • designer·PM·QA merge से पहले ही वास्तविक environment में बदलाव देख सकते थे
  • Heroku का प्रभाव कमज़ोर पड़ा और Railway, Render जैसे नई पीढ़ी के PaaS उभरे
  • AWS Lambda(2014) के केंद्र में Serverless की अवधारणा फैली
    • usage-based billing और automatic scaling मिली
    • cold start, state management, और debugging limitations के कारण यह universal solution नहीं था
    • Cloudflare Workers ने इसे edge execution model तक विस्तार दिया
  • CSS क्षेत्र में भी एक शांत बदलाव चल रहा था
    • Sass·Less के बाद CSS-in-JS से होते हुए Tailwind CSS(2017) को व्यापक adoption मिला
    • utility class आधारित approach ने
      • class naming का बोझ हटाया
      • cascade·specificity की समस्याएं घटाईं
      • और नतीजतन छोटे stylesheet बनाए रखना आसान किया
  • GraphQL(2015) को जटिल data structures संभालने वाले applications में एक शक्तिशाली solution के रूप में देखा गया
    • precise data queries, type-based schema, और tooling ecosystem के फायदे मिले
    • लेकिन server layer की complexity और caching की कठिनाई के कारण simple CRUD के लिए यह overkill साबित हुआ
    • कुछ teams ने REST बनाए रखा या tRPC जैसे सरल विकल्प चुने
  • container orchestration की प्रतिस्पर्धा 2018 के आसपास Kubernetes की जीत पर आकर खत्म हुई
    • यह शक्तिशाली था, लेकिन सीखने की ऊंची लागत और operational complexity साथ लाया
    • कई teams के लिए यह जरूरत से ज़्यादा solution था, और यही PaaS के फिर उभरने की पृष्ठभूमि बना
  • COVID(2020) ने web development की मांग को अचानक बहुत बढ़ा दिया
    • remote work, e-commerce, और collaboration tools अनिवार्य बन गए
    • इससे developers की मांग में विस्फोट और developer tools कंपनियों की तेज़ growth हुई
  • remote environment में asynchronous collaboration और documentation का महत्व बढ़ा
    • code review, PR description, और internal docs की quality प्रमुख तत्व बन गई
  • organizational स्तर पर भी maturity आई
    • engineer level systems स्थापित हुए
    • IC track की वैधता मजबूत हुई
    • PM·EM·tech lead की भूमिकाएं अधिक स्पष्ट रूप से अलग हुईं
  • Developer Experience(DX) को स्वतंत्र investment target के रूप में पहचाना जाने लगा
    • internal platform teams, तेज़ CI, और onboarding सुधार productivity के मुख्य तत्व बनकर उभरे
  • 2022 के आसपास web development जटिल तो था, लेकिन manageable state तक पहुंच चुका था
    • TypeScript का default बन जाना
    • Next.js-केंद्रित ecosystem
    • deployment automation और mature tooling system
  • और फिर सब कुछ बदल गया: OpenAI नाम की कंपनी ने ChatGPT नाम की चीज़ जारी कर दी

AI का क्षण

"Wait, I can just ask it to write the code?"

  • ChatGPT(2022) के लॉन्च के साथ ऐसा अनुभव सामने आया जिसमें केवल प्रश्न लिखने पर explanation·code·debugging results मिलने लगे, और development के नियम बदल गए
    • यह quantum physics की व्याख्या से लेकर Python debugging तक कर सकता था, और भले यह perfect नहीं था, लेकिन इतना उपयोगी ज़रूर था कि चौंका दे
    • developers ने तुरंत प्रयोग शुरू कर दिए, और React components लिखना, errors के कारणों का विश्लेषण करना, तथा भाषाओं के बीच code conversion documentation search या forum browsing के बिना कुछ ही सेकंड में संभव हो गया
  • GitHub Copilot(2022) ने editor के भीतर auto-completion के रूप में code generation दिया और केवल comments से implementation सुझाने वाला बेहद शक्तिशाली auto-completion अनुभव फैलाया
    • AI suggestions को तेज़ी से evaluate·adopt·modify·reject करने की नई meta skill developers की मुख्य क्षमता बनकर उभरी
  • repetitive boilerplate, test writing, और edge case handling जैसे काम बहुत तेज़ हो गए, जिससे flow तोड़े बिना development संभव हुआ
  • Cursor(2023) एक ऐसा IDE बनकर आया जिसने AI को feature नहीं बल्कि precondition की तरह integrate किया; code चुनकर refactoring मांगना, natural language descriptions के आधार पर multi-file edits, और codebase के साथ बातचीत संभव हो गई
  • इस बदलाव ने seniority के अर्थ को हिलाया, लेकिन वास्तव में क्या बनाना है यह तय करने, requirements·constraints·side effects का आकलन करने की क्षमता का महत्व और बढ़ गया
    • AI code लिख सकता है, लेकिन समस्या को परिभाषित कर सही दिशा नहीं चुन सकता
  • चरम रूप में “programming का अंत” और “बेकार का hype” जैसी दो ध्रुवीय प्रतिक्रियाएं दिखीं, लेकिन वास्तविक परिणाम AI का उपयोग करने वाले developers की productivity amplification के रूप में सामने आया
  • personal·side projects की entry barrier तेज़ी से घटी, और जिन क्षेत्रों को पहले आज़माने की हिम्मत नहीं होती थी (ML·games·नए frameworks), वहां भी conversation-based learning से पहुंच संभव हो गई
  • यह प्रवाह web की पुरानी दिशा, यानी creation का democratization, को और तेज़ करने वाले चरण की तरह काम कर रहा है
    • code जानने से केंद्र हटकर क्या बनाना है यह जानने पर आ गया
  • non-developers भी prototype बनाने में शामिल होने लगे, और PM·designers·domain experts खुद tools बनाने लगे, जिससे technical और non-technical के बीच की सीमा धुंधली होने लगी
  • indie hackers और solo builders की संख्या बढ़ी, और अकेले भी वास्तविक product बना सकने वाला environment हकीकत बन गया
  • इसी दौरान React Server Components, htmx, बेहतर CSS·JavaScript standards, और Bun जैसे tools ने “platform को जैसा है वैसा ही इस्तेमाल करें” वाली धारा को और मजबूत किया
  • 2022–2023 के बड़े hiring boom के बाद layoffs जुड़ने से बाज़ार हिला, लेकिन AI ने developers को replace नहीं किया; बल्कि AI का प्रभावी उपयोग करना basic expectation बन गया
  • 2025 के समय-बिंदु पर web development idea से deployment तक की गति के लिहाज़ से इतिहास में सबसे तेज़ स्थिति में है,
    • और cloud·framework·AI के मिले-जुले environment में व्यक्ति पहले से कहीं अधिक शक्तिशाली creator बन गया है
  • &lt;br&gt; टैग से शुरू हुआ web का वादा, “कोई भी बना सकता है और साझा कर सकता है”, AI युग में और भी मजबूत रूप में जारी है
  • अभी web development करने के लिए वाकई शानदार समय है

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

6 टिप्पणियां

 
ethanhur 2025-12-19

मैंने इसे इतिहास की किताब की तरह दिलचस्पी से पढ़ा।
 
zihado 2025-12-19

Cafe24 पर एक server hosting ली थी, ZeroBoard इंस्टॉल करके उसे अपने हिसाब से community जैसा सजाकर खेलते थे, वो भी क्या दिन थे haha
 
lethee 2025-12-19

यह पढ़कर बहुत मज़ा आया। जैसे मरने से पहले ज़िंदगी की झलकियाँ आँखों के सामने से गुजरती हैं, वैसा एहसास हुआ, हाहा
 
edunga1 2025-12-17

दिलचस्पी से पढ़ा।
अगर development environment की ओर जाएँ, तो VS Code और LSP का आगमन आता है। और फिर इसे Tabnine के AI युग से पहले वाले tools तक भी जोड़ा जा सकता है।
 
aer0700 2025-12-17

https://hi.news.hada.io/topic?id=21170
इस लेख के साथ इसे भी देखना अच्छा रहेगा
 
GN⁺ 2025-12-17
Hacker News की राय

  • यह कहना पूरी तरह सही नहीं है कि हर पेज पर एक जैसा header, navigation और footer चाहिए था लेकिन उन्हें साझा करने का कोई तरीका नहीं था
    web server में Server Side Includes(SSI) फीचर होता था, और अगर उसे इस्तेमाल नहीं करना हो तो बस cat header body > file कमांड से भी यह हल किया जा सकता था
    संबंधित दस्तावेज़: NCSA SSI ट्यूटोरियल (1997)

    • HTML मूल रूप से SGML-आधारित vocabulary के रूप में बनाया गया था, इसलिए SGML और XML में सामान्य header या footer जैसे document fragments को refer करने के लिए entity/text macro फीचर मौजूद थे
    • शायद मूल टिप्पणी केवल शुद्ध HTML को आधार बनाकर कही गई थी

  • लगा कि लेख का अंत कुछ इस तरह होना अच्छा रहता: "...और उस पूरी प्रक्रिया के बीच भी, विनम्र <br> टैग अब भी अपना काम कर रहा है"

  • जिस कंपनी में मैं पहले काम करता था, वहाँ हर deployment पर एक नया folder बनाया जाता था और symbolic link को latest version पर switch कर दिया जाता था
    यह manual था, लेकिन हर server पर atomic switch संभव था और rollback भी आसान था, इसलिए यह मुझे बहुत elegant तरीका लगता था
    इससे पहले दर्जनों servers पर हाथ से files copy करनी पड़ती थीं और 10~20 steps के commands खुद चलाने पड़ते थे, उसके मुकाबले यह कहीं ज़्यादा सुरक्षित और सरल था
    बाद में automation tools भी आज़माए, लेकिन उनकी configuration जटिल और अपारदर्शी थी, इसलिए उल्टा वह और भी fragile deployment process बन गया

  • यह कहा गया है कि “CGI script लिखने के लिए Perl या C सीखनी पड़ती थी”, लेकिन मुझे संदेह था कि क्या सचमुच सैकड़ों lines चाहिए होती थीं
    वास्तव में simple C functions से भी URL parameters पढ़े जा सकते हैं
    मैंने हाल ही में pure C में एक survey website बनाई, और पहले से बनाई हुई HTML generation library की वजह से यह काफी आसान रहा
    OS की CGI library को refactor करके इस्तेमाल किया, और SQLite को statically link करके single binary के रूप में deploy किया
    web server के बिना भी stdin/stdout से test किया जा सकता था
    निष्कर्ष यह है कि CRUD website C में भी काफ़ी आसान है, और क्योंकि HTML एक tree structure है, string interpolation एक गलत approach लगती है

    • क्योंकि code पहला parameter मैच करता है जो <param> पर खत्म होता है, इसलिए यह exact match नहीं भी हो सकता, और percent encoding भी handle नहीं करता
    • HTML के tree structure को व्यक्त करने के नज़रिये से string interpolation अनुपयुक्त है, इस बात से मैं सहमत हूँ
      लेकिन 30 साल बाद भी ऐसा लगता है कि string interpolation अब भी सबसे आम tool है

  • यह सचमुच व्यापक और बहुत अच्छी तरह लिखा गया लेख था
    लेखक आशावादी है, लेकिन मुझे web development जुगाड़ों के ढेर से बना एक अस्थिर टावर जैसा लगता है
    मुझे लगता है कि web standardization कुछ browser vendors के हाथों में केंद्रित हो गई, और मूल समस्याओं को हल करने के बजाय बस ऊपर-ऊपर परतें चढ़ती गईं
    हाल के generative AI tools भी इस जटिलता को bypass करने के लिए अस्थायी समाधान भर हैं
    आखिरकार यह टावर किसी दिन ढह जाएगा, ऐसा मुझे लगता है

  • यह लेख शायद एक क्लासिक के रूप में बचा रहेगा
    इसमें उस web technology history को संक्षेप में समेटा गया है जिसे आज के developers अक्सर चूक जाते हैं

  • “Virtual private servers changed this…” वाला हिस्सा पढ़कर मुझे याद आया
    दरअसल शुरुआती VPS providers में से पहला लगभग 2001 के आसपास JohnCompanies था, और वह FreeBSD jail पर आधारित था
    ग्राहक remote backups चाहते थे, और rsync को पसंद करते थे
    इसलिए चार साल बाद मैंने rsync.net domain register किया (rsync/samba के authors से अनुमति लेकर)

  • मैंने 1998 से 2012 तक web development किया, और यह लेख पढ़ते हुए ऐसा लगा जैसे यादों की यात्रा पर निकल गया हूँ
    यह उसके बाद हुए बदलावों का भी एक नज़र में सार देता है

  • लेख की सामग्री web technology के प्रवाह के बारे में मेरी यादों से लगभग पूरी तरह मेल खाती है
    PHP से पहले का CGI झंझट भरा ज़रूर था, लेकिन mod_perl और FastCGI की वजह से इस्तेमाल लायक था
    compiled language में CGI लिखना लगभग masochism के बराबर था, और उस लिहाज़ से PHP हल्का-फुल्का और मज़ेदार था
    मैंने jQuery के उभरने से ठीक पहले frontend development छोड़ दिया था

  • यह सचमुच हैरान कर देने वाला लेख था
    इसमें सिर्फ तकनीकी timeline नहीं गिनाई गई, बल्कि हर दौर की zeitgeist को जीवंत ढंग से पहुँचाया गया है
    आम तौर पर जो मानवीय संदर्भ सिर्फ मौखिक परंपरा में बचे रहते हैं, उन्हें लेख में दर्ज करना प्रभावशाली लगा
    यह “हम इतनी जटिल cloud दुनिया तक क्यों पहुँचे” इसकी आलोचना करने के बजाय, हर समय की तार्किक पसंदों के जमा होते गए ऐतिहासिक परिणाम के रूप में समझने में मदद करता है
    तकनीकी इतिहास के भीतर मानवीय विडंबना महसूस की जा सकती थी