वेब ने दूरस्थ अनुप्रयोगों और X के स्थान को क्यों नहीं जीता?


19

एक्स विंडो सिस्टम 25 साल पुराना है, कल (15 तारीख को) उसका जन्मदिन था।

जैसा कि आप शायद जानते हैं, इसकी सबसे महत्वपूर्ण विशेषताओं में से एक सर्वर साइड और क्लाइंट साइड का एक तरह से अलग होना है, जो कि न तो माइक्रोसॉफ्ट का है, न ही एपल्स या वायलैंड के विंडोिंग सिस्टम का है।

वापस दिनों में (अस्पष्ट फंतासी के लिए खेद है) कई लोगों का मानना ​​था कि सर्वर और क्लाइंट के इस अलगाव के कारण विंडोज़ बनाने के अन्य तरीकों पर एक्स हावी होगा, जिससे उपयोगकर्ता को क्लिक करने और उस पर टाइप करने पर एप्लिकेशन को कहीं और सर्वर पर चलाया जा सकता है। घर में खुद का कंप्यूटर।

यह उपयोग स्पष्ट रूप से अभी भी मौजूद है, लेकिन सर्वोत्तम रूप से हाशिए पर है। जब हम एक सर्वर पर चलने वाले प्रोग्राम लिखते हैं और उपयोग करते हैं, तो हम लगभग इसे html / css / js के साथ वेब का उपयोग करते हैं।

वेब क्यों जीता, और एक्स नहीं? वेब के लिए उपयोग की जाने वाली प्रौद्योगिकियाँ (कहा जाता है कि html / css / js) एक गड़बड़ है। सभी बैक-एंड-फ्रेमवर्क (रेल, Django और सभी) के साथ संयुक्त यह वास्तव में थ्रू नेविगेट करने के लिए एक जंगल है। फिर भी वेब रचनात्मकता और प्रगति के साथ पनपता है, जबकि रिमोट एक्स ऐप नहीं है।


6
दो भी दूर से तुलनीय नहीं हैं। एक्स-सर्वर कनेक्शन मुझे एक दूरस्थ अनुप्रयोग चलाने की अनुमति देता है, और यह स्थानीय रूप से जीयूआई है, जो मुझे एक स्थानीय क्लाइंट में दूरस्थ संसाधनों को लोड करने की अनुमति देने से पूरी तरह से अलग-अलग उपयोग-मामला है।
मार्टिज़न पीटर्स

3
मैं इस बात से सहमत नहीं हूं कि इसमें कोई अंतर है। जब मैं अपने वेब क्लाइंट (ब्राउज़र) को सर्वर (स्थानीय रूप से या दूरस्थ) से कनेक्ट करता हूं तो मैं अपने (वेब-) ऐप के जीयूआई को देख सकता हूं। ठीक उसी तरह जैसे मैं अपने ऐप के GUI को X सेशन के साथ देख सकता हूं।
मार्टिन जोसेफसन

4
X11 प्रोग्राम लिखने की कोशिश करें और इसकी तुलना HTML पेज से करें - जरूरत बैंडविड्थ की भी तुलना करें। इसके अतिरिक्त, डब्ल्यूडब्ल्यूडब्ल्यू ने एक्स 11 की जगह नहीं ली, यह गोफर की जगह ले ली।

2
पीटर: निश्चित रूप से, पृष्ठ क्लाइंट पर प्रस्तुत किया गया है, और जेएस क्लाइंट पर चलता है, लेकिन यह केवल तकनीकी है। अधिक बार नहीं, कोड सर्वर साइड (php, java, .net, python, ruby, जो भी हो) पर चलता है। व्यवहार में, वे सर्वर पर चलाने के लिए और क्लाइंट पर दिखाए जाने वाले ऐप्स के लिए दोनों इंटरफेस हैं। एक्स और वेब इसे अलग-अलग तरीकों से करता है, लेकिन यह इसका सार है।
मार्टिन जोसेफसन

