वास्तव में "उच्च-प्रदर्शन वेब ऐप" या "फ्रंटएंड" क्या है?

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

लेकिन जैसा कि हर गेम एएए नहीं है, हमें वेब ऐप्स पर चर्चा करते समय ध्यान से विचार करना चाहिए कि "उच्च-प्रदर्शन" से हमारा क्या मतलब है। यह अंतर आज के विषय के लिए महत्वपूर्ण है।

1. उच्च-प्रदर्शन वेब ऐप्स का दायरा

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

हालांकि, ऐसे वेब ऐप्स हैं जो WASM मॉड्यूल की मेमोरी सीमा के सभी 4 जीबी का उपयोग करते हैं, व्यवस्थित मेमोरी प्रबंधन को ध्यान में रखकर बनाए गए हैं, और ब्लेंडर या 3डी मैक्स जैसे मूल कार्यक्रमों के बराबर प्रदर्शन का लक्ष्य रखते हैं। ये ऐप्स एसईओ के लिए अनुकूलित पारंपरिक "वेब पेज" के बजाय "प्रोग्राम" की अवधारणा के साथ अधिक संरेखित होते हैं जो ब्राउज़र टैब के प्रत्येक संसाधन का उपयोग करते हैं।

हालाँकि वर्तमान ब्राउज़र वातावरण अभी भी मेमोरी सीमा और ओवरहेड के कारण देशी जैसा प्रदर्शन देने में संघर्ष कर सकता है, ऐसे ऐप्स के लक्ष्य मौलिक रूप से भिन्न हैं। वे बड़े डेटासेट को संभालते हैं और उच्चतम रेंडरिंग गति का अनुसरण करते हुए, पूरी 2-4GB मेमोरी का उपयोग करने का लक्ष्य रखते हैं।

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

शुरुआत में उल्लिखित "उच्च-प्रदर्शन वेब ऐप" और जिसका मैं यहां वर्णन कर रहा हूं वे अपने पथ में मौलिक रूप से भिन्न हैं। उन्हें एक ही शब्द में एक साथ रखना समस्याग्रस्त होगा। इन अंतरों को प्रतिबिंबित करने के लिए हमें अलग-अलग शब्दावली की आवश्यकता है।

इसलिए मेरा प्रस्ताव है कि हम बाद वाले को "उच्च-प्रदर्शन वेब ऐप" या "फ्रंटएंड" के रूप में संदर्भित करना बंद कर दें और इसके बजाय निम्नलिखित शब्दों का उपयोग करें:

• ब्राउज़र-आधारित हाई-परफॉर्मेंस फ्रेमवर्क इंजीनियरिंग (बीबीएचपीएफई)
• (ब्राउज़र-आधारित) हाई-परफॉर्मेंस सिस्टम इंजीनियरिंग (एचपीएसई)

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

[बातचीत 1]

ए: "मैं एक फ्रंटएंड ऐप विकसित कर रहा हूं लेकिन रिएक्ट का उपयोग नहीं कर रहा हूं।"
बी: "रिएक्ट के बिना एक फ्रंटएंड ऐप? फ्रंटएंड में रिएक्ट की 60% से अधिक बाजार हिस्सेदारी है! आप इसका उपयोग क्यों नहीं करेंगे?"

[बातचीत 2]

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

अब, आइए उन आवश्यक घटकों पर चर्चा करें जो एक एचपीएसई में होने चाहिए।

2-1. मेमोरी प्रबंधन
आप स्मृति को संबोधित किए बिना उच्च-प्रदर्शन कार्यक्रमों के बारे में बात नहीं कर सकते। चाहे कचरा संग्रहकर्ता का उपयोग करना हो या गतिशील रूप से आवंटित मेमोरी को मैन्युअल रूप से मुक्त करना हो, अप्रयुक्त मेमोरी को हमेशा मुक्त किया जाना चाहिए।

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

यदि पुराने डेटा के संदर्भ ठीक से जारी नहीं किए गए हैं, तो प्रत्येक मानचित्र परिवर्तन के साथ मेमोरी का उपयोग बढ़ता रहेगा। एक बार जब यह लगभग 2GB तक पहुंच जाता है, तो आपको "आउट ऑफ़ मेमोरी" त्रुटि का सामना करना पड़ सकता है, और ब्राउज़र क्रैश हो जाएगा।

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

2-2. आवश्यकताओं को पूरा करने में लचीलापन
मैंने एक बार किसी को यह कहते हुए सुना था, "जब तक आप जूनियर डेवलपर से इंटरमीडिएट की ओर बढ़ते हैं, तब तक आपको अपनी इच्छानुसार कुछ भी बनाने में सक्षम होना चाहिए।"

जावास्क्रिप्ट पहले से ही कुछ अंतर्निहित सीमाओं (मेमोरी सीमाओं के अलावा) के साथ एक प्रभावशाली भाषा है। यदि आप कुछ बनाना चाहते हैं, तो संभवतः यह बनाया जा सकता है।

असली सवाल यह है कि क्या आपकी वर्तमान परियोजना वास्तव में विभिन्न प्रकार की आवश्यकताओं को समायोजित कर सकती है।

जिस तरह किसी कारखाने में मशीनें निरंतर संचालन के बाद खराब हो जाती हैं, उच्च-प्रदर्शन, अनुकूलित सुविधाओं का पीछा करने से अनिवार्य रूप से अप्रत्याशित चुनौतियों का सामना करना पड़ता है। जब ऐसा होता है, तो लचीलापन और अद्वितीय आवश्यकताओं को पूरा करने की क्षमता आवश्यक है।

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

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

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

2-3. अपरिहार्य वस्तु-उन्मुख दृष्टिकोण
बड़े पैमाने के कार्यक्रमों के साथ काम करते समय, एक चीज अपरिहार्य हो जाती है: ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (ओओपी)।

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

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

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

जिन डेवलपर्स ने बड़े पैमाने की परियोजनाओं में भाग लिया है, वे संभवतः OOP से परिचित हैं। यह OOP-आधारित विकास को सहयोग के लिए अनुकूल बनाता है।

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

निष्कर्ष रूप में, मेरा मानना ​​है कि वस्तु-उन्मुख सिद्धांतों को शामिल करते हुए एक बहु-प्रतिमान दृष्टिकोण, एचपीएसई के लिए आदर्श होगा।