वेब डेवलपमेंट में क्लाइंट-साइड पर जाएं

10

पिछले कुछ महीनों में, मैंने वेब विकास में क्लाइंट-साइड स्क्रिप्टिंग के बारे में एक बड़ी उत्तेजना को पहचान लिया। लेकिन जब सर्वर-साइड प्रौद्योगिकियां परिपक्व, स्थिर और अच्छी तरह से बैकेंड-डेवलपर्स द्वारा स्वीकार की जाती हैं, तो क्लाइंट-साइड प्रौद्योगिकियां अपरिपक्व होती हैं (यानी बड़े सर्वर-साइड फ्रेमवर्क की तुलना में) और कई लंबे समय से स्थापित डेवलपर्स द्वारा नापसंद। फिर भी हर कोई इन दिनों क्लाइंट-साइड विकास कर रहा है। मैं व्यक्तिगत रूप से उन बड़े सर्वर-साइड चौखटों को चालू प्रवृत्ति को देखते हुए 2-5 वर्षों में गायब होने की उम्मीद करता हूं।

ऐसा क्यों हैं? एचटीएमएल 5 / जेएस में विकासशील नए और "फैलाना" क्लाइंट-साइड संभवतः बड़े और अच्छी तरह से सोचा सर्वर-साइड समाधानों से बेहतर कैसे हो सकते हैं?

— ब्रूनो शेपर
स्रोत

4

क्या आपके पास अपनी मान्यताओं को सत्यापित करने के लिए कोई स्रोत है? जावास्क्रिप्ट लगभग उतना ही पुराना है जितना कि इंटरनेट, और मैं सर्वर-साइड प्रोग्रामिंग को कभी भी जल्द ही नहीं देख सकता।

— tdammers

1

स्पष्ट करने के लिए, मेरी धारणाएं सामने के छोर तक सीमित हैं। मुझे यूआई लॉजिक, रेंडरिंग और उस तरह के सामान में क्लाइंट-साइड की ओर एक बदलाव दिखाई देता है। बेशक सर्वर-साइड कभी नहीं गया होगा, लेकिन एक REST-api (या उस मामले के लिए SOAP) में कम हो जाएगा।

— ब्रूनो स्कैपर

3

यह पारी आती है और चली जाती है। आम तौर पर फ्रंट-एंड डेवलपमेंट एक बार फिर से लोकप्रिय हो जाती है, जब नई-नई तकनीकों को पेश किया जाता है (Shockwave, Flash, JavaFX, Flex) या बड़े नए js चौखटे "दुनिया पर कब्ज़ा" करने की कोशिश कर रहे हैं (मोटल्स, jquery, इत्यादि)

— Bobak

1

@VainFellowman: आप वास्तव में क्लाइंट-साइड स्क्रिप्ट में SOAP का उपयोग नहीं करना चाहते हैं। वहाँ बहुत अधिक उपरि रास्ता है, यह दर्द हो रहा है, और आप ज्यादा जीत नहीं सकते क्योंकि अपने गतिशील टाइपिंग अनुशासन के साथ जावास्क्रिप्ट वैसे भी SOAP प्रकार की जानकारी का अधिक उपयोग करने में सक्षम नहीं होगा।

— tdammers

1

@ मैं नहीं चाहता, वास्तव में मैं नहीं। मुझे HTTP पर SOAP का उपयोग करने का कोई मतलब नहीं दिखता है। REST लगभग हर चीज के लिए उपयुक्त है।

— ब्रूनो शेपर

7

यह सच है:

वेब डेवलपमेंट में क्लाइंट-साइड पर जाएं

लेकिन यह क्लाइंट-साइड तक ही सीमित नहीं है, यह एक पूर्ण स्टैक मूवमेंट है।

मुझे पता है कि यह आश्चर्यजनक हो सकता है। प्लीज, मुझे सुन लो।

ऐसा क्यों हैं? एचटीएमएल 5 / जेएस में विकासशील नए और "फैलाना" क्लाइंट-साइड संभवतः बड़े और अच्छी तरह से सोचा सर्वर-साइड समाधानों से बेहतर कैसे हो सकते हैं?

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

दूसरी बात, क्योंकि यह बेहतर है।

अच्छा प्रश्न।

