من وجهة نظر أداء وقت التشغيل ، أنا مهتم به

يمكن أيضًا أن تصبح الأدوات التجريبية مثل AssemblyScript خيارًا لبعض الأجزاء الناقدة للأداء في شفرة المصدر

لقد كنت أقوم بتجربة Three.js core + WASM.

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

من التجربة التي أدركت أن نقل النواة بالكامل إلى WASM يمكن أن يحسن أداء وقت التشغيل ، أسرع بمقدار 1.5 مرة في المثال الخاص بي ، بينما نقل الأجزاء الصغيرة جزئيًا ، على سبيل المثال أكواد الرياضيات فقط (Vector3 ، Matrix4 ، ...) ، ليس مفيدًا لأنه من النفقات العامة الكبيرة JS-WASM.

لكنني لم أعتقد أنه من الجيد إعادة كتابة جوهر Three.js بأكمله إلى C ++ أو Rust للمساهمين بسبب صعوبة الصيانة ، لذلك كنت أبحث عن طرق بديلة. أنا مهتم بما إذا كان TypeScript + AssemblyScript يعمل بشكل جيد مع Three.js.

كيف تبدأ؟ هل يجب أن نبدأ في البداية فقط بملفات d.ts أم ننتقل بشكل كامل إلى TypeScript؟

سنقوم بإرسال PR الذي يضيف ملفات * .d.ts إلى Three.JS ، استنادًا بشكل أساسي إلى @ type / three (وبالتالي إعادة استخدام هذا العمل.) هذه نقطة بداية رائعة وتتيح لنا المتابعة في JS في الوقت الحالي. يمكن أيضًا أن يتم ذلك بشكل تدريجي.

takahirox عمل جميل :-) أنا دائمًا منبهر بمدى العمل المبتكر الذي يحدث حول Three.js. إنه لأمر مؤسف أن تحظى إثباتات هذه المفاهيم باهتمام أقل. أعتقد أيضًا أن إعادة كتابة كل شيء بلغة C ++ أو Rust ليس خيارًا. ربما يكون AssemblyScript ولكني لم أجرب AssemblyScript ، لذا يمكنني التحدث عما قرأته عن AssemblyScript. ولكن ربما يجب علينا التفكير في AssemblyScript أيضًا لأنني أفهم أنها مجموعة فرعية من TypeScript تقريبًا

bhouston لست متأكدًا مما إذا كان نقل ملفات d.ts من @types/three إلى الريبو three له معنى كبير. خاصةً لأنه يمكن إنشاء ملفات d.ts هذه من ملفات TypeScript ومن ثم تتم مزامنتها دائمًا. هل هناك طريقة للتأكد من أن ملفات d.ts متزامنة دائمًا مع ملفات js بطريقة آلية؟ إذا كانت الإجابة بنعم ثم أود أن أعتقد يضع d.ts الملفات إلى three الريبو يمكن أن تكون مفيدة. كما أعتقد أن ذلك يعتمد على قرار المشرفين. إذا لم يرغبوا في استخدام TypeScript ، فيمكن أن تكون ملفات d.ts خيارًا أيضًا. أيضًا إذا قرروا إضافة TypeScript في بعض السنوات ، فيمكننا سد هذه المرة بملفات d.ts . وإلا فإنني أخشى أن يكون هناك فائدة أقل ومزيد من العمل. لكن ربما أنا فقط أغفل شيئًا ما

bhouston لست متأكدًا مما إذا كان نقل ملفات d.ts من الأنواع @ / ثلاثة إلى الريبو الثلاثة منطقيًا جدًا. خاصةً لأنه يمكن إنشاء ملفات d.ts هذه من ملفات TypeScript ثم تكون دائمًا متزامنة.

