क्या हमने दक्ष software development में अपना रास्ता खो दिया है?

• लगभग 30MB Word दस्तावेज़ को ब्राउज़र में संपादित करते समय इनपुट लेटेंसी का सामना हुआ, और इससे आधुनिक web app की performance cost का व्यावहारिक एहसास हुआ
• दस्तावेज़ में अधिकांश हिस्सा text था और केवल कुछ images व tables शामिल थे, फिर भी Google Docs या Chrome वातावरण में यह सुचारु रूप से नहीं चल पाया
• पेड Microsoft Office के बजाय इंस्टॉल किए गए LibreOffice में वही दस्तावेज़ कहीं अधिक तेज़ चला, जिससे web app और native app के बीच का अंतर स्पष्ट हुआ
• आधुनिक web applications अधिक memory और CPU मांग रही हैं, जिससे यह सवाल उठता है कि hardware के high-spec होने की प्रवृत्ति कहीं resource-intensive web apps से जुड़ी तो नहीं
• PWA और browser-based UI के फैलाव के बावजूद, वास्तविक usability में native rendering और efficient software design अब भी महत्वपूर्ण हैं

---

30MB दस्तावेज़ से सामने आई web app performance समस्या

• Google account और cloud auto-sync का उपयोग किया जा सकता था, इसलिए पहले Google Docs चुना गया
• दस्तावेज़ को Google Docs पर अपलोड करने के बाद टाइप करके देखा गया, तो अक्षरों के स्क्रीन पर दिखने में कई सेकंड लग रहे थे
• फ़ाइल का आकार लगभग 30MB था, उसमें कुछ images और साधारण tables थे, लेकिन अधिकांश हिस्सा text ही था
• यह निष्कर्ष निकाला गया कि Chrome या Google Docs इस दस्तावेज़ को ठीक से handle नहीं कर पाए
• Microsoft Office पेड होने के कारण बाहर रखा गया, और उसके बजाय इंस्टॉल किए गए LibreOffice में वही दस्तावेज़ बहुत तेज़ चला

दक्षता को लेकर बड़ा सवाल

• यह सोचने पर मजबूर करता है कि क्या आधुनिक tools, frameworks और languages performance के मामले में software को और भारी बना रहे हैं
• resource-intensive web applications को संभालने के लिए hardware specs बढ़े हैं, और यदि केवल pure native apps होते तो शायद ऐसी मांग कम होती
• mobile devices में 16GB RAM की जरूरत वाली स्थिति का उदाहरण देकर software के बढ़ते resource usage पर सवाल उठाया गया
• यह तर्क दिया गया कि web को सिर्फ एक साधारण UI rendering engine wrapper बनकर नहीं रहना चाहिए, बल्कि उसमें native rendering जैसी efficiency होनी चाहिए
• 1966 के Apollo computer ने केवल 2KB RAM के साथ चंद्रमा पर लैंडिंग संभव की थी, लेकिन 2024 के browser में लगभग 30MB दस्तावेज़ पर काम करना भी कठिन है—यह तुलना optimization की जरूरत को रेखांकित करती है

[GN⁺]

Hacker News की राय

