एचटीएमएल 5 यूआई फ़्रेमवर्क

Question

मैंने पाया जैसे वहाँ पर एचटीएमएल 5 यूआई चौखटे के बहुत सारे,:

• Kendo
• Wijmo
• jqWidgets
• Zebra
• Sencha
• SproutCore
• YUI
• XUI
• Shield UI

मैं वहाँ फिर से इतना संसाधनों के साथ थोड़े अभिभूत हूँ। उनमें से कुछ को देखा, लेकिन लगभग सभी बहुत धीमी और हेवीवेट की तरह लग रहे थे।

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

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

आप मुझे सीखने के लिए कौन सी सलाह देते हैं?

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

Answer 1

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

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

शायद, आप बस अपनी वेबसाइट को कुछ विजेट्स जैसे टैब, संवाद, कुछ ड्रैग करने योग्य/ड्रॉप करने योग्य तत्व, टेक्स्ट संपादन आदि के साथ बढ़ाना चाहते हैं और आप अपने विकास मॉडल को बदलने के इच्छुक नहीं हैं। मेरा मतलब है, आप अपने पसंदीदा जावा/PHP/रूबी का उपयोग करते हैं और जावास्क्रिप्ट में अपने बहुत से ऐप के तर्क और व्यवहार को लिखना नहीं चाहते हैं। इस मामले में, jQuery- आधारित प्लगइन-जैसे समाधान आपके लिए विशेष रूप से jQuery UI और jQuery Mobile करेंगे।

jQuery विजेट्स इसके प्लगइन सिस्टम का पालन करते हैं। इसका आमतौर पर मतलब है कि वे उपयोग करने में बेहद आसान हैं।आदेश में एक बटन बनाने के लिए, आप लिखते हैं: जैसे

$('#myButton').button('disable'); 

और हो रही है या मूल्यों की स्थापना,:

$('#myButton').button(); 

अब अगर आप इसे अक्षम करना चाहते, तो आप निम्न पद्धति का उपयोग कर एक विधि कॉल स्लाइडर या डेटपिकर पर, इस तरह दिखता है:

$('#mySlider').slider('value'); 
$('#mySlider').slider('value', 42); 

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

इसे सारांशित करना: यदि आपके पास बहु-पृष्ठ वेबसाइट है, तो यदि आप अपने फॉर्म पोस्ट करते हैं, तो jQuery UI या हल्का समाधान जैसे Twitter Bootstrap का उपयोग करें।

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

आप कई जावास्क्रिप्ट ढांचे का उपयोग कर सकते हैं जो आपको मॉडल, डेटा बाध्यकारी और संभवतः वेब ऐप्स बनाने के अन्य साधन प्रदान करते हैं और उन्हें jQuery UI क्यों नहीं देते हैं। या आप Kendo या Wijmo या jqWidgets जैसे अधिक पूर्ण ढांचे का उपयोग कर सकते हैं। ये ढांचे jQuery पर भरोसा करते हैं (विज्मो jQuery यूआई पर निर्भर करता है) और डेटा मैनिपुलेशन के अतिरिक्त साधन प्रदान करता है। उनके पास डेटा मॉडल हैं। केंडो अपना स्वयं का समाधान लागू करता है (मुझे लगता है), जबकि विज्मो और जेकविड्ज लोकप्रिय नॉकआउट जेएस के साथ एकीकृत हैं।

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

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

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

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

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

Answer 2

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

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

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

दूसरी चीज़ जो मुझे डीएचटीएमएक्स के बारे में पसंद है वह उनकी वस्तुओं की गति है। उदाहरण के लिए ग्रिड ऑब्जेक्ट बहुत स्वीकार्य गति पर 10,000+ पंक्तियों को आसानी से संभाल लेगा।

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

आशा इस मदद करता है