दुनिया में कई गेम इंजन हैं: अवास्तविक इंजन, यूनिटी इंजन, गोडोट इंजन, क्राई इंजन, और बहुत कुछ।

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

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

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

"मुफ़्त दोपहर के भोजन जैसी कोई चीज़ नहीं है।"
"ऐसा कोई उपकरण नहीं है जो सब कुछ कर सके।"

रिएक्ट सिर्फ एक विकास उपकरण है, और इसकी अपनी सीमाएं हैं।

डेवलपर्स द्वारा रिएक्ट का उपयोग करने का प्राथमिक कारण उत्पादकता है। रिएक्ट इस प्रश्न के साथ बनाया गया था, "हम वेब विकास में DOM घटकों को अधिक कुशलता से कैसे विकसित कर सकते हैं?" रिएक्ट के दृष्टिकोण के केंद्र में DOM है। ठीक उसी तरह जैसे स्वचालित सुविधाओं का आम तौर पर अनुकूलन की कमी होती है, जिस "उत्पादकता" के बारे में वे बात करते हैं उसका अक्सर मतलब होता है "आप वर्चुअल DOM के माध्यम से ब्राउज़र के साथ मजबूती से जुड़े रेंडरिंग लूप को संशोधित नहीं कर सकते।"

रिएक्ट के साथ पहला प्रमुख मुद्दा DOM है। हर चीज़ DOM के इर्द-गिर्द नहीं घूमती, और हर प्रोग्राम पूरी तरह से इसके इर्द-गिर्द संचालित नहीं होता। फिर भी, रिएक्ट DOM को अपने दर्शन के मूल में रखता है। JSX सिंटैक्स, जहां प्रत्येक घटक कुछ "HTML एलिमेंट जैसा" लौटाता है, इस मानसिकता को स्पष्ट रूप से दर्शाता है।

दूसरा मुद्दा वर्चुअल DOM है। यहां बताया गया है कि वर्चुअल DOM कैसे काम करता है:

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

सवाल यह है कि एचपीएसई सबसे पहले ऐसी प्रणाली क्यों अपनाएगा? इस चिंता के अलावा कि यह प्रतिपादन दृष्टिकोण विभिन्न एचपीएसई आवश्यकताओं को संबोधित नहीं कर सकता है, बड़ी चिंता इस संदर्भ में इसकी वास्तविक उपयोगिता की कमी है।

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

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

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

रिएक्ट में घटकों में परिवर्तन वर्चुअल DOM के माध्यम से होना चाहिए, और वर्चुअल DOM को फाइबर आर्किटेक्चर द्वारा प्रबंधित किया जाता है, जो विशिष्ट प्राथमिकता नियमों का पालन करता है। हालाँकि, एचपीएसई की वास्तविक समय प्रदर्शन या सटीक समय की मांगों को पूरा करने के लिए रिएक्ट के आंतरिक कार्यों को कैसे अनुकूलित किया जाए, इस पर बहुत कम दस्तावेज हैं। ऐसा लगता है कि एक ऐसे इंजन के साथ AAA गेम विकसित किया जा रहा है जिसे अनुकूलित नहीं किया जा सकता।

"परेशान क्यों होना?"

यह एक ऐसा प्रश्न है जो सामने आता रहता है।

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

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

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

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

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

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