• अगर native app बनाना भी चाहें, तो लगता है Apple और Microsoft लगातार रास्ता रोकते रहते हैं। developer account, binary signing certificate, और बिना खास वजह के रेवेन्यू पर 30% कमीशन तक सहना पड़ता है, और खासकर Microsoft की API भी उलझी हुई तरह से बदल गई है
  इसलिए आखिरकार ज़्यादा सरल और सस्ता web चुनना पड़ता है

  • macOS में Apple Developer Program सिर्फ तब चाहिए जब आप binary signing या Mac App Store distribution चाहते हों। Microsoft में भी खर्च तभी आता है जब Microsoft Store में publish करना हो, या कंपनी का आकार किसी तय सीमा से ऊपर हो और Visual Studio इस्तेमाल कर रहे हों
    unsigned app भी Windows और macOS पर चल सकते हैं, लेकिन warnings ज़्यादा आती हैं। 30% कमीशन भी सिर्फ Mac App Store या Microsoft Store इस्तेमाल करने पर लागू होता है, और Microsoft Store में लगता है कि अगर वह game नहीं है और अपना payment system इस्तेमाल करता है, तो कोई कमीशन नहीं लिया जाता
  • C/C++ development लंबे समय तक करने के बाद JavaScript web development में जाने की एक वजह यही थी। iPhone app को Apple App Store पर डालने की प्रक्रिया नरक जैसी थी, जबकि web app के लिए license·approval·installer की ज़रूरत नहीं होती
  • सीधे कहूँ तो Microsoft के मामले में developer account बनाना, binary signing, और रेवेन्यू का 30% share देना अनिवार्य नहीं है। Microsoft API को भी मैं बिखरी हुई नहीं मानता; Win32, .NET, UWP जैसे विकल्प हैं, और ये काफ़ी अच्छे से काम करते हैं और लचीले भी हैं
    Apple के बारे में पक्का नहीं कह सकता, लेकिन Mac app शायद developer account के बिना भी बनाया जा सकता है, जबकि iPhone के लिए developer account चाहिए। पहले जो कीमत देखी थी वह सालाना $99 थी, और अगर app गंभीरता से बनाना है तो यह कोई बहुत बड़ी रकम नहीं है
  • web पर card payment सीधे जोड़ें तो Stripe को 2.9% + 30¢ देना पड़ता है। transaction fee को लगभग 6% तक लाने के लिए कम से कम 10 डॉलर लेने पड़ते हैं, इसलिए pricing floor और billing model पर सीमाएँ आ जाती हैं
    chargeback और refund संभालने में भी खर्च आता है, और customer support में समय देना पड़ता है या लोगों को रखना पड़ता है। अगर सालाना revenue 10 लाख डॉलर से कम है, तो Apple की fee 15% होती है, इसलिए low-cost app या value-added app के लिए Apple, खुद payment process करने से बेहतर सौदा हो सकता है
  • macOS, Windows, Linux के लिए native app बनाते समय यह सब करने की ज़रूरत नहीं पड़ती थी, बस Qt इस्तेमाल करते थे

• यह विडंबना है कि यह लेख Medium पर है, जो 265 शब्दों की एक पोस्ट के लिए 10.88MB डाउनलोड कराता है

  • Medium के नज़रिए से ads ही असली content हैं। लेख तो सिर्फ वह माध्यम है जो browser तक ads नाम के असली content को पहुँचाता है, और ad delivery के लिए बहुत जटिलता चाहिए होती है
  • Firefox about:process में देखा कि load खत्म होने के 10 मिनट बाद भी यह लेख 239MB memory और 0.06~0.2% CPU इस्तेमाल कर रहा था, और CPU time का 45% शायद Google reCAPTCHA में जा रहा था
    अच्छा होता अगर Mozilla या Google जैसी जगहें domain के हिसाब से CPU·memory·energy usage के आँकड़े इकट्ठा करें और performance की परवाह न करने वाले developers को सार्वजनिक रूप से शर्मिंदा करें
  • browser अब ज़्यादातर operating system से भी बड़े हो गए हैं, और ecosystem भी बंद-सा लगता है। WASM पर अभी भी कई पाबंदियाँ हैं, और web development में व्यावहारिक तौर पर असली विकल्प सिर्फ JS/HTML/CSS ही हैं
    web फिर से 2005 जैसा लगने लगा है। बस इस बार popup पेज के अंदर गड़े हुए हैं
  • ऐसे मामलों में Gemini browser में gemini://gemi.dev/bin/waffle.cgi खोलकर URL paste कर देता हूँ। जो लोग Gemini network इस्तेमाल नहीं करते, वे URL में medium.com को scribe.rip से बदल सकते हैं
  • text mode browser में यह ठीक है