लेकिन "बेहतर" व्यक्तिपरक है, इसलिए आपके प्रश्न का उत्तर है, विशेष रूप से बेहतर क्या है?

प्रश्न पर फिर से जाएँ:

एचटीएमएल 5 / जेएस में विकसित करने वाले क्लाइंट-साइड "फैलाना" संभवतः बड़े सर्वर-साइड समाधान से बेहतर कैसे हो सकता है?

Because small is nimble.
And big is clunky.

यह लचीलापन है।

एक बड़ी बात नहीं लगती। क्या यह? लचीलापन।

हालांकि, लचीलापन सब कुछ कम कर देता है। लचीलेपन में एक सुधार - सब कुछ सुधारता है।

रख-रखाव। तानाना। अनुमापकता। प्रतिरूपकता। प्रयोज्य। UX।

और इसे लागू करना तेज है। यही सच्चाई है। तेज़ और बेहतर।

This is why Windows 8 made JS a first-class citizen.

एचटीएमएल 5 - जेएस, एक सनक नहीं है और यह दूर नहीं जाएगा। हम केवल एक तकनीक के बीज देख रहे हैं जो टेबलेट को कंप्यूटिंग सामग्री और इंटरैक्शन व्यवहार प्रदान करने के लिए बढ़ेगा। गोलियाँ।

1950 के दशक में टीवी के बाद स्मार्ट फोन सबसे तेजी से मास-मीडिया अपनाने वाला था। अब, न केवल हमारे पास स्मार्टफ़ोन हैं - हमारे पास टैबलेट हैं।

पहले से ही मोज़िला और विंडोज पर विकास ओएस अपने बाजारों में भविष्य के उपकरणों पर चलेगा -> एचटीएमएल / जेएस।

कई समाधान और नवाचार रहते हैं।

लचीलेपन के आधार पर जेएस का एक पूरा ढेर उभर रहा है।

मुझे आशा है कि वह मदद करेंगे।

— जैक स्टोन
स्रोत

1

बहुत बढ़िया जवाब! लेकिन सर्वर-साइड चौखटे एक ही लाभ का वादा करते हैं, क्या वे नहीं?

— ब्रूनो स्कैपर

1

हां, सर-साइड फ्रेमवर्क समान लाभ का वादा करते हैं, हां। यह जानने की जरूरत है कि उभरती हुई प्रौद्योगिकी में, अप्रत्याशित रूप से पाए जाने वाले अतिरिक्त लाभ हैं। यह io में सबसे निचले स्तर (c) पर है। सूत्र प्रतीक्षा करते हैं। JS में इसका कॉलबैक है। यह इंतजार नहीं करता। इसलिए न्यूनतम स्तर पर एक io अनुकूलन है। यह एहसास अब, चुपचाप, Microsoft द्वारा बड़े पैमाने पर अपनाया गया है। जिस कारण उनका OS JS है। अंतिम बिंदु, यह सभी स्तरों पर अनुकूलन और मेटा ऑप्टिमाइज़ेशन देता है। क्योंकि भाषा लचीली है। एक साधारण-अदृश्य चीज। ज्ञात नहीं है। उम्मीद है की वो मदद करदे।

— जैक स्टोन

1

मैंने इस उत्तर को स्वीकार करना चुना, क्योंकि यह सबसे पूर्ण है। अन्य सभी के अच्छे अंक हैं, लेकिन यह सबसे निर्णायक है। सभी को धन्यवाद!

— ब्रूनो शापर

9

इस कहानी के हमेशा से दो पहलू रहे हैं; सर्वर-साइड और क्लाइंट-साइड कोड दोनों में उनके पेशेवरों और विपक्ष हैं।

क्लाइंट साइड स्क्रिप्टिंग के लाभों में शामिल हैं:

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

लेकिन सर्वर-साइड स्क्रिप्ट के बहुत सारे फायदे हैं:

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

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

देखा गया प्रचार दो हाल के घटनाक्रमों के संयोजन से आता है:

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

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

— tdammers
स्रोत

कठिन सत्य ... +1।

— जैक स्टोन

8

