questions - javascript programs




एक मानक ब्राउज़र आभासी मशीन की बजाय जावास्क्रिप्ट क्यों? (20)

... तुम्हारा मतलब है...

जावा और जावा एप्लेट फ्लैश और एडोब एयर आदि ..

आम तौर पर, कोई भी आरआईए ढांचा आपकी आवश्यकताओं को भर सकता है; लेकिन प्रत्येक के लिए इसका उपयोग करने के लिए भुगतान करने की कीमत है (ईजे रनटाइम ब्राउज़र पर / या प्रोपेटरी या / और शुद्ध डेस्कटॉप से ​​कम विकल्प) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

किसी भी गैर-वेब languaje के साथ वेब विकसित करने के लिए, आपके पास जीडब्ल्यूटी है: जावा विकसित करें, जावास्क्रिप्ट को संकलित करें

क्या किसी विशेष भाषा के उपयोग की आवश्यकता के बजाय ब्राउज़र में होस्ट की गई मानक वर्चुअल मशीन के माध्यम से भाषाओं (जावा, पायथन, रूबी इत्यादि) के एक सेट का समर्थन करने के लिए यह समझदारी नहीं होगी - वास्तव में, एक विशेष प्रतिमान - केवल क्लाइंट स्क्रिप्टिंग के लिए?

सुझाव को स्पष्ट करने के लिए, किसी वेब पेज में जावास्क्रिप्ट जैसी उच्च-स्तरीय भाषा की बजाय बाइट कोड होगा।

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


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

यदि आपके अनुप्रयोगों के लिए सहजता की कमी है क्योंकि सर्वर-साइड और क्लाइंट-साइड अच्छी तरह से संचार नहीं कर रहे हैं, तो हो सकता है कि आप पुनर्विचार करना चाहें कि आप अपने अनुप्रयोगों को कैसे आर्किटेक्ट करते हैं। मैंने बेहद मजबूत वेब साइटों और वेब अनुप्रयोगों के साथ काम किया है, और मैंने कभी कभी नहीं कहा है, "हम्म, मैं वास्तव में जावास्क्रिप्ट कर सकता हूं (xyz)।" अगर ऐसा हो सकता है, तो यह जावास्क्रिप्ट नहीं होगा - यह एक्शनस्क्रिप्ट या एआईआर या सिल्वरलाइट होगा। मुझे इसकी आवश्यकता नहीं है, और न ही अधिकांश डेवलपर्स करते हैं। वे अच्छी तकनीकें हैं, लेकिन वे एक तकनीक के साथ एक समस्या को हल करने की कोशिश करते हैं, न कि ... अच्छा, एक समाधान।


आप सबसे अच्छा कैसे परिभाषित करते हैं? ब्राउज़र के लिए सर्वश्रेष्ठ, या डेवलपर के लिए सबसे अच्छा? (प्लस ईसीएमएस्क्रिप्ट जावास्क्रिप्ट से अलग है, लेकिन यह एक तकनीकीता है।)

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

मुझे पसंद की कुछ विशेषताएं हैं:

  • प्रथम श्रेणी के नागरिकों के रूप में कार्य करना
  • किसी भी वस्तु पर किसी भी वस्तु को फ़ंक्शंस जोड़ने और निकालने में सक्षम होना (उपयोगी नहीं है लेकिन दिमाग उड़ने पर)
  • यह एक गतिशील भाषा है।

इससे निपटना मजेदार है और यह स्थापित है। इसका आनंद लें, जबकि यह चारों ओर है क्योंकि यह क्लाइंट स्क्रिप्टिंग के लिए "सर्वश्रेष्ठ" नहीं हो सकता है, यह निश्चित रूप से सुखद है।

मैं सहमत हूं कि ब्राउज़र असंगतताओं के कारण गतिशील पृष्ठों को बनाते समय निराशा होती है, लेकिन इसे यूआई पुस्तकालयों द्वारा कम किया जा सकता है। जावा के खिलाफ स्विंग होने के मुकाबले जावास्क्रिप्ट के खिलाफ यह नहीं होना चाहिए।