• हाँ, रास्ता भटका है, और वजह सरल है। क्योंकि ऐसा किया जा सकता था। वही सबसे कम प्रतिरोध वाला रास्ता था, इसलिए वही चुना गया
  software दशकों से hardware की प्रगति पर मुफ़्त की सवारी करता आया है, खासकर web और desktop app में। Moore's law एक वरदान भी था और अभिशाप भी, और आज जो software हम इस्तेमाल करते हैं, वह उन लोगों ने बनाया जिन्होंने उसी मुफ़्त सवारी के चरम दौर में यह तकनीक सीखी थी

  • कंप्यूटर से होने वाला काम हर साल लगभग वही रहता है, लेकिन software लगातार भारी होता जा रहा है, यह पागल कर देने वाला है। 2010 में भी desktop environment के साथ आने वाली Linux distribution boot के तुरंत बाद RAM 100MB लेती थी, और optimized version लगभग 60MB
    अब 8GB से कम वाला कंप्यूटर इस्तेमाल ही नहीं हो पाता, और 8GB भी बस जैसे-तैसे काफ़ी है। नया software Electron इस्तेमाल करता है और कम से कम 1GB RAM खा जाता है, और browser सहित हर चीज़ बेहिसाब memory लेती है
    Windows तो और भी कम समझ आता है। जब भी माँ के कंप्यूटर में मदद करता हूँ, हाल का i5 और 8GB RAM वाला PC होने के बावजूद बहुत धीमा लगता है, boot, program launch, और update सब में बहुत समय लगता है। अगर किसी कंप्यूटर को boot होने में 1 मिनट से ज़्यादा लगे, तो उसे खिड़की से बाहर फेंक देने का मन करता है
  • सही बात है। software की कई कठिन समस्याएँ हल नहीं हुईं, बस उन्हें bypass किया गया है। container इसका सबसे अच्छा उदाहरण है
    अलग-अलग language और environment वाली application deployment की समस्या हल नहीं हुई, बस container engine के सहारे उससे बच निकले। चाहें तो users को compiler और tools install करने वाला build script दे सकते हैं, लेकिन उसे ठीक से test करना मुश्किल होता है, इसलिए आखिर में container ही इस्तेमाल करते हैं
    Redbean और Cosmopolitan libc इस समस्या को “हल” करने के सबसे करीब लगे। अगर users चाहते हैं कि app आसानी और भरोसेमंद तरीके से deploy हो, तो container प्रतिस्पर्धा में फ़ायदा देता है, और फिर उसके साथ तुरंत 100MB+ disk usage और container engine भी आ जाता है
  • “क्योंकि कर सकते थे” वाली यही दलील AI killing bot swarms तक पहुँच जाए तो Slaughterbots बन जाता है
    जब तक देशों और कंपनियों के बीच की प्रतिस्पर्धा को तकनीकी विकास का मुख्य सिद्धांत माना जाएगा, तब तक climate change, ecosystem destruction, और lethal AI जैसी वैश्विक संकटों को नियंत्रित करना मुश्किल रहेगा। सबसे ऊँचे संगठनात्मक सिद्धांत के रूप में collaboration और cooperation की ज़रूरत है, और competition पूरी धरती पर बहुत बड़े negative externalities पैदा करता है
  • मैं सहमत नहीं हूँ। वजह framework और operating system की security features हैं, जैसे telemetry, और उनसे जुड़ी libraries
    Lazarus, यानी Free Pascal में लिखे गए program, Windows 11 जैसे modern Windows पर भी बहुत तेज़ चलते हैं। desktop पर किसी खास उद्देश्य के लिए लिखे गए software को बनाए रखना speed और stability के लिहाज़ से सबसे अच्छा है
    software का हर modernization, चाहे hardware हो या framework, मौजूदा functionality के पूरे ढाँचे पर एक tax की तरह काम करता है
  • “सबसे कम प्रतिरोध वाला रास्ता” यह अभिव्यक्ति अच्छी लगी। लगता है उस रास्ते पर résumé-driven development बहुत ज़्यादा बिखेर दिया गया है
    complexity पूरी तरह गलत जगह पर जमा हो गई है

