एक मानक ब्राउज़र वर्चुअल मशीन के बजाय जावास्क्रिप्ट क्यों?


167

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

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

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


17
मुझे नहीं पता कि यह मतदान क्यों हो रहा है। मुझे लगा कि यह एक अच्छा सवाल था!

11
क्योंकि यह एक प्रश्न से अधिक शिकायत है।
डस्टमैन

6
यह इस विचार के कारण है कि जावास्क्रिप्ट एक वास्तविक भाषा नहीं है, या अन्य भाषाओं की तरह अच्छी नहीं है। शुरुआती दिनों से इनमें से कोई भी सच नहीं है, फिर भी वर्तमान में 'गंदी' धारणा बनी हुई है।
एडम डेविस

43
वाह, मैंने एसओ समुदाय को कभी भी पूरी तरह से विफल होते नहीं देखा। एकमात्र उत्तर जो यहां तक ​​कि प्रस्तावित विचार को संबोधित करते हैं, नीचे की ओर सभी तरह से हैं, नीचे की ओर बढ़ रहे हैं, जबकि उत्तर "अनावश्यक रूप से जेएस का बचाव" सभी प्यार प्राप्त कर रहे हैं। यह सवाल जेएस पर हमला नहीं करता है, यह केवल वकालत पसंद है। यह बस कह रहा है: "जो भी आप जेएस के बारे में सोच सकते हैं, क्या यह अच्छा नहीं होगा कि आप कुछ अन्य भाषाओं का उपयोग करने में सक्षम हों और यदि आप उन्हें पसंद करते हैं?" तुम्हारी क्या दिक्कत है?
जॉर्डन

4
यह StackOverflow के साथ एक बड़ी समस्या है जो कई उत्तर प्रदान किए जाने के बाद भविष्य में संपादन के लिए अनुमति देता है। पूछे गए मूल प्रश्न शीर्ष उत्तरों के लिए अधिक प्रासंगिक हैं, जबकि बाकी संपादन के बाद प्रश्न की "नई भावना" को संबोधित करते हैं।

जवाबों:


28

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

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

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


54
आईई सीएसएस टीम टिप्पणी के लिए -1। IE6 खराब नहीं था जब इसे जारी किया गया था, तो यह मुख्य प्रतियोगी बकवास सॉफ़्टवेयर का बगगीस्ट टुकड़ा था जिसे कभी भी लिखा गया है। व्यक्ति के हमले, हालांकि कुछ मज़ेदार, दुनिया को एक बेहतर स्थान नहीं बनाते हैं।
इरिक्कलेन

5
जावास्क्रिप्ट के आपके आकलन से असहमत नहीं हो सका "... एक वेब अनुप्रयोग स्क्रिप्टिंग भाषा ..." कम। यह एक महान, लचीली भाषा है जिसकी तुलना में बहुत अधिक प्रयोज्यता है।
टीजे क्राउडर

2
@ टीजे क्राउडर: ITYM "[...] और अधिक असहमत नहीं हो सकता है?"
क्रिस्टोफ़र हैमरस्ट्रॉम

2
@ ज्रासॉल्ज़ स्ज़िल्वेस्की बेशर्म जेएस ज़ीलोटिज्म? क्या आपने इस पर गलत टिप्पणी की, यह एक और पोस्ट है? इसके अलावा, @erikkallen के लिए, IE CSS टीम की टिप्पणी को आमतौर पर "एक मजाक" के रूप में जाना जाता था।
एडम राइट

2
इस जवाब में कुछ "क्लैरवॉयन्स": अब हमारे पास कॉफीस्क्रिप्ट हैं।
andref

19

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

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

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


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

18

सवाल का जवाब दे रहे हैं - नहीं, इसका कोई मतलब नहीं होगा।

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

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

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

तो, नहीं, इसका कोई मतलब नहीं है।

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

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

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

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

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

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

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

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

इसका कोई मतलब नहीं है।


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

