GWT की चमक और गरीबी (या मुझे डार्ट पार्ट 2 में विश्वास क्यों नहीं है)

हैबे के सबसे चर्चित विषयों में से एक Google की एक नई डार्ट भाषा के निर्माण की घोषणा थी, जो जावास्क्रिप्ट को पूरी तरह से बदलने का दावा करती है।
Google के लिए, यह अपनी तरह का पहला प्रोजेक्ट नहीं है। 2006 से, Google वेब टूलकिट है जो आपको पूरी तरह से जावा में वेब एप्लिकेशन बनाने की अनुमति देता है। उदाहरण के लिए, ऐडवर्ड्स और गूगल वेव इस पर काम करते हैं।
लेकिन, सुंदर वादों और बहुत गंभीर, विशेष रूप से 2006 के मानकों के बावजूद, अवसरों, GWT ने कभी "बंद" नहीं किया। हां, परियोजना समर्थित और विकसित है, लेकिन डेवलपर्स के समुदाय ने काम नहीं किया। कुछ तृतीय-पक्ष घटक हैं, वे समर्थित नहीं हैं, प्रोग्रामर सिस्टम से परिचित होना मुश्किल है।
लगभग सभी डार्ट भाषा के "बन्स" जो वर्तमान में Google द्वारा विज्ञापित किए गए वेबटूलकिट में पहले ही लागू हो चुके हैं। इस आलेख में, मैं भविष्य के डार्ट के मैला आकार की जांच करने के प्रयास में जीडब्ल्यूटी की ताकत और कमजोरियों का विश्लेषण करना चाहता हूं।

लक्ष्य और उद्देश्य

प्रोग्रामर के दृष्टिकोण से, आधुनिक वेब एप्लिकेशन बनाने के लिए आपको प्रौद्योगिकियों के एक पूरे चिड़ियाघर का उपयोग करना होगा: क्लाइंट पक्ष के लिए एचटीएमएल, सीएसएस और जावास्क्रिप्ट; एसक्यूएल, पीएचपी, और अक्सर सर्वर के लिए स्मार्टली जैसे किसी तरह के टेंपलेटिंग इंजन; डेटा XML, JSON, या किसी प्रकार की बाइक का उपयोग करके नेटवर्क से गुजरता है।

यह एक क्लासिक यूनिक्स-तरीका है: काम के प्रत्येक क्षेत्र के लिए एक अलग उपकरण का उपयोग किया जाता है। यह दृष्टिकोण जबरदस्त लचीलापन प्रदान करता है। यदि आप किसी विशेष उपकरण की तरह नहीं हैं, तो आप इसे दूसरे से बदल सकते हैं: PHP for python, SQL for NoSQL, HTML for Flash।

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

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

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

प्रौद्योगिकी चिड़ियाघर के अलावा, IE के नेतृत्व में एक ब्राउज़र चिड़ियाघर भी है। अब भी, जावास्क्रिप्ट को कुंजी (ऑनकीप्रेस) को दबाने की प्रतिबंधात्मक घटना को संभालते हुए, आपको ब्राउज़र संस्करण की जांच करनी होगी, क्योंकि विभिन्न ब्राउज़र इस फ़ंक्शन को अलग-अलग तरीकों से कहते हैं। फिर, 2006 में, पेज को कमोबेश एक जैसा बनाने के लिए मुझे भारी संख्या में बैसाखी का उपयोग करना पड़ा। GWT ने इस समस्या को खूबसूरती से हल किया।

यह कैसे काम किया

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

सर्वर की तरफ, सब कुछ नियमित जावा सर्वर पेजों की तरह था जिसमें जीडब्ल्यूटी लाइब्रेरीज़ जुड़े थे। लेकिन चूंकि JSP होस्टिंग को अभी भी ढूंढने की जरूरत थी, एक तरह से या किसी अन्य को इस पूरी अर्थव्यवस्था की सेटिंग्स का पता लगाना था। हालाँकि, सर्वर पार्ट को किसी भी चीज़ पर बनाया जा सकता है, लेकिन एक ही भाषा के सभी फायदे निश्चित रूप से खो गए हैं।

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

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