सर्वर साइड हमेशा आसपास रहेगा। आप हर चीज के लिए क्लाइंट-साइड पर नहीं बैठ सकते। उदाहरण के लिए, आप अपने माइक्रो-कंट्रोलर के लिए एक बैकबोन.जेएस एमवीसी डिजाइन का उपयोग नहीं करना चाहते हैं जो आपको वास्तविक समय में उत्पादन मंजिल ओवरहेड क्रेन से पैरामीटर भेज रहा है।

प्रचार पर विश्वास मत करो।

— lwm
स्रोत

मुझे बताओ। क्या विंडोज 8 में जेएस, प्रचार है? -1। मैं पहले बिंदु से सहमत हूं, लेकिन प्रचार पर आपका दूसरा बिंदु, स्पष्टीकरण की आवश्यकता है।

— जैक स्टोन

JS क्लाइंट-साइड के लिए अनन्य नहीं है और कुछ समय के लिए नहीं है।

— एरिक रेपेन

@ क्लिंटनश हां, वास्तव में। Ms ने अपने प्लेटफॉर्म के लिए डेवलपर्स की संभावित संख्या बढ़ाने के लिए win8 ऐप बनाने के लिए j को सक्षम किया है। यह डेस्कटॉप प्रौद्योगिकियों पर उन तकनीकों को सीखने के लिए चुनने वाले लोगों के लिए एक प्रतिक्रिया है। लेकिन एक बदलाव के रूप में जो पहले से ही सी # / wpf जानता है, मुझे html / js के साथ win8 ऐप बनाने का कोई कारण नहीं दिखता है।

— एंडी

@ErikReppen यह सच है, लेकिन अकेले js ने इसे सर्वर पर नहीं काटा है, आपको इसमें निर्माण करने के लिए एक रूपरेखा की आवश्यकता है। स्पष्ट रूप से सर्वर पर स्क्रिप्ट का उपयोग करने की इच्छा मुझे चकरा देती है। हमने ऐसा पहले ही किया था, यह क्लासिक एएसपी था, और मुझे वास्तव में उस अनुभव को दोहराने की इच्छा नहीं है।

— एंडी

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

— एरिक रेपेने

6

मैंने 2009 में एक सर्वर-साइड PHP फ्रेमवर्क से सर्वर-साइड वेब सेवाओं से जुड़े क्लाइंट-साइड एक्सटीजेएस समाधान पर स्विच किया है।

मेरे प्रवास के कारण थे:

सर्वर पर एंडपॉइंट और कोड की मात्रा को कम करके बेहतर सुरक्षा।
वेब सेवाओं पर जाने से आप वेब सेवा सीमा पर इनपुट को मान्य करते हैं और आपके सर्वर के I / O पर अधिक सटीक नियंत्रण होता है। आपकी सुरक्षा वास्तुकला को बेहतर बनाने के लिए कोई सर्वर-साइड UI परत नहीं है।
कम सर्वर राउंडट्रिप्स के कारण बेहतर प्रदर्शन
आर्किटेक्चर में बदलाव इसलिए होता है कि डेटा फ़िंच अक्सर कम हो सकते हैं और यूआई प्रतिपादन के साथ स्थानीय स्तर पर डेटा को कैश किया जा सकता है। Roundtrips वेब ऐप के प्रदर्शन को मारते हैं।
UI की cacheability के कारण बेहतर प्रदर्शन
UI परत को पूरी तरह से CDN पर होस्ट किया जा सकता है। मैंने एचटीएमएल कोड को एचटीएमएल 5 ऐप कैश में भेजकर ऑफलाइन वेब ऐप भी बनाया है।
UI की उच्च निष्ठा (अमीर क्लाइंट-साइड नियंत्रण)
तीसरे पक्ष के डेवलपर्स उसी API का उपयोग कर सकते हैं जैसा कि मेरा स्वयं का फ्रंट-एंड उपयोग कर रहा है, और यदि वे सुविधाओं को साझा करते हैं तो मैं आसानी से एपीआई के मॉड्यूल का पुन: उपयोग कर सकता हूं।
इसका मतलब है कम विकास, क्यूए, प्रलेखन, ...
मुझे PHP, Python या Java से बेहतर जावास्क्रिप्ट में प्रोग्रामिंग पसंद है

