jquery - क्या अभी भी नई परियोजनाओं के लिए जीडब्ल्यूटी प्रासंगिक है?




gwt extjs gxt gquery (5)

मुझे लगता है कि बिंदु 1 का जवाब देना है, आपको देखना होगा कि आपकी वर्तमान स्थिति क्या है और आपके लक्ष्य क्या हैं।

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

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

मुझे सच में यकीन नहीं है कि कौन सा बिंदु 2 पूछ रहा है। यदि आप पूरे ढेर ढांचे के बारे में पूछ रहे हैं, तो मुझे लगता है कि आप नोडज का उपयोग करके कुछ ढूंढ सकते हैं, हालांकि मुझे नहीं लगता कि मेरे पास सलाह देने के लिए पर्याप्त अनुभव है।

बिंदु 3 पर, जहां मैं काम करता हूं, हम पाइथन और ग्रोवी में लिखे गए कुछ (नए) सर्वर / सेवाओं के साथ जेएस फ्रेमवर्क (विशेष रूप से एंगुलरजेएस) का उपयोग करने की ओर बढ़ रहे हैं, और अभी भी जावा में विरासत प्रणाली हैं। क्लोजर में हमारे पास कुछ सेवाएं भी लिखी जा रही हैं।

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

जीडब्ल्यूटी आजकल अधिक परिपक्व है

200 9 के प्रश्न / उत्तर के बाद, जीडब्ल्यूटी विकसित हुआ है और कुछ जेएस ढांचे जावा में उपलब्ध हैं:

  • GwtQuery लिए GwtQuery (gQuery)
  • ExtJS के लिए GXT (पूर्व ExtGWT)
  • स्मार्ट जीडब्ल्यूटी ने GWT-ext का अधिग्रहण किया है
  • ... और निश्चित रूप से और ... (कृपया संलग्न करने के लिए स्वतंत्र महसूस करें)

और भी अधिक, जावा कोड को स्टैंडअलोन जेएस पुस्तकालयों में परिवर्तित किया जा सकता है: gwt-exporter

लेकिन निम्न स्तर के जेएस ढांचे पर्याप्त हो सकते हैं

लेकिन जितना अधिक मैंने पढ़ा, मैं वेब डेवलपर्स को जीडब्ल्यूटी पर अपनी पीठ बारी करने और सीधे जेएस फ्रेमवर्क (जेएस फ्रेमवर्क के लिए Firebug , आईडीई प्लगइन्स ...) का उपयोग करने की सलाह देता हूं।

उत्पादकता

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

प्रशन

  1. किस तरह की नई 2014 परियोजना जीडब्ल्यूटी को (या नहीं) माना जाना चाहिए?
  2. क्या आसान AJAX वेब अनुप्रयोग विकास और तैनाती के लिए जीडब्ल्यूटी के प्रासंगिक विकल्प हैं?
  3. वर्तमान मोड और प्रवृत्ति क्या हैं?

मेरा विशिष्ट मामला

मैंने अभी Python3 (http.server.HTTPServer) कॉलिंग (POST) bash स्क्रिप्ट्स (सी ++ में कुछ प्रोसेसिंग) और JSON डेटा पुनर्प्राप्त करने के आधार पर एक पीओसी (इंट्रानेट वेब ऐप का) पूरा कर लिया है। प्रतिपादन के लिए वेब पेज में कुछ जेएस (कोई ढांचा नहीं)। इसलिए मैं अगले पुनरावृत्ति के लिए सबसे अच्छा विकल्प सोच रहा हूं।

लेकिन कृपया अन्य मामलों के बारे में भी इस प्रश्न का उत्तर दें। मैं कई लोगों के लिए उपयोगी होने के लिए एक सामान्य प्रश्न / उत्तर पसंद करूंगा।

अद्यतन अक्टूबर 2015