14
क्योंकि प्रौद्योगिकी ने वयस्क मनोरंजन उद्योग द्वारा सत्यापन को पारित नहीं किया था, इसलिए प्रौद्योगिकी को मुख्यधारा में अपनाने के लिए एक आवश्यक कदम (यह कहने का एक फैंसी तरीका है कि नग्न महिलाओं के चित्र एक्स सिस्टम पर जल्दी उपलब्ध नहीं हुए)।
dasblinkenlight 12

जवाबों:


22

अब यह पूरी तरह से स्पष्ट और मौलिक लगता है, लेकिन वर्ल्ड वाइड वेब का हत्यारा नवाचार हाइपरलिंक था। यहां तक ​​कि अगर X एक मॉडेम लिंक पर पूरी तरह से बेकार नहीं था, तो एक क्लिक के माध्यम से एक पूरी तरह से नए सर्वर पर एक पूरी तरह से नई प्रक्रिया शुरू करने में असमर्थता उस तरह के उपयोग के मामले में इसके गोद लेने में बाधा होगी।


1
यह बहुत सही जवाब हो सकता है। इसके अलावा वेब क्लाइंट Apple और Microsoft OS पर भी चले।
मार्टिन जोसेफसन

हाइपरलिंक वर्ल्ड वाइड वेब का एक नवाचार नहीं था। इसे पहले भी कई बार लागू किया गया था, जैसे कि एप्पल के हाइपरकार्ड में, 80 और 90 के दशक में एक वेब ब्राउजर के लिए कई असमानताओं के साथ एक लोकप्रिय कार्यक्रम। हाइपरटेक्स्ट और हाइपरलिंक्स की अवधारणा 60 के दशक में वापस जाती है, प्रोजेक्ट ज़ानाडू के साथ, और टिम बर्नर्स-ली द्वारा 90 के दशक में सर्न में हाइपरटेक्स्ट का अपना नेटवर्क-आधारित कार्यान्वयन बनाने से पहले इसे कई प्रारूपों में कई बार लागू किया गया है।
चार्ल्स साल्विया

3
@CharlesSalvia: HTML हाइपरलिंक्स की सफलता URL के कारण थी। विशेष रूप से इसके सार्वभौमिक पहलू: वैश्विक, काम करने के लिए बस पर्याप्त केंद्रीय प्राधिकरण के साथ, और एक विशिष्ट मीडिया प्रकार या प्रौद्योगिकी से बंधा नहीं है। आपकी पिछली प्रौद्योगिकियां दूर थीं, बहुत कम सार्वभौमिक थीं।
MSALERS

17

क्योंकि X को आवेदन लिखने के लिए आपके पास CS डिग्री होना आवश्यक है। जबकि वेब के लिए आवश्यक है कि आप टाइप करने की क्षमता रखते हैं (वह भी नहीं)।

खासकर शुरुआती दिनों में जब वेब सिर्फ html था। आप एक टर्मिनल खोल सकते हैं और 10 मिनट में एक कार्य प्रदर्शन का निर्माण कर सकते हैं और फिर तुरंत प्रतिक्रिया के साथ अंतःक्रियात्मक रूप से इसमें सुधार कर सकते हैं। प्रवेश के इस कम बार ने बड़े पैमाने पर उपयोगकर्ता को पीछे छोड़ दिया। दूसरी ओर एक्स-सर्वर एप्लिकेशन का निर्माण गैर-तुच्छ कार्य है जो अनुभवी प्रोग्रामर के लिए भी है।

वेब को कार्यक्षमता के मामले में X applicatoin का प्रत्यक्ष प्रतियोगी होने और क्षमताओं के समान GUI प्रदान करने में 10 साल लग गए हैं। इस कार्यक्षमता को भाषा स्टैक में जोड़ा गया है समय के साथ डेवलपर्स को अगले जोड़े जाने से पहले सुविधाओं के एक सेट को मास्टर करने की अनुमति दी गई थी; इसलिए तकनीकी जटिलता के इस क्रमिक विस्तार ने निम्न बार (जो लोग पहले से ही क्षेत्र में हैं और उनमें से बहुत से हैं) को बनाए रखा है। मैदान में कूदना अब 10 साल पहले की तुलना में बहुत कठिन है लेकिन यह अभी भी संभव है और वेब की त्वरित प्रतिक्रिया सीखने को अधिक संतुष्टिदायक बनाती है (मनुष्य को अपनी ड्राइव को सुदृढ़ करने के लिए त्वरित संतुष्टि की आवश्यकता होती है)।

