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

केवल वेब के लिए ही नहीं, अनुप्रयोगों को विकसित करना एक रचनात्मक कार्य है। यह संभावना नहीं है कि कोई भी इस कथन के साथ बहस करेगा। और रचनात्मकता में सौंदर्य वैज्ञानिक ज्ञान में एक अभ्यास की तरह है - सच्चाई की एक कसौटी। लेकिन अगर वैज्ञानिक अभ्यास वस्तुनिष्ठ है और मापन पर आधारित है, तो सौंदर्य एक व्यक्तिपरक विषय है, यह इस बात पर निर्भर करता है कि कौन देख रहा है। तो मैंने सोचा, लेकिन व्यक्तिगत रूप से मेरे लिए एक सुंदर वेब एप्लिकेशन क्या है?

(केडीपीवी पर आंख मेरी नहीं है, आंख महिला है, लेकिन, आईएमएचओ, केडीपीवी पर महिला आंख पुरुष आंख की तुलना में अधिक उपयुक्त है, क्योंकि यह केडीपीवी है !)

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

और जब से आप कट के तहत गए, तो कृपया टिप्पणियों में सावधान रहें। आखिरकार, यदि आप किसी लेख को पढ़ना बंद कर सकते हैं, जैसा कि उसमें बताया गया है, तो वह आपको बुरा लगता है या यहाँ तक कि आपको बदसूरत लगता है, तो मुझे, एक लेखक के रूप में, सभी टिप्पणियों को पढ़ना होगा।

वास

प्रोटोकॉल

मुझे यह भी पता नहीं है कि यह मानदंड अलग से लिया जाना चाहिए या नहीं। वेब एप्लिकेशन वेब पर रहते हैं और वेब (प्रोटोकॉल) के नियमों का पालन करने के लिए मजबूर हैं। वेब पर मुख्य प्रोटोकॉल टीसीपी और आईपी ​​हैं । कई अन्य प्रोटोकॉल उन पर आधारित हैं, लेकिन वेब अनुप्रयोगों के लिए मैं HTTP को सबसे महत्वपूर्ण (या बल्कि, इसका टीएलएस- आधारित HTTPS एक्सटेंशन) मानता हूं । अर्थात्, HTTPS / TLS (HTTP के माध्यम से एक विकल्प के रूप में) के माध्यम से एक सुंदर वेब एप्लिकेशन उपलब्ध है, और अन्य प्रोटोकॉल (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, ...) प्रत्येक के साथ कम सुंदर बनाते हैं। वैकल्पिक रूप से समर्थित प्रोटोकॉल। एप्लिकेशन स्वयं इन अतिरिक्त प्रोटोकॉल का उपयोग करके बाहरी संसाधनों का उपयोग कर सकता है।

WebSocket के लिए , मेरे पास इस एप्लिकेशन के साथ प्रोटोकॉल का उपयोग करने के लिए पर्याप्त अनुभव नहीं है। यह सुंदर और आशाजनक दिखता है, लेकिन मैं यह नहीं कह सकता कि यह कितना स्थिर और व्यावहारिक है।

ब्राउज़रों

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

YAP

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

सर्वर साइड (Java, PHP, perl, python, C #, Ruby, ...) पर अधिक स्वतंत्रता है, लेकिन मुझे ऐसा लगता है कि यह सुंदर है जब सर्वर साइड और ब्राउज़र दोनों एक प्रोग्रामिंग भाषा - जावास्क्रिप्ट का उपयोग करते हैं। फिर भी, भाषा सोच को निर्धारित करती है , और समान विचारधारा वाली टीमें अधिक उत्पादक होती हैं।

मानवता

एक सुंदर वेब एप्लिकेशन उपयोगी होना चाहिए। उपयोगी, सबसे पहले, अंत उपयोगकर्ता के रूप में एक व्यक्ति के लिए। इसलिए, मैं वेब सेवाओं को एक सुंदर वेब एप्लिकेशन नहीं कह सकता। एक सामान्य व्यक्ति (वेब ​​डेवलपर नहीं) के लिए यह करना मुश्किल है। वेब सेवाएं अपने तरीके से सुंदर हैं,

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

रिवर्स स्केलेबिलिटी

एक बार, कार्यक्रमों को फ्लॉपी डिस्क पर, अब फ्लैश ड्राइव पर, या तुरंत वेब से डाउनलोड किया जा सकता है। एक नियमित अनुप्रयोग की प्रतिलिपि बनाना और इसे दूसरी मशीन पर चलाना एक तुच्छ कार्य है। वेब अनुप्रयोगों के साथ, स्थिति कुछ विशेष है। एक नेटवर्क एक वैश्विक वातावरण है जिसमें एक ही वेब एप्लिकेशन के क्लोन होने की आवश्यकता नहीं है। एक Facebook, Twitter, Instagram, Mail.ru या Yandex वेब पर पर्याप्त है। आपके पास एक ही विषयगत आला में अलग-अलग वेब एप्लिकेशन हो सकते हैं, लेकिन अलग-अलग दर्शकों (जैसे फेसबुक और Vkontakte, Mail.ru और Gmail, Google मैप्स और एज़्योर मैप्स) के साथ। इस तरह के वेब-अनुप्रयोगों की वैश्विक उपलब्धता सुनिश्चित करने के लिए हार्डवेयर संसाधनों की आवश्यकता है, आइए बताते हैं, गैर-तुच्छ ।

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

एक सुंदर वेब एप्लिकेशन न केवल ऊपर और चौड़ाई में (उपयोगकर्ताओं के लिए), बल्कि नीचे और (डेवलपर्स के लिए)।

"उभयचर"

आधुनिक वेब अनुप्रयोगों तक पहुँचने के लिए दो प्रकार के उपकरणों का उपयोग किया जाता है:

• कंप्यूटर (लैपटॉप, डेस्कटॉप);
• मोबाइल डिवाइस (स्मार्टफोन और टैबलेट);

कहीं क्षितिज पर एक और " चीजों का इंटरनेट " है, लेकिन अब तक।

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

मैं बदसूरत उभयलिंगीपन को बदसूरत मानता हूं, यह दो (एसईओ - तीन) कुर्सियों पर बैठने की कोशिश कर रहा है। श्रेया से फियोना के रूप में बेहतर - दिन के दौरान एक और रात में एक और। हाँ, और अधिक महंगा है। लेकिन बेहतर है।

क्रॉस के बंटवारे

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

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

हार्वर्ड वास्तुकला

हार्वर्ड आर्किटेक्चर , वर्तमान सत्तारूढ़ प्रिंसटन की गेंद के विपरीत, कोड और डेटा को अलग करना शामिल है। वास्तुकला ने उड़ान नहीं भरी, लेकिन विचार ही मुझे सुंदर लगता है। खासकर वेब एप्लिकेशन के लिए। कोई भी स्टैटिक्स (HTML / CSS / JS / Images / ...) कोड है। इसे कम से कम सर्वर साइड पर, कम से कम क्लाइंट साइड पर कैश किया जा सकता है। और डेटा REST / JSON (सुंदर) या SOAP / XML (थोड़ा कम सुंदर) है। या WebSockets / JSON (सबसे अच्छा विकल्प हो सकता है, लेकिन मैंने कोशिश नहीं की है)।

स्थानीयकरण

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

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

डेथ स्टार्स की जगह फोर्ज

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

अब DNS जैसी सेवा को देखें। जब रूट सर्वर लेट हो जाते हैं, तो पूरी दुनिया बुखार में होती है ।

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

सारांश

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

पढ़ने के लिए धन्यवाद।