2
मुझे नहीं लगता कि ब्राउज़र में VM को भारी होना आवश्यक है। बेशक यह सिल्वरलाइट और ऐप्पल के रूप में पहले से मौजूद है। उत्तरार्द्ध लोकप्रियता हासिल करने में विफल रहा, मुझे लगता है कि ज्यादातर समय खराब होने और तकनीकी मूर्खता के कारण होता है जो ज्यादातर हल होते हैं। स्क्रिप्ट टैग (प्रतिबंधों के बीच) के बीच किसी भी भाषा की अनुमति देना बहुत अच्छा होगा, और निश्चित रूप से असंभव नहीं और न ही अव्यावहारिक।
गेरब्रांड

2
भारीपन (एमबी)? शायद ठीक है। भारीपन (जटिलता)? रास्ता बहुत भारी। आपके पास कोई भी बहु-भाषा VM, आपके पास शीर्ष पर बैठे भाषा कार्यान्वयन होंगे (जैसे। JRuby / IronRuby, Clojure, Jython / IronPython), आदि या तो JVM जटिलता को खाते हैं या भाषा कार्यान्वयनकर्ता करते हैं।
सुखी मोरन

कई ब्रांड के नए प्लेटफॉर्म (IE / Firefox / Safari ...) के लिए कई भाषाओं को फिर से लागू करने के लिए यह एक बड़ा काम होगा। और भाषाएं भी बदल जाती हैं। "यह पृष्ठ केवल रूबी 1.9 ब्राउज़र में दिखाई दे रहा है"? कृपया नहीं।
खुश मूर्ख

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

14

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

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

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

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


12

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

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

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

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


10

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

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


13
आप कैसे कह सकते हैं, कि जावास्क्रिप्ट पूर्ण विकसित वस्तु उन्मुख नहीं है? यह निश्चित रूप से सबसे अधिक वस्तु-उन्मुख भाषाओं में से एक है जिसे मैं जानता हूं। जावास्क्रिप्ट में सब कुछ एक वस्तु है - यहां तक ​​कि कार्य भी। यह सिर्फ इतना है कि जावास्क्रिप्ट में OOP कई अन्य भाषाओं में OOP की तरह नहीं दिखता है।
रेने सारसो

2
OOP जावास्क्रिप्ट के लिए अंतर्निहित नहीं है। आपके पास संकुल, इंटरफेस, अमूर्त कक्षाएं या कोर में निर्मित ओवरलोडिंग का तरीका नहीं है, और आप एक वस्तु का विस्तार नहीं कर सकते हैं - केवल एक वस्तु का प्रोटोटाइप, जो इसे तकनीकी रूप से प्रोटोटाइप-आधारित बनाता है, न कि OOP आधारित।

3
उस एक पर गलत मर गया। "प्रोटाइप" एक डिज़ाइन पैटर्न (गामा एट अल।, पीपी 117 - 126) है। जैसा कि आपको याद होगा कि डिज़ाइन पैटर्न ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में आम डिज़ाइनों के चारों ओर घूमते हैं। और सिर्फ इसलिए कि भाषा में अन्य ओओपी भाषाओं के समान विशेषताएं नहीं हैं इसका मतलब यह नहीं है कि यह ओओपी नहीं है।
डस्टमैन

13
आप गलत नहीं हैं, मुझे लगता है कि इसे लगाने का सबसे अच्छा तरीका यह है कि JS क्लास आधारित OO नहीं है, यह प्रोटोटाइप OO है।
जुआन मेंडेस

14
1. जावास्क्रिप्ट पूरी तरह से OOP है। OOP वस्तुओं के बारे में है, कक्षाओं के बारे में नहीं। 2. आप जावास्क्रिप्ट में एक ऑब्जेक्ट का विस्तार कर सकते हैं, वह है प्रोटोटेम्पल ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का पूरा बिंदु। 3. आप सवाल का जवाब नहीं दे रहे हैं, सवाल जेएस पर हमला नहीं कर रहा है, बस पसंद पूछ रहा है। मुझे लगता है कि जेएस एक महान भाषा है, लेकिन मुझे ब्राउज़र में प्रोग्रामिंग करते समय अन्य विकल्प पसंद होंगे।
मैनुअल सेरोन

