Three.js: اعتماد بعض ميزات ES6

ربما في وقت مبكر قليلا؟ الدعم ليس جيدًا عبر المتصفح باستمرار: http://kangax.github.io/compat-table/es6/

let غير مكشوف في FF وليس في 100٪ من المواقف في Chrome و IE.
generators غير متوفر في IE
class متاح فقط في Chrome و IE12 (Spartan) للمعاينة الفنية لنظامي Win10 و FF39 وهما إصداران أعلى من الإصدار الحالي.
import غير متوفر في أي مكان بعد
super متاح فقط في IE12 ، وليس IE11 أو Chrome أو FF
arrow functions ليس في IE11 أو Chrome

كما أن كلا من المولدات و for-of هي قاتلة التحسين لمتصفح Chrome

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

لقد تأخرت قليلاً في حفلة ES6. هذه تبدو لي لغة مختلفة. أساهم بانتظام في Three.js ولكن إذا بدت مثل المقتطفات أعلاه ، فلا أعرف ما إذا كنت سأستمر. أنا فقط لا أملك الصبر لتعلم نسخة مختلفة المظهر وذات وظائف مختلفة من JavaScript ، والتي تقوم في الأساس بنفس الأشياء مثل 'new function ()' و 'object.prototype' ، ولكن ربما تكون أبطأ.

هل هذا ما طالب به مجتمع الويب من لجنة اللغة ES6؟ أمارس البرمجة لمدة 20 عامًا ولم تظهر كلمة "class" في أي مكان في مشروعاتي (ولن تظهر أبدًا إذا كان لدي طريقي). بصراحة ، بدأت JavaScript في الظهور مثل JAVA ... (نص برمجي). : - \

أنا مع benaadams و @ jonnenauha ؛ مبكرًا جدًا ، وقد يؤدي ذلك إلى إبطاء الكود إذا لم يقم Chrome و Firefox بتحسين هذا الإصدار الجديد من اللغة بشكل كبير كما لو أنهما يعملان بالفعل على تحسين JavaScript تحت الغطاء (V8 ، إلخ ...).

: +1:

erichlof حسنًا ، أنا في الواقع أنتظر دعم فئة ES6 والوحدة النمطية أكثر. أنا أستخدم AMD حاليًا لتطبيقاتي. مشروع JS الرئيسي الذي أعمل عليه هو حوالي 10 آلاف سطر مع مئات "الفئات" و AMD هي منقذ للحياة. سواء أثناء التطوير أو في إنتاج البنيات. تحتاج مشاريع Imo الكبيرة أو حتى الصغيرة إلى نوع من نظام الوحدات وطريقة للأشياء للإعلان عما تعتمد عليه. يصبح الأمر مشعرًا جدًا بحيث لا يمكن إدارته بمجرد أن يكون لديك هيكل مشروع معقد. لا ينبغي أن يترك للمبرمج تحديد ترتيب وضع علامات 25x <script> . يعد هذا أمرًا سخيفًا بمجرد أن يكون لديك كمية من الملفات مثل ملفات three.js. تحل معظم المشاريع هذا عن طريق إنشاء ملف js كبير واحد (مثل three.js) ثم هناك مجلدات إضافية / مساعدين عشوائية حيث يمكنك تضمين أشياء أخرى. هذا مقيد إلى حد ما ويجب علي تضمين ~ 500 كيلو بايت (مصغر) للحصول على ~ كل شيء تحت الشمس.

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

قد لا يكون لديك "class" في مشاريعك ولكن إذا كنت تستخدم object.prototype (مثل three.js بكثافة) فهو نفس الشيء فعليًا ، هل توافق؟ نحب وضع الأشياء معًا ومنحها غرضًا. ثم يريد رمز آخر استخدام الكائنات المذكورة وطريقة تعريفية نظيفة لاستيرادها.

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

لم يكن PS صراخًا ضد three.js ، فقط قيل إنه قد تكون هناك فوائد في ES6 لمشاريع مثل three.js بمجرد أن يتوفر دعم المتصفح :) وغالبًا ما يكون السكر النحوي أكثر من جعله لغة جديدة تمامًا. سيكون لديها المزيد من الأشياء.

ميزة أخرى قد تكون مفيدة لـ three.js هي WeakMap وربما WeakSet . لست متأكدًا من الآثار المترتبة على ذلك ، ولكن يبدو أنه يمكن استخدام هذا لتتبع الأشياء دون إبقاء GC تقوم بعملها إذا لم يعد "المالك" يحمل الحكم. هناك الكثير من الحالات المماثلة في three.js واستخدامها داخليًا قد يحدث فرقًا. يبدو لي أن هذا يشبه إلى حد ما ptrs المشتركة / الضعيفة في C ++ لإعلان الملكية.

قد يكون المرشح الجيد أشياء مثل https://github.com/mrdoob/three.js/blob/master/src/lights/SpotLight.js#L12 حيث يمكن أن يكون هذا المرجع ضعيفًا وسيتم مسحه تلقائيًا إذا كان الهدف إزالتها من مكان الحادث وجمعها. لكن أعتقد أنه لا يمكنك الاعتماد على المجموعة بأي حال من الأحوال ، لكنك ستحتاج على أي حال إلى إلغاء ذلك بمجرد إزالة الهدف من المشهد.

من يدري ، سأنتظر حتى يكتب الخبراء بعض منشورات المدونة كيف أن كل هذه الميزات قد تفيد التطبيقات بشكل عام :)

مرحبًا jonnenauha ،

نعم ، أوافق على أن الميزات الجديدة مثل "الاستيراد" و "التصدير" ستكون مفيدة ، لا سيما عندما يتعلق الأمر بالنمطية. أعتقد أن هذا هو الاتجاه الذي يحاولcoballast و @ kumavis اتباعه لجعل THREE.js أكثر نمطية وقابلية للإدارة من أجل الإنشاءات المخصصة وقابلية صيانة قاعدة التعليمات البرمجية. أنا جميعًا مع الوحدات النمطية وإعادة استخدام الكائنات والوظائف ، خاصةً عندما يكون لدينا تنسيق مكتبة كبير مثل THREE.js.