लागत एक और ड्राइवर है। वास्तव में एक एक्स-सर्वर को विकसित करने के लिए पर्याप्त प्रोग्रामिंग कौशल सीखने की लागत महत्वपूर्ण है। फिर इसके अलावा आपके एप्लिकेशन को चलाने के लिए सर्वर की उपलब्धता ने लागत को बढ़ा दिया है। एचटीएमएल लिखना सीखना व्यावहारिक रूप से "हैलो वर्ल्ड" पेज को प्राप्त करने के लिए कुछ भी नहीं था और चल रहा है और इंटरनेट सेवा प्रदाताओं ने आपको एक वेब कनेक्शन प्राप्त करने के लिए प्रेरित करने के लिए मुफ्त होस्टिंग प्रदान की है। तो आप मुफ्त में अभ्यास कर सकते हैं। जब आपको अंततः व्यवसाय की आवश्यकता होती है, तो होस्टिंग कंपनियों की उपलब्धता बढ़ी है और लागत हमेशा अपेक्षाकृत सस्ती रही है।


1
आप मानते हैं कि एक्स पर प्रयोग होने वाले ऐप को लिखने के लिए आपको एक्स एपी को समझने की आवश्यकता है। लेकिन जिस तरह आपको वेब ऐप लिखने के लिए HTTP को समझने की आवश्यकता नहीं है, आपको X के तहत चलने वाले ऐप को लिखने के लिए X को समझने की आवश्यकता नहीं है। आप इसे एक भाषा में लिख सकते हैं, जिसे आप पसंद करते हैं, और बस शीर्ष पर एक जीटीके पुस्तकालय है। Html और css और js और एक सर्वरसाइड भाषा सीखने की तुलना में आसान तरीका है। इसका सार यह है: जिस तरह आपको एक वेब साइट को प्रकाशित करने के लिए http सर्वर लिखने की आवश्यकता नहीं है, वैसे ही आपको एक एक्स ऐप लिखने के लिए एक्स सर्वर लिखने की आवश्यकता नहीं है।
मार्टिन जोसेफसन

मैं वहां आपके विश्लेषण से असहमत हूं। यद्यपि आपके पास एक बिंदु है कि एक आधुनिक वेब एप्लिकेशन लिखना अब लगभग उतना ही जटिल है जितना कि एक्स एप्लिकेशन लिखना 10 साल पहले था। एक्स-एप्लिकेशन लिखने के लिए अभी भी एक तुच्छ प्रक्रिया नहीं है। यह एक विंडोज़ अनुप्रयोग लिखने की तरह है। अच्छी तरह से किसी की क्षमता से परे, जिसने महत्वपूर्ण प्रोग्रामिंग अनुभव नहीं किया है। दूसरी ओर एक HTML पेज लगाना तुच्छ है और इसे 10 मिनट में किया जा सकता है (एक शुरुआत के द्वारा भी)। इस प्रकार त्वरित पुन: प्रवर्तन और जल्दी से प्रयोग करने की क्षमता होती है। यह प्रवेश के लिए बहुत कम बार बनाता है।
मार्टिन यॉर्क

वेब स्थापित होने के बाद तक GTK उपलब्ध नहीं था।
user16764