7

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

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

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


6

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


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

6

इस पुराने प्रश्न पर त्वरित अपडेट।

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

जून 2015 W3C ने WebAssembly की घोषणा की जो है

वेब पर संकलन के लिए उपयुक्त एक नया पोर्टेबल, आकार- और लोड-टाइम-कुशल प्रारूप।

यह अभी भी प्रायोगिक है, लेकिन फ़ायरफ़ॉक्स रात और क्रोम कैनरी में पहले से ही कुछ प्रोटोटाइप कार्यान्वयन है और पहले से ही कुछ प्रदर्शन कार्य कर रहे हैं

वर्तमान में, WebAssembly ज्यादातर C / C ++ से निर्मित होने के लिए डिज़ाइन किया गया है, हालांकि

जैसा कि WebAssembly विकसित करता है, यह C / C ++ की तुलना में अधिक भाषाओं का समर्थन करेगा, और हमें उम्मीद है कि अन्य कंपाइलर भी इसका समर्थन करेंगे

मैं आपको परियोजना के आधिकारिक पृष्ठ पर एक करीब से देखने देता हूं , यह वास्तव में रोमांचक है!


5

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

ए) अभ्यस्त होने और बी) पहले से ही यहाँ है।

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

विज्ञापन ए

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

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

विज्ञापन बी

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

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

विज्ञापन सी

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


इसके अलावा:

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

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


4

वास्तव में। सिल्वरलाइट प्रभावी रूप से बस इतना ही है - एक ग्राहक पक्ष। नेट आधारित वीएम।


4

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

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

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

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

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


3

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

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

मुझे इसमें से कुछ सुविधाएँ पसंद हैं:

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

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

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


+1 - कोड की ब्राउज़र व्याख्या के साथ भाषा के मुद्दों को भ्रमित नहीं करता है।
जेएल

आपको जेएस का बचाव क्यों करना चाहिए, जब उसने बस एक बाईटेकोड पसंद के लिए कहा था?
मिलिंद आर

3

जावास्क्रिप्ट ब्राउज़र की मानक आभासी मशीन है। उदाहरण के लिए, OCaml और Haskell में अब दोनों कंपाइलर हैं जो जावास्क्रिप्ट को आउटपुट कर सकते हैं। सीमा जावास्क्रिप्ट भाषा नहीं है, सीमा जावास्क्रिप्ट के माध्यम से पहुंच योग्य ब्राउज़र ऑब्जेक्ट्स है, और एक्सेस कंट्रोल मॉडल का उपयोग यह सुनिश्चित करने के लिए किया जाता है कि आप अपनी मशीन से समझौता किए बिना सुरक्षित रूप से जावास्क्रिप्ट चला सकें। वर्तमान अभिगम नियंत्रण इतने खराब हैं, कि सुरक्षा कारणों से जावास्क्रिप्ट को केवल ब्राउज़र ऑब्जेक्ट्स तक बहुत सीमित पहुंच की अनुमति है। सद्भाव परियोजना इसे ठीक करना चाह रही है।


3

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

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

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


अगर आप मजाक कर रहे हैं तो मैं नहीं बता सकता, लेकिन आपका विचार वास्तव में अच्छा है।
मिलिंद आर

3

मैं जावास्क्रिप्ट के अलावा किसी भी भाषा का स्वागत करना संभव स्क्रिप्टिंग भाषा के रूप में होगा।

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

मैं कुछ समय पहले एक क्रॉस रूबस्क्रिप्ट लेकर आया था ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby और http://code.google.com/p/ruby इन-ब्राउज़र /
फिर भी प्रयोगात्मक और प्रगति में है, लेकिन आशाजनक लगता है।
.Net के लिए मैंने अभी पाया: http://www.silverlight.net/learn/dynamic-languages/ बस साइट को ढूंढ निकाला, लेकिन दिलचस्प भी लग रहा है। मेरे Apple Mac से भी काम करता है

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