إذا انتقلنا مباشرة إلى TypeScript ، فلن تكون هناك حاجة لملفات * .d.ts. تكمن المشكلة في أن مشروع @ أنواع / ثلاثة دائمًا ما يكون قديمًا دائمًا مع Three.JS لأنه يتم صيانته بشكل منفصل. كما أنه يعكس البنية المبنية لـ three.js بدلاً من الملفات الفردية ، وبالتالي لا يمكنه دعم اهتزاز الشجرة وأشكال التحسين الأخرى. وبالتالي فإن إضافة ملفات * .d.ts يحسن المشروع بشكل كبير من حالته الحالية ، لكنه ليس جيدًا مثل الانتقال إلى ملفات * .ts مباشرة.

إذا تمكنا من الانتقال إلى ملفات * .ts مباشرة ، فهذا هو الخيار الأفضل. لم أكن متأكدًا من وجود دعم لذلك.

أفهم أن شركة Three.JS تحب القيام بالأشياء بشكل تدريجي ، وبالتالي كان هذا خيارًا تدريجيًا وليس انفجارًا كبيرًا.

bhouston أتفق معك تمامًا. وأعتقد أيضًا أن إعادة كتابة الانفجار الكبير غير ممكن ، لذا نحتاج إلى اعتماده بشكل تدريجي. ولكن إذا قرأت مستندات TypeScript ، فيبدو أنه يمكننا الحصول على ملفات ts و js جنبًا إلى جنب. لذلك يمكننا البدء في تحويل الملفات الفردية إلى ts. لمزيد من التفاصيل ، يمكنك قراءة منشور المدونة هذا: https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html

ولكن كيفية التعامل مع TypeScript يجب أن يقررها أحد المشرفين. أعتقد أن كلا الخيارين (ملفات d.ts أو خلط ملفات ts و js) ممكنان. وهي بشكل أو بآخر مسألة تفضيلات شخصية وأسلوب.

tschoartschi أود وافقتmrdoob جنبا إلى جنب * .d.ts الملفات. أود الذهاب إلى هناك لأنه لا يفرض TypeScript على الأشخاص على الفور ويمكننا التراجع عنه دون الحاجة إلى إعادة كتابة جميع المساهمات أثناء مرحلة * .ts. وبعد ذلك لا يزال بإمكاننا تحويل ملفات * .js إلى ملفات * .ts بشكل تدريجي في الغالب لدمجها مع ملفات * .d.ts جنبًا إلى جنب.

أعتقد أن ملفات * .d.ts جنبًا إلى جنب هي خطوة أولى جيدة حقًا ومن السهل القيام بها. أفضل عدم السماح لـ "الكمال" بمنعنا من إحراز تقدم تدريجي.

bhouston رائع 😎 يمكنني أيضًا المساعدة. أعتقد أنه من المنطقي أن تبدأ أنت والآخرين ويمكنني بعد ذلك الانضمام. ربما يمكننا أيضًا التحدث إلى المشرفين على @types/three . هل يجب إنشاء قناة Slack في مساحة عمل Three.js؟ حتى نتمكن من المواءمة بشكل أسرع وعدم تلويث هذه المشكلة بمحادثات تشبه الدردشة. ومع ذلك ، سأنتظر لحظة حتى يضيف mrdoob وجهة نظره. لأنه إذا كان ضد TypeScript ، أعتقد أنه لا ينبغي لنا استثمار الوقت.

أنا على استعداد لتخصيص الوقت للميناء بمجرد أن يحصل هذا على مباركة منmrdoob.

حتى لا تدعم المتصفحات TypeScript محليًا ، أفضل التركيز على JavaScript ES6.

أتفهم أنه يمكن تجميعها إلى .js ، لكننا بدأنا للتو في الاستيراد من src مباشرة وأعتقد أن هذا سيساعد المشروع أكثر من التحويل إلى TypeScript.

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

تبدو إضافة ملفات * .d.ts جنبًا إلى جنب أمرًا جيدًا ولكنها ستحتاج إلى شخص ما لامتلاكها وتحديثها باستمرار.

