सब कुछ अच्छा है, लेकिन इसे इस्तेमाल करने पर सिस्टम से Wireguard को कंट्रोल नहीं किया जा सकता। अगर आप इसे टनल से अलग इस्तेमाल करना चाहते हैं, तो इसे VM में अलग करके इस्तेमाल करना होगा।
वेब भले ही ऐप जैसा हो, फिर भी मेरा मानना है कि निष्कर्ष में कही गई दिशा के करीब जाने की कोशिश करनी चाहिए। JavaScript का ज़्यादा इस्तेमाल करने पर क्लाइंट के नज़रिए से चीज़ें भारी हो जाती हैं.
असल में ऐसा implement कर सकने वाले framework मौजूद नहीं हैं, ऐसा भी नहीं है। अभी Next.js में भी अगर client component का इस्तेमाल सिर्फ़ ज़रूरत पड़ने पर किया जाए और उसे न्यूनतम रखा जाए, तो यह मोटे तौर पर संभव है। और जैसा किसी और ने कहा था, Rails ecosystem में Hotwire(https://hotwired.dev/) जैसा framework suite (Turbo, Stimulus आदि) है, जो लेखक के बताए निष्कर्ष के काफ़ी करीब पहुँचते हुए ऐप-जैसे वेब को support करता है।
OpenAI के अधिग्रहण वाले मामले की वजह से Claude ने latest version का लाइसेंस देना बंद कर दिया है, इसलिए WindSurf में Claude 4.x version मॉडल इस्तेमाल करने के लिए महंगा API सीधे खरीदना पड़ता है—क्या Claude फिर से वापस आएगा?
कोरिया में जहां development culture management -> planner -> developer के क्रम में नीचे आती है, वहीं पश्चिम में कोरिया जैसी planner की अवधारणा नहीं होती और developer product planning आदि में सक्रिय रूप से शामिल होते हैं। पश्चिम में PM जैसी भूमिकाएं भी cover letter और self-introduction letter की तरह पूरी तरह एक जैसी अवधारणाएं नहीं हैं, इसलिए वे कोरिया के planner से भी पूरी तरह मेल नहीं खातीं। बेशक, जिन games में creative project का स्वभाव मजबूत होता है और fun व gameplay महत्वपूर्ण होते हैं, वहां पश्चिम भी एशिया की तुलना में अधिक horizontal है, लेकिन फिर भी director से developer तक नीचे आने वाली संरचना मौजूद रहती है।
लोग जिन browsers का इस्तेमाल करते हैं, उनकी किस्में भी इतनी ज़्यादा नहीं हैं, फिर frameworks इतने सारे क्यों हैं? क्या बेहतर नहीं होगा कि browsers को मैनेज करने वाली कंपनियाँ एक optimal framework बनाकर उसे साथ में मैनेज करें? आखिर हम इस बुरे चक्र को कब तक दोहराते रहेंगे?
मैं इस स्थिति से सहमत हूँ, लेकिन निष्कर्ष से सहमत नहीं हूँ.
इस स्थिति का सतही कारण, जैसा कि मूल लेख में भी कहा गया है, यह है कि "ऐप-जैसे वेब" की मांग बढ़ गई है,
और तब भी और अब भी, वेब "ऐप-जैसी किसी चीज़" को बनाने के लिए उपयुक्त नहीं था, लेकिन बहुत जुगाड़ किया जाए तो "कुछ हद तक वैसा बनाया जा सकता है" — मैं इसे ऐसी स्थिति मानता हूँ.
असल में, वेब की उत्पत्ति ही शोध-पत्र जैसी किसी "दस्तावेज़" प्रकृति की चीज़ों को साझा करने के लिए बने एक प्लेटफ़ॉर्म के रूप में हुई थी.
सिर्फ HTML के बुनियादी घटकों को देखकर भी यह समझा जा सकता है.
फिर CGI जैसी dynamic content बनाने वाली तकनीकें आईं, और browser पक्ष में script language एम्बेड होने से आउटपुट में dynamism देना संभव हुआ, जिसके साथ "दस्तावेज़ के रूप में वेब" से बाहर निकलने की शुरुआत हुई.
समस्या यह है कि उस शुरुआती बदलाव के क्षण से लेकर आज तक, वेब की बुनियाद अब भी "दस्तावेज़" आधारित सिस्टम ही है.
बेशक web socket, webrtc, wasm जैसी "दस्तावेज़" उन्मुखता से हटने वाली कई नई तकनीकें आई हैं, लेकिन आज भी अधिकांश वेबसाइटें उसी पुराने "दस्तावेज़" आधारित प्लेटफ़ॉर्म पर निर्भर रहकर विकसित की जाती हैं.
आज भी हमें स्क्रीन बनाने के लिए div टैगों को एक के ऊपर एक जमाना पड़ता है.
यहीं तक इस स्थिति का विश्लेषण है, और फिर सवाल आता है कि समाधान क्या है.
अगर व्यवहारिकता जैसी बातों को बिल्कुल न सोचें और अगले आदर्श प्लेटफ़ॉर्म की क्षमताओं की कल्पना करें, तो वह कुछ ऐसी हो सकती है.
(यह नहीं कि हर साइट ऐसी ही होनी चाहिए, बल्कि सिर्फ application प्रकृति वाली साइटों तक सीमित करके)
सबसे पहले, browser एक तरह का app launcher बन जाएगा.
एक बार डाउनलोड कर लेने के बाद उसे offline में भी चलना चाहिए.
और app को मौजूदा html/css/js से हटकर किसी दूसरी भाषा में implement किया जाएगा.
उस प्रक्रिया में Android की तरह browser एक तरह का framework दे सकता है.
server के साथ communication का तरीका भी मौजूदा web request से हटकर किसी दूसरे paradigm का उपयोग कर सकता है.
जिन संचारों में real-time की जरूरत हो, वहाँ मौजूदा TCP communication को वैसे का वैसा इस्तेमाल किया जा सकता है,
और HTTP protocol का उपयोग न करने वाला कोई और अधिक सरल RPC communication नया बनाकर इस्तेमाल किया जा सकता है.
एक महीने पहले CURSOR का उपयोग करके AI coding क्या है यह सीखने के लिए मैंने एक development framework बनाना शुरू किया।
करीब 3 हफ्तों तक, सफलता और AI Agent द्वारा validate किया गया source code बार-बार टूटता रहा, और मैंने हर संभव तरीका अपनाकर AI Agent को नियंत्रित करने की कोशिश की, लेकिन असफल रहा।
फिर मुझे एहसास हुआ कि development framework बनाने से पहले AI Agent को नियंत्रित करने वाला source code विकसित करना प्राथमिकता है।
आखिरकार, पहला AI क्या है यह समझने के लिए शुरुआत करने के ठीक एक महीने के भीतर, मैंने ऐसा software पूरी तरह विकसित कर लिया जो AI द्वारा 100% implement और 100% operate किया जा सकता है — या अधिक सटीक रूप से कहें तो जिसमें external LLM या AI Agent की आवश्यकता ही नहीं है।
अब 14वें दिन पर, अतिरिक्त उन्नयन के लिए मैं उस META AI को आगे train कर रहा हूँ और उसके लिए operation rules बनाकर उनका पालन करवाने की प्रक्रिया चला रहा हूँ। साथ ही, लोगों द्वारा पहले अपूर्ण रूप से बनाए गए 3 MES systems का एक साथ migration, improvement और standardization चल रहा है, और यह अब समापन चरण में है।
MCP-B तकनीक का मुख्य विज़न कुछ इस तरह समझा जा सकता है।
"Chrome extension नाम के एक विश्वसनीय माध्यम के जरिए, browser पहले से सुरक्षित रूप से प्रबंधित कर रहा user information (cookie, session, authentication आदि) का उपयोग करके,
web page पर developer द्वारा पहले से परिभाषित किए गए 'tools' को AI chat window से natural language commands के जरिए कॉल और नियंत्रित किया जाएगा।"
लेकिन मुझे लगता है कि "इसके फैलने की गुंजाइश कम दिखती है", और इसके कारण मुझे इस प्रकार लगते हैं।
उपयोगकर्ता प्रतिरोध: यह सबसे बड़ी बाधा है। उपयोगकर्ताओं में अपनी browser information तक पहुंच रखने वाले extension को install करने को लेकर स्वाभाविक हिचकिचाहट और security concerns होते हैं। अगर यह तकनीक देने वाली सुविधा उन चिंताओं से कहीं अधिक प्रभावशाली न हो, तो उपयोगकर्ता installation को लेकर हिचकिचाएंगे।
web developers पर बोझ: वेबसाइट developers को मौजूदा API बनाने के अलावा MCP-B के लिए अलग से 'tools' परिभाषित और प्रबंधित करने का अतिरिक्त बोझ उठाना होगा। यदि इस तकनीक के व्यापक adoption से मिलने वाला लाभ बड़ा नहीं है, तो developers शायद यूं ही दोगुना प्रयास नहीं करना चाहेंगे।
security issues में जिम्मेदारी का सवाल: यदि इस तकनीक के जरिए कोई security incident होता है, तो जिम्मेदारी वेबसाइट developer की है, extension developer की है, या AI model provider की है—यह अस्पष्ट हो सकता है। ऐसी जटिलता कंपनियों को इस तकनीक को अपनाने से हतोत्साहित करती है।
केंद्रीकृत platform का अभाव: फिलहाल ऐसा कोई standardized directory या platform नहीं है जो बताए कि "कौन-सी वेबसाइट कौन-से tools प्रदान करती है"। उपयोगकर्ताओं के लिए वेबसाइट पर जाने से पहले यह जानना मुश्किल है कि वे कौन-सी AI capabilities इस्तेमाल कर सकते हैं।
निष्कर्षतः,
MCP-B का विचार अपने आप में तकनीकी रूप से बहुत रोचक और innovative है, लेकिन यह शायद उपयोगकर्ताओं और developers दोनों को इस बुनियादी सवाल का स्पष्ट जवाब नहीं दे पाता: "आखिर यह तरीका ही क्यों इस्तेमाल किया जाए?" मौजूदा API तरीके की तुलना में मिलने वाले फायदे स्पष्ट नहीं हैं, जबकि security concerns और development complexity जैसे नुकसान साफ दिखाई देते हैं।
इसलिए फिलहाल यह तकनीक कुछ उत्साही लोगों या विशेष उद्देश्य वाले developers के बीच प्रयोगात्मक रूप से इस्तेमाल हो सकती है, लेकिन पूरे web ecosystem में व्यापक रूप से फैलने के लिए इसके सामने काफी मुश्किलें दिखती हैं।
मैं इस लेख की मूल समस्या-चेतना से सहमत हूँ, लेकिन कुछ हिस्से ऐसे भी हैं जो थोड़ा अटपटा महसूस कराते हैं.
उदाहरण के लिए, हमारी कंपनी द्वारा संचालित एक खास सेवा-प्रचार वेबसाइट ठीक वैसी ही सादगी बनाए हुए है जिसकी इस लेख में प्रशंसा की गई है. अच्छी बात यह है कि इस वेबसाइट के ज़्यादातर तत्व काफ़ी static हैं. फ्रंटएंड का HTML और CSS जैसी चीज़ों का कोड बिना किसी framework के सीधे लोगों ने हाथ से लिखा है, और JS भी बस jQuery और Google Analytics तक ही लगा हुआ है. notice या board जैसी चीज़ें jQuery-आधारित AJAX से लागू की गई हैं, लेकिन मुझे नहीं लगता कि वह किसी तरह से अव्यावहारिक या ज़रूरत से ज़्यादा जटिल स्तर की हैं. जब मैंने बहुत पहले बुनियादी web development सीखना शुरू किया था, तब jQuery के आधार पर जिस स्तर तक implement कर सकता था, मुझे यह लगभग वैसा ही लगता है. जहाँ तक मुझे पता है, यह साइट Internet Explorer के दौर से चल रही है, इसलिए मैंने इसे खुद नहीं बनाया, लेकिन मुझे यह बुरी नहीं लगती.
लेकिन इसके साथ Git version control और CI/CD pipeline जुड़ी हुई है, और staging server तथा actual production server को अलग रखा गया है. Main branch में Pull Request merge होते ही pipeline में bundler चलाकर बने artifacts अपने-आप staging server पर deploy हो जाते हैं, और ज़िम्मेदार व्यक्ति staging server की जाँच करके deployment को अंतिम approval दे दे तो वही फिर production server पर deploy हो जाता है. पहले यह बस FTP के ज़रिए source files को सीधे production server पर overwrite करने का तरीका था, लेकिन संबंधित काम हमारी टीम में आने के बाद हमने इसे इस तरह बदल दिया.
क्या यह सचमुच अव्यावहारिक जटिलता है? पहले उस वेबसाइट का title tag बदलना मतलब बस FTP access सपोर्ट करने वाले AcroEdit (हाँ, जिन्होंने मूल रूप से उस साइट का HTML सीधे लिखा था, वे अब भी यही इस्तेमाल कर रहे थे.) से production server के HTML file में सीधे जाकर एक लाइन बदलना, save करना, और काम ख़त्म हो जाना था. इसलिए वे लोग शायद सचमुच ऐसा महसूस कर सकते हैं.
लेकिन मेरी नज़र में, इस हद तक जटिलता बढ़ाना पूरी तरह स्वीकार करने लायक था. हर काम सिर्फ़ title tag की एक पंक्ति बदलने जितना आसान तो नहीं होता. और पुराना code comment-out करके जगह-जगह चिपकाए रखने के बजाय, जब चाहें rollback कर सकने की वजह से उसे बेझिझक पूरी तरह हटा सकना, बदलावों को पारदर्शी तरीके से track और rollback कर पाना, और bundler के ज़रिए ज़रूरत हो तो कुछ बुनियादी optimization और जोड़ पाना—मेरे हिसाब से ये काफ़ी बड़े फ़ायदे हैं. actual environment में deploy होने से पहले preview करने के लिए staging server जोड़ना भी किसी नज़रिए से जटिलता ही कहा जा सकता है, लेकिन मुझे लगता है कि इसकी ज़रूरत थी.
मैं भी इस बात से काफ़ी असंतुष्ट हूँ कि तरह-तरह की वेबसाइटों का अंदरूनी code structure ज़रूरत से ज़्यादा जटिल और भारी हो गया है. आजकल Windows का Outlook app web app-आधारित है, और हाल के समय में वह ख़ास तौर पर और भी भारी हो गया है. हालत यह है कि सिर्फ़ स्क्रीन पर mail body लिखने या body को select all करने भर से lag होने लगता है, यहाँ तक कि कभी-कभी "page not responding" तक आ जाता है. यह क्यों हो रहा है, यह देखने के लिए मैंने web Outlook में developer tools खोले, और मैं चौंक गया. एक बार cache साफ़ करके refresh किया तो एक मिनट बाद भी न जाने कैसी requests लगातार आती रहीं. browser में जाँचने पर देखा कि सिर्फ़ MS Office साइट से जुड़ी चीज़ों के लिए ही कई gigabytes data store हो रखा था.
लेकिन यह लेख कई बातों को आपस में मिलाकर पेश करता है; कुछ हिस्सों से मैं सहमत हूँ, लेकिन कुछ हिस्से मुझे बिल्कुल नहीं जँचते. semantic HTML या accessibility के बारे में तो मेरी जानकारी में अतीत और भी ज़्यादा भयानक था. इसके अलावा, developer experience बेहतर होने से user experience खराब होता है—इस बात से, शायद इसलिए कि मैं web frontend developer नहीं हूँ, मुझे बिल्कुल भी सहमति नहीं होती. यहाँ तक कि यह कहना कि सारी शक्ति और नियंत्रण developers के हाथ में केंद्रित हो गए हैं, मुझे बेतुकी बात लगती है. कंपनी में शक्ति management के पास नहीं होती क्या? क्या पश्चिम में कंपनियों की संरचना कोरिया से इतनी अलग है?
हमेशा की तरह, संतुलन और मध्यम मार्ग, सादगी और व्यावहारिकता महत्वपूर्ण मूल्य हैं, और decision-making में इन्हें प्राथमिकता मिलनी चाहिए—इस बात से मैं पूरी तरह सहमत हूँ. लेकिन यह लेख ऐसा दावा करता है मानो "हर वेबसाइट को software product की तरह treat करना" पूरी तरह developers की ही ज़िम्मेदारी हो, और मुझे लगता है कि यही हिस्सा मूल समस्या-बोध को उल्टा धुंधला कर देता है. और जो हिस्से कुछ इस तरह दिखते हैं मानो बिना व्यवस्थित system वाले 'अच्छे पुराने दिनों' का महिमामंडन किया जा रहा हो, मुझे लगता है कि उल्टा वही आलोचना के ज़्यादा योग्य हैं.
सब कुछ अच्छा है, लेकिन इसे इस्तेमाल करने पर सिस्टम से Wireguard को कंट्रोल नहीं किया जा सकता। अगर आप इसे टनल से अलग इस्तेमाल करना चाहते हैं, तो इसे VM में अलग करके इस्तेमाल करना होगा।
वेब भले ही ऐप जैसा हो, फिर भी मेरा मानना है कि निष्कर्ष में कही गई दिशा के करीब जाने की कोशिश करनी चाहिए। JavaScript का ज़्यादा इस्तेमाल करने पर क्लाइंट के नज़रिए से चीज़ें भारी हो जाती हैं.
असल में ऐसा implement कर सकने वाले framework मौजूद नहीं हैं, ऐसा भी नहीं है। अभी Next.js में भी अगर client component का इस्तेमाल सिर्फ़ ज़रूरत पड़ने पर किया जाए और उसे न्यूनतम रखा जाए, तो यह मोटे तौर पर संभव है। और जैसा किसी और ने कहा था, Rails ecosystem में Hotwire(https://hotwired.dev/) जैसा framework suite (Turbo, Stimulus आदि) है, जो लेखक के बताए निष्कर्ष के काफ़ी करीब पहुँचते हुए ऐप-जैसे वेब को support करता है।
OpenAI के अधिग्रहण वाले मामले की वजह से Claude ने latest version का लाइसेंस देना बंद कर दिया है, इसलिए WindSurf में Claude 4.x version मॉडल इस्तेमाल करने के लिए महंगा API सीधे खरीदना पड़ता है—क्या Claude फिर से वापस आएगा?
कोरिया में जहां development culture management -> planner -> developer के क्रम में नीचे आती है, वहीं पश्चिम में कोरिया जैसी planner की अवधारणा नहीं होती और developer product planning आदि में सक्रिय रूप से शामिल होते हैं। पश्चिम में PM जैसी भूमिकाएं भी cover letter और self-introduction letter की तरह पूरी तरह एक जैसी अवधारणाएं नहीं हैं, इसलिए वे कोरिया के planner से भी पूरी तरह मेल नहीं खातीं। बेशक, जिन games में creative project का स्वभाव मजबूत होता है और fun व gameplay महत्वपूर्ण होते हैं, वहां पश्चिम भी एशिया की तुलना में अधिक horizontal है, लेकिन फिर भी director से developer तक नीचे आने वाली संरचना मौजूद रहती है।
क्योंकि लोग जिस development philosophy का पीछा करते हैं, वह बहुत अलग-अलग होती है.........
लगता है AI भी निष्पक्ष नहीं है।
यह बहुत डरावना है।
दुर्भावना से दर्ज किया गया रिकॉर्ड,
यादों और अनुभवों को मात देकर सबूत बन जाए
और हमें धमकाने जैसी स्थिति पैदा हो सकती है।
लोग जिन browsers का इस्तेमाल करते हैं, उनकी किस्में भी इतनी ज़्यादा नहीं हैं, फिर frameworks इतने सारे क्यों हैं? क्या बेहतर नहीं होगा कि browsers को मैनेज करने वाली कंपनियाँ एक optimal framework बनाकर उसे साथ में मैनेज करें? आखिर हम इस बुरे चक्र को कब तक दोहराते रहेंगे?
यह क्यों रद्द हुआ, यह जानने की जिज्ञासा है।
यूज़र को खुश करने वाले AI का अंतिम रूप तो पता चला कि बॉस को खुश करने वाला AI था...
मैं इस स्थिति से सहमत हूँ, लेकिन निष्कर्ष से सहमत नहीं हूँ.
इस स्थिति का सतही कारण, जैसा कि मूल लेख में भी कहा गया है, यह है कि "ऐप-जैसे वेब" की मांग बढ़ गई है,
और तब भी और अब भी, वेब "ऐप-जैसी किसी चीज़" को बनाने के लिए उपयुक्त नहीं था, लेकिन बहुत जुगाड़ किया जाए तो "कुछ हद तक वैसा बनाया जा सकता है" — मैं इसे ऐसी स्थिति मानता हूँ.
असल में, वेब की उत्पत्ति ही शोध-पत्र जैसी किसी "दस्तावेज़" प्रकृति की चीज़ों को साझा करने के लिए बने एक प्लेटफ़ॉर्म के रूप में हुई थी.
सिर्फ HTML के बुनियादी घटकों को देखकर भी यह समझा जा सकता है.
फिर CGI जैसी dynamic content बनाने वाली तकनीकें आईं, और browser पक्ष में script language एम्बेड होने से आउटपुट में dynamism देना संभव हुआ, जिसके साथ "दस्तावेज़ के रूप में वेब" से बाहर निकलने की शुरुआत हुई.
समस्या यह है कि उस शुरुआती बदलाव के क्षण से लेकर आज तक, वेब की बुनियाद अब भी "दस्तावेज़" आधारित सिस्टम ही है.
बेशक web socket, webrtc, wasm जैसी "दस्तावेज़" उन्मुखता से हटने वाली कई नई तकनीकें आई हैं, लेकिन आज भी अधिकांश वेबसाइटें उसी पुराने "दस्तावेज़" आधारित प्लेटफ़ॉर्म पर निर्भर रहकर विकसित की जाती हैं.
आज भी हमें स्क्रीन बनाने के लिए
divटैगों को एक के ऊपर एक जमाना पड़ता है.यहीं तक इस स्थिति का विश्लेषण है, और फिर सवाल आता है कि समाधान क्या है.
अगर व्यवहारिकता जैसी बातों को बिल्कुल न सोचें और अगले आदर्श प्लेटफ़ॉर्म की क्षमताओं की कल्पना करें, तो वह कुछ ऐसी हो सकती है.
(यह नहीं कि हर साइट ऐसी ही होनी चाहिए, बल्कि सिर्फ application प्रकृति वाली साइटों तक सीमित करके)
सबसे पहले, browser एक तरह का app launcher बन जाएगा.
एक बार डाउनलोड कर लेने के बाद उसे offline में भी चलना चाहिए.
और app को मौजूदा html/css/js से हटकर किसी दूसरी भाषा में implement किया जाएगा.
उस प्रक्रिया में Android की तरह browser एक तरह का framework दे सकता है.
server के साथ communication का तरीका भी मौजूदा web request से हटकर किसी दूसरे paradigm का उपयोग कर सकता है.
जिन संचारों में real-time की जरूरत हो, वहाँ मौजूदा TCP communication को वैसे का वैसा इस्तेमाल किया जा सकता है,
और HTTP protocol का उपयोग न करने वाला कोई और अधिक सरल RPC communication नया बनाकर इस्तेमाल किया जा सकता है.
ओह, लगता है WindSurf का भविष्य भी इतना उज्ज्वल नहीं है।
एक महीने पहले CURSOR का उपयोग करके AI coding क्या है यह सीखने के लिए मैंने एक development framework बनाना शुरू किया।
करीब 3 हफ्तों तक, सफलता और AI Agent द्वारा validate किया गया source code बार-बार टूटता रहा, और मैंने हर संभव तरीका अपनाकर AI Agent को नियंत्रित करने की कोशिश की, लेकिन असफल रहा।
फिर मुझे एहसास हुआ कि development framework बनाने से पहले AI Agent को नियंत्रित करने वाला source code विकसित करना प्राथमिकता है।
आखिरकार, पहला AI क्या है यह समझने के लिए शुरुआत करने के ठीक एक महीने के भीतर, मैंने ऐसा software पूरी तरह विकसित कर लिया जो AI द्वारा 100% implement और 100% operate किया जा सकता है — या अधिक सटीक रूप से कहें तो जिसमें external LLM या AI Agent की आवश्यकता ही नहीं है।
अब 14वें दिन पर, अतिरिक्त उन्नयन के लिए मैं उस META AI को आगे train कर रहा हूँ और उसके लिए operation rules बनाकर उनका पालन करवाने की प्रक्रिया चला रहा हूँ। साथ ही, लोगों द्वारा पहले अपूर्ण रूप से बनाए गए 3 MES systems का एक साथ migration, improvement और standardization चल रहा है, और यह अब समापन चरण में है।
और अब मैं एक और evolution की तैयारी कर रहा हूँ।
MCP-B तकनीक का मुख्य विज़न कुछ इस तरह समझा जा सकता है।
"Chrome extension नाम के एक विश्वसनीय माध्यम के जरिए, browser पहले से सुरक्षित रूप से प्रबंधित कर रहा user information (cookie, session, authentication आदि) का उपयोग करके,
web page पर developer द्वारा पहले से परिभाषित किए गए 'tools' को AI chat window से natural language commands के जरिए कॉल और नियंत्रित किया जाएगा।"
लेकिन मुझे लगता है कि "इसके फैलने की गुंजाइश कम दिखती है", और इसके कारण मुझे इस प्रकार लगते हैं।
निष्कर्षतः,
MCP-B का विचार अपने आप में तकनीकी रूप से बहुत रोचक और innovative है, लेकिन यह शायद उपयोगकर्ताओं और developers दोनों को इस बुनियादी सवाल का स्पष्ट जवाब नहीं दे पाता: "आखिर यह तरीका ही क्यों इस्तेमाल किया जाए?" मौजूदा API तरीके की तुलना में मिलने वाले फायदे स्पष्ट नहीं हैं, जबकि security concerns और development complexity जैसे नुकसान साफ दिखाई देते हैं।
इसलिए फिलहाल यह तकनीक कुछ उत्साही लोगों या विशेष उद्देश्य वाले developers के बीच प्रयोगात्मक रूप से इस्तेमाल हो सकती है, लेकिन पूरे web ecosystem में व्यापक रूप से फैलने के लिए इसके सामने काफी मुश्किलें दिखती हैं।
मैं इस लेख की मूल समस्या-चेतना से सहमत हूँ, लेकिन कुछ हिस्से ऐसे भी हैं जो थोड़ा अटपटा महसूस कराते हैं.
उदाहरण के लिए, हमारी कंपनी द्वारा संचालित एक खास सेवा-प्रचार वेबसाइट ठीक वैसी ही सादगी बनाए हुए है जिसकी इस लेख में प्रशंसा की गई है. अच्छी बात यह है कि इस वेबसाइट के ज़्यादातर तत्व काफ़ी static हैं. फ्रंटएंड का HTML और CSS जैसी चीज़ों का कोड बिना किसी framework के सीधे लोगों ने हाथ से लिखा है, और JS भी बस jQuery और Google Analytics तक ही लगा हुआ है. notice या board जैसी चीज़ें jQuery-आधारित AJAX से लागू की गई हैं, लेकिन मुझे नहीं लगता कि वह किसी तरह से अव्यावहारिक या ज़रूरत से ज़्यादा जटिल स्तर की हैं. जब मैंने बहुत पहले बुनियादी web development सीखना शुरू किया था, तब jQuery के आधार पर जिस स्तर तक implement कर सकता था, मुझे यह लगभग वैसा ही लगता है. जहाँ तक मुझे पता है, यह साइट Internet Explorer के दौर से चल रही है, इसलिए मैंने इसे खुद नहीं बनाया, लेकिन मुझे यह बुरी नहीं लगती.
लेकिन इसके साथ Git version control और CI/CD pipeline जुड़ी हुई है, और staging server तथा actual production server को अलग रखा गया है. Main branch में Pull Request merge होते ही pipeline में bundler चलाकर बने artifacts अपने-आप staging server पर deploy हो जाते हैं, और ज़िम्मेदार व्यक्ति staging server की जाँच करके deployment को अंतिम approval दे दे तो वही फिर production server पर deploy हो जाता है. पहले यह बस FTP के ज़रिए source files को सीधे production server पर overwrite करने का तरीका था, लेकिन संबंधित काम हमारी टीम में आने के बाद हमने इसे इस तरह बदल दिया.
क्या यह सचमुच अव्यावहारिक जटिलता है? पहले उस वेबसाइट का title tag बदलना मतलब बस FTP access सपोर्ट करने वाले AcroEdit (हाँ, जिन्होंने मूल रूप से उस साइट का HTML सीधे लिखा था, वे अब भी यही इस्तेमाल कर रहे थे.) से production server के HTML file में सीधे जाकर एक लाइन बदलना, save करना, और काम ख़त्म हो जाना था. इसलिए वे लोग शायद सचमुच ऐसा महसूस कर सकते हैं.
लेकिन मेरी नज़र में, इस हद तक जटिलता बढ़ाना पूरी तरह स्वीकार करने लायक था. हर काम सिर्फ़ title tag की एक पंक्ति बदलने जितना आसान तो नहीं होता. और पुराना code comment-out करके जगह-जगह चिपकाए रखने के बजाय, जब चाहें rollback कर सकने की वजह से उसे बेझिझक पूरी तरह हटा सकना, बदलावों को पारदर्शी तरीके से track और rollback कर पाना, और bundler के ज़रिए ज़रूरत हो तो कुछ बुनियादी optimization और जोड़ पाना—मेरे हिसाब से ये काफ़ी बड़े फ़ायदे हैं. actual environment में deploy होने से पहले preview करने के लिए staging server जोड़ना भी किसी नज़रिए से जटिलता ही कहा जा सकता है, लेकिन मुझे लगता है कि इसकी ज़रूरत थी.
मैं भी इस बात से काफ़ी असंतुष्ट हूँ कि तरह-तरह की वेबसाइटों का अंदरूनी code structure ज़रूरत से ज़्यादा जटिल और भारी हो गया है. आजकल Windows का Outlook app web app-आधारित है, और हाल के समय में वह ख़ास तौर पर और भी भारी हो गया है. हालत यह है कि सिर्फ़ स्क्रीन पर mail body लिखने या body को select all करने भर से lag होने लगता है, यहाँ तक कि कभी-कभी "page not responding" तक आ जाता है. यह क्यों हो रहा है, यह देखने के लिए मैंने web Outlook में developer tools खोले, और मैं चौंक गया. एक बार cache साफ़ करके refresh किया तो एक मिनट बाद भी न जाने कैसी requests लगातार आती रहीं. browser में जाँचने पर देखा कि सिर्फ़ MS Office साइट से जुड़ी चीज़ों के लिए ही कई gigabytes data store हो रखा था.
लेकिन यह लेख कई बातों को आपस में मिलाकर पेश करता है; कुछ हिस्सों से मैं सहमत हूँ, लेकिन कुछ हिस्से मुझे बिल्कुल नहीं जँचते. semantic HTML या accessibility के बारे में तो मेरी जानकारी में अतीत और भी ज़्यादा भयानक था. इसके अलावा, developer experience बेहतर होने से user experience खराब होता है—इस बात से, शायद इसलिए कि मैं web frontend developer नहीं हूँ, मुझे बिल्कुल भी सहमति नहीं होती. यहाँ तक कि यह कहना कि सारी शक्ति और नियंत्रण developers के हाथ में केंद्रित हो गए हैं, मुझे बेतुकी बात लगती है. कंपनी में शक्ति management के पास नहीं होती क्या? क्या पश्चिम में कंपनियों की संरचना कोरिया से इतनी अलग है?
हमेशा की तरह, संतुलन और मध्यम मार्ग, सादगी और व्यावहारिकता महत्वपूर्ण मूल्य हैं, और decision-making में इन्हें प्राथमिकता मिलनी चाहिए—इस बात से मैं पूरी तरह सहमत हूँ. लेकिन यह लेख ऐसा दावा करता है मानो "हर वेबसाइट को software product की तरह treat करना" पूरी तरह developers की ही ज़िम्मेदारी हो, और मुझे लगता है कि यही हिस्सा मूल समस्या-बोध को उल्टा धुंधला कर देता है. और जो हिस्से कुछ इस तरह दिखते हैं मानो बिना व्यवस्थित system वाले 'अच्छे पुराने दिनों' का महिमामंडन किया जा रहा हो, मुझे लगता है कि उल्टा वही आलोचना के ज़्यादा योग्य हैं.
उबाऊ~ सा दिखावा…
कोरिया में तो हर चीज़ का नतीजा आखिर Java ही होता है, इसलिए यह थोड़ा अजीब लग रहा है lol
मेरा मानना है कि दूसरे देश की तकनीक != दूसरे देश का डेटा
फिलहाल जब तक यह फ्री में उपलब्ध नहीं होता, तब तक यक़ीन नहीं होगा। Grok तो 30 डॉलर का भी है, इसलिए सब्सक्राइब करने में भी डर लगता है...
हाहाहाहा अचानक पिट गए graduate student पूरी तरह हैरान ..