आपके तर्क में कुछ त्रुटियां हैं।

  1. मानक ब्राउज़र में मानक वर्चुअल मशीन कभी मानक नहीं होगी। हमारे पास 4 ब्राउज़र हैं, और आईई के पास 'मानक' के संबंध में विवादित हित हैं। तीन अन्य तेजी से विकसित हो रहे हैं लेकिन नई प्रौद्योगिकियों की गोद लेने की दर धीमी है। फोन, छोटे उपकरणों, पर ब्राउज़रों के बारे में क्या ...

  2. विभिन्न ब्राउज़रों और उसके पिछले इतिहास में जेएस का एकीकरण आपको जेएस की शक्ति का अनुमान लगाता है। आप एक मानक प्रतिज्ञा करते हैं, लेकिन जेएस को अस्वीकार करते हैं क्योंकि शुरुआती सालों में मानक काम नहीं करता था।

  3. जैसा कि दूसरों ने बताया है, जेएस एआईआर / .NET / ... और जैसा नहीं है। जेएस अपने वर्तमान अवतार में पूरी तरह से अपने लक्ष्यों को फिट करता है।

लंबी अवधि में, पर्ल और रूबी जावास्क्रिप्ट को अच्छी तरह से बदल सकते हैं। फिर भी उन भाषाओं को अपनाना धीमा है और यह ज्ञात है कि वे कभी भी जेएस को नहीं ले पाएंगे।


इसे देखें http://www.visitmix.com/Labs/Gestalt/ - आपको अजगर या रूबी का उपयोग करने देता है, जब तक कि उपयोगकर्ता के पास चांदी की रोशनी स्थापित हो।