जीडब्ल्यूटी कम सक्रिय दिखता है क्योंकि 11 महीने से कोई नई रिलीज नहीं है। लेकिन अतीत में संस्करण 2.4 और 2.5 के बीच 13 महीने तक। गिट रेपो दर्पण अभी भी बहुत सक्रिय है। इसके अलावा जीडब्ल्यूटी एक्सटेन्सिबल है, और नए जीडब्ल्यूटी फ्रेमवर्क रिलीज की आवश्यकता के बिना जीडब्ल्यूटी पुस्तकालयों से नई विशेषताएं आ सकती हैं। उदाहरण के लिए सबसे आम मोबाइल जीडब्ल्यूटी पुस्तकालयों और इसी तरह के रिलीज चक्र देखें। इस बीच प्रवृत्ति हर जगह Node.js का उपयोग करना है! नई परियोजनाओं के लिए जीडब्ल्यूटी को गोद लेना वास्तव में डेवलपर्स कौशल / प्रेरणा और परियोजना जीवनकाल (कारोबार / प्रशिक्षण / रखरखाव) पर निर्भर करता है। उपलब्ध स्रोत कोड और समय-समय पर बाजार के पुन: उपयोग के रूप में कुछ अन्य मानदंडों को भी ध्यान में रखा जा सकता है ... नीचे दिए गए उत्कृष्ट उत्तर देखें।


