रनटाइम प्रदर्शन के दृष्टिकोण से, मुझे इसमें दिलचस्पी है

साथ ही एसेम्बलीस्क्रिप्ट जैसे प्रायोगिक उपकरण स्रोत कोड के कुछ बहुत ही प्रदर्शन आलोचक भागों के लिए एक विकल्प बन सकते हैं

मैं तीन.जेएस कोर + डब्ल्यूएएसएम प्रयोग कर रहा हूं।

https://github.com/takahirox/three.wasm-experimental
https://twitter.com/superhoge/status/1071132448426262529

प्रयोग से मैंने महसूस किया कि पूरे कोर को WASM में पोर्ट करने से रनटाइम प्रदर्शन में सुधार हो सकता है, मेरे उदाहरण पर 1.5x तेज, जबकि छोटे भागों को आंशिक रूप से पोर्ट करना, उदाहरण के लिए केवल मैथ कोड (वेक्टर 3, मैट्रिक्स 4, ...), कोई लाभ नहीं है क्योंकि बड़े JS-WASM ओवरहेड का।

लेकिन मुझे नहीं लगता था कि रखरखाव की कठिनाई के कारण योगदानकर्ताओं के लिए संपूर्ण थ्री.जेएस कोर को सी ++ या रस्ट में फिर से लिखना एक अच्छा विचार है, इसलिए मैं वैकल्पिक तरीकों की तलाश कर रहा हूं। मुझे इसमें दिलचस्पी है कि अगर टाइपस्क्रिप्ट + असेंबलीस्क्रिप्ट तीन.जेएस के लिए ठीक काम करता है।

कैसे शुरू करें? क्या हमें पहले केवल d.ts फाइलों के साथ शुरुआत करनी चाहिए या पूरी तरह से टाइपस्क्रिप्ट में कूदना चाहिए?

हम एक पीआर सबमिट करेंगे जो थ्री.जेएस में *.d.ts फाइलें जोड़ता है, जो मुख्य रूप से @types/three (इस प्रकार उस काम का पुन: उपयोग) पर आधारित है। यह एक महान प्रारंभिक बिंदु है और हमें अभी के लिए JS में जारी रखने देता है। इसे क्रमिक रूप से भी किया जा सकता है।

@takahirox अच्छा काम :-) मैं हमेशा रोमांचित हूं कि

@bhouston मुझे यकीन नहीं है कि d.ts फ़ाइलों को @types/three से three रेपो में ले जाना बहुत समझ में आता है। विशेष रूप से क्योंकि ये d.ts फाइलें टाइपस्क्रिप्ट फाइलों से उत्पन्न हो सकती हैं और फिर वे हमेशा सिंक में रहती हैं। क्या यह आश्वस्त करने का कोई तरीका है कि d.ts फाइलें हमेशा स्वचालित तरीके से जेएस-फाइलों के साथ समन्वयित होती हैं? यदि हाँ तो मुझे लगता है कि d.ts फाइलों को three रेपो में डालना फायदेमंद हो सकता है। साथ ही मुझे लगता है कि यह अनुरक्षकों के निर्णय पर निर्भर करता है। यदि वे टाइपस्क्रिप्ट को नहीं अपनाना चाहते हैं, तो d.ts फाइलें भी एक विकल्प हो सकती हैं। इसके अलावा अगर उन्होंने कुछ वर्षों में टाइपस्क्रिप्ट जोड़ने का फैसला किया तो हम इस बार d.ts फाइलों के साथ पुल कर सकते हैं। नहीं तो मुझे डर है कि फायदा कम और काम ज्यादा है। लेकिन शायद मैं कुछ देख रहा हूँ

@bhouston मुझे यकीन नहीं है कि d.ts फ़ाइलों को @ प्रकार/तीन से तीन रेपो में ले जाना बहुत समझ में आता है। विशेष रूप से क्योंकि ये d.ts फाइलें टाइपस्क्रिप्ट फाइलों से उत्पन्न की जा सकती हैं और फिर वे हमेशा सिंक में रहती हैं।

अगर हम सीधे टाइपस्क्रिप्ट में चले जाते हैं तो *.d.ts फाइलों की कोई आवश्यकता नहीं होगी। मुद्दा यह है कि वर्तमान में @types/three प्रोजेक्ट हमेशा थ्री.जेएस के साथ पुराना है क्योंकि इसे अलग से बनाए रखा जाता है। इसके अलावा यह अलग-अलग फाइलों के बजाय तीन.जेएस की निर्मित संरचना को प्रतिबिंबित करता है और इस प्रकार पेड़ के हिलने और अनुकूलन के अन्य रूपों का समर्थन नहीं कर सकता है। इस प्रकार *.d.ts फाइलों को जोड़ने से परियोजना की वर्तमान स्थिति में काफी सुधार होता है, लेकिन यह सीधे *.ts फाइलों की ओर बढ़ने जितना अच्छा नहीं है।