ومع ذلك ، لا أعتقد أننا بحاجة إلى السكر النحوي الإضافي للفئات ، سوبر ، دعونا ، من ، وظائف الأسهم ، وما إلى ذلك .. عندما نحصل بشكل أساسي على نفس الوظيفة في JavaScript الآن والتي كانت مستخدمة منذ عقود ولديها الكثير من الجر بالفعل. قد أكون عتيقًا ، لكنني مع دوجلاس كروكفورد عندما قال إن JavaScript هي بالفعل لغة موجهة للكائنات (بمعنى الوظائف = كائنات = مواطنون من الدرجة الأولى) ، ولكنها ليست لغة "كلاسيكية" - لذلك لا ينبغي أن نهتم بها فصول الأحذية إلى جافا سكريبت. لقد تم تصميمه بأسلوب مختلف - وهو نهج فوجئت به في البداية (قادم من برمجة C / C ++ في التسعينيات) ، لكنني أتفق مع المزيد والمزيد في كل مرة أجلس فيها إلى الكود أو أحاول حل بنية الكود مشاكل.

بدلاً من التغييرات النحوية على THREE.js ، أفضل أن أرى الترحيل نحو ميزات مثل واجهة برمجة SIMD الجديدة. أعتقد أن جميع كود الرياضيات الثلاثة (خاصة Vector3 و Matrix4) يمكن أن تستفيد بشكل كبير من هذا. هذا رابط فيديو (راجع 22:51 في رمز الوقت):
https://youtu.be/CbMXkbqQBcQ؟t=1371
عندما تهبط هذه الميزة في المتصفحات الرئيسية ، سيرى كل مستخدم THREE.js تسريعًا ملحوظًا في معدل الإطارات نتيجة لذلك.

آسف إذا كانت رسالتي السابقة تبدو وكأنها صاخبة ، فأنا أحب الطريقة التي تبدو بها THREE.js الآن - يمكنني بسهولة تحديد أي جزء عشوائي منه ومعرفة ما يجري ، ومن أين أتت ، وما الذي تستخدمه. :)

erichlofjonnenauha أجد نفسي مضطرا أن نشير إلى أن الطبقات ES6 هي السكر عادل وهم داخليا باستخدام آلية النموذج لتنفيذ كل شيء في وقت التشغيل.

أنا متفائل إلى حد ما بأن ميزات es6 لن تؤثر على الأداء الحسابي. قد تؤثر وحدات es6 على وقت التحميل عندما يتم تنفيذ هذه الوحدات في النهاية بواسطة المحركات ، لأنك تجلب مجموعة من الملفات الصغيرة بدلاً من ملف واحد كبير. قد يجعل HTTP / 2 ذلك ليس مشكلة بالرغم من ذلك. في كلتا الحالتين ، إذا استخدمنا وحدات es6 ، فيمكننا استخدام browserify لإنشاء حزمة كما نفعل دائمًا.

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

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

لا أعتقد أن نقل التعليمات البرمجية يدويًا فكرة جيدة. كما قال دوج ماكلروي ، مخترع أنابيب يونيكس وعمومًا نصف إله:
"يفضل استخدام الأدوات للمساعدة غير الماهرة لتخفيف مهمة البرمجة ، حتى إذا كان عليك الالتفاف لبناء الأدوات وتوقع التخلص من بعضها بعد الانتهاء من استخدامها."

أود أن أشجع أي شخص مهتم بـ es6 على القفز والمساعدة في هذا الريبو: https://github.com/5to6/5to6

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

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

ولا يجب أن ننظر فقط إلى es6. على سبيل المثال ، ستكون ams.js رائعة مثل التكنولوجيا التي تدير عارض البرامج. لمزيد من المعلومات ، http://stackoverflow.com/questions/18427810/three-and-asmjs/18439786#18439786.

ولا يجب أن ننسى أن معظم المساهمين يساهمون بشكل أساسي لأن جافا سكريبت مألوفة و es6 ليست كذلك لمعظم المساهمين.

@ gero3 هذه نقاط جيدة لم أفكر فيها. إذا كنا نتحدث عن التحسين الجزئي ، فأنا أتفق معك بنسبة 100٪. لا أريد الاستفادة من هذه الميزات بدون دعم المتصفح.

إلى حد كبير ما كنت أتحدث عنه أعلاه هو استخدام السكر النحوي الذي يحتوي على دلالات متطابقة مع ميزات es5 الحالية ، وبالتالي يمكن بناؤه باستخدام أجهزة التحويل دون التأثير على الأداء كثيرًا.

تحديث:
ربما لا أحد يهتم ، لكني غيرت رأيي. أعتقد أننا لا يجب أن نستخدم الفصول الدراسية. ما زلت أعتقد أن وحدات es6 فكرة جيدة.

أنا أؤيد الفصول تمامًا. أحصل على كل الأشياء الرائعة التي يمكن أن يفعلها النموذج الأولي للكائن في JavaScript. ومع ذلك ، في THREE.js (والعديد من مشاريع أنظمة التشغيل الحديثة الأخرى) ، نستخدم الوراثة النموذجية لمحاكاة الفئات ، فلماذا لا نمتلك التركيبات اللطيفة لتتماشى معها ، والتخلص من الأشياء المخترقة مثل:

THREE.Object3D.call( this );

و

THREE.Scene.prototype = Object.create( THREE.Object3D.prototype );

بمجرد أن يتم دعم الفئات في مستقر Chrome و Firefox ، لا أمانع في التفكير في تحديث الكود 😊

يتم دعم فئات mrdoob في Chrome 42

يبدو أن Safari على iOS هو الذي يسحب هذه الأيام ... 😣

الفصول مذهلة وكذلك ميزات ES7 الأخرى. نحن نستخدمها في أحد مشاريعنا ، ولكن كان علينا تقديم مترجم متقاطع (babel.js) لأننا نحتاج إلى التشغيل على جميع المتصفحات - Chrome و Firefox و IE و Safari.