जीडब्ल्यूटी प्रासंगिक है। इसका उपयोग 130,000 डेवलपर्स है। यदि आप मुझ पर विश्वास नहीं करते हैं तो देखें [जीडब्ल्यूटी 2015 में वापस आ रहा है .. [blog.xam.de/2014/02/gwt-is-coming-back-in-2015.html] और दूसरा स्टैक एक्सचेंज प्रश्न जो इस बारे में बात करता है। जीडब्ल्यूटी आपको पहला विकल्प नहीं होना चाहिए क्योंकि इसमें बहुत जटिलता शामिल है।

जीडब्ल्यूटी के लिए कौन सी परियोजनाएं अच्छी हैं? जीडब्ल्यूटी बहुत जटिल है :

  • जावा एक कठिन भाषा है जो खराब कोड लिखना मुश्किल बनाती है
  • जावास्क्रिप्ट के लिए संकलन जटिलता जोड़ता है
  • जीडब्ल्यूटी को अत्यधिक जटिल वेब ऐप्स के लिए ग्राउंड अप से बनाया गया था
  • जीडब्ल्यूटी समुदाय जावास्क्रिप्ट समुदाय से अधिक डेवलपर अनुभव पर उपयोगकर्ता अनुभव और प्रदर्शन को प्राथमिकता देता है

हालांकि, यह क्लीनर अधिक रखरखाव कोड है, यह जावा है, यह तेज़ है, और यदि आप जे 2 ओबीजेसी का उपयोग करते हैं तो आप अपने कोड को जेवीएम और आईओएस पर पुन: उपयोग कर सकते हैं

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

जीडब्ल्यूटी Google के रुझानों और वास्तव में नौकरी के रुझानों के अनुसार नीचे जा रहा है लेकिन जावास्क्रिप्ट और jQuery भी नीचे जा रहे हैं। मुझे नहीं पता कि ये तकनीकें क्यों नीचे जा रही हैं। मेरा सिद्धांत यह है कि बहुत सारे नए ढांचे हैं जो डेवलपर्स को जीडब्ल्यूटी और जावास्क्रिप्ट से चुरा रहे हैं। मुझे नहीं लगता कि इसका जरूरी अर्थ यह है कि जावास्क्रिप्ट और जीडब्ल्यूटी अभी भी मर रहे हैं। यह बहुत अधिक प्रतिस्पर्धा के परिणाम से ज्यादा कुछ नहीं है।


बिंदु 1 के लिए मैं आपको कुछ मानदंड दे सकता हूं जो मैं उपयोग करूंगा:

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

आपके लक्षित प्लेटफ़ॉर्म के संदर्भ में डिबगिंग की ज़रूरतें भी मेरे लिए मानदंड हैं। जीडब्ल्यूटी कोड को डीबग करना बहुत अच्छा है जब तक आपके पास एक ब्राउज़र है जो DevMode द्वारा समर्थित है या कम से कम नए स्रोत मानचित्र आधारित SuperDevMode के साथ उपयोग किया जा सकता है। मैकोज़ एक्स पर एफ़ सफारी समर्थित नहीं है। मोबाइल उपकरणों के लिए, आप एंड्रॉइड क्रोम पर रिमोट डीबग जावास्क्रिप्ट कर सकते हैं लेकिन जहां तक ​​मुझे पता है कि यह जीडब्ल्यूटी के लिए संभव नहीं है।

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

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

निश्चित रूप से, जीडब्ल्यूटी और जावास्क्रिप्ट ढांचे दोनों के लिए अधिक मानदंड हैं।

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

बिंदु 2 के बारे में:

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

बिंदु 3 के संबंध में:

  • जावास्क्रिप्ट के साथ बेहतर टाइपिंग और इंटरऑपरेबिलिटी के कारण मुझे निश्चित रूप से टाइपस्क्रिप्ट पर एक नज़र डालेंगी
  • जहां तक ​​मुझे याद है, डार्ट का एक समान लक्ष्य है
  • सदाबहार JQuery है लेकिन आपकी जरूरतों पर निर्भर अच्छे विकल्प हैं। लेकिन यह अत्यधिक व्यक्तिपरक है
  • विगेट्स के लिए, ट्विटर बूटस्ट्रैप ( http://getbootstrap.com/ ) अच्छा है अगर चीजों को करने का तरीका आपके लिए ठीक है। इसका एक जीडब्ल्यूटी संस्करण भी है ( http://gwtbootstrap.github.io/ )

स्टीफन द्वारा महान जवाब। मैंने इसे टिप्पणी के रूप में लिखना शुरू कर दिया, लेकिन पाया कि मैंने अपेक्षा से अधिक टाइप किया है, इसलिए इसे एक अलग उत्तर बना रहा है। अंक के लिए शिकार नहीं ...

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

इसलिए एक कंपनी में अधिकांश डेवलपर्स जावा डेवलपर्स (या .NET, जो इस वार्तालाप के बाहर है) होगा। उन्हें यूआई पर काम करने के लिए आपको जावा संगत तकनीक का उपयोग करना होगा, जो जेएसपी या जीडब्ल्यूटी होगा। जेएसपी को जेएस पुस्तकालयों को आगे बढ़ने के लिए अधिक या कम प्रस्तुत करने की आवश्यकता होगी।

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

हालांकि आंतरिक उपयोग के लिए लिखे गए अधिकांश आवेदन सार्वजनिक रूप से नहीं हैं। आपने जो वर्णन किया है, उससे आपका उपयोग केस इस श्रेणी के अंतर्गत आ सकता है।

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

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

हमारे लिए जीएफटी के साथ जीडब्ल्यूटी आंतरिक अनुप्रयोगों का एक सेट बनाने का एक आसान और त्वरित तरीका था। हमारी कंपनी के जावा डेवलपर्स की टीम के साथ, हम कभी भी इसी अवधि के भीतर गुणवत्ता या यहां तक ​​कि परियोजनाओं की पूर्णता के करीब नहीं आते।


You can use jquery mx (used in javascriptMVC) which is a set of scripts that allows you to use models, views, and controllers. I've used it in a project and helped me create structured javascript, with minimal script sizes because of compression. This is a controller example:

$.Controller.extend('Todos',{
  ".todo mouseover" : function( el, ev ) {
   el.css("backgroundColor","red")
  },
  ".todo mouseout" : function( el, ev ) {
   el.css("backgroundColor","")
  },
  ".create click" : function() {
   this.find("ol").append("<li class='todo'>New Todo</li>"); 
  }
})

new Todos($('#todos'));

You can also use only the controller side of jquerymx if you aren't interested in the view and model parts.





jquery gwt extjs gxt gquery