• ऐसी शिकायतें बार-बार दोहराई जाती हैं, लेकिन असल में यह ऐसी स्थिति है जिसे लगभग कोई भी सचमुच नहीं चाहता
  डेवलपर वेब को पसंद करते हैं, जो एक पूरी तरह integrated और connected general-purpose computing platform है, और यूज़र भी लगता है कि अगर चीज़ें काफ़ी हद तक ठीक चलें तो performance की बहुत परवाह नहीं करते। आखिरकार software को इतना ख़राब होने तक भी स्वीकार कर लिया जाता है कि वह यूज़रों को ज़रूरत से ज़्यादा परेशान न करे
  management को भी बेहतर software बनाने में दिलचस्पी नहीं होती, अगर पर्याप्त रूप से अच्छा software पहले ही बन चुका हो। जब तक कोई यह न तय करे कि बड़े पैमाने पर churn ज़रूरी है, कुछ नहीं बदलता, और किसी भी नज़रिए से बदलाव के लिए प्रोत्साहन बहुत कम है

  • लोग performance और download size को लेकर निश्चित रूप से शिकायत करते हैं, लेकिन आमतौर पर इसे side effects के रूप में व्यक्त करते हैं। जैसे पूछना कि laptop इतना गर्म क्यों हो रहा है, या iPhone में “screen freeze” क्यों हो रहा है
    जिन लोगों को कमज़ोर signal वाले फ़ोन पर बड़े apps डाउनलोड करने पड़ते हैं, या जो अस्थिर इंटरनेट वाले इलाक़ों में रहते हैं, या कम आय वाले तथा developing countries में पुराने devices इस्तेमाल करते हैं, वे बड़े और धीमे apps से परेशान होते हैं। अगर आपको लगता है कि लोग performance और app size की परवाह नहीं करते, तो हो सकता है आप ग़लत लोगों से ग़लत सवाल पूछ रहे हों
  • software bloat कोई नई घटना नहीं है। इसकी शिकायत कम से कम 1990 के दशक के मध्य से हो रही है, और कुछ लोग इसे 1980 या 1970 के दशक तक पीछे ले जाएंगे
    समय के साथ शिकायत करने वाले लोग ही अजीब माने जाने लगते हैं, और बाकी लोग upgrade कर लेते हैं, bloat को झेल लेते हैं, या पुराना software इस्तेमाल करते रहते हैं
    लेकिन उस bloat से मिलने वाले फ़ायदों को भी देखना चाहिए। अगर Google Docs सिर्फ Word की नकल होता, तो शायद इतना इस्तेमाल नहीं होता, लेकिन कुछ लोग इसे free होने, कई devices से access, और सहज collaboration की वजह से इस्तेमाल करते हैं
    और जो चीज़ें bloat जैसी लगती हैं, उनमें से कुछ वास्तव में सुविधा में सुधार हैं। proportional fonts जो किसी भी size पर सुंदर दिखते हैं, Unicode fonts, memory से बड़े documents को संभालना, working documents और reference materials के बीच switching, और memory protection जैसी सुविधाएँ resources ज़्यादा लेती हैं, लेकिन जीवन को बेहतर बनाती हैं
  • सच में ऐसा है क्या, इस पर संदेह है। web developers के लिए ऐसा हो सकता है, लेकिन मैंने ख़ुद लगभग कभी web development नहीं किया। web interface एक विकल्प है, और subscription revenue चाहने तथा one-time sale से बचने की commercial need बड़ी प्रेरक शक्ति लगती है
    आधुनिक cloud-based या आधा-online दुनिया यूज़र के नज़रिए से काफ़ी अप्राकृतिक लगती है, और जहाँ monetization की ज़रूरत नहीं होती, जैसे OpenOffice, वहाँ desktop application बने रहना संभव है
  • सफल startup में से एक single-page app था, जो 5MB bundle डाउनलोड करता था और data को पहले से पढ़ता था, और शुरू होने में लगभग 10 सेकंड लेता था
    किसी ने इसकी शिकायत नहीं की, और app के कुछ हिस्सों की performance बहुत ख़राब होने पर भी customer complaints कम ही थीं। शिकायतें तब शुरू होती थीं जब loading लगभग 60 सेकंड तक पहुँच जाती थी
    फिर भी उस software की बहुत प्रशंसा होती थी, क्योंकि वह एक बेहद मूल्यवान समस्या हल करता था, जो एक हफ़्ते का काम कुछ मिनटों में कर देता था। प्रतिस्पर्धा बढ़ने पर सुधार की ज़रूरत पड़ी, लेकिन ज़्यादातर लोगों को सचमुच फ़र्क नहीं पड़ता था, और यह हमेशा सबसे कम priority पर रहता था
  • यह अंतर सबसे ज़्यादा तब महसूस होता है जब आप ऐसा software इस्तेमाल करते हैं जो इस जाल में नहीं फँसा। MYOB EXO/CRM या SAP ERP जैसे systems ने दशकों पुराने codebase को बहुत धीरे-धीरे बदला है, और वे मूलतः 2000s की technology ही हैं, इसलिए आज भी इस्तेमाल में असुविधाजनक हैं, लेकिन यही उनकी बड़ी ताकत बन जाती है
    Task Manager खोलकर यह देखना दिलचस्प होता है कि मौजूदा database का अच्छा-खासा हिस्सा loaded होने के बावजूद वह सिर्फ RAM 20~30MB इस्तेमाल कर रहा है। VLC और Blender भी ऐसे ही उदाहरण हैं

