अपडेट: यह उत्तर काफी लोकप्रिय प्रतीत होता है इसलिए मैंने इसे थोड़ा सा साफ करने के लिए, कुछ नई जानकारी जोड़ने और कुछ चीजें स्पष्ट करने के लिए कुछ समय लिया जो मुझे लगा कि पर्याप्त रूप से स्पष्ट नहीं थे। कृपया टिप्पणी करें कि क्या आपको लगता है कि कुछ और स्पष्टीकरण या अपडेट की आवश्यकता है।
आपकी अधिकांश चिंताएँ वास्तव में राय और व्यक्तिगत पसंद की बात हैं, लेकिन मैं जितना हो सके उतने उत्तर देने की कोशिश करूँगा:
देशी बनाम संकलित
वेनिला जावास्क्रिप्ट में जावास्क्रिप्ट लिखें, सीएसएस में सीएसएस लिखें, एचटीएमएल में एचटीएमएल लिखें।
दिन में गर्म बहसें हुईं कि क्या किसी को हाथ से मूल विधानसभा लिखनी चाहिए या आपके लिए कंपाइलर जनरेट कोड बनाने के लिए C जैसी उच्च स्तरीय भाषा का उपयोग करना चाहिए । पहले भी कि लोगों पर विश्वास करने से इनकार कर अस्सेम्ब्लेर्स और लिखने के लिए प्राथमिकता दी देशी मशीन कोड अलग-अलग ( और मैं मजाक नहीं कर रहा हूँ )।
इस बीच, आज बहुत से लोग हैं जो HTML को Haml या Jade , CSS in Sass या Less और जावास्क्रिप्ट में CoffeeScript या TypeScript में लिखते हैं । यह वहाँ है। यह काम करता हैं। कुछ लोग इसे पसंद करते हैं, कुछ नहीं।
मुद्दा यह है कि वेनिला जावास्क्रिप्ट में सीएसएस, सीएसएस में सीएसएस और एचटीएमएल में HTML नहीं लिखने में मौलिक रूप से कुछ भी गलत नहीं है । यह वास्तव में वरीयता की बात है।
आंतरिक बनाम बाहरी डीएसएल
इसके बजाय शैडो डीओएम रिएक्ट का उपयोग करने वाले स्टाइल एनकैप्सुलेशन में यह है, जिसे जावास्क्रिप्ट में सीएसएस लिखने की आवश्यकता होती है। सुंदर नहीं।
सुंदर या नहीं, यह निश्चित रूप से अभिव्यंजक है। जावास्क्रिप्ट एक बहुत शक्तिशाली भाषा है, सीएसएस की तुलना में बहुत अधिक शक्तिशाली (यहां तक कि सीएसएस प्रीप्रोसेसर में से कोई भी)। यह इस बात पर निर्भर करता है कि आप उन चीजों के लिए आंतरिक या बाहरी DSLs पसंद करते हैं या नहीं। फिर से, वरीयता का मामला।
(नोट: मैं रिएक्ट में इनलाइन शैलियों के बारे में बात कर रहा था जिसे मूल प्रश्न में संदर्भित किया गया था।)
DSLs के प्रकार - स्पष्टीकरण
अद्यतन: मेरे उत्तर को पढ़ने के कुछ समय बाद इसे लिखने के बाद मुझे लगता है कि मुझे यह समझाने की आवश्यकता है कि मेरा यहाँ क्या मतलब है। डीएसएल एक डोमेन-विशिष्ट भाषा है और यह आंतरिक भी हो सकती है (जावास्क्रिप्ट जैसी होस्ट भाषा का सिंटैक्स का उपयोग करना - उदाहरण के लिए जेएसएक्स के बिना रिएक्ट, या ऊपर उल्लिखित रिएक्ट में इनलाइन शैलियों की तरह) या यह बाहरी हो सकता है (एक अलग सिंटैक्स का उपयोग करके) होस्ट भाषा की तुलना में - जैसे इस उदाहरण में जावास्क्रिप्ट (जावास्क्रिप्ट के अंदर एक बाहरी DSL) को इनलाइन किया जाएगा।
यह भ्रामक हो सकता है क्योंकि कुछ साहित्य उन प्रकार के डीएसएल का वर्णन करने के लिए "आंतरिक" और "बाहरी" की तुलना में अलग-अलग शब्दों का उपयोग करते हैं। कभी-कभी "आंतरिक" के बजाय "एम्बेडेड" का उपयोग किया जाता है, लेकिन "एम्बेडेड" शब्द का अर्थ अलग-अलग हो सकता है - उदाहरण के लिए लूआ को "लुआ: एक एक्सटेंसिबल एम्बेडेड भाषा" के रूप में वर्णित किया गया है, जहां एम्बेडेड का एम्बेडेड (आंतरिक) DSL के साथ कुछ भी नहीं है कौन सा अर्थ यह काफी विपरीत है - एक बाहरी डीएसएल) लेकिन इसका मतलब है कि यह उसी अर्थ में एम्बेडेड है जो कहते हैं, SQLite एक एम्बेडेड डेटाबेस है। यहाँ तक कि eLua भी है जहाँ "e" का अर्थ एक तीसरे अर्थ में "एम्बेडेड" है - जो कि एम्बेडेड सिस्टम के लिए है! इसलिए मुझे "एम्बेडेड डीएसएल" शब्द का उपयोग करना पसंद नहीं है क्योंकि एलुआ जैसी चीजें "डीएसएल" हो सकती हैं जो कि "एम्बेडेड डीएसएल" नहीं होने पर भी दो अलग-अलग इंद्रियों में "एम्बेडेड" होती हैं!
चीजों को बदतर बनाने के लिए कुछ परियोजनाएं मिश्रण के लिए और भी अधिक भ्रम का परिचय देती हैं। उदाहरण के लिए। फ्लैटिरॉन टेम्प्लेट को "डीएसएल-फ्री" के रूप में वर्णित किया गया है, जबकि वास्तव में यह सिंटैक्स जैसे आंतरिक डीएसएल का एक आदर्श उदाहरण है:map.where('href').is('/').insert('newurl');
यह कहा गया है, जब मैंने लिखा था "जावास्क्रिप्ट एक बहुत शक्तिशाली भाषा है, सीएसएस की तुलना में बहुत अधिक शक्तिशाली है (यहां तक कि सीएसएस के किसी भी पूर्ववर्ती सहित)। यह इस बात पर निर्भर करता है कि आप उन प्रकार की चीजों के लिए आंतरिक या बाहरी DSLs पसंद करते हैं। प्राथमिकता का विषय। " मैं उन दो परिदृश्यों के बारे में बात कर रहा था:
एक:
/** @jsx React.DOM */
var colored = {
color: myColor
};
React.renderComponent(<div style={colored}>Hello World!</div>, mountNode);
दो:
// SASS:
.colored {
color: $my-color;
}
// HTML:
<div class="colored">Hello World!</div>
पहले उदाहरण में उस प्रश्न का वर्णन किया गया है जो इस प्रकार है: "जावास्क्रिप्ट में सीएसएस लिखना। सुंदर नहीं।" दूसरा उदाहरण सैस का उपयोग करता है। जबकि मैं मानता हूं कि सीएसएस लिखने के लिए जावास्क्रिप्ट का उपयोग करना सुंदर नहीं हो सकता है ("सुंदर" की कुछ परिभाषाओं के लिए) लेकिन ऐसा करने का एक फायदा है।
मेरे पास सास में चर और कार्य हो सकते हैं लेकिन क्या वे शाब्दिक रूप से स्कोप या गतिशील रूप से स्कूप किए गए हैं? क्या वे सांख्यिकीय या गतिशील रूप से टाइप किए गए हैं? जोरदार या कमजोर रूप से? संख्यात्मक प्रकारों के बारे में क्या? प्रकार का फैलाव? कौन से मूल्य सत्य हैं और कौन से मिथ्या हैं? क्या मेरे पास उच्च-क्रम के कार्य हो सकते हैं? प्रत्यावर्तन? टेल कॉल? लेक्सिकल क्लोजर? क्या उनका मूल्यांकन सामान्य क्रम या आवेदक क्रम में किया जाता है? क्या आलसी या उत्सुक मूल्यांकन है? क्या मूल्य या संदर्भ द्वारा पारित कार्यों के तर्क हैं? क्या वे परस्पर हैं? अपरिवर्तनीय? लगातार? वस्तुओं के बारे में क्या? क्लासेस? प्रोटोटाइप? विरासत?
वे तुच्छ प्रश्न नहीं हैं और फिर भी मुझे उनके उत्तर जानने हैं, यदि मैं सैस या कम कोड को समझना चाहता हूं। मैं जावास्क्रिप्ट के लिए उन उत्तरों को पहले से ही जानता हूं, इसलिए इसका मतलब है कि मैं पहले से ही उन स्तरों पर हर आंतरिक डीएसएल (इनलाइन शैलियों की तरह) को समझता हूं, इसलिए यदि मैं रिएक्ट का उपयोग करता हूं तो मुझे उन लोगों के जवाबों का केवल एक सेट जानना होगा (और कई इसी तरह के) ) प्रश्न, जब मैं उदाहरण के लिए उपयोग करता हूं। सैस और हैंडलबार्स तो मुझे उन उत्तरों के तीन सेटों को जानना होगा और उनके निहितार्थ को समझना होगा।
यह कहना नहीं है कि एक तरीका या दूसरा हमेशा बेहतर होता है, लेकिन हर बार जब आप किसी अन्य भाषा को मिश्रण से परिचित कराते हैं तो आप कुछ ऐसी कीमत अदा करते हैं जो पहली नज़र में स्पष्ट नहीं हो सकती है, और यह कीमत जटिलता है।
मुझे आशा है कि मैंने स्पष्ट किया कि मैं मूल रूप से थोड़ा सा क्या था।
अनिवार्य तथ्य
दो तरफा बंधन
यह वास्तव में एक दिलचस्प विषय है और वास्तव में प्राथमिकता का विषय भी है। दो-तरफ़ा हमेशा एक-तरफ़ा से बेहतर नहीं होता है। यह एक सवाल है कि आप अपने आवेदन में परस्पर स्थिति को कैसे मॉडल करना चाहते हैं। मैं हमेशा दो तरफ़ा बाइंडिंग को एक विचार के रूप में देखता था जो कार्यात्मक प्रोग्रामिंग के सिद्धांतों के विपरीत है, लेकिन कार्यात्मक प्रोग्रामिंग केवल प्रतिमान नहीं है जो काम करता है, कुछ लोग इस तरह के व्यवहार को पसंद करते हैं और दोनों दृष्टिकोण व्यवहार में बहुत अच्छा काम करते हैं। यदि आप अभिक्रिया में राज्य के मॉडलिंग से संबंधित डिज़ाइन निर्णयों के विवरण में रुचि रखते हैं, तो पीट हंट (प्रश्न में जुड़ा हुआ) और टॉम ओशिनो और जॉर्डन वॉके द्वारा की गई बातचीत को देखें जो इसे बहुत अच्छी तरह से समझाते हैं। मेरी राय।
अपडेट: पीट हंट द्वारा एक और बात भी देखें: पूर्वानुमानित रहें, सही नहीं: कार्यात्मक डोम प्रोग्रामिंग ।
अद्यतन 2: यह ध्यान देने योग्य है कि कई डेवलपर्स द्विदिश डेटा प्रवाह, या दो-तरफ़ा बाइंडिंग के खिलाफ बहस कर रहे हैं , कुछ इसे एंटी-पैटर्न भी कहते हैं। उदाहरण के लिए फ्लक्स एप्लिकेशन आर्किटेक्चर को लें जो स्पष्ट रूप से अप्रत्यक्ष डेटा प्रवाह के पक्ष में एमवीसी मॉडल (जो बड़े फेसबुक और इंस्टाग्राम अनुप्रयोगों के लिए बड़े पैमाने पर साबित होता है) से बचा जाता है (देखें हैकर वे: फेसबुक पर पुनर्विचार वेब ऐप डेवलपमेंट टॉक द्वारा) टॉम ओशिनो, जिंग चेन और एक अच्छे परिचय के लिए पीट हंट)। साथ ही, AngularJS के खिलाफ काफी आलोचना की (सबसे लोकप्रिय वेब फ्रेमवर्क जो MVC मॉडल पर आधारित है, दो-तरफ़ा डेटा बाइंडिंग के लिए जाना जाता है) में उस द्विदिश डेटा प्रवाह के विरुद्ध तर्क शामिल हैं, देखें:
अद्यतन 3: एक और दिलचस्प लेख जो अच्छी तरह से समझाता है कि ऊपर उल्लिखित कुछ मुद्दों पर रिएक्टजेस की फ्लक्स में गिरावट आ रही है - रीफ्लक्सजेएस (फ्लक्स से प्रेरित यूनिडायरेक्शनल डेटा फ्लो एप्लीकेशन आर्किटेक्चर के लिए एक सरल पुस्तकालय) के लेखक, मिकेल ब्रैसमैन द्वारा रिएक्टजेएस के साथ एमवीसी का उपयोग नहीं करना ।
अद्यतन 4: Ember.js वर्तमान में दो-तरफ़ा डेटा बाइंडिंग से दूर जा रहा है और भविष्य के संस्करणों में यह डिफ़ॉल्ट रूप से वन-वे होगा। देखें: 15 नवंबर, 2014 को टोरंटो में एम्बरगार्टन संगोष्ठी से स्टीफन पेनर द्वारा एम्बर की भविष्य की बातचीत।
अद्यतन 5: यह भी देखें: एम्बर 2.0 आरएफसी की सड़क - टॉम डेल द्वारा पुल अनुरोध में दिलचस्प चर्चा :
"जब हमने मूल टेम्प्लेटिंग परत को डिज़ाइन किया, तो हमें लगा कि सभी डेटा बाइंडिंग को दो-तरफ़ा बनाना बहुत हानिकारक नहीं है: यदि आप दो-तरफ़ा बाइंडिंग सेट नहीं करते हैं, तो यह वास्तव में एक तरह से बाध्यकारी है!
हमने तब से महसूस किया है कि (रिएक्ट में हमारे दोस्तों से कुछ मदद के साथ), यह घटक अपने बच्चों को डेटा भेजने में सक्षम होना चाहते हैं, जो बिना किसी परिवर्तन के म्यूटेशन के गार्ड के रूप में हैं।
इसके अतिरिक्त, घटकों के बीच संचार अक्सर घटनाओं या कॉलबैक के रूप में सबसे स्वाभाविक रूप से व्यक्त किया जाता है । यह एम्बर में संभव है, लेकिन दो-तरफ़ा डेटा बाइंडिंग का प्रभुत्व अक्सर लोगों को एक संचार चैनल के रूप में दो-तरफ़ा बाइंडिंग का उपयोग करने का एक मार्ग नीचे ले जाता है । अनुभवी एम्बर डेवलपर्स (आमतौर पर) यह गलती नहीं करते हैं, लेकिन यह बनाने के लिए एक आसान है। " [जोर जोड़ा]
मूल निवासी बनाम वी.एम.
देशी ब्राउज़र समर्थन (पढ़ें "तेज़ होने की गारंटी")
अब अंत में कुछ ऐसा है जो राय का विषय नहीं है।
वास्तव में यहाँ यह बिल्कुल दूसरा तरीका है। बेशक "देशी" कोड सी ++ में लिखा जा सकता है लेकिन आपको क्या लगता है कि जावास्क्रिप्ट इंजन में लिखा जाता है?
तथ्य के रूप में जावास्क्रिप्ट इंजन वास्तव में उन अनुकूलन में अद्भुत हैं जो वे आज का उपयोग करते हैं - और न केवल वी 8 और भी, स्पाइडरमोंकी और यहां तक कि चक्र भी इन दिनों चमकता है। और ध्यान रखें कि जेआईटी संकलक के साथ कोड न केवल मूल के रूप में यह संभवतः हो सकता है, बल्कि ऐसे समय अनुकूलन अवसर भी हैं जो किसी भी संकलित कोड में बस करना असंभव है।
जब लोग सोचते हैं कि जावास्क्रिप्ट धीमा है, तो उनका मतलब आमतौर पर जावास्क्रिप्ट होता है जो DOM तक पहुँचता है। DOM धीमा है। यह मूल है, सी ++ में लिखा गया है और फिर भी इसे लागू करने की जटिलता के कारण नरक के रूप में धीमा है।
अपना कंसोल खोलें और लिखें:
console.dir(document.createElement('div'));
और देखते हैं कि कितने गुण एक खाली divतत्व है जो डोम से जुड़ा नहीं है, उसे लागू करना है। ये केवल पहले स्तर के गुण हैं जो "स्वयं के गुण" हैं। प्रोटोटाइप श्रृंखला से विरासत में नहीं मिला:
संरेखित करें, onwaiting, onvolumechange, ontimeupdate, ऑनसाइट, onubmit, onstalled, onshow, onseeking, onseeked, onscroll, onscroll, onreset, onratechange, onprogress, onprogress, onplaying, onplay, onmsem, onmheem onmouseenter, onmousedown, onloadstart, onloadedmetadata, onloadeddata, onloadup, onkeyup, onkeypress, onkeydown, oninvalid, oninput, onfocus, onerror, onended, onemptied, onemptied, ondurationchange, ondragstart, ondragartart, ondartart, onart, oncontextmenu, onclose, onclick, onchange, oncanplaythrough, oncanplay, oncancel, onblur, onabort, spellcheck, isContentEditable, contentEditable, externalText, innerText, accessKey, हिडन, webkitdropzone, dragIable, tabIndex, dIndexx, dIndexफ़र्स्टफेलचाइल्ड, बच्चे, नेक्स्टइमलीस्लिंग, पिछलेइलीमेंट सिब्लिंग, ऑनव्हील, ऑनवेबकिटफुलसर्केलरेंचर, ऑनवेबकिटफुलसर्केलचेंज, ऑनसेप्टस्टार्ट, ऑनसर्च, ऑनपेक, ऑनकॉपी, ऑनकोपी, ऑनबीस्पस्ट, ऑनबीसबेटी, ओबेबेल्ली, टॉबेबेल्ली, टॉबेबेल्ली क्लायंटहाइट, क्लाइंटविट, क्लाइंटटॉप, क्लाइंटलिफ्ट, ऑफसेटपार्टेंट, ऑफसेटहाइट, ऑफसेटविट, ऑफसेटटाइप, ऑफसेटलिफ्ट, लोकलनेम, उपसर्ग, नेमस्पेसि, आईडी, शैली, विशेषताएँ, टैगनाम, पेरेंटनेम, पैरेंटइमेंट, टेक्स्टकॉन्टेंट, बेसुरंट, बेसक्रीपी, आईडीएक्वायमेंट, एनएफ़टी। parentNode, नोडटाइप, नोडवैल्यू, नोडनेमoncopy, onbeforepaste, onbeforecut, onbeforecopy, webkitShadowRoot, डेटासेट, classList, क्लासनाम, आउटरएचटीएमएल, इनरएचटीएमएल, स्क्रॉलहाइट, स्क्रॉलविट, स्क्रोलटॉप, स्क्रोल लाइट, क्लाइंटहाइट, क्लाइंटहाइट, क्लायंट राइट, क्लायंट, क्लाइंट। नामस्थान, आईडी, शैली, विशेषताएँ, टैगनाम, पेरेंटमेंट, टेक्स्टकंटेंट, बेसुरि, ओनरडिमेंटल, नेक्स्टबेलिंग, पिछलीसालिंग, अंतिमचिल्ड, फर्स्ट चाइल्ड, चाइल्डकोड, पैरेंटकोड, नोडटाइप, नोडवैल्यू, नोडनेमoncopy, onbeforepaste, onbeforecut, onbeforecopy, webkitShadowRoot, डेटासेट, classList, क्लासनाम, आउटरएचटीएमएल, इनरएचटीएमएल, स्क्रॉलहाइट, स्क्रॉलविट, स्क्रोलटॉप, स्क्रोल लाइट, क्लाइंटहाइट, क्लाइंटहाइट, क्लायंट राइट, क्लायंट, क्लाइंट। नामस्थान, आईडी, शैली, विशेषताएँ, टैगनाम, पेरेंटमेंट, टेक्स्टकंटेंट, बेसुरि, ओनरडिमेंटल, नेक्स्टबेलिंग, पिछलीसालिंग, अंतिमचिल्ड, फर्स्ट चाइल्ड, चाइल्डकोड, पैरेंटकोड, नोडटाइप, नोडवैल्यू, नोडनेमपेरेंटलीमेंट, टेक्स्टकंटेंट, बेसुरि, ओनरडिमेंटमेंट, नेक्स्टबेलिंग, पिछलेसिबलिंग, लास्ट चाइल्ड, फर्स्ट चाइल्ड, चाइल्डकोड, पैरेंटकोड, नोडटाइप, नोडवैल, नोडफ्लेमपेरेंटलीमेंट, टेक्स्टकंटेंट, बेसुरि, ओनरडिमेंटमेंट, नेक्स्टबेलिंग, पिछलेसिबलिंग, लास्ट चाइल्ड, फर्स्ट चाइल्ड, चाइल्डकोड, पैरेंटकोड, नोडटाइप, नोडवैल, नोडफ्लेम
उनमें से कई वास्तव में नेस्टेड ऑब्जेक्ट हैं - divअपने ब्राउज़र में एक खाली मूल के दूसरे स्तर (खुद के) गुणों को देखने के लिए, इस फिडेल को देखें ।
मैं गंभीरता से मतलब है, हर एक div नोड पर onvolumechange property? क्या यह एक गलती है? नहीं, यह केवल एक विरासत डोम स्तर 0 ईवेंट हैंडलर में से एक का पारंपरिक इवेंट मॉडल संस्करण है "जो सभी HTML तत्वों द्वारा समर्थित होना चाहिए , क्योंकि दोनों सामग्री विशेषताएँ और IDL विशेषताएँ" [जोर जोड़ा गया] HTML की धारा 6.1.6.2 में W3C द्वारा - इसके आसपास कोई रास्ता नहीं।
इस बीच, ये फर्जी-डोम के पहले स्तर के गुण हैं divरिएक्ट में:
सहारा, _owner, _lifeCycleState, _pendingProps, _pendingCallbacks, _pendingOwner
काफी अंतर है, है ना? वास्तव में यह पूरी वस्तु JSON ( LIVE DEMO ) के लिए अनुक्रमित है , क्योंकि हे वास्तव में आप इसे JSON में अनुक्रमित कर सकते हैं क्योंकि इसमें कोई परिपत्र संदर्भ नहीं है - देशी DOM की दुनिया में अकल्पनीय कुछ ( जहां यह सिर्फ एक अपवाद फेंक देगा। ):
{
"props": {},
"_owner": null,
"_lifeCycleState": "UNMOUNTED",
"_pendingProps": null,
"_pendingCallbacks": null,
"_pendingOwner": null
}
यह बहुत मुख्य कारण है कि रिएक्ट देशी ब्राउज़र डोम की तुलना में अधिक तेज़ हो सकता है - क्योंकि इसमें इस गड़बड़ को लागू नहीं करना है ।
देखें स्टीवन Luscher द्वारा इस प्रस्तुति देशी डोम C ++ लिखित या एक नकली डोम जावास्क्रिप्ट में पूरी तरह से लिखा: क्या तेजी से होता है देखने के लिए। यह बहुत ही निष्पक्ष और मनोरंजक प्रस्तुति है।
अपडेट: भविष्य के संस्करणों में Ember.js एक वर्चुअल डोम का उपयोग करेगा जो रिएक्ट से प्रेरित होकर परिपूर्णता में सुधार करेगा। देखें: 15 नवंबर, 2014 को टोरंटो में एम्बरगार्टन संगोष्ठी से स्टीफन पेनर द्वारा एम्बर की भविष्य की बातचीत।
इसे सम्मिलित करने के लिए: टेम्प्लेट, डेटा बाइंडिंग या कस्टम एलीमेंट जैसे वेब कंपोनेंट्स के फीचर्स का रिएक्ट पर बहुत अधिक लाभ होगा लेकिन जब तक डॉक्यूमेंट ऑब्जेक्ट मॉडल खुद काफी सरलीकृत नहीं हो जाता है तब तक परफॉर्मेंस उनमें से एक नहीं होगी।
अपडेट करें
इस जवाब को पोस्ट करने के दो महीने बाद कुछ खबरें आईं जो यहां प्रासंगिक हैं। जैसा कि मैंने अभी हाल ही में ट्विटर पर लिखा है, जावास्क्रिप्ट में गिटहब द्वारा लिखे गए एटम टेक्स्ट एडिटर का सबसे अंतिम संस्करण फेसबुक के रिएक्ट का उपयोग करता है ताकि बेहतर प्रदर्शन हो सके, भले ही विकिपीडिया के अनुसार "परमाणु क्रोमियम पर आधारित है और सी ++ में लिखा है" इसलिए यह पूर्ण नियंत्रण है देशी सी ++ डोम कार्यान्वयन ( परमाणु के नाभिक देखें ) और वेब घटकों के लिए समर्थन की गारंटी है क्योंकि यह अपने स्वयं के वेब ब्राउज़र के साथ जहाज करता है। यह एक वास्तविक विश्व परियोजना का एक बहुत ही हालिया उदाहरण है जो किसी भी अन्य प्रकार के अनुकूलन का उपयोग कर सकता है आमतौर पर वेब अनुप्रयोगों के लिए अनुपलब्ध है और फिर भी इसने रिएक्ट का उपयोग करने के लिए चुना है जो स्वयं जावास्क्रिप्ट में लिखा गया है, सर्वश्रेष्ठ प्रदर्शन प्राप्त करने के लिए, भले ही एटम। के साथ शुरू करने के लिए प्रतिक्रिया के साथ नहीं बनाया गया था, इसलिए ऐसा करना एक तुच्छ परिवर्तन नहीं था।
अपडेट २
है टोड पार्कर द्वारा एक दिलचस्प तुलना का उपयोग कर WebPagetest के प्रदर्शन की तुलना TodoMVC कोणीय, रीढ़ में लिखा उदाहरण, एंबर, पॉलिमर, CanJS, YUI, नॉकआउट, प्रतिक्रिया और कम संसाधनों में। यह सबसे अधिक उद्देश्य की तुलना है जिसे मैंने अब तक देखा है। यहां जो महत्वपूर्ण है वह यह है कि सभी संबंधित उदाहरण विशेषज्ञों द्वारा उन सभी रूपरेखाओं में लिखे गए थे, वे सभी GitHub पर उपलब्ध हैं और किसी के द्वारा भी सुधार किया जा सकता है जो सोचता है कि कुछ कोड को तेजी से चलाने के लिए अनुकूलित किया जा सकता है।
अपडेट ३
भविष्य के संस्करणों में Ember.js में कई रिएक्ट के फीचर्स शामिल होंगे, जिन पर यहां चर्चा की गई है (जिसमें एक वर्चुअल डोम और यूनिडायरेक्शनल डेटा बाइंडिंग शामिल है, बस कुछ ही नाम देने के लिए) जिसका अर्थ है कि रिएक्ट में उत्पन्न होने वाले विचार पहले से ही अन्य फ्रेमवर्क में माइग्रेट कर रहे हैं। देखें: द रोड टू एम्बर 2.0 आरएफसी - टॉम डेल द्वारा पुल अनुरोध में दिलचस्प चर्चा (प्रारंभ दिनांक: 2014-12-03): "एम्बर 2.0 में, हम एक" वर्चुअल डोम "और डेटा प्रवाह मॉडल को अपनाएंगे जो गले लगाता है रिएक्ट से सर्वश्रेष्ठ विचारों और घटकों के बीच संचार को सरल करता है। "
साथ ही, Angular.js 2.0 यहाँ चर्चा की गई अवधारणाओं का एक बहुत कार्यान्वयन कर रहा है।
अद्यतन ४
मुझे Igwe Kalu की इस टिप्पणी का जवाब देने के लिए कुछ मुद्दों पर विस्तार से बताना है:
"रिएक्ट (जेएसएक्स या संकलन आउटपुट) की तुलना सादे जावास्क्रिप्ट से करना समझदारी नहीं है, जब रिएक्ट अंततः सादे जावास्क्रिप्ट के लिए होता है। [...] डोम सम्मिलन के लिए जो भी रणनीति प्रतिक्रिया का उपयोग करता है, वह रिएक्ट का उपयोग किए बिना लागू किया जा सकता है। सुविधा के अलावा प्रश्न में सुविधा पर विचार करने पर कोई विशेष लाभ नहीं जोड़ा जाता है। ” (पूरी टिप्पणी यहां )
यदि यह पर्याप्त रूप से स्पष्ट नहीं था, तो मेरे उत्तर के भाग में मैं मूल डोम ( सीधे ब्राउज़र में होस्ट ऑब्जेक्ट के रूप में कार्यान्वित) बनाम रिएक्ट के नकली / वर्चुअल डोम (जावास्क्रिप्ट में लागू) पर काम करने के प्रदर्शन की तुलना कर रहा हूं । बिंदु मैं बनाने की कोशिश कर रहा था कि आभासी डोम जावास्क्रिप्ट में कार्यान्वित किया है सकते हैं असली डोम सी ++ में लागू मात और नहीं है कि जावास्क्रिप्ट (क्योंकि यह जो स्पष्ट रूप से ज्यादा मतलब नहीं होगा मात कर सकते हैं प्रतिक्रिया है जावास्क्रिप्ट में लिखा)। मेरा कहना था कि "देशी" C ++ कोड हमेशा "नहीं-देशी" जावास्क्रिप्ट से तेज होने की गारंटी नहीं है। उस बिंदु का वर्णन करने के लिए रिएक्ट का उपयोग करना केवल एक उदाहरण था।
लेकिन यह टिप्पणी एक दिलचस्प मुद्दे को छू गई। एक मायने में यह सच है कि आपको किसी भी कारण से किसी भी ढांचे (प्रतिक्रिया, कोणीय या jQuery) की आवश्यकता नहीं है (जैसे प्रदर्शन, पोर्टेबिलिटी, सुविधाएँ) क्योंकि आप हमेशा यह बता सकते हैं कि फ्रेमवर्क आपके लिए क्या करता है और पहिया को सुदृढ़ करता है - यदि आप लागत का औचित्य सिद्ध कर सकते हैं।
- लेकिन डेव स्मिथ अच्छी तरह से यह में डाल के रूप में कैसे बात याद आती है जब वेब रूपरेखा प्रदर्शन की तुलना : "जब दो वेब चौखटे तुलना, सवाल नहीं है सकते हैं मेरे ऐप तेज हो ढांचा एक्स के साथ सवाल है जाएगा मेरे ऐप ढांचे के साथ तेजी से हो एक्स।"
में करने के लिए अपने 2011 जवाब: क्या कुछ अनुभवजन्य तकनीकी कारणों से jQuery का उपयोग नहीं कर रहे हैं मैं एक ऐसी ही मुद्दे की व्याख्या यह है कि यह असंभव jQuery की तरह एक पुस्तकालय के बिना पोर्टेबल डोम-हेरफेर कोड लिखने के लिए नहीं है, लेकिन लोग शायद ही कभी ऐसा है कि।
प्रोग्रामिंग लैंग्वेज, लाइब्रेरी या फ्रेमवर्क का उपयोग करते समय, लोग सही नहीं बल्कि असुविधाजनक चीजों को करने के सबसे सुविधाजनक या मुहावरेदार तरीकों का उपयोग करते हैं। अच्छे ढाँचों का सही मूल्य आसान है जो अन्यथा करना कठिन होगा - और रहस्य सही चीजों को सुविधाजनक बना रहा है। परिणाम अभी भी आपके निपटान में ठीक वैसी ही शक्ति है जैसे लैम्ब्डा कैलकुलस या सबसे आदिम ट्यूरिंग मशीन का सबसे सरल रूप है, लेकिन कुछ अवधारणाओं की सापेक्ष अभिव्यक्ति का मतलब है कि उन अवधारणाओं को अधिक आसानी से या बिल्कुल भी व्यक्त किया जाता है, और वह सही समाधान न केवल संभव हैं बल्कि वास्तव में व्यापक रूप से लागू किए गए हैं।
अद्यतन ५
प्रतिक्रिया + प्रदर्शन = जुलाई २०१५ से पॉल लुईस का लेख एक उदाहरण दिखाता है जहां रिएक्ट वेनिला जावास्क्रिप्ट की तुलना में धीमा है जो फ्लिकर चित्रों की एक अनंत सूची के लिए हाथ से लिखा गया है, जो मोबाइल पर विशेष रूप से महत्वपूर्ण है। यह उदाहरण दिखाता है कि सभी को हमेशा विशिष्ट उपयोग के मामले और विशिष्ट लक्ष्य प्लेटफार्मों और उपकरणों के लिए प्रदर्शन का परीक्षण करना चाहिए।
के लिए धन्यवाद केविन Lozandier के लिए यह मेरा ध्यान में लाने ।