अगर हम सीधे *.ts फाइलों की ओर जा सकते हैं, तो यह बेहतर विकल्प है। मुझे यकीन नहीं था कि इसके लिए समर्थन था।

मैं थ्री को समझता हूं। जेएस चीजों को वृद्धिशील रूप से करना पसंद करता है, इस प्रकार यह एक बड़े धमाके के बजाय एक वृद्धिशील विकल्प था।

@bhouston मैं https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html

लेकिन टाइपस्क्रिप्ट से कैसे संपर्क किया जाए, यह किसी एक अनुरक्षक द्वारा तय किया जाना चाहिए। मुझे लगता है कि दोनों विकल्प ( d.ts फाइलें या टीएस और जेएस फाइलों को मिलाकर) संभव हैं। और यह कमोबेश व्यक्तिगत प्राथमिकताओं और शैली का सवाल है।

@tschoartschi मैं इस मुद्दे को आगे बढ़ाना चाहता हूं। @mrdoob ने साथ-साथ *.d.ts फाइलों को मंजूरी दी है। मैं वहां जाना चाहता हूं क्योंकि यह टाइपस्क्रिप्ट को लोगों पर तुरंत लागू नहीं करता है और हम *.ts चरण के दौरान सभी योगदानों को फिर से लिखे बिना इससे बाहर निकल सकते हैं। और फिर हम अभी भी *.js फाइलों को *.ts फाइलों में परिवर्तित कर सकते हैं, ज्यादातर मेरे द्वारा उन्हें साथ-साथ *.d.ts फाइलों के साथ मर्ज किया जा रहा है।

मुझे लगता है कि साथ-साथ *.d.ts फ़ाइलें वास्तव में एक अच्छा पहला कदम है और इसे करना आसान है। मैं "पूर्णता" को हमें वृद्धिशील प्रगति करने से रोकने की अनुमति नहीं देना पसंद करूंगा।

@bhouston कूल मैं भी मदद कर सकता था। मुझे लगता है कि यह समझ में आता है कि आप शुरू करते हैं और अन्य और मैं फिर इसमें शामिल हो सकता हूं। हो सकता है कि हम @types/three के अनुरक्षकों से भी बात कर सकें। क्या हमें Three.js कार्यक्षेत्र में एक स्लैक चैनल बनाना चाहिए? इसलिए हम जल्दी से संरेखित कर सकते हैं और इस मुद्दे को चैट जैसी बातचीत से प्रदूषित नहीं कर सकते हैं। फिर भी, मैं एक पल का इंतजार करूंगा जब तक

एक बार @mrdoob से आशीर्वाद मिलने के बाद मैं बंदरगाह के लिए समय देने को तैयार हूं।

जब तक ब्राउज़र मूल रूप से टाइपस्क्रिप्ट का समर्थन नहीं करते, मैं जावास्क्रिप्ट ES6 पर ध्यान केंद्रित करना पसंद करता हूं।

मैं समझता हूं कि इसे .js में संकलित किया जा सकता है, लेकिन हम सीधे src से आयात करने में सक्षम होना शुरू कर रहे हैं और मुझे लगता है कि यह प्रोजेक्ट को टाइपस्क्रिप्ट में बदलने से अधिक मदद करने वाला है।

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L37 -L48

साथ-साथ *.d.ts फ़ाइलें जोड़ना अच्छा लगता है, लेकिन इसके लिए किसी ऐसे व्यक्ति की आवश्यकता होगी जो इसका स्वामी हो और उन्हें अद्यतित रखे।

@mrdoob मुझे नहीं लगता कि टाइपस्क्रिप्ट का समर्थन करने के लिए ब्राउज़र की प्रतीक्षा करना एक विकल्प है। मैंने टाइपस्क्रिप्ट को लागू करने के लिए किसी भी ब्राउज़र विक्रेता का कोई इरादा नहीं सुना। लेकिन मैं आपकी चिंताओं को देखता हूं, खासकर उदाहरणों के साथ। मैंने नए उदाहरणों पर एक नज़र नहीं डाली। यह कमाल है कि उदाहरणों में केवल स्रोत फ़ाइलों को आयात करना संभव है।

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

three/
├── src/
    ├── cameras
        ├── PerspectiveCamera.ts // authored code
        ├── PerspectiveCamera.js // generated code by TS compiler