क्योंकि उनके पास पहले से ही बाइटकोड दुभाषियों के साथ वीएम हैं, और बाइटकोड भी अलग है। {चक्र (आईई), फ़ायरफ़ॉक्स (स्पाइडरमोन्की), सफारी (गिलहरीफिश), ओपेरा (कारकन)।

क्षमा करें, मुझे लगता है कि क्रोम (वी 8) आईए 32 मशीन कोड पर संकलित है।


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


जावास्क्रिप्ट आपका एकमात्र मूल, मानक विकल्प उपलब्ध है। यदि आप बहुत सारी शक्ति चाहते हैं, तो jQuery को पकड़ें, लेकिन यदि आपको अधिक गुच्छा करने की आवश्यकता है, तो फ़ायरफ़ॉक्स के लिए एक एडन लिखने पर विचार करें? या आईई आदि के लिए समान है।


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

इस तरह की निराशा कुछ समय से चल रही है। मेरा सुझाव है कि आप इसे विशिष्ट मुद्दों के साथ शामिल करने, या दोबारा पोस्ट करने के लिए संपादित करें। आपको मिलने वाली कुछ राहत से आप सुखद आश्चर्यचकित हो सकते हैं।

एक पुरानी साइट, लेकिन अभी भी शुरू करने के लिए एक महान जगह है: डगलस क्रॉकफोर्ड की साइट


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

किसी भी तरह, आपको क्लाइंट पर काम करने के लिए "गंदे" होने की आवश्यकता नहीं है। उदाहरण के लिए, जीडब्ल्यूटी का प्रयास करें।


मुझे लगता है कि जावास्क्रिप्ट एक अच्छी भाषा है, लेकिन क्लाइंट-साइड वेब अनुप्रयोगों को विकसित करते समय मुझे पसंद करना अच्छा लगेगा। विरासत के कारणों से हम जावास्क्रिप्ट के साथ फंस गए हैं, लेकिन ऐसी परिदृश्य बदलने के लिए परियोजनाएं और विचार हैं:

  1. Google मूल क्लाइंट : ब्राउज़र में देशी कोड चलाने के लिए तकनीक।
  2. Emscripten : जावास्क्रिप्ट के लिए Emscripten बाइटकोड संकलक। ब्राउज़र में एलएलवीएम भाषाओं को चलाने की अनुमति देता है।
  3. आइडिया: ब्राउज़र में .NET CLI, मोनो के निर्माता द्वारा: http://tirania.org/blog/archive/2010/May-03.html

मुझे लगता है कि हमारे पास लंबे समय तक जावास्क्रिप्ट होगा, लेकिन यह जल्द या बाद में बदल जाएगा। ब्राउज़र में अन्य भाषाओं का उपयोग करने के इच्छुक कई डेवलपर्स हैं।


मुझे लगता है कि यह इतना आसान मुद्दा नहीं है। हम कह सकते हैं कि हम जेएस के साथ फंस गए हैं, लेकिन क्या यह वास्तव में jQuery, प्रोटोटाइप, स्क्रिप्टैकियस, म्यूटूल और सभी शानदार पुस्तकालयों के साथ इतना बुरा है?

याद रखें, जेएस हल्का वजन है , और भी अधिक V8, TraceMonkey, SquirrelFish - आधुनिक ब्राउज़र में उपयोग किए जाने वाले नए जावास्क्रिप्ट इंजन।

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

मुझे लगता है कि जावास्क्रिप्ट को समय के साथ संशोधित और सुधारने जा रहा है, जैसे एचटीएमएल और सीएसएस है। प्रक्रिया लंबी हो सकती है, लेकिन इस दुनिया में सबकुछ संभव नहीं है।


मैं निश्चित रूप से ब्राउज़र में एक मानक भाषा स्वतंत्र वीएम का स्वागत करता हूं (मैं एक स्थिर रूप से टाइप की गई भाषा में कोड करना पसंद करूंगा)।

(तकनीकी रूप से) यह धीरे-धीरे काफी व्यावहारिक है: पहला एक बड़ा ब्राउज़र इसका समर्थन करता है और सर्वर को या तो बाइटकोड भेजने की संभावना है यदि वर्तमान अनुरोध संगत ब्राउज़र से है या कोड को जावास्क्रिप्ट में अनुवादित करें और सादा-पाठ जावास्क्रिप्ट भेजें।

जावास्क्रिप्ट को संकलित करने वाली कुछ प्रयोगात्मक भाषाएं पहले से मौजूद हैं, लेकिन परिभाषित वीएम होने से (बेहतर) बेहतर प्रदर्शन की अनुमति होगी।

मैं मानता हूं कि "मानक" हिस्सा काफी मुश्किल होगा, हालांकि। लाइब्रेरी से संबंधित भाषा सुविधाओं (जैसे स्थिर स्थिर बनाम गतिशील टाइपिंग) के बीच भी संघर्ष होंगे (माना जाता है कि नई चीज एक ही लाइब्रेरी का उपयोग करेगी)। इसलिए मुझे नहीं लगता कि यह होने वाला है (जल्द ही)।


यह एक अच्छा विचार है। इसे एक कदम आगे क्यों नहीं लेते?

  • एक ही वीएम भाषा में एचटीएमएल पार्सर और लेआउट इंजन (ब्राउज़र में सभी जटिल बिट्स) वास्तव में लिखें
  • इंजन को वेब पर प्रकाशित करें
  • पृष्ठ का उपयोग किस लेआउट इंजन का उपयोग करने के लिए और उसके यूआरएल की घोषणा के साथ करें

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


यह सवाल नियमित रूप से पुनरुत्थान करता है। इस पर मेरा रुख है:

ए) नहीं होगा और बी) पहले से ही यहाँ है।

माफ़ करना, क्या? मुझे समझाने दो:

विज्ञापन ए

एक वीएम सिर्फ कुछ प्रकार की सार्वभौमिक जादुई डिवाइस नहीं है। अधिकांश वीएम को एक निश्चित भाषा और कुछ भाषा विशेषताओं के लिए अनुकूलित किया जाता है। जेआरई / जावा (या एलएलवीएम) लें: स्थैतिक टाइपिंग के लिए अनुकूलित, और गतिशील टाइपिंग या अन्य चीजों को लागू करते समय निश्चित रूप से समस्याएं और डाउनसाइड्स हैं, जहां जावा पहले स्थान पर समर्थन नहीं करता था।

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

विज्ञापन बी