هناك تحويل في المتصفح لتشغيل babel.js (babelify) ، لذلك سيعمل بشكل جيد مع جهودي.

بدافع الفضول فقط ، هل بدأ العمل في بعض هذه الأشياء؟ :)

لا لأننا ما زلنا لا نعرف الآثار المترتبة على سرعة هذه.

أفهم أن ES6 غير مؤدٍ في الغالب وبالتالي ليس للإنتاج حتى يتم غرسه في المتصفح. مع ذلك ، يجب أن تتكيف المشاريع أو الوحدات الجديدة مع وسائل الراحة هذه اليوم ولكن يجب أن يؤخذ الأداء في الاعتبار في هذا القرار.

أتفق مع erichlof imo أن التطبيق الأكثر فائدة سيكون SIMD (https://github.com/tc39/ecmascript_simd) ، حتى مع استخدام polyfill. يبدو أن المستخدمين سيستفيدون أكثر من ذلك.

أين تناسب SIMD في ThreeJS؟ أعتقد أن ThreeJS تقوم بالفعل بإلغاء تحميل كل العمليات الحسابية المهمة إلى وحدة معالجة الرسومات. بينما يمكنني أن أفهم نوعًا ما استخدامه في فئات Vector ، هناك القليل جدًا من العمليات الحسابية التي يتم إجراؤها بالفعل في ThreeJS ، في الغالب يتم نقل هذه المتجهات إلى وحدة معالجة الرسومات (GPU).

أتحدث من التجربة لأنني قمت بتطبيق ملحقات SSE2 / SSE4 من قبل ووجدت أن الفوائد كانت عابرة في معظم الحالات - كانت الحالات الحقيقية الوحيدة التي كانت فيها فائدة هي عندما كان لدي مصفوفات كبيرة أردت أن أفعل الشيء نفسه عليها عملية.

مرحبًا bhouston ،
هل ينطبق الأمر نفسه على عمليات المصفوفة؟ عندما كنت أفكر في SIMD ، كنت أفكر في أن عمليات المصفوفة 4 × 4 ستستفيد أكثر من غيرها. وكما نعلم جميعًا ، تُستخدم المصفوفات كل إطار للرسوم المتحركة في Three.js على جانب JavaScript / CPU ، بغض النظر عن مدى تعقيد التطبيق.

إذا كان شباب Babylon.js لا يمانعون ، فإليك تلميحًا لكيفية بدء كل هذا:
https://github.com/BabylonJS/Babylon.js/blob/master/src/Math/babylon.math.js#L2030 -L2093

أعتقد أن مصفوفة واحدة متعددة إذا كان عليك تحويل التنسيق من المحتمل أن تكون خاسرة. إذا كانت لديك المصفوفات الخاصة بك دائمًا بتنسيق SIMD ، فقد يكون ذلك مفيدًا.

ولكن مع ذلك ، فإن عملية ضرب المصفوفة ليست هي الحل الأمثل لأنك تضطر إلى مضاعفة الأعمدة في الصفوف ، الأمر الذي يتطلب عملية إعادة ترتيب.

لقد وجدت أن معظم الجهود المبذولة في تحسين SIMD (باستثناء المصفوفات الكبيرة ذات العمليات المتجانسة) لا تستحق الجهد المبذول ، لكنني على ما يرام مع الآخرين الذين يقومون بإجراء معايير لمعرفة ذلك.

من الصعب تصحيح الكود الناتج والمحافظة عليه أيضًا.

تتمثل إحدى الإستراتيجيات التي يمكن أن تنجح في جعل جميع المتجهات والمصفوفات تستخدم تخطيط ذاكرة متوافق مع SIMD كتمثيل أصلي - وهو ما أؤمن به Quake 3 في مكتبة الرياضيات الخاصة به. ولكن بعد ذلك ، يتعين عليك استخدام 4 عوامات لأنواع vec2 و vec3 لتحقيق الكفاءة ، ولكن بعد ذلك يصبح ذلك مشكلة عندما تريد التحميل إلى وحدة معالجة الرسومات لأن لديك الآن عوامات إضافية في الطريق.

أرى ما تقصده ، شكرًا لك على بصيرتك وخبرتك. إن الإعجاب بالعرض التقديمي SIMD.js منذ فترة ، وإلصاقه في three.js والحفاظ عليه هما شيئان مختلفان أفترض. سيكون من المثير للاهتمام كما قلت إجراء بعض مقارنات الأداء. ربما مكتبات الفيزياء مثل Cannon.js و Oimo.js ، التي تُستخدم جنبًا إلى جنب مع three.js ، ستحصل على المزيد من الفوائد من SIMD؟

bhouston Ahh حسنًا ، هذا منطقي ، بعض المعايير ستكون ممتعة للغاية رغم ذلك.

erichlof إذا كنت مهتمًا ، فقد بدأت فرعًا ، https://github.com/Globegitter/three.js/tree/include-SIMD ، حيث بدأت في استبدال Vector3 بـ SIMD. لا يزال العمل قيد التقدم ثقيلًا ووقتي محدود ، لذا سنصل إلى أي مدى سأصل إليه. أيضًا ، باستخدام أحدث إصدار من Firefox ليلاً ، يمكنك تشغيل هذا الكود بدون تعبئة (حيث يبدو أن التنفيذ الأصلي أسرع بنحو 20 مرة مقارنةً بـ polyfill: https://blog.mozilla.org/javascript/2015/03/10/state -من-simd-js-performance-in-firefox /).

erichlofjonnenauha أجد نفسي مضطرا أن نشير إلى أن الطبقات ES6 هي السكر عادل وهم داخليا باستخدام آلية النموذج لتنفيذ كل شيء في وقت التشغيل.
أنا متفائل إلى حد ما بأن ميزات es6 لن تؤثر على الأداء الحسابي.

قد تكون سريعًا بعض الشيء في استنتاج ما يلي: هناك بالفعل مسارات رمز مختلفة لـ ES6 في كل محرك JS في التنفيذ (المعقد إلى حد ما) لكائنات JS.

قد تؤثر وحدات es6 على وقت التحميل عندما يتم تنفيذ هذه الوحدات في النهاية بواسطة المحركات ، لأنك تجلب مجموعة من الملفات الصغيرة بدلاً من ملف واحد كبير. قد يجعل HTTP / 2 ذلك ليس مشكلة بالرغم من ذلك.

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

إن جعل مترجم الإغلاق يتفهم Three.js سيسمح بالتجميع إلى ES6 ومعرفة الوقت المناسب للتبديل ، بالإضافة إلى العديد من المزايا الإضافية. أعتقد أن هذا هو المكان الذي يجب أن تتجه فيه الجهود من هذا النوع في الوقت الحالي ...

ولكن مع ذلك ، فإن ضرب المصفوفة [SIMD] غالبًا لا يكون هو الأمثل لأنه يتعين عليك مضاعفة الأعمدة بالصفوف ، الأمر الذي يتطلب عملية إعادة ترتيب.

غالبًا ما تحتوي مجموعات تعليمات SIMD على تعليمات "الضرب حسب العددي وإضافة" ، لتنفيذ عملية ضرب المصفوفة مثل هذا:

for i : 0..3:
    dst.col[i] = lhs.col[i] * rhs.co[i][0] // multiply vector by scalar
    for j : 1..3:
        dst.col[i] += lhs.col[i] * rhs_col[i][j] // multiply vector by scalar & add

إن عملية ضرب المصفوفة هي في الواقع مجرد تطبيق تحويل على متجهات العمود لمعامل الجانب الأيمن. الآن ، يمكن النظر إلى التحويلات على أنها مجموعة من المنتجات النقطية (الطريقة المربكة التي نستخدمها عادةً مع القلم والورق) ، أو كمجموعة خطية من متجهات المحور لمساحة الوجهة = متجهات العمود في الجانب الأيسر المعامل.

Globegitter نجاح باهر هذه بداية رائعة! سأحصل على Firefox Nightly حتى أتمكن من تجربة الفرع الجديد أيضًا!

Globegitter أحب عندما يمضي شخص ما قدمًا ويفعل شيئًا ما عندما يؤمن به. يحدد الكود وجهات النظر المتباينة بشكل أسرع مما تفعله المناقشة.

حيث يبدو أن التنفيذ الأصلي أسرع بنحو 20 مرة مقارنةً بالبوليفل

سيكون مهتمًا أيضًا بمعرفة مقدار البطء مقارنةً بغيرها من polyfill

سأحصل على Firefox Nightly حتى أتمكن من تجربة الفرع الجديد أيضًا!

يجب أيضًا أن تكون قادرًا على تجربته في Edge عن طريق التبديل التجريبية و asm.js في about: flags

Globegitter أعتقد أن https://github.com/Globegitter/three.js/commit/d835ca3a22eed4ed4603534773ae55c29d5a8026

ألاحظ أنك تصنع نوع SIMD كسيارة جانبية:

https://github.com/Globegitter/three.js/commit/8ed9c1d351a3b0587a1f05051922d271d79f642d

هل لي أن أقترح عليك تغيير Vector3 x و y و z إلى أداة تجميع / أدوات تخزين وتخزين float32x4 فقط؟ أعتقد أن مثل هذا النهج قد يكون أسهل بكثير في التنفيذ مع تغييرات أقل.

لست متأكدًا من أفضل طريقة لتحديد الخصائص ولكن mrdoob يفعل شيئًا كهذا هنا:

https://github.com/mrdoob/three.js/blob/5c7e0df9b100ba40cdcaaf530196290e16c34858/examples/js/wip/proxies/ProxyVector4.js#L18

من المحتمل أن يكون استخدام SIMD كنوع التخزين الرئيسي وراء نوع الرياضيات هو الأكثر كفاءة ، ولا يلزم إجراء تحويلات إضافية. فيما يلي مكتبة الرياضيات Bullet Physics SSE إذا كنت بحاجة إلى دليل لأي عمليات متجه / مصفوفة قياسية:

https://code.google.com/p/bullet/source/browse/trunk/src/vectormath/sse/

bhouston ، شكرًا على هذه الملاحظات. كنت نوعاً ما أذهب مباشرة إلى هناك لأرى إلى أي مدى سأصل في غضون ساعات قليلة دون أن أعمل كثيرًا مع ثلاثة و SIMD من قبل (نستخدمها في معظم مشاريعنا). لذا فإن هذه التعليقات من شخص يعرف ثلاثة هي موضع تقدير حقًا. ونعم يجب إيقاف ذلك في المحرر الخاص بي.

tschw شكرا للملاحظة على المصفوفة / متجه الرياضيات! أنت محق ، هذا أفضل.

Globegitter هنا مثال أفضل على setter / getter على النموذج الأولي لكائن: https://github.com/mrdoob/three.js/blob/master/src/core/Object3D.js#L83

بعض سنتات العمل على ES2015 (خاصة في العقدة)

• هناك أماكن تحتاج محركات جافا سكريبت (مثل V8) للعب اللحاق بها لتحسين ميزات ES6
• من كود تجربتي مثل let x = 1, y = 2 سيؤدي إلى تحسين الإصدار 8 على الرغم من أنني أتوقع أن يدعمه الإصدار 8 في النهاية
• يمكن تشغيل التعليمات البرمجية المنقولة إلى ES5 بشكل أبطأ من كود ES6 (وهذا هو السبب في أنني أفضل استخدام ميزات ES6 المدعومة فقط في> العقدة 4 ، وهذا هو كل شيء تقريبًا باستثناء نظام الاستيراد والتصدير)
• الخرائط والمجموعات هي مكاسب الأداء
• الفصول جميلة
• يمكن أن يكون استخدام Babel مؤلمًا لسير عملك ، وربما لا يستحق الجهد المبذول إذا كنت تستخدم ES6 فقط لتركيب السكر

قبل نصف عام قمت بتحويل بعض وظائف Three.js (مضاعفة المصفوفة 4x4 ، Vector4 ، إلخ) إلى SIMD ويمكنك تجربتها. في مرحلة ما ، كان يعمل كإشارة مرجعية ولكن قد يتطلب الآن تحديثًا للعمل مع أحدث إصدار من ثلاثة

• يدعم Firefox Nightly SIMD الأصلية خارج الصندوق
• Chrome مع العلم --js-flags = "- Harmony-simd" يدعم JS polyfill الخاص بـ SIMD ، لذا سيكون أبطأ من الإصدار غير البسيط. على الأقل يمكنك التحقق مما إذا كانت تعمل وتجرب!

مكاسب الأداء بنسبة 350٪ هي LIE :)