सुरक्षा के लिए, यदि भाषा JVM (या उस विषय के लिए .Net इंजन) के अंदर चलती है, तो वीएम सुरक्षा का ध्यान रखेगा, इसलिए हमें इस बारे में चिंता करने की ज़रूरत नहीं है - कम से कम अधिक नहीं तो हमें कुछ भी चलाने के लिए चाहिए ब्राउज़र के अंदर।


2

शायद, लेकिन ऐसा करने के लिए हमें उनके समर्थन के लिए प्रमुख ब्राउज़र प्राप्त करने की आवश्यकता होगी। IE समर्थन पाने के लिए सबसे कठिन होगा। जावास्क्रिप्ट का उपयोग किया जाता है क्योंकि यह एकमात्र चीज है जिसे आप उपलब्ध होने पर भरोसा कर सकते हैं।


2

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

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

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


मुझे यह जानने के लिए उत्सुक होना चाहिए कि "HTML DOM" दर्द बिंदु क्यों है
एलेक्स मूर-नीमी

2

ठीक है, हमारे पास पहले से ही VBScript है, क्या हम नहीं? रुको, केवल IE इसे समर्थन करता है!
VM के अपने अच्छे विचार के लिए भी। क्या होगा यदि मैं लूआ का उपयोग करके अपने पेज को स्क्रिप्ट करता हूं, और आपके ब्राउज़र के पास इसे बाइटकोड में बदलने के लिए पार्सर नहीं है? बेशक, हम एक स्क्रिप्ट टैग की कल्पना कर सकते हैं जो कि बायटेकोड की एक फ़ाइल को स्वीकार करता है, यहां तक ​​कि काफी कुशल भी होगा।
लेकिन अनुभव से पता चलता है कि वेब पर कुछ नया लाना मुश्किल है: इस तरह एक क्रांतिकारी नए बदलाव को अपनाने में कई साल लगेंगे। कितने ब्राउज़र SVG या CSS3 का समर्थन करते हैं?

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


2

इसे देखें http://www.visitmix.com/Labs/Gestalt/ - जब तक उपयोगकर्ता के पास सिल्वरलाइट स्थापित है, तब तक आप अजगर या माणिक का उपयोग कर सकते हैं।


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

सच कहूं, तो शायद ऐसा करना आसान है कि रूबी को यानी 6/7/8/9 / ff / क्रोम / सफारी में एम्बेड किया जाए। हेक क्रोम में पहले से ही फ्लैश शामिल है, एसएल क्यों नहीं!
mcintyre321 12

2

यह एक बहुत अच्छा सवाल है।

यह केवल जेएस में समस्या नहीं है, क्योंकि यह जेएस में बड़े कार्यक्रमों को विकसित करने के लिए अच्छे मुफ्त आईडीई की कमी है। मैं केवल एक ही जानता हूं जो मुक्त है: ग्रहण। दूसरा अच्छा माइक्रोसॉफ्ट का विजुअल स्टूडियो है, लेकिन मुफ्त नहीं।

यह क्यों मुफ्त होगा? यदि वेब ब्राउज़र विक्रेता ऑनलाइन ऐप्स के साथ डेस्कटॉप ऐप्स को बदलना चाहते हैं (और वे चाहते हैं) तो उन्हें हमें, प्रोग्रामर, अच्छे देव टूल्स को देना होगा। आप एक साधारण टेक्स्ट एडिटर, JSLint और अंतर्निहित Google Chrome डीबगर का उपयोग करके जावास्क्रिप्ट की 50,000 लाइनें नहीं बना सकते। जब तक आप एक macohist नहीं हैं।

जब बोरलैंड ने 1987 में टर्बो पास्कल 4.0 के लिए एक आईडीई बनाई, तो यह प्रोग्रामिंग में एक क्रांति थी। 24 साल हो गए। शर्म की बात है, वर्ष 2011 में कई प्रोग्रामर अभी भी कोड पूरा करने, वाक्यविन्यास जाँच और उचित डिबगर्स का उपयोग नहीं करते हैं। शायद इसलिए कि कुछ अच्छे आईडीई हैं।

