"सस्ता" वेब

सस्ता वेब ≠ मुफ़्त

• अच्छी चीज़ें बनाना कठिन होता है और इसमें बहुत समय लगता है.
• अगर हम चाहते हैं कि रचनाकार हमारे लिए अच्छी चीज़ें बनाएं, तो हमें उनके जीवन-यापन और सामग्री की लागत चुकानी होगी.
• अगर आप मनोरंजन पर प्रति घंटा $1 से कम खर्च करते हैं, तो आपको रचनाकारों और उन्हें सहारा देने वाली इन्फ्रास्ट्रक्चर का समर्थन करने के तरीकों पर विचार करना चाहिए.

सस्ता वेब ≠ परिष्कृत

• Apple वेबसाइट का HTML source अंदर से "सुंदर" नहीं है, लेकिन इसके लिए Apple इंजीनियरों को HTML की भद्दी प्रकृति का दोष नहीं दिया जा सकता.
• HTML/CSS ऐसा महसूस होना चाहिए जैसे डिजिटल कंक्रीट को तराश रहे हों, लेकिन हक़ीक़त में यह अधपकी पास्ता से पुल बनाने जैसा लगता है.
• जब तक हम कोई सरल और स्थिर markup language नहीं अपनाते, तब तक सभी वेबसाइटें एक जैसी दिखती रहेंगी.
• software इतना जटिल हो गया है कि ईमानदारी बनाए रखना मुश्किल हो गया है.
• Bartosz Ciechanowski जैसे लोग एक अधिक सुरुचिपूर्ण भविष्य की राह बना रहे हैं.

सस्ता वेब ≠ डरावना

• अमेरिका का मध्य क्षेत्र समतल, उपजाऊ और बहुत हवा वाला है.
• tumbleweed अमेरिका की मूल वनस्पति नहीं थी, लेकिन यह Wild West का प्रतीक बन गई.
• World Wide Web एक ऐसी जगह है जो विशाल आबादी को जोड़ती है, और विज्ञापन राजस्व से चलती है जो अलग-अलग लोगों को निजी रूप से एक-दूसरे से दूर रखती है.
• social platforms ने इंटरनेट को एक शत्रुतापूर्ण और गैर-निजी जगह में बदल दिया है.
• छोटा और सच्चा संचार चुपचाप फल-फूल रहा है, और उसे ढूंढना भी आसान है और बनाना भी.

सस्ता वेब ≠ गहराई

• Sturgeon’s law के अनुसार, "हर चीज़ का 90% कचरा होता है".
• World Wide Web का 10% हिस्सा पहुँचना मुश्किल है.
• spam, JavaScript, images, accessibility, payments, मनमाने पते, platforms, archival जैसी समस्याओं के कारण इंटरनेट का बड़ा हिस्सा टूटा हुआ है या गायब है.

सस्ता वेब ≠ अंधकार

• NFT शायद शुरू से ही एक बुरा विचार था, लेकिन cryptocurrency community ने सम्मानजनक लक्ष्यों का पीछा किया.
• वैश्विक वित्तीय व्यवस्था के संरक्षकों ने हमें कई बार निराश किया है.
• blockchain का टिकाऊ तकनीकी भविष्य में क्या रोल होगा, यह स्पष्ट नहीं है, लेकिन जिस सुविधा और privacy की हमें चाह है उसके लिए बहुत अधिक ऊर्जा बर्बाद करने की ज़रूरत नहीं होनी चाहिए.

सस्ता वेब = सस्ता

• इसका maintenance cost कम होना चाहिए.
• वेब से बाहर निकलना आसान होना चाहिए.
• accessibility अच्छी होनी चाहिए.
• वेब के साथ interact करना आसान होना चाहिए.
• वेब पर नेविगेट करना आनंददायक होना चाहिए.
• वेबसाइट बनाना/host करना स्क्रैपबुक बनाने से भी आसान होना चाहिए.

GN⁺ की राय