• यह दिलचस्प है कि ज़्यादातर लोग developers को दोष देते हैं, लेकिन वास्तविकता में यह सब business decisions हैं
  cloud की ओर जाना इसलिए होता है क्योंकि कंपनियों को subscription से स्थिर revenue पसंद है, और enterprise customers बिना IT team रखे भी काम चला सकते हैं, साथ ही ज़िम्मेदारी बाहर चली जाती है, इसलिए वे high uptime की मांग कर सकते हैं। performance बस अंतिम यूज़र के लिए “काफ़ी ठीक” होनी चाहिए
  on-premise software upgrade से इनकार करने वाले customers ने लंबे maintenance cycles और अंतहीन patches को जन्म दिया, और web पर एक बार develop करने का तरीका business के लिहाज़ से हर platform के लिए अलग developers और testers रखने से ज़्यादा फ़ायदेमंद है। सिर्फ developers की expertise इन बुनियादी ताक़तों को नहीं बदल सकती

  • कुछ समय बीतने के बाद वह software customer के लिए बस ठीक से काम करता है। Photoshop इसका अच्छा उदाहरण है
    आप चमकदार नए features नहीं इस्तेमाल कर पाएँगे, लेकिन Win7 मशीन पर CS4 अभी भी बिना अतिरिक्त लागत के इस्तेमाल किया जा सकता है
  • cloud पर भी efficient web apps बनाए जा सकते हैं। आखिर वह भी server ही है
    समस्या यह है कि developers ऐसे machines पर development करते हैं जिनकी performance आम यूज़र खरीद ही नहीं सकता, और वे performance तथा efficient code पर ध्यान नहीं देते
  • लगता है कई developers भी यही फ़ैसला करेंगे। एक ही software के platform-specific versions को अलग-अलग maintain करना बहुत कष्टदायक है, और servers संभालने का काम development time छीन लेता है