mrdoob لا أعتقد أن انتظار المتصفحات لدعم TypeScript يعد خيارًا. لم أسمع أي نية من أي بائع متصفح لتطبيق TypeScript. لكني أرى مخاوفك ، خاصة مع الأمثلة. لم ألقي نظرة على الأمثلة الجديدة. إنه لأمر رائع أنه من الممكن فقط استيراد الملفات المصدر في الأمثلة.

لست متأكدًا من أفضل حل لتأليف المكتبة في TypeScript وما زلت تحتفظ بإمكانية استيراد JavaScript من src. بالطبع ، يمكننا تحويل ملفات TypeScript ومن ثم الحصول على ملف JavaScript المقابل جنبًا إلى جنب (وهو الإعداد القياسي لمترجم TypeScript) ولكن هذا قد يعقد أشياء مثل إصدار التعليمات البرمجية وما إلى ذلك.

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

ومع ذلك ، يبدو هذا محرجًا بعض الشيء بالنسبة لي نظرًا لأن الشفرة المنقولة يجب أن تنتقل في مكان ما إلى مجلد dist أو build أو bin . لكن هذا مجرد رأي وليس حقيقة صعبة. ربما يكون هناك بعض خبراء TypeScript الذين يعرفون حلاً أفضل.

الخيار الآخر هو ملف d.ts اقترحهbhouston. ولكن كما ذكر mrdoob ، قد يكون من الصعب الاحتفاظ بملفات d.ts محدثة. خاصة على المدى الطويل. هل من الممكن حقًا إبقائهم محدثين للسنوات القادمة؟ يمكنني المساعدة في إعداد ملفات d.ts لكن لا يمكنني ضمان أنني سأشارك في تحديثها طوال الوقت. بالنسبة لي ، فإن الالتزام بوقت مستمر أصعب بكثير من حظر فترة زمنية واحدة وإنجاز بعض الأشياء. ما زلت غير متأكد مما إذا كان من الأفضل دعم مشروع @types/three أم إضافة ملفات d.ts مباشرة إلى مشروع three . مشروع @types/three يعمل بالفعل ويخدم نفس الاحتياجات مثل نهج d.ts . كما أن لديها تحديات مماثلة. وهو في الأساس إبقاء الأمور محدثة.

لذا فإن استنتاجي هو أنه لا يبدو جيدًا جدًا بالنسبة إلى TypeScript في Three.js في المستقبل على المدى المتوسط. هذا جيد بالنسبة لي على الرغم من أنني أرغب في رؤية المزيد من اعتماد TypeScript.

مجرد اقتراح آخر:
يستخدم إطار لعبة Phaser تعليقاته لإنشاء تعريفات النوع تلقائيًا. أعتقد أن الأداة مفتوحة المصدر. لذلك يمكن إنشاء تعريفات TS بإضافة / ** تعليقات * / فوق الوظائف بالطريقة الصحيحة.

يستخدم إطار لعبة Phaser تعليقاته لإنشاء تعريفات الأنواع تلقائيًا ...

راجع https://github.com/mrdoob/three.js/issues/11550 و https://github.com/mrdoob/three.js/issues/4725#issuecomment -41833647.

على الرغم من أن إنشاء وثائق من التعليقات في ملفات *.d.ts قد يكون مثيرًا للاهتمام. 🤔

تبدو إضافة ملفات * .d.ts جنبًا إلى جنب أمرًا جيدًا ولكنها ستحتاج إلى شخص ما لامتلاكها وتحديثها باستمرار.

إذا كان من الممكن التحقق من الكتابة مقابل المصدر برمجيًا ، فأنا موافق على ذلك. إذا لم يكن الأمر كذلك ، وإذا لم نكن نخطط في النهاية لإعادة كتابة التعليمات البرمجية في TypeScript ، فلا أعتقد أنه من الجيد نقل الكتابة إلى المستودع. إذا كان هناك أي شيء ، فنحن أقل استعدادًا للاحتفاظ بها هنا - على الأقل يستخدم المشرفون الحاليون TypeScript بأنفسهم.