फिर भी यह मेरे लिए थोड़ा अजीब लगता है क्योंकि पारदर्शी कोड कहीं dist , build या bin फ़ोल्डर में जाना चाहिए। लेकिन यह सिर्फ एक राय है न कि एक कठिन तथ्य। हो सकता है कि कुछ टाइपस्क्रिप्ट गीक्स हों जो एक अच्छा समाधान जानते हों।

दूसरा विकल्प @bhouston द्वारा सुझाई गई d.ts फ़ाइल है। लेकिन जैसा कि @mrdoob ने उल्लेख किया है कि d.ts फ़ाइलों को अद्यतित रखना मुश्किल हो सकता है। खासतौर पर लॉन्ग टर्म व्यू पर। क्या उन्हें अगले वर्षों तक अद्यतित रखना वाकई प्रबंधनीय है? मैं d.ts फ़ाइलों को सेट करने में मदद कर सकता हूं लेकिन मैं इस बात की गारंटी नहीं दे सकता कि मैं उन्हें हर समय अपडेट करने में शामिल रहूंगा। मेरे लिए वन-टाइम-स्लॉट को ब्लॉक करने और कुछ काम करने की तुलना में लगातार समय देना बहुत कठिन है। मुझे अभी भी यकीन नहीं है कि @types/three प्रोजेक्ट का समर्थन करना बेहतर है या d.ts फाइलों को सीधे three प्रोजेक्ट में जोड़ना बेहतर है। @types/three प्रोजेक्ट पहले से ही काम कर रहा है और d.ts दृष्टिकोण के समान आवश्यकताओं को पूरा करता है। इसमें भी इसी तरह की चुनौतियां हैं। जो मूल रूप से चीजों को अप टू डेट रख रहा है।

तो मेरा निष्कर्ष यह है कि यह मध्यावधि भविष्य में थ्री.जेएस में टाइपस्क्रिप्ट के लिए बहुत अच्छा नहीं लग रहा है। मेरे लिए यह ठीक है, हालांकि मुझे और टाइपस्क्रिप्ट अपनाने को देखना अच्छा लगेगा।

बस एक और सुझाव:
फेजर गेम फ्रेमवर्क अपनी टिप्पणियों का उपयोग ऑटो प्रकार की परिभाषाओं को उत्पन्न करने के लिए करता है। मुझे लगता है कि उपकरण ओपनसोर्स है। तो TS परिभाषाएँ कार्यों के ऊपर /** टिप्पणियाँ */ को सही तरीके से जोड़कर उत्पन्न की जा सकती हैं।

फेजर गेम फ्रेमवर्क अपनी टिप्पणियों का उपयोग ऑटो प्रकार की परिभाषाओं को उत्पन्न करने के लिए करता है ...

https://github.com/mrdoob/three.js/issues/11550 और https://github.com/mrdoob/three.js/issues/4725#issuecomment -41833647 देखें।

हालांकि, *.d.ts फाइलों में टिप्पणियों से दस्तावेज तैयार करना दिलचस्प हो सकता है। मैं

साथ-साथ *.d.ts फ़ाइलें जोड़ना अच्छा लगता है, लेकिन इसके लिए किसी ऐसे व्यक्ति की आवश्यकता होगी जो इसका स्वामी हो और उन्हें अद्यतित रखे।

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

यह परियोजना भी है https://github.com/semleti/three.ts
शायद एक नया शुरू करने के बजाय इसे देखने और इसे v100 तक लाने के लायक है?
क्योंकि मुझे टाइपस्क्रिप्ट में थ्री.जेएस को फिर से लिखा हुआ नहीं दिख रहा है, जब तक कि यह स्पष्ट न हो कि इतने बड़े प्रोजेक्ट के लिए टाइप के साथ काम करना कितना अच्छा है ... और मैं अच्छी तरह से समझता हूं कि ऐसा कभी क्यों नहीं हो सकता है क्योंकि यह एक भाषा पर निर्भर होगा। जो ब्राउज़र के अंदर मानक नहीं है।