लेकिन, कोई गलती न करें, अब जो हो रहा है वह एक प्रचार है। यह खत्म हो जाएगा और कई वेब ऐप फिर से एक सर्वर-साइड UI आर्किटेक्चर का उपयोग करेंगे।

— जोएरी सेब्रेट्स
स्रोत

क्या, प्रचार? -1 सौभाग्य यह है कि जब विंडोज 8 जेएस को प्रथम श्रेणी का नागरिक बनाता है। हां, सर्वर-साइड UI आर्किटेक्चर नोड में लिखे गए हैं। शायद। हमें इसे सीखने की आवश्यकता है क्योंकि यह गैर-अवरुद्ध है।

— जैक स्टोन

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

— एरिक रेपेन

6

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

— Carson63000
स्रोत

अच्छी तरह से कहा ... +1।

— जैक स्टोन

बहुत अच्छी बात है।

— ब्रूनो शेपर

4

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

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

यही कारण हैं कि अस्थिरता के बावजूद, क्लाइंट-साइड प्रौद्योगिकियां अधिक लोकप्रियता प्राप्त कर रही हैं। इसके अलावा, JS और HTML / CSS सभी आधुनिक ब्राउज़रों द्वारा समर्थित (लगभग) हैं।

अनुप्रयोगों के ये दो भाग अलग से मौजूद नहीं हो सकते हैं। और इंटरनेट निकट भविष्य में कहीं भी नहीं लगता है।
मुझे नहीं लगता है कि big server-side frameworksया तो गायब होने की संभावना है। हमेशा ऐसी कंपनियां होंगी जो उन्हें वहन कर सकती हैं, और अपने महत्वपूर्ण लाभों का उपयोग करेंगी।

— Superm
स्रोत

4

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

इस समस्या को ठीक करने के लिए कुछ समाधान हैं। उदाहरण के लिए यदि आप jquery का उपयोग करते हैं तो आपको आश्वासन मिलता है कि आपकी स्क्रिप्ट इस विशेष jquery लाइब्रेरी द्वारा समर्थित ब्राउज़र पर काम करेगी। लेकिन यह केवल कुछ / सबसे / सभी ब्राउज़रों के साथ संगतता प्रदान करने के लिए इसके लेखकों पर निर्भर है। सवाल यह है कि कौन सी टीम आपका बेहतर समर्थन करेगी। क्या यह मोटल्स टीम, jquery टीम, अन्य टीम होगी? यदि वे किसी विशेष वेब ब्राउज़र को सहायता प्रदान नहीं करते हैं, तो आपकी परियोजना उस ब्राउज़र में काम नहीं कर सकती है।

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

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

— आंद्रेज बोबाक
स्रोत

1

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

— ब्रूनो शापर

1

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

— ब्रूनो स्कैपर

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

— Andrzej बोबाक

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

— ब्रूनो स्कैपर

-1

आपकी भावनाओं से बिल्कुल सहमत हैं। मैं यह भी मानता हूं कि आप जो कह रहे हैं, उससे परे हम रेस्ट में एक नाटकीय गिरावट देखने के लिए जा रहे हैं और वेबसैट में बड़े पैमाने पर उतार-चढ़ाव हो रहे हैं, जिस तरह से हम देखते हैं कि साइटें अपने सर्वर पर वापस संचार करती हैं। Vert.x, Node.js आदि .. संपूर्ण सर्वर साइड, साथ ही क्लाइंट साइड, इवेंट संचालित प्रोग्रामिंग के लिए आगे बढ़ रहा है। जावा ईई, पीएचपी, रेल, आदि .. इन सभी को अनुकूलित करने की आवश्यकता है या वे बहुत जल्दी खो देंगे।

— कोडिंग
स्रोत

स्पष्टीकरण के बिना, यह उत्तर उस स्थिति में बेकार हो सकता है जब कोई अन्य व्यक्ति अलग राय रखता है। उदाहरण के लिए, यदि कोई दावा करता है जैसे "हम REST में एक नाटकीय गिरावट और वेबसोकेट्स में भारी उतार-चढ़ाव नहीं देखेंगे", तो यह उत्तर पाठक को इन भिन्न रायों को चुनने में कैसे मदद करेगा? विचार को बेहतर आकार में संपादित करें

— gnat