पहले से ही यहां: बाइटकोड कंपाइलर / वीएम नहीं हो सकता है, लेकिन आपको वास्तव में एक की आवश्यकता नहीं है। afaik जावास्क्रिप्ट पूर्ण ट्यूरिंग है, तो यह भी संभव होना चाहिए:

  1. भाषा एक्स से जावास्क्रिप्ट (उदाहरण के लिए कॉफ़ीस्क्रिप्ट) से अनुवादक बनाएं
  2. जावास्क्रिप्ट में एक दुभाषिया बनाएं जो भाषा एक्स (जैसे brainfuck ) का brainfuck । हाँ, प्रदर्शन अबाध होगा, लेकिन हे, सब कुछ नहीं हो सकता है।

विज्ञापन सी

क्या? पहली जगह में एक बिंदु सी नहीं था !? क्योंकि अभी तक नहीं है ... अभी तक। गूगल एनएसीएल। अगर कोई ऐसा कर सकता है, तो यह Google है। जैसे ही Google इसे काम कर लेता है, आपकी समस्याएं हल हो जाती हैं। केवल, ओह, यह कभी काम नहीं कर सकता, मुझे नहीं पता। आखिरी बार जब मैंने इसके बारे में पढ़ा तो वास्तव में मुश्किल तरह की कुछ अनसुलझा सुरक्षा समस्याएं थीं।

इसके अलावा:

  • जावास्क्रिप्ट ~ 1995 = 15 साल के बाद से रहा है। फिर भी, ब्राउज़र कार्यान्वयन आज भिन्न है (हालांकि कम से कम यह अब और अधिक अपरिवर्तनीय नहीं है)। इसलिए, यदि आप अभी तक कुछ नया शुरू करते हैं, तो आपके पास 2035 के आसपास एक वर्क वर्क क्रॉस ब्राउज़र हो सकता है। कम से कम एक वर्किंग सबसेट। जो केवल संक्षेप में अलग है। और संगतता libs और परतों की जरूरत है। यद्यपि चीजों को बेहतर बनाने की कोशिश नहीं करने में कोई बात नहीं है।

  • भी, पठनीय स्रोत कोड के बारे में क्या? मुझे पता है कि बहुत सी कंपनियां अपने कोड को "तरह के" ओपन सोर्स के रूप में नहीं देना पसंद करेंगे। व्यक्तिगत रूप से, मैं बहुत खुश हूं अगर मैं कुछ ख़राब महसूस करता हूं या उससे सीखना चाहता हूं तो मैं स्रोत को पढ़ने में सक्षम हूं। स्रोत कोड के लिए हुरेय!


वास्तव में, जावास्क्रिप्ट एकमात्र ऐसी भाषा है जो किसी भी ब्राउज़र लंबे समय तक उपयोग करेगी, इसलिए अन्य भाषाओं का उपयोग करना बहुत अच्छा होगा, लेकिन मैं इसे नहीं देख सकता।

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

आपको इस वीएम में प्रत्येक प्रोग्रामिंग भाषा को सैंडबॉक्स करना होगा और प्रत्येक भाषा को सिस्टम में पहुंच की मात्रा को कम करना होगा, भाषाओं में बहुत सारे बदलाव और कई सुविधाओं को हटाने या पुन: कार्यान्वयन की आवश्यकता होगी। जबकि जावास्क्रिप्ट में पहले से ही यह दिमाग में है, और एक लंबे समय से किया है।


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

पायथन Win32 एक्सटेंशन ने आईई को आसानी से इस तरह पाइथन जोड़ने की इजाजत दी, लेकिन यह वास्तव में एक अच्छा विचार नहीं था क्योंकि पाइथन सैंडबॉक्स के लिए काफी कठिन है: कई भाषा विशेषताएं पर्याप्त कार्यान्वयन हुक का पर्दाफाश करती हैं ताकि माना जाता है कि एक प्रतिबंधित प्रतिबंधित एप्लिकेशन को तोड़ने की अनुमति मिलती है ।

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

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


शायद आप Google के मूल ग्राहक की तलाश में हैं।