@schoening मैंने यह चर्चा इसलिए शुरू की क्योंकि @flyover द्वारा किया गया है (https://github.com/flyover/three.ts, https://github.com/mrdoob/three.js/issues/11552#issuecomment-367026821) . एक फोर्कड थ्री.टीएस संस्करण के साथ मुख्य समस्या अप-टू-डेट रहना है। सभी रेपो कुछ संस्करण पीछे हैं और मुझे लगता है कि यह उन सभी परियोजनाओं के साथ होगा जिन्हें "कोर" -टीम द्वारा बनाए रखा नहीं जाता है। अगर Three.js प्रोजेक्ट टाइपस्क्रिप्ट का समर्थन नहीं करेगा, तो मुझे लगता है कि @types/three प्रोजेक्ट को सिंक में रहने में मदद करना सबसे अच्छा है। मुझे लगता है कि हमें वहां सेना में शामिल होना चाहिए।

यदि दूर भविष्य में किसी बिंदु पर Three.js टाइपस्क्रिप्ट का समर्थन करने जा रहा है, तो यह सोचना बहुत अच्छा होगा कि ऐसा संक्रमण कैसे सफल हो सकता है। जैसा कि @donmccurdy ने उल्लेख किया है कि बेहतर टाइपस्क्रिप्ट संगतता प्राप्त करने के लिए कई दृष्टिकोण हैं। मुझे लगता है कि JSDoc एक व्यवहार्य दृष्टिकोण हो सकता है। मैं अभी भी *.d.ts फाइलों से आश्वस्त नहीं हूं क्योंकि मुझे लगता है कि उन्हें JSDoc टिप्पणियों की तुलना में अद्यतित रखना और भी कठिन है। साथ ही मुझे नहीं लगता कि *.d.ts फाइलों के साथ प्रोग्रामेटिक रूप से स्रोत के खिलाफ जांच करने का कोई तरीका है। लेकिन हो सकता है कि @bhouston अपने दृष्टिकोण को रेखांकित कर सके, विशेष रूप से चीजों को अप-टू-डेट रखने की चिंता। हो सकता है कि इस समस्या के कुछ स्मार्ट समाधान हों।

मेरे लिए अब तक का सबसे अच्छा अनुभव vscode + d.ts + JSDoc, सभी एक ही प्रोजेक्ट में हैं, इसलिए सिंक में रहना आसान है।

नवीनतम बनाम कोड संस्करण ने checkJs समर्थन में सुधार किया है ( tsconfig.json में सक्षम किया जा सकता है), जो मूल रूप से टाइपस्क्रिप्ट कंपाइलर जावास्क्रिप्ट फाइलों की जांच कर रहा है, जेएसडीओसी के प्रकारों का उपयोग करके प्लस घोषणा d.ts से विलय कर रहा है अधिक "उन्नत" प्रकारों के लिए, जो JSDoc सिंटैक्स में बदसूरत होगा।

चूंकि vscode सभी प्रकार की त्रुटियों का पता लगा सकता है, इसलिए जब भी रिफैक्टरिंग की जाती है, तो "बग्गी/पुराने" प्रकारों को d.ts से देखना और संपादित करना आसान होता है, इसलिए इसे सिंक किया जा रहा है .

टाइपस्क्रिप्ट के बारे में सबसे बुरी बात अतिरिक्त पारदर्शी कदम है, जिसमें प्रत्येक कोड परिवर्तन के लिए कुछ सेकंड लग सकते हैं। संक्षेप में, JSDoc + d.ts vscode में प्रकार के सभी फायदे हैं, लेकिन अतिरिक्त धीमे ट्रांसपाइल चरण के नकारात्मक पक्ष नहीं हैं।

केवल समस्या हर चीज में 100% उचित JSDoc प्रकार जोड़ने की है, इसलिए vscode इस पर भरोसा कर सकता है (बस सामान जैसे @constructor , <strong i="16">@enum</strong> {number} , <strong i="18">@param</strong> {number} n Number of steps )

मैं यहां यह भी जोड़ना चाहता हूं कि @bhouston और @LuWangThreekit ने *.d.ts फाइलों के लिए एक पीआर बनाया। अधिक जानकारी के लिए उनका नोट देखें: https://github.com/mrdoob/three.js/issues/11552#issuecomment -454881060 और/या उनके पीआर https://github.com/mrdoob/three.js/pull/ 15597

Sidenote: टाइपप्रति ब्राउज़रों में नहीं हो सकता है दूर करता है, तो Deno (ए टाइपप्रति दुभाषिया GitHub पर 32,000 सितारों के साथ वी 8 और जंग पर बनाया गया) योग्य साबित होता है।

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

टाइपस्क्रिप्ट में रुचि रखने वाले किसी भी व्यक्ति के लिए...

यह तीन.जेएस -प्रेरित पुस्तकालय

https://threeify.org/

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

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

मुझे लगता है कि @pailhead ने विभिन्न तीन.जेएस संस्करणों के साथ काम करना । इसलिए मुझे लगता है कि समुदाय में ऐसे लोग हैं जो उन कुछ चीजों को अपनाने में मदद करना चाहते हैं जिन्हें थ्रीफाई लागू करने की कोशिश करता है। मुझे लगता है कि एक नया पुस्तकालय बनाने के बजाय बलों में शामिल होना और तीन.जेएस में सुधार करना बहुत अच्छा होगा।

इंटरनेट पर कई लेखों की तरह, पेलहेड का लेख पक्षपाती है। पुस्तकालय के अन्य उपयोगों को ध्यान में नहीं रखता है।

मुझे नहीं लगता कि एक पुस्तकालय बनाना संभव है जो एक दूसरे के विकास वर्कफ़्लो को बाधित किए बिना सभी प्रकार के जेएस डेवलपर्स को पूरा करता है।

हमारे पास @pailhead के समान ही अनुभव हैं, मुझे नहीं लगता कि उनका कार्यप्रवाह एक विशिष्ट कार्यप्रवाह है। मुझे लगता है कि Vue , Ember , React , Svelte , Angular ... जैसे आधुनिक फ्रंट-एंड फ्रेमवर्क के साथ काम करने वाले डेवलपर्स के लिए उनका वर्कफ़्लो बहुत आम है ...

शायद हमें यह देखना चाहिए कि Vue इसे कैसे कर रहा है। इसमें PHP प्रोग्रामर से लेकर उपयोगकर्ता-आधार है जो परिष्कृत वेब ऐप विकसित करने वाले लोगों के लिए अपनी वेबसाइट को बढ़ाना चाहते हैं। यह उन विभिन्न प्रकार के उपयोगकर्ताओं के बीच वक्र को बहुत अच्छी तरह से मोड़ता है।

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

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

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

@mrdoob , कुछ डेटा एकत्र करने के लिए सर्वेक्षण के बारे में क्या? टाइपस्क्रिप्ट का उपयोग एक बात है और मुझे यकीन है कि अन्य गुणात्मक चर हैं जिन पर हम अनुमान लगाने का प्रयास कर सकते हैं।

@ रूमल-बिल्ड क्या आप लाइब्रेरी को टाइपस्क्रिप्ट में बदलने के नुकसान को सूचीबद्ध कर सकते हैं?

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

• हम गैर-टीएस-उपयोगकर्ताओं के लिए एक अच्छा अनुभव कैसे प्रदान कर सकते हैं?
• बिना बिल्ट-स्टेप के उपयोगकर्ता पुस्तकालय का उपयोग कैसे कर सकते हैं?
• और निश्चित रूप से अन्य सभी चीजें जिनके बारे में मैंने नहीं सोचा था

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

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

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

मैं विखंडन का प्रशंसक नहीं हूं और मुझे लगता है कि एक दूसरे के खिलाफ काम करने की तुलना में एक साथ काम करना बेहतर है।

वेब में अधिक 3D इंजन होने का मतलब यह नहीं है कि डेवलपर्स एक दूसरे के खिलाफ काम कर रहे हैं। कभी-कभी यह वास्तव में बेहतर होता है यदि विभिन्न परियोजनाएं अलग-अलग चीजों पर ध्यान केंद्रित करती हैं।

मुझे लगता है कि three.js के सबसे बड़े फायदों में से एक इसकी पहुंच है। @ रूमले-बिल्ड ने जिन बिंदुओं को सूचीबद्ध किया है, वे इंजन के उपयोग में आसानी को खराब कर देंगे (विशेषकर शुरुआती के संदर्भ में)।

मैं इसे इस तरह से नहीं देखता क्योंकि अन्य प्रोजेक्ट एक्सेसिबिलिटी पर किसी भी प्रभाव के बिना टाइपस्क्रिप्ट में अपना कोड लिखते हैं। मैंने पहले उदाहरण के रूप में Vue और Ember का उल्लेख किया था। शायद टाइपस्क्रिप्ट के खिलाफ रुख की समीक्षा करना समझ में आता है? हमें कुछ का आविष्कार करने की आवश्यकता नहीं होगी, हमें केवल अन्य परियोजनाओं के सफल दृष्टिकोणों की नकल करने की आवश्यकता होगी। इसके अलावा, मुझे लगता है कि टाइपस्क्रिप्ट का यह लाभ होगा कि three.js योगदानकर्ताओं के लिए अधिक सुलभ होगा क्योंकि आईडीई उन्हें पूरी परियोजना का तेजी से अवलोकन करने में मदद कर सकता है।

मैं जावास्क्रिप्ट का उपयोग जारी रखने के लिए वोट करता हूं जब तक कि ब्राउज़र में वैकल्पिक प्रोग्रामिंग भाषा मूल रूप से समर्थित न हो।

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

मुझे लगता है कि हमने अपनी स्थिति स्पष्ट कर दी है।