يوجد أيضًا هذا المشروع https://github.com/semleti/three.ts
ربما يستحق إلقاء نظرة وتقديمه إلى الإصدار v100 بدلاً من البدء بمظهر جديد؟
لأنني لا أرى إعادة كتابة Three.js في TypeScript ما لم يكن واضحًا مدى جمال العمل مع الأنواع لمثل هذا المشروع الضخم ... وأنا أفهم تمامًا لماذا قد لا يحدث أبدًا لأنه سيعتمد على لغة هذا ليس معيارًا داخل المتصفح.

schoening لقد بدأت هذه المناقشة نظرًا لوجود بعض إصدارات TypeScript لإثبات صحة المفهوم من Three.js. إنه الريبو الذي قمت بربطه ، أو الريبو الذي تم بواسطة @ type

إذا كانت Three.js ستدعم TypeScript في وقت ما في المستقبل البعيد ، فسيكون من الرائع التفكير في كيفية نجاح هذا الانتقال. كما ذكر donmccurdy ، هناك عدة طرق لتحقيق توافق أفضل مع TypeScript. أعتقد أن JSDoc يمكن أن يكون نهجًا قابلاً للتطبيق. ما زلت غير مقتنع بالملفات *.d.ts لأنني أعتقد أنه من الصعب تحديثها أكثر من تعليقات JSDoc. كما أنني لا أعتقد أن هناك طريقة للتحقق من المصدر برمجيًا باستخدام ملفات *.d.ts . لكن ربما يستطيع bhouston أن يلخص منهجه ، لا سيما المخاوف المتعلقة بإبقاء الأمور محدثة. ربما هناك بعض الحلول الذكية لهذه المشكلة.

أفضل تجربة بالنسبة لي حتى الآن هي vscode + d.ts + JSDoc ، كلها في نفس المشروع ، لذلك من السهل الاستمرار في المزامنة.

أحدث إصدار من vscode تحسن من دعم checkJs (يمكن تمكينه في tsconfig.json ) ، والذي هو أساسًا برنامج التحويل البرمجي TypeScript الذي يتحقق من ملفات JavaScript ، وذلك باستخدام أنواع من إعلان JSDoc plus الذي تم دمجه من d.ts للأنواع الأكثر "تقدمًا" ، والتي ستكون قبيحة في بناء جملة JSDoc.

نظرًا لأن vscode يمكنه اشتقاق جميع الأنواع ، فإنه يمكنه اكتشاف جميع أنواع أخطاء الكتابة أيضًا ، لذلك عند إجراء إعادة البناء ، من السهل رؤية أنواع "عربات التي تجرها الدواب / القديمة" وتعديلها من d.ts ، لذلك تستمر مزامنتها .

أسوأ شيء في TypeScript هو خطوة التحويل الإضافية ، والتي يمكن أن تستغرق بضع ثوانٍ لكل تغيير في الكود. باختصار ، JSDoc + d.ts في vscode لديه جميع مزايا الأنواع ولكن ليس الجانب السلبي لخطوة التحويل البطيء الإضافية.

المشكلة الوحيدة هي إضافة نوع JSDoc مناسب 100٪ لكل شيء ، لذلك يمكن أن يعتمد 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: قد لا يكون TypeScript في المتصفحات بعيدًا إذا ثبت أن Deno (مترجم من TypeScript مبني على V8 و Rust مع 32000 نجمة على GitHub) يستحق.

نظرًا لأننا أضفنا ملفات تعريف النوع للنواة والوحدات النمطية المعيارية ، أعتقد أنه من المقبول إغلاق المشكلة في الوقت الحالي. يجب أن تكون تجربة التطوير لمستخدمي TS أفضل بالتأكيد من العام الماضي.

لأي شخص مهتم بـ TypeScript ...