لقد قمت أيضًا باستدار جزء من Vector3 ولكن تم التعليق عليه.

https://github.com/DVLP/three.turbo.js

تحرير: لدي إصدار أكثر حداثة في مكان ما على محرك الأقراص الثابتة ، لذا سأقوم بتحديث هذا المشروع قريبًا

مشاهدة رائعة والتحديق في +1 لذلك.
ما قد يكون رائعًا هو نظام يتحقق من الأداء ويمكّن أو يعطل مثل هذه الميزات اعتمادًا على الأداء المذكور.

ما قد يكون رائعًا هو نظام يتحقق من الأداء ويمكّن أو يعطل مثل هذه الميزات اعتمادًا على الأداء المذكور.

أعتقد أنه سيكون لدى أحد تعريفين لـ Vector3 داخل وحدة Vector3 وستقوم بإرجاع أحدهما أو الآخر بشكل مشروط اعتمادًا على ما إذا كانت SIMD محلية؟ أعتقد أن هذا سيعمل ، لكنه سيزيد من جانب التنزيل. ربما يمكنك فقط الحصول على بعض الوظائف التي يتم تبديلها اعتمادًا على ما إذا كانت SIMD متوفرة - ربما تكون SIMD هي الأكثر أهمية فقط لمجموعة فرعية صغيرة من وظائف الرياضيات. إذا كان هذا صغيرًا من حيث إجمالي الكود ، فقد يكون من المفيد وضعه الآن. ولكن يجب أن يكون اختياريًا حتى لا يصبح بطيئًا عند عدم توفر SIMD.