@ user16764: यह सच नहीं है। मैं 1997 में GTK का उपयोग कर रहा था (यह सुनिश्चित नहीं था कि जब वे पहली बार शुरू हुए थे लेकिन उससे पहले)। वेब (एचटीएमएल / एचटीटीपी के रूप में) तब हो सकता है, लेकिन अच्छी तरह से स्थापित नहीं हुआ। मेरा मतलब है कि वेब ब्राउज़र केवल 92 में मुख्य धारा में लाया जा रहा था (पहली बार मैंने देखा था)। X में कई अन्य विंडो मैनेजर हैं जो हालांकि उससे पहले प्रयोग करने योग्य थे। मुझे याद है कि मैं टॉम का उपयोग कर रहा हूं (टॉम का विंडो मैनेजर मुझे विश्वास है) और एक अन्य थोड़ा उच्च स्तर का एक (जिसे मैं भूल जाता हूं) लेकिन 90 में (बहुत सारे) से चुनने के लिए बहुत सारे थे (और वे इससे पहले उपलब्ध थे (मुझे लगता है))।
मार्टिन यॉर्क

@ लॉकीस्टारी: आप विंडो मैनेजरों और जीयूआई के कामों को भ्रमित कर रहे हैं। हालांकि एक निश्चित ओवरलैप (GNOME / Gtk, KDE / Qt) वे निश्चित रूप से समान नहीं हैं। यहां तक ​​कि खिड़की के प्रबंधकों के साथ भी आपके पास दर्द की दुनिया थी।
एमएसलटर्स

11

इसका उत्तर यह है कि "तकनीकी कारणों के बजाय ऐतिहासिक या सामाजिक-राजनीतिक कारणों से कई तकनीकों को अपनाया जाता है।" किसी समस्या के लिए सबसे अच्छा समाधान हमेशा प्रमुख तकनीक नहीं बनता है। (वास्तव में, यह शायद ही कभी होता है।)

2012 में, जहां डेस्कटॉप एप्लिकेशन के साथ परस्पर अनुप्रयोगों को बनाने के लिए HTTP सर्वर का उपयोग किया जा रहा है, HTTP और X के बीच तुलना दिलचस्प है। दृष्टिहीनता में, समृद्ध, संवादात्मक नेटवर्क परिनियोजित अनुप्रयोगों को विकसित करने के लिए X संभवतः एक बेहतर तकनीक है। इंटरएक्टिव डेस्कटॉप जैसे एप्लिकेशन HTTP की तरह एक स्टेटलेस, डॉक्यूमेंट-ओरिएंटेड टेक्नोलॉजी के लिए अच्छी तरह से मैप नहीं करते हैं और इस मिसमैच में ऐतिहासिक रूप से सभी तरह के वर्क-अराउंड (हैक्स) हैं, जिससे राज्य बनाया जा सकता है, जैसे कि कुकीज, सेशन आदि।

लेकिन HTTP का मूल उद्देश्य स्टेटफुल डेस्कटॉप जैसी ऐप विकसित करना नहीं था। यह दस्तावेजों को पुनः प्राप्त करने और जानकारी प्रदर्शित करने के लिए था - ऐसी जानकारी जो अन्य दस्तावेजों से लिंक हो सकती है जो तुरंत प्रदर्शित हो सकती है। दस्तावेजों के एक जुड़े संग्रह का विचार थिओडोर नेल्सन के " प्रोजेक्ट ज़ानाडू " के साथ 1960 के दशक में वापस चला गया । वेब को नेल्सन की अवधारणा का कार्यान्वयन माना जाता था हाइपरटेक्स्ट, जो मुद्रित पृष्ठ को कंप्यूटरीकृत करने का एक प्रयास था - जैसे कि विश्वकोश या समाचार पत्र - उपयोगकर्ता को एक क्लिक से एक लेख से दूसरे में तुरंत "कूद" करने की अनुमति देता है।

इस विचार के कई पुनरावृत्तियाँ आई हैं, जैसे कि Apple गईं हाइपरकार्ड , जिसने हाइपरटेक्स्ट / हाइपरलिंक्स की अवधारणा को लागू किया था, लेकिन कभी भी नेटवर्क पर तैनात नहीं किया गया था। वर्ल्ड वाइड वेब CERN के हाइपरटेक्स्ट की अवधारणा का नेटवर्क आधारित कार्यान्वयन था, और संभवत: यह बंद हो गया क्योंकि टिम बर्नर्स-ली ने अपने ब्राउज़र कोड लाइब्रेरी को मुफ्त में जारी किया, जिससे दूसरों को इसके साथ प्रयोग करने की अनुमति मिली। इसने अंततः नेटस्केप के पूर्ववर्ती मार्क एंड्रीसेन के मोज़ेक ब्राउज़र का नेतृत्व किया। और बाकी इतिहास है।