यह प्रोग्रामर के लिए उचित (मुफ़्त) उपकरण बनाने के लिए वेब ब्राउज़र विक्रेताओं के हित में है यदि वे चाहते हैं कि हम उन अनुप्रयोगों का निर्माण करें जिनके साथ वे विंडोज, लिनक्स, मैकओएस, आईओएस, सिम्बियन, आदि लड़ सकते हैं।


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

1

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

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

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



1

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


0

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

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

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

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


मेरी जानकारी के अनुसार, जेएस सैंडबॉक्स (और आमतौर पर) के लिए किया गया हर सुरक्षा चेक बाइट कोड पर अनुमतियों की जाँच के रूप में किया जाता है और टेक्स्ट का एक गुच्छा देखकर ऐसी चीजें करना कंप्यूटर के लिए कठिन होता है। मानक जेएस के बजाय क्लाइंट को बाइट कोड भेजना नहीं बदलना चाहिए
गिदोनमैक्स

0

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

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


0

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

जावा और जावा एप्लेट फ्लैश और एडोब आकाशवाणी आदि।

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

वेब को किसी भी गैर-वेब वेबसाईट के साथ विकसित करने के लिए, आपने GWT: जावा विकसित करें, जावास्क्रिप्ट को संकलित करें


1
इसलिए एक वीएम को मानकीकृत करने का सुझाव इसलिए यह सर्वव्यापी होगा। जावास्क्रिप्ट का उपयोग "वेब के लिए मशीन भाषा" के रूप में अविश्वसनीय रूप से क्लंकी और अक्षम लगता है।
16

मुझे लगता है कि आप गलत समझ रहे हैं, मूल पोस्टर यह सुझाव नहीं दे रहा है कि ब्राउज़र को अन्य भाषाओं का समर्थन करना चाहिए, वह सुझाव दे रहा है कि java to js को संकलित करने के बजाय, आप java को VM में संकलित करेंगे।
गिदोनमेक्स

0

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

क्षमा करें, मुझे लगता है कि Chrome (V8) IA32 मशीन कोड के लिए संकलित है।


0

खैर, सभी ब्राउज़रों पर पहले से ही VM का उपयोग करने के बारे में, मुझे नहीं लगता कि वेब के लिए VM भाषा बनाना इतना कठिन होगा।
मुझे लगता है कि यह कुछ कारणों से बहुत मदद करेगा:
1. चूंकि सर्वर कोड को संकलित करता है, इसलिए भेजे गए डेटा की मात्रा छोटी होती है और ग्राहक कोड को संकलित करने में कमर का समय नहीं लेता है।
2. चूंकि सर्वर तैयारी में कोड को संकलित कर सकता है और इसे स्टोर कर सकता है, क्लाइंट के विपरीत जो जेएस को कम समय में जल्दी से कम करने की कोशिश करता है, यह बेहतर कोड अनुकूलन कर सकता है।
3. एक भाषा को बाइट कोड के लिए संकलित करना आसान है और फिर जेएस को ट्रांसप्लांट करना।

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


-1

IMO, जावास्क्रिप्ट, भाषा, समस्या नहीं है। जावास्क्रिप्ट वास्तव में काफी अभिव्यंजक और शक्तिशाली भाषा है। मुझे लगता है कि यह एक बुरा प्रतिनिधि है क्योंकि इसे शास्त्रीय OO सुविधाएँ नहीं मिली हैं, लेकिन मेरे लिए जितना अधिक मैं प्रोटोटाइप नाली के साथ जाता हूं, उतना ही मुझे यह पसंद है।

जैसा कि मैंने देखा कि यह समस्या वेब पर समर्थन करने के लिए मजबूर कई ब्राउज़रों में परतदार और असंगत कार्यान्वयन है। JQuery जैसी जावास्क्रिप्ट लाइब्रेरी उस गंदे एहसास को कम करने की दिशा में एक लंबा रास्ता तय करती है।

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