يمكننا البدء بعمل نسخة SIMD من Matrix4 's multiplyMatrices() لأنها الطريقة الأكثر استخدامًا حاليًا في المشاهد المعقدة.

https://github.com/mrdoob/three.js/blob/dev/src/math/Matrix4.js#L383 -L419

mrdoob انظر هنا لقد
https://github.com/DVLP/three.turbo.js/blob/master/src/three.turbo.js

جرب كمختصر:
javascript:(function(){var script=document.createElement('script');script.src='//rawgit.com/DVLP/three.turbo.js/master/src/three.turbo.js';document.head.appendChild(script);})()

الجزء المسؤول عن الكود

THREE.Matrix4.prototype.multiplyMatrices = function(a, b) {
    var ae = a.elements,
      be = b.elements,
      tb = this.elements,
      arr1 = SIMD.Float32x4.load(ae, 0),
      arr3 = SIMD.Float32x4.load(ae, 4),
      arr5 = SIMD.Float32x4.load(ae, 8),
      arr7 = SIMD.Float32x4.load(ae, 12),
      arr2,
      arr4,
      arr6,
      arr8,
      res;
    // calculated version
        for (var i = 0; i < 4; i++) {
            arr2 = SIMD.Float32x4.splat(be[i * 4]);
            arr4 = SIMD.Float32x4.splat(be[i * 4 + 1]);
            arr6 = SIMD.Float32x4.splat(be[i * 4 + 2]);
            arr8 = SIMD.Float32x4.splat(be[i * 4 + 3]);
            res = SIMD.Float32x4.add(SIMD.Float32x4.add(SIMD.Float32x4.mul(arr1, arr2), SIMD.Float32x4.mul(arr3, arr4)), SIMD.Float32x4.add(SIMD.Float32x4.mul(arr5, arr6), SIMD.Float32x4.mul(arr7, arr8)));
            SIMD.Float32x4.store(tb, i * 4, res);
          }
}

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

هناك المزيد من الوظائف في الفرع "معكوس"
https://github.com/DVLP/three.turbo.js/blob/inverse/src/three.turbo.js

ما هو الفرق في الأداء؟

https://jsfiddle.net/tk6zx5dm/6/

هذا يعتمد. في Nightly عندما يكون عدد العمليات الحسابية صغيرًا (<1000) ، تكون النتيجة أبطأ بثلاث مرات. عندما يكون عدد العمليات الحسابية أعلى من 10000 ، تكون السرعة ~ 40٪ أسرع

في Chrome مع تمكين علامة --js-flags="--harmony-simd" ، لا توجد SIMD حقيقية ، ولكن من الواضح أن السرعة أبطأ عدة مرات في الوقت الحالي.

سيكون مكانًا جيدًا للاختبار هو مشروع Crosswalk (استنادًا إلى Chromium). لديهم SIMD حقيقي لنظام Android ، لذا قد تكون تجربة مثيرة للاهتمام لبناء مشروع برمز من JSFiddle لمعرفة النتيجة.

قد لا ترغب في تضمين polyfill البسيط على أي حال في صفحاتك النموذجية. فقط أكثر ملاءمة للناس لتجربتها. سجل سطرًا في وحدة التحكم أو ضع بعض النص على الشاشة عندما لا يتوفر أصلي (ربما يترك polyfill بعض التلميحات بأنّه ممكّن).

لا أستطيع أن أتخيل لماذا يقوم Chrome بتحميل js simd polyfill بـ --js-flags="--harmony-simd" ، هذا لا معنى له عندما يمكن القيام به بالفعل في أرض المستخدم؟! ما فائدة هذا. ربما سيبدأون في وضع الأشياء تدريجيًا. أين قرأت هذا ما يحدث بالفعل مع العلم ، أي روابط جيدة؟ يبدو أنه "قيد التطوير" هنا https://www.chromestatus.com/features/5757910432874496

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