सही है। निश्चित रूप से अगर हमारे पास टाइम मशीन थी, तो वापस जाकर और जावास्क्रिप्ट सुविधाओं को सुनिश्चित करने के लिए अलग-अलग डिजाइन किए गए थे, यह एक प्रमुख शगल होगा (और, आईई के सीएसएस इंजन को डिजाइन करने वाले लोगों को आईटी में कभी नहीं मिला)। लेकिन ऐसा होने वाला नहीं है, और हम अब इसके साथ अटक गए हैं।

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

मुझे नहीं लगता कि, इनमें से कोई भी "बेहतर डिज़ाइन की गई भाषा" जावा, पायथन या रूबी होगी। जावास्क्रिप्ट, कहीं और इस्तेमाल करने की क्षमता के बावजूद, एक वेब अनुप्रयोग स्क्रिप्टिंग भाषा है। यह देखते हुए कि मामले का उपयोग, हम उन भाषाओं में से किसी भी से बेहतर कर सकते हैं।


सवाल का जवाब - नहीं, यह समझ में नहीं आता है।

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

आइए इस विचार की जांच करें कि आप एक नया, बहुभाषी वीएम लिख सकते हैं जो मौजूदा समाधान से बेहतर होगा।

  • आप स्थिरता पर पीछे हैं।
  • आप जटिलता पर पीछे हैं (रास्ता, रास्ता, पीछे क्योंकि आप कई भाषाओं में सामान्यीकृत करने की कोशिश कर रहे हैं)
  • आप गोद लेने के पीछे हैं

तो, नहीं, यह समझ में नहीं आता है।

याद रखें, इन भाषाओं का समर्थन करने के लिए आपको अपने एपीआई को कुछ भयंकर तरीके से अलग करना होगा, किसी भी ऐसे हिस्सों को तोड़ना होगा जो ब्राउज़र स्क्रिप्ट के संदर्भ में समझ में नहीं आता है। यहां डिजाइन किए जाने वाले डिजाइन निर्णयों की एक बड़ी संख्या है, और त्रुटि के लिए एक बड़ा अवसर है।

कार्यक्षमता के मामले में, हम शायद वास्तव में केवल डीओएम के साथ काम कर रहे हैं, इसलिए यह वास्तव में वाक्यविन्यास और भाषा की मूर्ति का मुद्दा है, जिस बिंदु पर यह पूछने के लिए समझ में आता है, "क्या यह वास्तव में इसके लायक है?"

ध्यान में रखते हुए, एकमात्र चीज जिसके बारे में हम बात कर रहे हैं वह क्लाइंट साइड स्क्रिप्टिंग है, क्योंकि सर्वर साइड स्क्रिप्टिंग आपकी पसंद की किसी भी भाषा में पहले से ही उपलब्ध है। यह अपेक्षाकृत छोटा प्रोग्रामिंग क्षेत्र है और इसलिए कई भाषाओं को लाने का लाभ संदिग्ध है।

लाने के लिए कौन सी भाषाएं समझदारी होगी? (चेतावनी, व्यक्तिपरक सामग्री निम्नानुसार है)

सी जैसी भाषा में लाने से यह समझ में नहीं आता है क्योंकि यह धातु के साथ काम करने के लिए बनाया गया है, और ब्राउज़र में वास्तव में बहुत अधिक धातु उपलब्ध नहीं है।

जावा जैसी भाषा में लाने से यह समझ में नहीं आता है क्योंकि इसके बारे में सबसे अच्छी बात एपीआई है।

रुबी या लिस्प जैसी भाषा में लाने से यह समझ में नहीं आता है क्योंकि जावास्क्रिप्ट एक शक्तिशाली गतिशील भाषा है जो योजना के बहुत करीब है।

अंत में, कौन सा ब्राउज़र निर्माता वास्तव में कई भाषाओं के लिए डीओएम एकीकरण का समर्थन करना चाहता है? प्रत्येक कार्यान्वयन में अपनी विशिष्ट बग होगी। हम एमएस जावास्क्रिप्ट और मोज़िला जावास्क्रिप्ट के बीच मतभेदों से निपटने से पहले ही आग से गुजर चुके हैं और अब हम उस दर्द को पांच या छह गुना गुणा करना चाहते हैं?

यह समझ में नहीं आता है।






javascript