लेकिन ... इतनी सारी तकनीकों के साथ, नई संभावनाएं उभरने लगीं कि HTTP या हाइपरटेक्स्ट के मूल डिजाइनर वास्तव में बहुत ज्यादा नहीं सोचते थे। वेब का व्यवसायीकरण हो गया और लोगों ने ऐसी वेबसाइटें विकसित करना शुरू कर दिया, जिनमें खरीदारी की गाड़ियां और लॉगइन जैसी स्टेटफुल इंटरेक्टिविटी दिखाई गई। यह अधिक से अधिक स्पष्ट हो गया कि HTTP का स्टेटलेस और डॉक्यूमेंट-ओरिएंटेड स्वभाव डेस्कटॉप जैसी एप्लिकेशन के लिए बहुत अच्छी तरह से अनुकूल नहीं था। लेकिन उस समय, यह बहुत देर हो चुकी थी। हर कोई पहले से ही HTTP का उपयोग कर रहा था। तो, यहाँ हम आज हैं, विभिन्न हैक किए गए AJAX अनुप्रयोगों के साथ, वे डेस्कटॉप ऐप हैं।


3

प्रौद्योगिकियां अब इसी तरह की समस्याओं को हल करने की कोशिश कर सकती हैं, लेकिन उन्हें यकीन है कि अतीत में नहीं था।

वर्तमान HTML स्टैक वास्तव में सरल पाठ-दस्तावेज़ हस्तांतरण से समय के साथ विकसित हुआ, "दृश्य" दस्तावेजों के माध्यम से थोड़ा स्क्रिप्टिंग के साथ, पूर्ण-विशेषताओं वाले एप्लिकेशन प्लेटफ़ॉर्म में।

उस समय जब HTML शुरू हुआ, कोई भी कभी भी दूरस्थ कंप्यूटर से कनेक्ट करने और वहां ग्राफ़िकल एप्लिकेशन चलाने के बारे में सपने नहीं देख सकता था। इंटरनेट के बाद ही बेहतर विलंबता मिली और थ्रूपुट संभव हुआ। फिर भी उस समय, HTML पहले से ही मौजूद था। हर कोई जानता था कि यह ग्राहकों और उपयोगकर्ताओं को ग्राफिकल एप्लिकेशन तक पहुंच प्रदान करने का तरीका था, जो रिमोट मशीन पर चलता है।

और हर "फ्री" सिस्टम के साथ, पूरी चीज़ को "रीसेट" करना और इस बार इसे बेहतर करने के लिए नए सिरे से शुरू करना असंभव हो गया। इसलिए हमें एचटीएमएल / सीएसएस / जेएस को बंद करने और उपयोग करने की आवश्यकता है और केवल लोगों की इच्छा है कि इसका समर्थन करने वाले अंत में समझदार होंगे और इसे वर्षों की विरासत के साथ दफन कर देंगे।

इस सवाल का जवाब "वेब क्यों जीता?"। कोई प्रतियोगिता नहीं थी, सब कुछ शुरू होने से पहले वेब जीता।


1
जिस समय HTML शुरू हुआ, उस समय NSCA HTTP सर्वर और इसके SGI के साथ पहले से ही सर्वर-साइड कंप्यूटिंग मौजूद थी। अधिकांश अनुप्रयोगों ने पाठ दिया, लेकिन मुझे याद है कि वह बी / डब्ल्यू कस्टम मानचित्र, गूगल मैप्स के पूर्वज को प्रस्तुत करने में सक्षम था।
मौविसील

छवि नक्शे वास्तव में पिछली शताब्दी के अंतिम दशक के शुरुआती वर्षों में आते हैं।
MSALERS

1