يمكن لثلاثة أن يقفزوا على هذا عندما ينضج ، أم أن دعم three.js يمكن أن يدفع تطبيقات المتصفح للقيام بعمل أفضل؟ أعتقد أن المحرك غير الواقعي وحالات استخدام المحاكاة / الرياضيات الأخرى ستكون القوة الدافعة لبائعي المستعرضات ، وليس تحديدًا عدد libs الذين يريدون استخدام الميزة. لكن من يعلم.

لا أستطيع أن أتخيل لماذا يقوم Chrome فقط بتحميل js simd polyfill مع --js-flags = "- Harmony-simd"

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

كل الحجج التي تدعم حتمية أن قائد المئة مطلوب. مراقبة في الوقت الفعلي للأداء يمكنها تمكين الميزات أو تعطيلها وتحديد الأداء الأمثل. لذا ، حتى كثافة خريطة الظل يجب أن تتغير بناءً على مسافة الكاميرا وما إلى ذلك. على أي حال ، أعرف أن الإجماع قد قرر أن هذه ستكون أداة طرف ثالث وليست ضرورية. ما زلت أريد فقط الاحتفاظ بهذه النقطة في العقل الواعي إن لم يكن العقل الباطن.
ربما تقوم فقط بالتحقق من وجود pollyfill وتعطيل SIMD ولكن مرة أخرى تخبر FPS كل شيء. من المحتمل أن تكون أولويات ما يجب تمكينه أو تعطيله هي الأفضل كتفضيل محدد لمستخدم / تطبيق. شكرا على الإنصات! أنا أتطلع إلى GL أسرع في المستقبل القريب. لنكن مستعدين لتفوق البقية.

يبدو أن عملية تحميل البيانات إلى SIMD قد تؤدي إلى زيادة النفقات التي تتحدى ميزة استخدام SIMD في Nightly. أشعر بالفضول الشديد بشأن الأداء في Chrome ولكن أحدث إصدار من Chromium مع SIMD حقيقي موجود هنا http://peterjensen.github.io/idf2014-simd/
انها قديمة.

تحديث:
يعمل الآن SIMD أيضًا في Edge. يمكنك تمكينه بالانتقال إلى : العلامات والتحقق من "تمكين ميزات JavaScript التجريبية" (إعادة تشغيل Edge)
لست متأكدًا مما إذا كان هذا هو SIMD حقيقي أو polyfill رغم ذلك. يعرض هذا الاختبار SIMD أبطأ بنسبة 40٪ تقريبًا على جهازي: / https://jsfiddle.net/tk6zx5dm/6/

تباين الاختبار مع كائنات SIMD المخزنة مؤقتًا في كائن Matrix4 ، لست متأكدًا مما إذا كان هذا سيكون مفيدًا على الإطلاق
https://jsfiddle.net/tk6zx5dm/15/
الأمر المثير للاهتمام هو أن الكود الذي يحتوي على كائنات SIMD المخزنة مؤقتًا _ في بعض الأحيان_ أسرع حتى في Chrome الذي يستخدم polyfill SIMD (...؟ غريب)

THREE.Matrix4.prototype.multiplyMatrices = function(a, b) {
  var i = 4;
  while(i--) {
    SIMD.Float32x4.store(this.elements, i * 4, 
      SIMD.Float32x4.add(
        SIMD.Float32x4.add(
          SIMD.Float32x4.mul(
            a.cacheSIMDRow1,
            b.cacheSIMDSplat[i * 4]
          ),
          SIMD.Float32x4.mul(
            a.cacheSIMDRow2,
            b.cacheSIMDSplat[i * 4 + 1]
          )
        ),
        SIMD.Float32x4.add(
          SIMD.Float32x4.mul(
            a.cacheSIMDRow3,
            b.cacheSIMDSplat[i * 4 + 2]
          ), 
          SIMD.Float32x4.mul(
            a.cacheSIMDRow4,
            b.cacheSIMDSplat[i * 4 + 3]
          )
        )
      )
    );
  }
}

التخزين المؤقت - ربما يجب تنفيذه على كل updateMatrix () مما قد يجعل الحل بأكمله أبطأ في النهاية

THREE.Matrix4.prototype.updateSIMDCache = function() {
  this.cacheSIMDRow1 = SIMD.Float32x4.load(this.elements, 0);
  this.cacheSIMDRow2 = SIMD.Float32x4.load(this.elements, 4);
  this.cacheSIMDRow3 = SIMD.Float32x4.load(this.elements, 8);
  this.cacheSIMDRow4 = SIMD.Float32x4.load(this.elements, 12);

  if(!this.cacheSIMDSplat) {
    this.cacheSIMDSplat = [];
  }
  for(var i = 0; i < 16; i++) {
    this.cacheSIMDSplat.push(SIMD.Float32x4.splat(this.elements[i]));
  }
};

أشعر بالفضول هل تمت إعادة النظر في أسلوب ES6؟ الكود بالكامل غير قابل للاستخدام في الوقت الحالي دون تشغيل متسلسل ، فلماذا لا تشغل أيضًا بابل وتبدأ في استخدام عناصر ES6 عند الاقتضاء؟

الكود بالكامل غير قابل للاستخدام في الوقت الحالي دون تشغيل متسلسل ، فلماذا لا تشغل أيضًا بابل وتبدأ في استخدام عناصر ES6 عند الاقتضاء؟

ويرجع ذلك أساسًا إلى عدم وجود اختبارات على تأثير أداء الكود الذي أنتجته شركة بابل. سمعت أيضًا أن V8 ينتج رمزًا أسرع عند استخدام var بدلاً من let / const.

لمعلوماتك: لقد بدأت مؤخرًا في تجربة bublé التي "تقتصر على ميزات ES التي يمكن تجميعها إلى ES5 المدمجة والأداء".