قد تكون هذه المكتبة المستوحاة من Three.jsbhouston هي ما تبحث عنه:

https://threeify.org/

Threeify منbhouston يبدو وكأنه المشروع الكبير 🤩 لها SemVer والاستخدامات الدلالي الإفراج. إنه مبني على قمة TypeScript ويبدو أن قيمه الأساسية هي أشياء مثل Tree Shaking و Small Build Files وما إلى ذلك. كل الأشياء التي يرغب الكثير منا في رؤيتها في Three.js أيضًا. لذا فأنا أقدر حقًا العمل الذي يدخل في Threeify 👍

bhoustonmrdoob ولكن هل من الضروري حقا لإنشاء مشروع جديد؟ هل يعقل تقسيم المجتمع؟ تمكنت العديد من أطر العمل الأمامية الكبيرة من القيام بالانتقال إلى أشياء مثل SemVer و TypeScript و Tree Shaking وما إلى ذلك دون تفرع من كودها ومجتمعها.

أعتقد أن pailhead كتب مقالًا مثيرًا للاهتمام حول العمل مع Three.js ، وأعتقد أنه كان كالتالي: العمل مع إصدارات three.js مختلفة . لذلك أعتقد أن هناك أشخاصًا في المجتمع يرغبون في المساعدة في تبني بعض الأشياء التي تحاول Threeify تنفيذها. أعتقد أنه سيكون من الرائع الانضمام إلى القوى وتحسين Three.js بدلاً من إنشاء مكتبة جديدة.

مثل العديد من المقالات على الإنترنت ، فإن مقال Pailhead متحيز. لا تأخذ بعين الاعتبار الاستخدامات الأخرى للمكتبة.

لا أعتقد أنه من الممكن إنشاء مكتبة تخدم جميع أنواع مطوري js دون تعطيل سير عمل التطوير لبعضهم البعض.

لدينا تجارب مشابهة جدًا لـ pailhead لا أعتقد أن سير العمل الخاص به هو سير عمل متخصص. أعتقد أن سير العمل الخاص به شائع جدًا للمطورين الذين يعملون مع أطر أمامية حديثة مثل Vue و Ember و React و Svelte و Angular ...

ربما يجب أن نلقي نظرة على كيفية قيام Vue بذلك. يحتوي على قاعدة مستخدمين تتراوح من مبرمجي PHP الذين يريدون فقط تحسين موقعهم على الويب إلى الأشخاص الذين يطورون تطبيقات ويب متطورة. إنه ينحني المنحنى بين تلك الأنواع المختلفة من المستخدمين بشكل جيد للغاية.

أيضًا حول ترقية قاعدة التعليمات البرمجية الحالية دون كسر التجربة للجميع ، هناك أمثلة رائعة هناك. يمكن أن نلقي نظرة على كيفية تمكن Ember من النمو باستمرار مع مجتمع الويب ومعايير الصناعة الخاصة به.

لن أفكر في البقاء على اطلاع دائم بتطوير الويب الحديث. لكنني أتفق تمامًا على أنه يتطلب الكثير من الجهد وعلينا أن نفكر كثيرًا في هذه الأشياء. لهذا السبب أعتقد أنه من الأفضل العمل معًا لخلق تجربة حديثة بدلاً من إنشاء العديد من المشاريع الجديدة.

عندما تمر في هذا الموضوع ، يوجد بالفعل مشروعان مختلفان ، Three.ts و Threeify وربما يكون هناك العديد من المشاريع الأخرى. أعتقد حقًا أنه ستكون هناك فائدة كبيرة لمجتمع Three.js بأكمله إذا عملنا معًا بدلاً من إنشاء مفترقات ومبادرات منفصلة.

mrdoob ما رأيك في استبيان لجمع بعض البيانات؟ استخدام الكتابة المطبوعة هو شيء وأنا متأكد من أن هناك متغيرات نوعية أخرى يمكننا أن نحاول الحصول على تقدير لها.