सामान्य तौर पर, सिद्धांत रूप में, सब कुछ बहुत अच्छा लग रहा था।

अभ्यास

व्यवहार में, सब कुछ इतना रसीला नहीं था।

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

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

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

सिद्धांत रूप में, GWT JSNI का समर्थन करता है - सी में एक ला विधानसभा भाषा, केवल एक कोडांतरक के रूप में जावास्क्रिप्ट के साथ। लेकिन यह केवल एक ही तरह से काम करता है। यही है, आप जीडब्ल्यूटी से कुछ बाहरी जेएस लाइब्रेरी को बिना किसी समस्या के कॉल कर सकते हैं। लेकिन इसके विपरीत ... क्या जावास्क्रिप्ट है, इसे GWT में इंटरसेप्ट करने के लिए एक html एलिमेंट पर अपने ऑनक्लिक को लटकाएं - इस तरह की शर्मिंदगी को मैनुअल में वर्णित नहीं किया गया था और ऐसा लगता है, डेवलपर्स द्वारा बिल्कुल भी प्रदान नहीं किया गया था। ऐसा करना संभव था, लेकिन जावास्क्रिप्ट ट्रिक की मदद से जीडब्ल्यूटी नहीं।

Google ने ब्राउज़र के बीच सभी अंतरों को पूरी तरह से अवरुद्ध करने की कोशिश की, लेकिन फिर भी अंत तक ऐसा नहीं कर सका। वहाँ बने रहे (कम से कम संस्करण २.२ में, मैंने आगे काम नहीं किया) कुछ सूक्ष्म बिंदु जो कि जावास्क्रिप्ट में भी "shamanism" से संबंधित हैं, जैसे कि धुंधले माउस क्लिक के साथ पाठ को उजागर करने का निषेध। लेकिन यह नाइटपैकिंग है।

वैचारिक मुद्दे

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

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

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

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

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

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

जीडब्ल्यूटी को क्लासिक ओओपी के सच्चे प्रशंसकों द्वारा बनाया गया था, जिन्होंने पवित्र पैटर्न से किसी भी विचलन की अनुमति नहीं दी थी। यदि किसी ने तय किया कि आप तत्वों की इनलाइन शैलियों का उपयोग नहीं कर सकते हैं, तो आप रोक नहीं सकते। ऐसा कोई फ़ंक्शन नहीं है - स्टाइल बदलने के लिए, और नहीं, सीएसएस कक्षाओं के साथ सब कुछ करेंगे। सामान्य तौर पर, ज्यादातर मामलों में, इनलाइन शैलियों का वास्तव में उपयोग नहीं किया जाना चाहिए, लेकिन कैसे, उदाहरण के लिए, एनीमेशन को लागू करने के लिए? प्रपत्र .opacity03 {अपारदर्शिता: 0.3} के 20 वर्ग बनाएं?

लानत है, GWT में ग्रिड प्रकार (एक टेबल की तरह एक नियंत्रण जिसमें आप कोशिकाओं को संपादित कर सकते हैं) का एक घटक होता है, जिसमें इसका अपना MVC पूरी तरह से लागू होता है। दृश्य नियंत्रण में ... यदि आपको 2x3 प्लेट बनाने की आवश्यकता है, तो आपको मॉडल, कंटेनर और फिर सूची को नीचे वर्णित करना होगा। 200 कोड के लिए लाइन्स :)

यदि एक ही टीम ने डार्ट ... अच्छा किया, तो मुझे नहीं पता। अब 2006 का वर्ष नहीं है, जावास्क्रिप्ट मजबूत हो गया है, बस गया है और jQuery के स्तर के पुस्तकालयों के साथ अति हो गया है। मैं एक भी कारण नहीं देखता कि डार्ट "शूट" क्यों करेगा। Google की सारी शक्ति के बावजूद।