• 90 के दशक की शुरुआत में MS Word कुछ floppy disks में आ जाता था, और याद है कि उसकी मुख्य executable फ़ाइल 2MB थी। यह कुल 2MB RAM वाले 16MHz 386 पर भी अच्छी तरह चलता था
  आज जो ज़्यादातर काम हम करते हैं, वह तब भी हो जाते थे, बस grammar checker जैसा कुछ नहीं था। अब चीज़ें GB में मापी जाती हैं, 1000 गुना बड़ी हो गई हैं, लेकिन समझ नहीं आता कि बदले में हमने क्या पाया। हम सिर्फ़ रास्ता ही नहीं भटके, मंज़िल भी भूल गए

  • मिला क्या है: features और graphics
    उदाहरण के लिए, Linux की dict.words ही 4.8MB है, और Arial Unicode लगभग 20MB का font है। जिस app पर काम चल रहा है उसका एक icon ही 400KB है, और crash handling के लिए Google Crashpad handler भी कई MB का है
    4K true color screen 640x480 16-color screen से 138 गुना बड़ी है
  • कुछ साल पहले April Fools मज़ाक में PXE network boot server पर DOS/Windows 3.11 disk image चढ़ाई थी। उसमें काम करने वाला Word 6 for Windows शामिल था, और gzip-compressed image 12MB के भीतर आ गई थी
    उस दौर के PC, UEFI के बिना भी boot हो जाते थे, और सही तरह सेट करने पर Windows 3.11 लगभग तुरंत चालू हो जाता था, Word भी फौरन खुल जाता था
    आज के Word में कई बहुत छोटे features और कुछ बड़े features ज़रूर जुड़े हैं, लेकिन यक़ीन है कि अगर Microsoft सच में ध्यान दे तो memory usage को 10वें हिस्से तक ला सकता है। बस उसके लिए कोई incentive नहीं है। कंप्यूटर तेज़ हैं, memory बहुत है, और अब floppy पर निर्भरता नहीं रही, इसलिए यह बस अतिरिक्त cost बनकर रह गया है
    मुझे लगता है कि software bloat का पर्यावरण पर भी नज़रअंदाज़ न किया जा सकने वाला असर हो सकता है, लेकिन जब तक बहुत मज़बूत विरोध या EU का कोई anti-software-bloat कानून जैसा कुछ नहीं आता, तब तक बदलाव नहीं होगा
    हाल ही में GitHub पर MS Word for Windows 1.0 का source भी देखा। इसका मूल प्रकाशन Computer History Museum में है, और https://computerhistory.org/blog/microsoft-word-for-windows-... पर देखा जा सकता है। वह pure C था, और बड़े हिस्से assembly में थे, लेकिन code इतना बेतरतीब था कि आज के C/C++ standards, patterns, या language features से उसकी तुलना ही नहीं की जा सकती
  • पहले disposal के लिए आए एक पुराने PowerBook Duo पर nostalgia में Word 5.1 चला कर देखा था
    मैंने कहीं यह अभिव्यक्ति पढ़ी थी कि software भी gas की तरह होता है, उसे जितनी जगह दी जाए वह उतना फैल जाता है
    live distributions में भी यही दिखता है। पहले उन्हें CD-R में फिट करना होता था, इसलिए वे 700MB की होती थीं, अब 2GB USB में आने वाली ढूँढना मुश्किल हो गया है। फिर भी “minimal” का फिर से महत्व बढ़ना अच्छा लगता है
  • कंपनी में machine learning code चलाने वाली Docker file 6GiB की है। इसमें model files भी शामिल नहीं हैं
    Nvidia आख़िर डाउनलोड क्या करवा रहा है? क्या यह ऐसे generated code combinations के हज़ारों सेट खिंचवा रहा है जिन्हें कभी इस्तेमाल ही नहीं करना
  • Word 6 में जो features थे, असल में वही आज के latest Word में भी इस्तेमाल होते हैं
    बस अब उन पर चढ़ी हुई भारी-भरकम नई features की परतों के बीच मनचाही चीज़ ढूँढने में ज़्यादा समय लगता है