• इस लेख की सबसे महत्वपूर्ण बात वेब डिज़ाइन और development की accessibility तथा sustainability पर दिया गया ज़ोर है.
• सस्ता वेब सिर्फ़ कम लागत से आगे बढ़कर एक नैतिक और सच्चे इंटरनेट वातावरण की तलाश करने वाला दर्शन है.
• रचनाकारों और उपयोगकर्ताओं दोनों के लिए एक निष्पक्ष और टिकाऊ वेब ecosystem बनाने के लिए दिए गए विभिन्न प्रस्ताव दिलचस्प हैं, और ये तकनीक के भविष्य तथा हमारे समाज पर महत्वपूर्ण प्रभाव डाल सकते हैं.

[GN⁺]

Hacker News राय

• मूल पोस्टर (OP) शायद E-ink स्क्रीन और org/vimwiki/markdown जैसा कुछ चाहता है। समस्या styling से शुरू होती है, लेकिन अगर आप सच में एक accessible hypertext किताब चाहते हैं, तो styling की ज़रूरत नहीं है। इसका नियंत्रण user के पास होना चाहिए, और default theme में पढ़ने में आसान फ़ॉन्ट, सफेद बैकग्राउंड पर काला टेक्स्ट, headings 36pt bold, और paragraphs 14pt regular टेक्स्ट होना चाहिए। वास्तविक उपयोग में Epub एक शानदार format है, और मैं वेबसाइट द्वारा सुझाए गए अनुभव की तुलना में इस तरह के "browsing" अनुभव को पसंद करता हूँ। या फिर OP शायद CSS और HTML का एक higher-level रूप चाहता हो, लेकिन वह एक नई language बनाने और अधिक जटिल ontology का दावा करने की समस्या तक पहुँचता है। निश्चित रूप से, आप कुछ default styling options के साथ markdown बना सकते हैं, लेकिन मुझे यक़ीन है कि किसी खास markdown को सीखने और चलाने तथा किसी खास server पर वेबसाइट serve करने की तुलना में बुनियादी HTML और CSS सीखना इतना जटिल नहीं है.
• वेब और styling तब जटिल हो गए जब 2000 के दशक की वेब styling, अलग-अलग browsing devices का आगमन, और smartphones के साथ interaction के तरीके आपस में मिले। आज का browser लगभग एक OS जैसा है, और जो complexity साझा की जा सकती है वह 1990 के दशक के PC पर बनाई जा सकने वाली complexity से भी अधिक है। उदाहरण के लिए, browser में Godot engine चलाया जा सकता है: आप दोस्तों के साथ मज़े के लिए project prototypes बना सकते हैं, या अपनी पसंद के लोगों से संवाद करने के लिए एक personal platform बना सकते हैं। JS पर बहुत आलोचना होती है, लेकिन जब मैंने इसे पहली बार देखा तो यह सपने के सच होने जैसा लगा, और इसने मुझे अनुभव बनाने और उन्हें लगभग बिना मेहनत के साझा करने की ताकत दी। बड़ी कंपनियों ने अगर over-engineered frameworks में उबाऊ वेबसाइटें बनाने का फ़ैसला किया है, तब भी यह बात नहीं बदलती.
• मैं web developer नहीं हूँ, लेकिन वेब की शुरुआत documents साझा करने के साधन के रूप में हुई थी, HTML उसी के आसपास बना, और आखिरकार लोग सामान्य applications (जैसे Google Docs) बनाना चाहते थे, इसलिए उन्होंने non-document चीज़ों को document जैसा दिखाने वाले tools बना लिए। सबने सोचा कि ये tools बेहतरीन हैं और इन्हें इस्तेमाल करना शुरू कर दिया, लेकिन वेब का 90% हिस्सा आज भी documents ही है, फिर भी अब लगभग सब कुछ ऐसे frameworks में बनाया जाता है जो non-document चीज़ें बनाने के लिए बने थे, जबकि वास्तव में ज़्यादातर लोग शुरुआत से ही documents बना रहे हैं। पूरी स्थिति बेहद भ्रमित करने वाली है, और यह समझ से बाहर है कि वैश्विक engineering culture इसे पूरी तरह पागलपन क्यों नहीं मानती.
• मुझे हैरानी है कि क्या किसी ने HTTP के ऊपर CommonMark का प्रस्ताव दिया है। अगर markdown को GET response में रखा जाए और Content-Type: text/markdown सेट किया जाए, तो client यह तय कर सकता है कि उसे कैसे render करना है। यह एक आधुनिक Gopher जैसा होगा.
• जब दूसरे लोग भी वही महसूस करते हैं जो मैं करता हूँ, तो मुझे सच में आश्चर्य होता है। ज़्यादातर लोगों को परवाह नहीं है, और वे परवाह करना भी नहीं चाहते। पेज की भयानक aesthetics की वजह से तर्क ही बर्बाद हो जाता है.
• काश हम 2000 के दशक की शुरुआत में लौट पाते, जब किसी भी पेज पर source view बहुत साफ़-सुथरे format में code दिखाता था। कई कंपनियाँ अलग-अलग कारणों से frontend code को जानबूझकर obfuscate करना चाहती हैं, और कई कंपनियाँ client payload size और parsing time को थोड़ा और efficient बनाने के लिए minify करती हैं, जिससे अनजाने में भी obfuscation हो जाता है। browser स्तर पर यह तय होना चाहिए: क्या हम चाहते हैं कि client ठीक-ठीक समझ सके कि browser में क्या चल रहा है? अगर वर्तमान स्थिति अच्छी लगती है तो शायद नहीं, लेकिन वर्तमान स्थिति बहुत निराशाजनक है, और WASM-आधारित payloads के आने से, जहाँ हर चीज़ के ऊपर disassemble भी करना पड़ेगा, यह और भी बदतर होने वाली है.
• जैसे-जैसे software सड़ता जाता है, वेबसाइटें बनाने वाला एकमात्र पक्ष बहुराष्ट्रीय कंपनियाँ रह सकती हैं। open source software के मामले में भी पहले से वही तय कर रही हैं कि यह किसके लिए है। लोग जिस बात को सबसे कम समझते हैं, वह यह है कि बहुत से अमीर लोगों और उनकी ताकत के बिना, बहुत से गरीब लोगों और उनकी बेबसी का अस्तित्व नहीं होता। पहले पक्ष के हित हमेशा दूसरे पक्ष को प्रभावी रूप से कमज़ोर करते हैं। उसी तरह, ऐसा software नहीं हो सकता जो बहुराष्ट्रीय कंपनियों और सामान्य लोगों—दोनों को एक साथ संतुष्ट करे। पहले पक्ष के हित हमेशा दूसरे पक्ष को प्रभावी रूप से कमज़ोर करते हैं.
• चैट के लिए distributed XMPP servers का इस्तेमाल किया जाना चाहिए, क्योंकि यह दूसरे chat विकल्पों के विपरीत, बहुत कमज़ोर hardware पर भी काम करता है.
• ऐसे सरल websites ब्राउज़ करना ताज़गीभरा लगता है जिनमें ज़्यादातर content text हो और images कम इस्तेमाल हों। सभी "modern" websites बहुत थका देने वाली हैं। अगर कोई वेबसाइट पहली विज़िट पर स्क्रीन पर कुछ ठूँस देती है—चाहे newsletter signup हो, login prompt हो, या viewport को ढकने वाली बड़ी image—तो मैं तुरंत reader view पर स्विच कर देता हूँ.
• ज़्यादातर webpages को अनिश्चितकाल तक काम करना चाहिए और उनका maintenance cost कम होना चाहिए। साधारण HTML तब तक काम करता है जब तक उस version के HTML और CSS को support करने वाले browsers मौजूद हैं। dynamic HTML serve करने वाला static Go binary भी संभव है। लेकिन Python, Ruby वगैरह के लिए यह हासिल करना आसान होगा, इसकी कल्पना करना मुश्किल है। यानी, यह भी सवाल है कि क्या यह एक अच्छा नियम है, और इसे ज़्यादा हासिल करने योग्य बनाने के लिए शायद दोबारा काम करने की ज़रूरत हो.
• मुझे लगता है कि 2005 में जब हमने तय कर लिया कि सबके pages एक जैसे दिखेंगे (जैसे TheFacebook™ profile), तब कुछ क़ीमती चीज़ खो गई। दुर्भाग्य से, उसी के साथ Google ने भी ऐसे बदलाव किए जिनसे personal sites जैसी results को कम महत्व मिलने लगा, और इसने इन शानदार custom pages को लगभग नष्ट कर दिया.