يساعد الجزء السفلي من هذا الرابط في شرح حلقات var vs let in
http://stackoverflow.com/questions/21467642/is-there-a-performance-difference-between-let-and-var
أنا شخصياً أنتظر حلول لا يوجد محول لتصل إلى المتصفح. مثل كلمة "انتظار" عاجلاً كان ذلك أفضل ، ولكن في الوقت الحالي ربما يجب كتابتها بهذه الطريقة وتشغيلها (كونها مشوهة بشكل فظيع بواسطة) ناقل ، ولكن إذا كان يعمل في Chrome؟! حتى اختبار المتصفحات الأخرى؟ أقول "دعهم يأكلون الكعك ... أو يستخدمون Chrome." (تعبيري المفضل).
أعتقد أنه يجب استخدام كلمة "let" إذا كانت في موقف يُفضل أن يكون من الأفضل القيام بذلك عبر الاختبارات.
أفترض أن الأمر يشبه رفع "var" لتجنب تحديد النطاق ولكنك قد ترغب في ذلك ، ومن ثم يكون "Let" هو الأفضل. أعتقد / آمل أن تحافظ كلمة "Let" على بصمة ذاكرتك أصغر في مواقف معينة أيضًا.

لن تكون الشفرة المنقولة بالسرعة التي تم تحسينها يدويًا. إنه لأمر مخز أن تكون JSPerf معطلة. اعتدت أن أزوره أكثر من Google.
تحرير: JSPerf.com ليست معطلة! لقد افترضت أنها ميتة إلى الأبد بعد أن لم تكن تعمل لمدة عام
let 3x أبطأ من var في Chrome Canary: https://jsperf.com/let-vs-var-performance/14
في Firefox و Edge لا فرق في السرعة ولكن Chrome هو الأهم.
هل يمكن لشخص أن يختبر في Safari؟

تبدو الفصول رائعة وحديثة! لا أحد يعرف ما إذا كان هذا بالفعل على الجدول الزمني؟

@ Rubinhuang9239 لم أر أي شخص يقوم بذلك.

اترك 3 مرات أبطأ من var في Chrome Canary: https://jsperf.com/let-vs-var-performance/14

مقابل ما يستحق ، أصبح الآن let و const أسرع بشكل هامشي من var بالنسبة لي على Chrome 66 و Firefox 59 و Edge 42 ، باستخدام هذا الاختبار.

أعتقد أن التبديل بين الفصول الدراسية يجب أن يكون واضحًا للغاية - كان الجزء الأكبر من العمل هو اعتماد التراكمي الذي تم منذ بعض الوقت. لن أتفاجأ من أن بطلاً يمكن أن ينفذ دروسًا في ThreeJS في غضون بضع ساعات.

حسنًا ، هناك الكثير من الفصول الدراسية ، لذلك ربما يستغرق الأمر 8 ساعات أو نحو ذلك إذا قمت بذلك يدويًا.

ربما تبدأ صغيرة وتحول فصول الرياضيات أولاً ثم قم بإجراء العلاقات العامة. إذا نجح ذلك ، فانتقل إلى الآخرين.

looeee لقد مر أكثر من عام ، لذا لم يكن مفاجئًا أن يتمكن ES6 من اللحاق بالأداء

2019 هو العام الذي نبدأ فيه أخيرًا في اعتماد بعض أكواد ES6 في الأمثلة / المستندات ، أليس كذلكmrdoob؟ 😄

كان ES6 هو المعيار لبعض الوقت الآن ، يتعلم المطورون الجدد ES6. كما يمكننا التوقف عن دعم IE11 في الأمثلة كما ناقشتم يا رفاق في # 16220 ، أي المطورين ينظرون إلى أمثلة three.js باستخدام IE11؟ 😅

أعتقد أن أكثر الميزات المطلوبة من أجل ببساطة كتابة التعليمات البرمجية للوافدين الجدد هي الفئات وسلاسل القالب ، مع عدم نسيان const / let الافتراضية الآن.

يمكنني المساهمة إذا قررنا أن نبدأ.

خطوة بخطوة. لنبدأ بتحديث الأمثلة لاستخدام three.module.js في الوقت الحالي.

خطوة بخطوة. لنبدأ بتحديث الأمثلة لاستخدام three.module.js في الوقت الحالي.

تم الانتهاء من هذه الخطوة لفترة من الوقت الآن. ربما حان الوقت للانتقال رسميًا إلى الخطوة التالية؟

مرشحان:

1. const / اسمحوا
2. الطبقات

نظرًا لأن الفصول الدراسية قد تم استخدامها بالفعل في هندسة الصندوق لفترة من الوقت الآن ، فإنني أصوت للقيام بذلك أولاً. أو يمكننا القيام بالأمرين معًا في نفس الوقت.

ذات صلة: # 11552 ، # 18863

إذا فهمت بشكل صحيح ، فالمشكلة هي أنه لا يمكننا تحويل أي شيء إلى فئات ES6 إذا تم تمديدها من خلال الأمثلة ، حتى يتم تحويل الأمثلة أيضًا. وهذا قد يعني الانتظار حتى يختفي examples/js ؟ ما لم نتمكن من التأكد من أن البرنامج النصي modularize سوف يدعم الفئات ، لتحويل ملفات examples/js في نفس الوقت مع فصولهم الأصلية.

كما أفهمها ، فإن examples/js هو نوع من جميع الميزات الزائدة التي لا مثيل لها ولكن إذا تم دمجنا جميعًا في src/... فسوف ينفخها بشكل غير متناسب. بطبيعتها ، الإجابة على السؤال "هل نقدم أمثلة / نصوصًا لما تم إنشاؤه بشكل شائع x ، y ، z؟". أخاطر بتخمين أن إجابة three.js هي في الغالب نعم ولكن كمواد تعليمية داخل الموقع. يبدو أن إزالة examples/js غير وارد في هذه المرحلة. على الرغم من أنني ربما أساء فهم كيفية الإشارة إلى / استخدام examples/js يرجى إعلامي.