• minimal software मौजूद है, लेकिन लोग अक्सर उसे चुनते नहीं हैं। मैं dependencies को सावधानी से चुनने में काफ़ी समय लगाता हूँ, और उससे हल्का और performant stack बनता है
  आजकल Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2], Mako Server[3] जैसे tools पसंद हैं। बेहतरीन, हल्के, स्थिर और efficient software मुफ़्त में उपलब्ध हैं, लेकिन इसके लिए आम रास्ते से थोड़ा हटना पड़ता है। ये वे चीज़ें नहीं हैं जिनका नाम आप Stack Overflow पर बार-बार सुनते हैं
  frontend को लेकर थोड़ा द्वंद्व है। मुझे native apps और web pages पसंद हैं, लेकिन मैं Tiddlywiki रोज़ इस्तेमाल करता हूँ और मानता हूँ कि web apps की अपनी जगह है। फिर भी 6MB की Tiddlywiki file वाला tab 155MB RAM खा रहा है, जबकि काफ़ी customized Emacs session सिर्फ़ 88MB इस्तेमाल करता है, इसलिए लेखक की समस्या-चेतना से मैं सहमत हूँ
  [0]: https://fennel-lang.org/
  [1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md
  [2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
  [3]: https://makoserver.net/

  • Lua मेरी नज़र में सबसे underrated programming tools में से एक है। Lua में proficiency हासिल करना programming skill बढ़ाने के सबसे अच्छे तरीकों में से एक है
    बेशक इसका गलत इस्तेमाल भी हो सकता है, लेकिन ज़्यादातर दूसरी languages की तुलना में Lua program कितने छोटे और efficient हो सकते हैं, यह लगभग चौंकाने वाला है

• समस्या मोटे तौर पर कुछ ऐसी लगती है। किसी कंपनी का executive यह तय करता है कि competitiveness के लिए developers को top-end hardware चाहिए, और developer कंपनी के दिए हुए 128GB RAM high-performance laptop पर web app बनाता है
  फिर वह अपने पिता के 2010 वाले family PC जैसे माहौल में test नहीं करता, या इतनी नियमित और गहराई से test नहीं करता कि उसे पता चले कि बहुत-सी चीज़ें वहाँ टूट चुकी हैं या लगभग बेकार हैं

  • network connection के साथ भी यही बात है। office में Wifi 7 और symmetric gigabit fiber internet पर app इस्तेमाल करने वाले व्यक्ति का अनुभव, किसी apartment complex के घटिया Wi-Fi router और consumer-grade internet line पर इस्तेमाल करने वाले व्यक्ति से अलग ही होगा
  • इसे आसानी से सुधारा जा सकता है। development के दौरान developer tools को mobile और constrained connection mode पर सेट कर दें
    तब mobile-first responsiveness, सीमित screen space, और खराब connection में आने वाली संभावित समस्याएँ प्राथमिक concern बन जाती हैं
    आमतौर पर product owner को ऐसी समस्या बताओ तो वह बस आगे बढ़ जाता है। इसलिए तीसरे बिंदु को यूँ बदला जा सकता है: “2010 वाले family PC पर भी test होता है, लेकिन ज़्यादा महत्वपूर्ण stakeholders के लिए यह concern नहीं है”
  • मैं अभी जो काम करता हूँ, उसका एक हिस्सा पुराने hardware या low-performance hardware, अब भी इस्तेमाल हो रहे पुराने browsers, और खासकर mobile environments में testing करना है
  • यह कोई बिल्कुल ग़लत अनुमान नहीं है। बस मूल लेख ख़ुद एक काल्पनिक समस्या पर लिखा गया था
  • इसी से जुड़ा एक सवाल है: क्या Google के Android engineers खुद Android phones इस्तेमाल करके test करते हैं? लगता है कि उनमें से ज़्यादातर शायद Apple users होंगे

• हाल ही में एक पुराने पेज को pure HTML और backend-generated तरीके से React में migrate किया, तो लगभग हज़ार items वाले एक dropdown को खुलने में कई सेकंड लग गए। पहले पूरा पेज लगभग 100ms में खुल जाता था
  शुरुआत में सुझाव आया कि पहले सिर्फ 100 items दिखाएँ और user तीन अक्षर टाइप करे तभी render करें। आजकल हक़ीक़त कुछ ऐसी ही है
  बेशक, असल में खराब React code को ठीक करके उसे तुरंत render होने लायक बना दिया गया

  • सही है। यह आम बात है। first paint time जैसी performance posts बढ़ती जा रही हैं, और इस बीच React ने इस तरह की बिल्कुल नई problem category बना दी है
  • Turbo जैसे server-side rendering framework का इस्तेमाल किया जा सकता है। आजकल लोग जो client-side frameworks चाहते हैं, उनमें से कई आज़माए हैं, लेकिन data ज़्यादा होने पर सब धीमे थे, और Turbo ही अपवाद था
  • हज़ारों options वाला select box user experience के लिहाज़ से बहुत खराब लगता है
    अगर कोई नया framework समस्या को इतना साफ़ तौर पर सामने लाता है कि किसी के पास उसे सच में ठीक करने का कारण बन जाए, तो उल्टा उस framework को इस्तेमाल करने की वजह और बढ़ जाती है

• “idiomatic Ruby” या “premature optimization is the root of all evil” जैसे लेख आगे रखकर, और यह कहकर कि “performance से ज़्यादा development time महत्वपूर्ण है”, नतीजा यही होना था
  पहले ऐसे developers थे जो कम समय में इससे बेहतर code लिखते थे

  • मैं सहमत नहीं हूँ। आज efficient code लिखने में मदद करने वाले resources पहले की तुलना में बहुत ज़्यादा हैं
    पुराने code में मैंने बहुत सा ऐसा भयानक code देखा है जो आज के समय में शायद बनाया ही न जाता