मैं सहमत हूं कि, सिद्धांत रूप में, दोनों समान हैं। यदि आप यह सवाल पूछते हैं कि "हम एक सर्वर पर कोड कैसे चला सकते हैं लेकिन एक दूरस्थ क्लाइंट पर विज़ुअलाइज़ेशन प्रदान करते हैं?", यह सोचना उचित है कि स्वतंत्र टीम या तो समाधान के साथ आ सकती है।

मुझे संदेह है कि एक कारण कुछ पहलुओं में दूसरे की तुलना में अधिक लोकप्रिय है क्योंकि दोनों एक ही समस्या को पूरी तरह से अलग-अलग दृष्टिकोण से देखते हैं। X एक तकनीकी समस्या का एक तकनीकी समाधान है, लेकिन वेब एक सामाजिक को हल करने की आवश्यकता के रूप में विकसित हुआ है समस्या - मैं किसी दूरस्थ सर्वर से संसाधन कैसे ले सकता हूं और इसे अपने स्थानीय मशीन पर प्रदर्शित कर सकता हूं, और इसे इस तरह से कर सकता हूं जो आसान है और सुविधाजनक?

वेब "जीता" क्योंकि यह अधिक लोगों द्वारा अनुभव की गई समस्या को हल करता है। एक कार सादृश्य के बारे में सोचें: दोनों लक्जरी सेडान और ट्रक समान रूप से एक ही समस्या को हल करते हैं: किसी चीज़ को एक स्थान से दूसरे स्थान तक कैसे पहुँचाया जाए।

ट्रक ने बिंदु A से बिंदु B तक किसी चीज़ को ढोना कैसे संभव है, की तकनीकी समस्या को हल किया और इसके लिए यह काफी अच्छी तरह से काम करता है। यात्री कार लोगों के लिए आरामदायक होने के साथ-साथ यात्रा करने और अधिक लोगों और कम खाद को ले जाने के लिए विकसित हुई। यह एक आवश्यकता बन गई जो कि उपयुक्तता की आवश्यकता थी। इस प्रकार, समय के साथ, दूर तक जाने वाली यात्री कारों की संख्या ने सड़क पर पिक ट्रकों की संख्या को बढ़ा दिया है (मैं अनुमान लगा रहा हूं, शिकागो यातायात के अवलोकन के आधार पर, शायद यह टेक्सास में अलग है? :-)

तो, कार / ट्रक सादृश्य की तरह, वेब और X11 दोनों यकीनन एक ही तकनीकी समस्या को हल करते हैं, लेकिन वे पूरी तरह से अलग उद्देश्यों की पूर्ति करते हैं।


1

आप सेब की तुलना नाशपाती से कर रहे हैं। एक्स विंडो स्क्रीन सामग्री के प्रतिपादन को एक स्थानीय ग्राहक में अलग करने के बारे में है, जो कि पतली तार द्वारा सामग्री के स्रोत से जुड़ा हो सकता है। यह वास्तव में "ग्लास ट्टी" युग से उच्च गुणवत्ता वाले ग्राफिक्स के डोमेन तक कम्प्यूटेशनल मॉडल का विस्तार है। X की उत्पत्ति उस समय हुई जब पीसी अभी भी बहुत कमज़ोर थे, और अधिकांश वास्तविक गणना यूनिक्स या फ़्रेमेन्स बॉक्स पर की गई थी। यह विचार अपेक्षाकृत सस्ते "एक्स टर्मिनल्स" और अपेक्षाकृत धीमी नेटवर्क की शक्ति का उपयोग करने के लिए किया गया था, ताकि इन गंभीर कम्प्यूटेशनल रीसस को ग्राफिक रूप से तैयार किया जा सके।

मैक और पीसी पर यह नहीं जीता गया कारण यह है कि उनका विकास हमेशा गेम, संपादकों और व्यावसायिक ग्राफिक्स सहित स्थानीय अनुप्रयोगों में उच्च अंत ग्राफिक्स का समर्थन करने की इच्छा से प्रेरित था । सहायक नेटवर्क निवासी अनुप्रयोगों का समर्थन हाल ही में किया गया है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.