ترك examples/js كموقع ويب / تعليمي فقط يخطئ جزءًا من نقطة ما يمكن أن يكون عليه هذا المجلد ، أي نصوص / محتوى / مشاريع مجتمعية / أخرى يرغب الأشخاص في مشاركتها ولكني لست على دراية بمكان ما يتضاعف فيه الذي - التي.

أنا أستطرد.

حتى يتم تحويل الأمثلة أيضًا.

يعجبني صوت هذا باعتباره أفضل خطوة مؤقتة تالية.

DefinitelyMaybe أننا لا examples/js ، هناك دليلان جديران بالملاحظة:

• examples/js/*
• examples/jsm/*

الأول يحتوي على ملفات قديمة ، والأخير يحتوي على وحدات ES تم إنشاؤها من تلك الملفات ، مع نفس الوظيفة. سنقوم في النهاية بإزالة الأول. البرنامج النصي الذي يقوم بالتحويل لا يدعم فئات ES حاليًا. حتى تتم إزالة ذلك ، لا يمكن تحويل الملفات الموجودة في examples/js إلى فئات ES. يقوم بعضها بتمديد الملفات في src/ ، ولا يمكنك تمديد فئات ES بدون استخدام فئات ES ، لذلك فهذه تبعية حظر.

آه ، كان مرتبكًا من التعليق السابق

وهذا قد يعني الانتظار حتى تختفي الأمثلة / js؟

من المنطقي الآن.

يذكرني modularize.js بمشروعي الأولي الذي أتى بي إلى هنا. محول . رأيت تعليقات هنا حول الانتقال إلى فصول ES6 لذلك اعتقدت أنني سأنتقل هنا بدلاً من ذلك.

لذلك إذا امتد examples/js src بطريقة ما ، يجب تحويل كلاهما إلى فصول ES6 في نفس الوقت
أو...
العمل على نمطي حتى يولد الطبقات / es6؟

لا يمكننا تحويل أي شيء إلى فئات ES6 إذا تم توسيعه بالأمثلة

لا يزال هناك الكثير من الأشياء في الجوهر لم يتم توسيعها في الأمثلة ، فلماذا لا نبدأ بذلك؟

قد يبدو ذلك جميلا بالنسبة لي.

@ Mugen87 هل كان هناك أي شيء آخر يمنع تغيير فئة ES ، أو ذلك بالضبط؟

لا يزال هناك الكثير من الأشياء في الجوهر لم يتم توسيعها في الأمثلة ، فلماذا لا نبدأ بذلك؟

قائمة البرامج النصية لم يتم تمديدها بأمثلة .

تحرير: تم تحديث القائمة!

الحواجز هي أقسام مثل هذه:

https://github.com/mrdoob/three.js/blob/6865b8e6367d0ce07acbacfae6663c4cce3ac21e/examples/js/loaders/ColladaLoader.js#L6 -L12

https://github.com/mrdoob/three.js/blob/6865b8e6367d0ce07acbacfae6663c4cce3ac21e/examples/js/cameras/CinematicCamera.js#L38 -L39

https://github.com/mrdoob/three.js/blob/6865b8e6367d0ce07acbacfae6663c4cce3ac21e/examples/js/controls/OrbitControls.js#L1149 -L1150

استخدام THREE.<class>.call و Object.create( THREE.<class> هو الأنماط الأكثر احتمالاً. مما يعني أنه لا يمكن تحويل Loader و EventDispatcher و PerspectiveCamera (من بين العديد من البرامج الأخرى على الأرجح) إلى فئات.

https://github.com/mrdoob/three.js/commit/1017a5432eede4487436d6d34807fda24b506088

حسنًا ، أعتقد أنه يمكننا البدء بـ let و const في src/ .

DefinitelyMaybe هل هذا شيء تود المساعدة فيه؟

🎉 💯 الجحيم نعم!

أردت فقط أن أثير قلقًا من أنه إذا كنت تقوم بتحميل رمز ساخن ، فإن خوفي هو أن يتسبب في حدوث مشكلات. إذا كان صحيحًا في جميع جافا سكريبت أن الكائنات تحل محل الثابت تمامًا ، فلا مشكلة. للأسف ، إذا لم يفعلوا ذلك ، فلا ينبغي استخدام جميع const. أقوم فقط بدمج هياكل الكائنات مع وظائف التعليمات البرمجية المخصصة لمفاتيح أشجار الكائنات (مثل الهياكل) ، لذلك أتجنب الحاجة إلى استخدام let أو const في معظم الأحيان.
على أي حال ، إنه شيء يجب التفكير فيه وأعتقد بشكل أساسي أنه لا ينبغي استخدام const وهي غير ضرورية حقًا. بشكل رئيسي لمخاوفي مع تحميل الرمز الساخن.
ما زلت أعتقد أنها ليست ثابتة كما تعتقد ، لذلك ربما شخص يفهم أن المزيد يمكن أن يشرح أنه لا معنى له في إعادة تحميل الاستيراد أو أي شيء آخر. شكرا لك على النظر والمدخلات.
يجب ألا يكون هناك "دع"! أخيرا.

قال كروكفورد إن var كان خطأً كبيرًا ولكن لا يمكن تغييره ، لذلك تم إنشاء "let" ولكن يعتبر var معيبًا ويجب أن يكون رمز "let" إصلاحًا لـ var ، لكنه كان سيكسر عددًا قليلاً من حالات الحافة غير المشفرة المتبقية. يتربص في البرية. الوضع الصارم والرفع هي قضايا حول هذا الموضوع.

MasterJames لا توجد مشاكل على الإطلاق مع إعادة التحميل

أنا أعمل في بيئة React وإعادة التحميل الساخن هي القاعدة هناك ، بالإضافة إلى const و let ، والتي هي المعيار في الوقت الحاضر.

أوافق على أن هذا لن يتداخل مع إعادة التحميل الساخنة. ربما أخطأت في جعل const كائنات غير قابلة للتغيير مع Object.freeze ؟ نحن لا نخطط للقيام بذلك.