@ roomle-build هل يمكنك سرد عيوب تحويل المكتبة إلى TypeScript؟

لا أرى عيبًا حقيقيًا في الاعتماد التدريجي على TypeScript للمكتبة. في المقابل ، أعتقد أنه سيحقق الكثير من الفوائد (وهذا هو سبب تحويل العديد من المشاريع إلى TypeScript). ومع ذلك ، هناك بعض التحديات بالطبع ، على سبيل المثال:

• كيف يمكننا تقديم تجربة لطيفة لمستخدمي TS؟
• كيف يمكن للمستخدمين بدون خطوة مدمجة استخدام المكتبة
• وبالطبع كل الأشياء الأخرى التي لم أفكر فيها

ولكن كما قلت من قبل ، تم حل تلك الأسئلة في مشاريع أخرى أيضًا ويمكننا نسخ هذه الحلول من هناك (مثل Vue أو Ember على سبيل المثال).

لكن الشيء الرئيسي الذي أردت أن أشير إليه هو أنني أعتقد أنه من الخطير أن ينفصل المجتمع عن بعضه ولدينا العديد من المشاريع المختلفة وشوكة مفترق طرق. أنا لست من محبي التجزئة وأعتقد أنه من الأفضل العمل معًا بدلاً من العمل ضد بعضنا البعض. بالطبع هناك أشخاص آخرون يجادلون بأن المنافسة رائعة وأن هذا سيزدهر أيضًا في مشروع Three.js ولكني مؤمن أكثر بالتعاون 🙂

أعتقد أن إحدى أكبر مزايا three.js هي إمكانية الوصول. ستؤدي النقاط @ roomle-build المدرجة إلى تفاقم سهولة استخدام المحرك (خاصة في سياق المبتدئين). أنا أصوت لمواصلة استخدام JavaScript ما لم يتم دعم لغة برمجة بديلة في المستعرضات.

أنا لست من محبي التجزئة وأعتقد أنه من الأفضل العمل معًا بدلاً من العمل ضد بعضنا البعض.

إن وجود المزيد من المحركات ثلاثية الأبعاد على الويب لا يعني أن المطورين يعملون ضد بعضهم البعض. في بعض الأحيان يكون من الأفضل فعلاً أن تركز المشاريع المختلفة على أشياء مختلفة.

أعتقد أن إحدى أكبر مزايا three.js هي إمكانية الوصول. ستؤدي النقاط @ roomle-build المدرجة إلى تفاقم سهولة استخدام المحرك (خاصة في سياق المبتدئين).

لا أرى الأمر بهذه الطريقة لأن المشروعات الأخرى تقوم بتأليف التعليمات البرمجية الخاصة بها في TypeScript دون أي تأثير على إمكانية الوصول. ذكرت Vue و Ember كأمثلة من قبل. ربما يكون من المنطقي مراجعة الموقف ضد TypeScript؟ لن نحتاج إلى ابتكار شيء ما نحتاجه فقط لنسخ الأساليب الناجحة من المشاريع الأخرى. علاوة على ذلك ، أعتقد أن TypeScript ستحظى بميزة أن three.js سيكون متاحًا بشكل أكبر للمساهمين لأن IDE يمكن أن يساعدهم في الحصول على نظرة عامة على المشروع بأكمله بشكل أسرع.

أنا أصوت لمواصلة استخدام JavaScript ما لم يتم دعم لغة برمجة بديلة في المستعرضات.

أعتقد أن هذا لن يحدث في المستقبل المنظور ، وبالتالي أعتقد أنه يجب أن يكون لدينا وجهة نظر أكثر واقعية حول TypeScript. كما كتبت أعلاه ، أعتقد أنها مشكلة تتعلق فقط بكيفية تنظيم المشروع وإعادة الشراء وليست مقايضة بين سهولة الاستخدام وتجربة التطوير.

أعتقد أننا أوضحنا موقفنا.