kyle: " paul_irish لا أوافق. http://bit.ly/9IfMMN cacheability (CDN's الخارجية) ، تنزيل موازي ، تغيير البرنامج النصي ..."

james burke : " يوجد لدى RequireJS أداة بناء للقيام بتجميع / تصغير البرنامج النصي ، لذلك يمكن الحصول على أفضل ما يلي: ديناميكي ومنشئ مسبقًا"

ربما تكون أسهل طريقة للمطورين لبدء تحميل البرنامج النصي هي استخدام $ Lab.js ، لأنه يستخدم بالفعل بناء جملة متسلسل يعرفه مستخدمو jQuery.

إذا كانوا ينشئون تطبيقات مؤسسية كبيرة ، فيمكنهم دائمًا الترحيل إلى request.js إذا لزم الأمر.

يوجد حاليًا ثلاث تقنيات رئيسية لتحميل البرنامج النصي:

1. رئيس JS
2. التحكم
3. لابجس

استخدمه أم لا ، أيهما يمكن استخدامه قابل للنقاش: http://blog.getify.com/2010/12/on-script-loaders/

هناك أيضًا يتطلبان JS و EnhanceJS فقط لإعلامك بالبدائل لـ HeadJS ControlJS و LabJS . حتى ياهو وجوجل يقدمان شيئًا مشابهًا.

مع إصدار jQuery 1.5 والمؤجل - http://www.erichynds.com/jquery/using-defirmeds-in-jquery/ ، استخدمها بوريس مور في DeferJS ، وهو مشروع محمل نصوص جديد: https: // github. كوم / BorisMoore / DeferJS

يؤدي تحميل البرنامج النصي افتراضيًا إلى إيقاف جميع التنزيلات الأخرى ، لذا يعد تنزيل modernizr في العنوان أمرًا سيئًا. إن أداة التحميل المضمنة منطقية ، لأن برامج التحميل يمكنها تنزيل البرنامج النصي بالتوازي وليس في وضع الحظر. على سبيل المثال ، إذا لم تكن بحاجة إلى جميع ميزات modernizr ، فيمكنك تضمين head.min.js الذي يبلغ حجمه 6 كيلو بايت فقط أو إنشاء مخصص من modernizr (http://modernizr.github.com/Modernizr/2.0-beta/). أحيانًا يكون تضمين CSS منطقيًا أيضًا. تستخدم Google المضمنة ، وهي css و js مضمنة وصور متحركة فارغة 1x1 من خلال البيانات.

أصبح LabJS مستخدمًا على نطاق واسع وهو حل جيد - كما يمكن تضمينه بشكل غير متزامن بحيث لا تحتاج إلى حظره.

http://blog.getify.com/2010/12/on-script-loaders/ بواسطة المؤلف

http://yepnopejs.com/ ذهب للتو 1.0 ولم ينكسر في webkit الجديد ، على عكس LAB و head.js. تحميل البرنامج النصي صعب.

تم أيضًا دمج yepnope في Modernizr كـ Modernizr.load .. http://modernizr.github.com/Modernizr/2.0-beta/

لذلك من المحتمل أن يكون لدينا مُحمل نصوص في h5bp عن طريق Modernizr.load قريبًا.

لا أعتقد أنه سينتج 1.0 ولكن بمجرد أن أقوم برفع Modernizr إلى 1.8 سنقوم بإلقاء ذلك في h5bp 1.1. أجل

مرحبا بول

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

ما الذي تنصح باستخدامه في الوقت الحالي؟

1. قم بتضمين yepnope.js مع modernizer.js في أعلى الصفحة
2. قم بتضمينه في أسفل الصفحة ، ليتم تحميله بعد انتهاء تحميل HTML.
3. استخدم الإصدار التجريبي من modernizer.js
4. يمكنني ربط yepnope.js مع modernizer.js في تضمين واحد.

بغض النظر عن أفضل طريقة لتضمينها ، كيف توصي بتحميل البرامج النصية باستخدام yepnope ، js؟

أعتقد أنه يجب علينا القيام بذلك هنا: https://github.com/paulirish/html5-boilerplate/blob/master/index.html#L52 واستخدام yepnope لتحميل نسخة CDN / المحلية من jQuery والنصوص الأخرى الخاصة بنا.

ولكن ، هل تعتقد أنه من الأفضل استخدام برنامج نصي خارجي يتضمن كتلة نصية أو يعرضها داخل html ، والذي يقوم بعد ذلك بتحميل البرامج النصية عبر yepnope.js؟

تشكرات.

آندي

أوه وشيء آخر.

نظرًا لأنه يمكن لـ yepnope تحميل css عبر ، أود أن أقول أنه من الأفضل تضمين css الرئيسي كما تفعل عادةً واستخدام yepnope لتضمين css لإصلاحات محددة فقط.

على سبيل المثال ، تضمين بعض ملفات css التي يتم تطبيقها فقط على الإصدارات الأقدم من IE.

هوكابوكا

استخدم الإصدار التجريبي من modernizr .. فقط قم بتضمين ما تحتاجه (وقم بتضمين Modernizr.load() ) ثم ضع ذلك في أعلى الصفحة.

الكود الفعلي لـ jquery الاحتياطي مع yepnope موجود على http://yepnopejs.com/

ونعم تعجبني فكرتك عن الحمل الشرطي لـ IE css.

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

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

وبالتالي.

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

لقد أجريت قدرًا كبيرًا من البحث حول concat مقابل الحمل الموازي. ما زلت ، دون تحفظ ، أوصي بدمج جميع js في ملف واحد أولاً ، ثم تقسيمها إلى 2-3 ~ قطع متساوية الحجم ، وتحميلها بالتوازي.

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

إذا كان بإمكاني / يمكننا حل مشكلة النطاق الترددي للاختبار ، فلدي الاختبارات التي يمكن إجراؤها لمعرفة ما إذا كانت نظرية التحميل الموازي قابلة للتطبيق في الواقع (كما أعتقد).

getify ماذا تحتاج بقدر جهاز اختبار؟

يمكنني عمل حوالي 1.5 تيرابايت من البيانات من خادمي الشخصي أكثر مما أستخدمه حاليًا. لقد قمت بتثبيت Nginx ويمكنه التعامل في مكان ما مع حوالي 4 تريليون كوادريليون نتيجة لكل ميكروثانية. لا أشعر أن التكنولوجيا هي العائق هنا.

إذا كنا قلقين بشأن المواقع ، فيمكننا انتحال زمن انتقال أعلى ، و / أو العثور على شخصين آخرين بهما مساحة إضافية صغيرة في صناديقهم.

راجع للشغل ، أنا أعاني قليلاً من "الإيمان الأعمى".

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

البيان الخاص بك عبارة عن فرضية خاطئة إلى حد ما لأنه يفترض أننا نحاول مقارنة ، لكل موقع ، بالتحميل الموازي مع script-concat. معظم المواقع على الويب لا تستخدم / لا تستطيع في الواقع استخدام script-concat ، لذا فإن المقارنة (بالنسبة لهم ، الأغلبية) ليست دقيقة ومعقدة تمامًا كما تفترض. إذا لم يتمكنوا / لا يمكنهم استخدام script-concat (لأي سبب كان) ، فإن المقارنة بسيطة: التحميل المتوازي يكاد يكون دائمًا فوزًا على علامات البرنامج النصي.

إذا كانوا منفتحين على script-concat (أو يستخدمونه بالفعل) ، فعندئذ نعم ، يصبح الأمر أكثر دقة / تعقيدًا لتحديد ما إذا كان التحميل المتوازي يمكن أن يساعد أم لا. لكن script-concat ليس حلاً واحدًا يناسب الجميع أيضًا ، لذلك هناك الكثير من المواقع التي سيظل التحميل الموازي هو الأسلوب المفضل والأفضل لها.

فقط لأن بعض المواقع تتعامل مع الفروق الدقيقة / التعقيدات في الاختيار بين التحميل المتوازي مقابل script-concat لا يعني أن المناقشة الأكبر (الأكثر تأثيرًا) للتحميل المتوازي مقابل علامات النص البرمجي يجب أن تضيع في المزيج. من الصعب إثبات الأول ، لكن الأخير تقريبًا معطى في هذه المرحلة.

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

إنه قسم فرعي أصغر (لكنه مهم) من تلك المواقع التي يمكن أن تستفيد بشكل أكبر من استكشاف script-concat مقابل التحميل المتوازي. لكن حالة استخدام الأقلية ليست ما يجب تحسينه في نموذج معياري.

فقط بضعة سنتات.

تضمين التغريدة

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

علاوة على ذلك ، لدي أكثر من عشرة أنواع مختلفة من هذا الاختبار أعتقد أننا بحاجة إلى استكشافها. لذا ، فإن عشرات المرات من استخدام 100-200 جيجابايت من عرض النطاق الترددي سيكون كل منها باهظ التكلفة بالنسبة لي لدفع الفاتورة. لم أكن أرغب في البدء في هذا الطريق إلا إذا كنت متأكدًا من أن لديّ نطاق ترددي كافٍ لإنهاء المهمة.

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

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

يمكنني عمل عدد غير محدود من تيرابايت على خادم الأحلام الخاص بي ، لذا لن تكون هذه مشكلة. في الوقت الحالي ، أعمل 72 جيجابايت / يوم ويمكنني التعامل مع المزيد. :)

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

تنص فقرتك الأولى على أنه "سهل" و "يمكن إثباته" و "بدون سؤال" حيث تعمل برامج تحميل البرامج النصية على تحسين الأداء.

لقد قدمت افتراضًا مشابهًا لـ وقمنا بتجميع بعض الصفحات المتطابقة بأفضل ما في وسعنا لمحاولة قياس أداء تقنياتنا الأفضل. إنه معجب بـ concat بنسبة 100٪ ، وقد جربت تقنيتين مختلفتين لتحميل البرنامج النصي.

https://github.com/SlexAxton/AssetRace

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

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

أعتقد أن السيناريو الأسوأ هو أن الناس يأخذون شيئًا مثل yepnope أو lab.js ويستخدمونه كعلامة نصية polyfill. سيؤدي ذلك بالتأكيد إلى تحميل أبطأ (لملفات الـ 19 JS و 34 CSS الخاصة بهم) ، بالإضافة إلى تقديم عدد كبير من مشكلات التوافق العكسي والأمامي التي لن يكونوا على دراية بها تمامًا.

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

تضمين التغريدة

... أظهرت النتائج في أحسن الأحوال أن أداة تحميل البرامج النصية هذه كانت بنفس سرعة طريقة concat (مع إرشادات التحميل المتوازي ذات الحجم المماثل التي تم اتباعها من 3 ملفات) ...

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

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

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

لقد ساعدت حرفيًا أكثر من 50 موقعًا مختلفًا على الانتقال من علامات البرامج النصية إلى LABjs ، وبدون فشل المواقع شهدت تحسينات في الأداء على الفور. في وقت مبكر من الجهود ، أخذت عينات من 7 أو 8 مواقع ساعدتها ، وشهدوا بشكل جماعي تحسنًا بنسبة 15٪ في سرعة التحميل. بالنسبة للمواقع الأربعة أو الخمسة التي أديرها ، قمت بالطبع بتنفيذ LABjs ، ورأيت على الفور سرعة تحميل تصل إلى 3x.

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

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

ألق نظرة على المخططين الموجودين في الشريحة 10 من هذه المجموعة:

http://www.slideshare.net/shadedecho/the-once-and-future-script-loader-v2

قارن بين موضع الخط الأزرق (جاهز لـ DOM). يعد هذا تحسنًا كبيرًا في الأداء المتصور (UX) ، حتى لو لم يكن وقت تحميل الصفحة الإجمالي (أو الوقت لإنهاء تحميل جميع الأصول) أفضل.

... يقدم h5bp أداة بناء نص برمجي ...

الافتراض الخاطئ هنا هو أنه لمجرد أن h5bp يقدم هذه الأداة ، فإنه يمكن لجميع (أو حتى معظم) مستخدمي h5bp استخدامها. حتى لو استخدمه 100٪ من مستخدمي h5bp _do_ ، فإن هذا لا يعني أنه إذا تم نشر h5bp على الإنترنت الطويل ، فإنهم جميعًا سيستخدمون أداة concat. هناك مجموعة من العوامل الأخرى التي يمكن أن تمنع بسهولة أي شخص من استخدام ذلك. هناك _قليلة_ من الأسباب التي تجعل شخصًا ما لا يمكنه الانتقال من استخدام علامات البرنامج النصي إلى استخدام أداة تحميل البرامج النصية المتوازية.

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

أعتقد أن السيناريو الأسوأ هو أن الناس يأخذون شيئًا مثل yepnope أو lab.js ويستخدمونه كعلامة نصية polyfill. سيؤدي ذلك بالتأكيد إلى إبطاء التحميل ...

لم أستطع الاختلاف مع هذا البيان أكثر. تم تصميم LABjs خصيصًا ليكون علامة البرنامج النصي polyfill. كما أن تحسينات LABj على علامات البرنامج النصي العادية (تجاهل concat النصي في الوقت الحالي) راسخة ولم يتم دحضها بجدية. إذا كان لديك دليل على أن معظم (أو حتى الكثير) المواقع الموجودة التي تستخدم LABjs سيكون من الأفضل الرجوع إلى العلامات النصية ، فالرجاء المشاركة.

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

تقديم عدد كبير من مشكلات التوافق العكسي والأمامي التي لن يكونوا على دراية بها تمامًا.

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

يحتوي LABjs 1.x على مجموعة من الاختراقات المجنونة فيه ، مثل التحميل المسبق لذاكرة التخزين المؤقت ، والتي كانت بالفعل مصدر قلق كبير لكسر مع المتصفحات. لقد قلب LABjs 2.x ذلك رأسًا على عقب تمامًا ، ويستخدم الآن أساليب موثوقة وموحدة للتحميل المتوازي في جميع الحالات ، ويعود فقط إلى الاختراق لمتصفح webkit الأقدم. بالإضافة إلى ذلك ، فإن LABjs 2.x لديه بالفعل فحوصات في اختبارات الميزات لتقنيات تحميل البرنامج النصي قريبًا (نأمل أن يتم توحيدها قريبًا) مثل "التحميل المسبق الحقيقي".

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

للتوضيح قليلاً لماذا أنوي أن يكون LABjs في الواقع عبارة عن علامة نصية متعددة التعبئة ...

1. من الواضح أن المتصفحات الأقدم أقل شأناً في التعامل مع علامات البرامج النصية التي يمكن أن يتعامل معها التحميل الموازي. كان ذلك في "المتصفحات القديمة" (التي كانت الأحدث / الأفضل عندما تم إطلاق LABjs قبل عامين) رأينا تحسنًا في وقت تحميل الصفحة بمقدار 3 أضعاف. بحكم التعريف تقريبًا ، هذا يجعل LABjs علامة متعددة تعبئة أفضل لبرنامج نصي ، لأنه يجلب ميزة (أي أداء التحميل الموازي) إلى المتصفحات التي لا تدعمها بنفسها.
2. من الواضح أن المتصفحات الأحدث أفضل كثيرًا. لكنهم لم يتجنبوا تمامًا فوائد برامج تحميل البرامج النصية. chrome مؤخرًا مثل الإصدار 12 (أعتقد أنه تم إصلاحه أخيرًا في الإصدار 13 كما يبدو) كان لا يزال يحظر تحميل الصور أثناء انتهاء تحميل علامات البرنامج النصي. حتى مع أحدث إصدارات IE و Firefox و Chrome ، فإنهم جميعًا لا يزالون يحظرون استعدادًا لـ DOM أثناء تحميل البرامج النصية ديناميكيًا ، لأنهم جميعًا لا يزالون مضطرين إلى افتراض أن document.write() قد يكون كامنًا.

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

بصراحة ، ما زلت أعتقد أنه يجب علينا تقديم الالتماس لمعايير كائن تحميل البرنامج النصي. إن الاضطرار إلى إنشاء علامة نصية من نوع مختلف عن text / javascript لتشغيل ذاكرة التخزين المؤقت (أو ما هو أسوأ من ذلك ، استخدام علامة كائن أو كائن صورة أو أي إصدار جديد يتطلبه متصفح شائع) يؤدي إلى القفز كثيرًا من الحلقات من أجل لا شيء وسيختلف الأداء اعتمادًا على الكثير من المتغيرات. أستطيع أن أفهم أننا ما زلنا نحمل أوراق الأنماط باستخدام إدراج عقدة dom (ولكن هذا فقط بسبب الترتيب) ولكن عندما يتعلق الأمر بالبرنامج النصي ، أعتقد أنه لم يعد منطقيًا على الإطلاق (أتمنى أن تتوقف Google عن استخدام document.write في معظم نصوصهم ولكن هذه قصة أخرى تمامًا).

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

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

هذا مكثف.

@ jaubourg--

بصراحة ، ما زلت أعتقد أنه يجب علينا تقديم الالتماس لمعايير كائن تحميل البرنامج النصي.

هناك الكثير من الالتماسات الجارية بشأن كيف يمكن للمعايير / المواصفات والمتصفحات أن تعطينا تقنية أفضل لتحميل البرنامج النصي. أول فوز كبير في هذه الفئة منذ سنوات كان "غير متزامن مرتب" ( async=false ) الذي تم اعتماده مرة أخرى في فبراير وهو الآن في كل مستعرض إصدار حالي رئيسي (باستثناء: Opera قريبًا جدًا ، و IE10p2 به ).

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

راجع هذا الويكي لمزيد من المعلومات: http://wiki.whatwg.org/wiki/Script_Execution_Control

الحاجة إلى إنشاء علامة برنامج نصي من نوع مختلف عن text / javascript لتشغيل ذاكرة التخزين المؤقت (أو ما هو أسوأ ، استخدم علامة كائن أو كائن صورة أو أي إصدار جديد يتطلبه متصفح شائع)

هذا يسمى "تحميل ذاكرة التخزين المؤقت" ، وهو اختراق قبيح ومروع. تعمل طريقة LABjs على إلغاء التأكيد على هذا الآن اعتبارًا من الإصدار 2 (يستخدمه فقط كإجراء احتياطي لـ webkit الأقدم). لسوء الحظ ، لا تزال برامج تحميل البرامج النصية الأخرى تستخدمه كآلية تحميل أساسية. ولكن 90٪ من الحاجة إلى "التحميل المسبق لذاكرة التخزين المؤقت" يمكن حلها باستخدام "عدم التزامن المرتب" ، وهو معيار قياسي وليس اختراقًا ، لذلك يجب أن يفضل محملو البرامج النصية حسن التصرف ذلك على "التحميل المسبق لذاكرة التخزين المؤقت" الآن.

لذا ، أوافق على أن "التحميل المسبق لذاكرة التخزين المؤقت" سيء ، ولكن هناك طرقًا أفضل بكثير لاستخدام document.createElement("script") والتي لا تتضمن مثل هذه الاختراقات ، لذلك لا أوافق على أن هذه حجة ضد الاستمرار في الاعتماد على عنصر النص البرمجي للمتصفح تحميل البرنامج النصي. إذا تمكنا من الحصول على "تحميل مسبق حقيقي" ، فسيكون عنصر البرنامج النصي هو كل ما نحتاج إليه. أنا أؤمن بذلك بصدق.

أعتقد أننا نفتقد أكبر نقطة فيما يتعلق بأدوات تحميل البرامج النصية هنا: أن نتمكن من تحميل كود js عند الطلب

أوافق بشدة على أن هذه فائدة مهمة تجلبها برامج تحميل البرامج النصية. لكنها نوع من الحجة الجدلية في هذا الموضوع ، لأن "سكريبت concat" الناس ببساطة لا يستطيعون ، بدون تحميل البرنامج النصي ، حل حالة الاستخدام ، لذلك ليس من المنطقي "مقارنة" الاثنين. يمكنك القول بأنه "مؤيد لـ" سلسلة نصية "جيدة ، نحن لا نهتم بحالة الاستخدام هذه" ، ولكن لا يمكنك القول "يمكننا تقديم حالة الاستخدام هذه بشكل أفضل باستخدام XYZ".

الأداء المتصور _ ضخم ومهم ، أوافق. يعتبر التحميل عند الطلب جزءًا كبيرًا من تحقيق ذلك. سيؤدي التحميل عند الطلب أيضًا إلى تحسين الأداء الفعلي الحقيقي (وليس التصور فقط) لأنه يؤدي إلى تقليل التنزيل الفعلي إذا قمت فقط بتنزيل ما هو مطلوب (تتطلب زيارات قليلة للصفحة 100٪ من الشفرة التي كتبتها).

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

يجب أن أحب التعليقات الطويلة والعاطفية منgetify
كايل ...

إذا كان بإمكاني المساهمة بأي شكل من الأشكال في البحث ، فسأحب ذلك.
لا يبدو أن عرض النطاق الترددي (التكاليف) هو المشكلة ، لذا getify ، ما الذي تقترحه للمضي قدمًا؟
لا تتردد في الاتصال بي عبر البريد الإلكتروني (aaron [at] aaronpeters [dot] أو twitter (aaronpeters)

@ kyle

نعم ، لقد اتبعت مناقشة علامة البرنامج النصي "التحسينات" المتعلقة بالتحميل المسبق وأنا لا أشتري أسلوب "إضافة سمة أخرى على علامة البرنامج النصي" كنهج قابل للتطبيق. لقد رأيت ما فعله بالمواصفات xhr: الكثير من التعقيد فيما يتعلق بالفائدة القليلة التي نحصل عليها في النهاية.

ما هو واضح هو أننا نحتاج إلى حد كبير فقط إلى سلوك التحميل المسبق عند القيام بالإدراج الديناميكي (على سبيل المثال ، القيام بذلك في جافا سكريبت بالفعل) فلماذا على الأرض لا يزال يتعين علينا استخدام حقن العلامات النصية؟ ليس الأمر وكأننا نحتفظ بالعلامة هناك أو نستخدمها كعقدة DOM: إنها مجرد وسيلة لتحقيق غاية لا علاقة لها ببنية المستند.

سأكون أكثر راحة مع شيء من هذا القبيل:

window.loadScript( url, function( scriptObject ) {
    if ( !scriptObject.error ) {
        scriptObject.run();
    }
});

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

بعد قولي هذا ، أتفق معك بنسبة 100٪ على الأداء المتصور ، أردت فقط أن أشير إلى ذلك لأن شعار "دعونا ندمجها معًا" أصبح سريعًا نوعًا من الاعتقاد الذي يطمس الأشياء كثيرًا بالنسبة لذوقي ؛)

fwiw ، يتم دعم defer في IE4 + و Chrome و Safari و FF 3.5+. غير مدعوم في Opera.

هذا يعني أن .... 98.5٪ من المستخدمين لديهم دعم بالفعل script@defer .

getify

ومع ذلك ، فإن defer لديه عدد من المراوغات لذلك ،

التفاصيل بلز؟ لم أر أي شيء عن هذا

هل يتم تنفيذ البرامج النصية ذات المؤجل قبل أو بعد إطلاق حدث جاهز لـ DOM؟

هل يتم الاحتفاظ بأمر التنفيذ في جميع المتصفحات؟

ماذا عن أمر exec والاقتران الخارجي بالنصوص المضمنة؟

@ paulirish--

... 98.5٪ من المستخدمين لديهم دعم script @ defer بالفعل.

قد يكون الدعم موجودًا في العديد من المتصفحات ، لكن هذا لا يعني أنه يمكن الاعتماد عليه في العديد من المتصفحات. هذا ما قصدته. (انظر أدناه)

ومع ذلك ، هناك عدد من المراوغات لذلك ،

التفاصيل بلز؟ لم أر أي شيء عن هذا

Lemme انظر ... IIRC:

1. دعم التأجيل لعناصر النص الديناميكي غير معرّف أو مدعوم في أي متصفح ... يعمل فقط مع علامات البرنامج النصي في الترميز. هذا يعني أنه عديم الفائدة تمامًا لتقنيات وحالات الاستخدام "عند الطلب" أو "التحميل البطيء".
2. أعتقد أنه كانت هناك حالة حيث سيبدأ تنفيذ البرامج النصية المؤجلة في بعض المتصفحات على الفور قبل تنشيط DOM الجاهز ، وفي حالات أخرى ، حدث ذلك فور بدء تشغيل DOM الجاهز. سوف تحتاج إلى القيام بالمزيد من الحفر لمزيد من التفاصيل حول ذلك.
3. defer المستخدم في علامة البرنامج النصي التي تشير إلى مورد خارجي يتصرف بشكل مختلف عن defer المحدد في علامة البرنامج النصي مع التعليمات البرمجية المضمنة فيه. وهذا يعني أنه لا يمكن ضمان العمل على تأجيل كلا النوعين من البرامج النصية وجعلها تعمل بالترتيب الصحيح.
4. يختلف defer على علامة البرنامج النصي المكتوبة بواسطة عبارة document.write() عن علامة البرنامج النصي في الترميز باستخدام defer .

ليس لدي الكثير من التفاصيل الجاهزة في متناول يدي حول هذه القضايا. أتذكر منذ حوالي عامين (قبل LABjs) محاولة استخدام defer ، والتعامل مع عدد كافٍ منهم في اختبار عبر المتصفحات التي وضعتها جانباً بشكل أساسي ولم أقم بزيارتها كثيرًا منذ ذلك الحين.

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

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

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

اسمح لي بإعادة الصياغة من الأعلى: "بالنسبة إلى المتصفحات الحديثة ، يعد LABjs نوعًا من" تعبئة متعددة "لسلوك" غير متزامن مرتب "، وهو أمر لا يمكن اختياره في الترميز فقط في أي متصفح."

أنا أحب "أمر غير متزامن" ، هذه عبارة جيدة.

Kyle> afaik ، ستنفذ السكربتات ذات المؤجل _before_ ، حتى قبل domready.
سيتم تنفيذ البرامج النصية ذات السمة غير المتزامنة في أسرع وقت ممكن ، و _ دائمًا_ _قبل_ التحميل ، ولكن ليس بالضرورة قبل domready

@ aaronpeters--
أعتقد أنك قد تكون خارج المسار قليلاً. إليك كيف أفهمها:

سيتم تنفيذ البرامج النصية async (سواء في الترميز أو التي تم إنشاؤها ديناميكيًا) في أسرع وقت ممكن ، أي في أي وقت قبل أو بعد جاهزية DOM. بكلمات أخرى ، يجب ألا تنتظر البرامج النصية async أي شيء (باستثناء توفر محرك JS نفسه). ومع ذلك ، إذا تم طلبها قبل window.onload ، فعندئذٍ في جميع المتصفحات تقريبًا سوف "توقف" الحدث window.onload حتى يتم تحميلها وتنفيذها. أعتقد أنه كانت هناك حالة موثقة حيث لم تصمد البرامج النصية async window.onload ، فقط لم تتذكر التفاصيل الدقيقة.

من ناحية أخرى ، يعني defer تحديدًا: انتظر حتى تصبح جاهزًا لـ DOM. علاوة على ذلك ، هناك "قائمة انتظار" لجميع النصوص البرمجية التي تم تعيينها على defer ، بحيث لا تتم معالجة قائمة الانتظار إلا بعد أن تكون جاهزة لـ DOM وهذا يعني أنه يجب عليهم جميعًا التنفيذ بشكل صارم بعد استعداد DOM (أو بدلاً من ذلك ، بعد DOM جاهز وتم الانتهاء من التحليل ، على وجه الدقة). لكنها قد تتأخر أكثر (إذا كان التحميل يسير ببطء). يجب أن يحملوا window.onload رغم ذلك. أتذكر فقط من الذاكرة السابقة الغامضة أنه في بعض إصدارات IE كانت الممارسة الفعلية لهذه النظرية غامضة بعض الشيء.

getify

لم أكن أرغب في إخراج هذا الموضوع عن مساره أكثر من ذلك ، لذا قمت بنشر أفكاري حول التحميل المسبق للبرنامج النصي واقتراحك على صفحة WHATWG هنا: http://jaubourg.net/driving-a-nail-with-a-screwdriver-the-way -ويب

سيتم تنفيذ البرامج النصية async (سواء في الترميز أو التي تم إنشاؤها ديناميكيًا) في أسرع وقت ممكن ، أي في أي وقت قبل أو بعد جاهزية DOM. بكلمات أخرى ، يجب ألا تنتظر البرامج النصية async أي شيء (باستثناء توفر محرك JS نفسه). ومع ذلك ، إذا تم طلبها قبل window.onload ، فعندئذٍ في جميع المتصفحات تقريبًا سوف "توقف" الحدث window.onload حتى يتم تحميلها وتنفيذها.

ربما يكون هذا أسهل للفهم بمجرد أن تدرك أن JavaScript مترابط واحد. (أعلم أن الأمر استغرق مني بعض الوقت ...)

وبالمثل ، إذا كنت تستخدم setTimeout(fn, 0) لتنزيل الموارد ، ودخلوا قائمة انتظار التنزيل قبل إطلاق onload ، فإن تحميل هذه الموارد (لا يزال) يؤخر onload .

أعتقد أنه كانت هناك حالة موثقة حيث لم تصمد البرامج النصية async window.onload ، فقط لم تتذكر التفاصيل الدقيقة.

أود الحصول على مزيد من المعلومات حول هذا. أرجوك تذكر! :)

ياي محمل البرنامج النصي!

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

وبالتالي ، بدأت في مشروع علمي لمحمل البرامج النصية (Boot.getJS) للتعامل مع هذا الأمر. الفكرة هي تنزيل جميع السكربتات بشكل متوازٍ وتنفيذها بالترتيب مهما حدث وبأسرع وقت ممكن. كما يدعم التأجيل للتجهيز أو التحميل والتخزين المؤقت للنصوص. يتم استعارة (سرقة) معظم الأفكار من قبل الأشخاص في هذا الموضوع ، لذا شكرًا يا رفاق. :)

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

http://artzstudio.com/files/Boot/test/benchmarks/script.html

لمعرفة كيف تتصرف برامج التحميل المختلفة ، امسح ذاكرة التخزين المؤقت ، وراقب طلبات الشبكة والوقت الأخير بالإضافة إلى ترتيب تنفيذ البرامج النصية.

Dave (artzstudio) ، txs لمشاركة أفكارك والرابط إلى صفحة الاختبار الخاصة بك.

سؤال: لماذا تقوم بتحميل LABjs على علامة "<script> في الصفحة الرئيسية"؟ يبدو أن هذا خطأ.

artzstudio أيضًا ، أنت تستخدم إصدارًا قديمًا من LABjs. هل هذا متعمد؟ إذا كان الأمر كذلك لماذا؟

aaronpeters في AOL لدينا نصوص برمجية مثل Omniture رمز إعلان (والمزيد) التي تحتاج إلى

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

لمعلوماتك (آمل أن يكون هذا مثيرًا للاهتمام / مناسبًا إلى حد ما) ، أجريت بعض الاختبارات على Webpagetest.org لمعرفة ما يحدث في IE8 عند تحميل بعض صفحات اختبار artzstudio .
علامات البرنامج النصي: http://www.webpagetest.org/result/110810_C7_752b756180e132f50a3ef065e9e059ca/
Yepnope: http://www.webpagetest.org/result/110810_8S_a53f4ed2e16179c328fc57c572e71076/
LABjs: http://www.webpagetest.org/result/110810_ZV_1ece92044799e52ed5199aed6b407133/
RequireJS: http://www.webpagetest.org/result/110810_Z3_a1537e41a0b0570286151859973d0cfa/

فيديو يقارن بين Yepnope و LABjs: http://www.webpagetest.org/video/view.php؟id=110810_074cb94c1b04a7ac9bd6538ec3fdd8d3c07f842d

بعض الملاحظات:

• Gzip مغلق على الخادم ، لذا فإن الطريقة التي يكون بها حجم الملف الأكبر لـ RequireJS لها تأثير
• كما ذكرنا سابقًا ، تُحمِّل صفحة علامات البرنامج النصي LABjs في HEAD (لا معنى لها) وهذا بالطبع له تأثير

لهذين السببين أنشأت مقطع فيديو يظهر فقط Yepnope و LABjs.

ما أجده مثيرًا للاهتمام هو أن وقت بدء العرض أفضل كثيرًا لـ LABjs. لماذا هذا؟ أحب أن أفهم بشكل أفضل.

ملاحظة ختامية: أنا لا أنشر هذا بهدف تفضيل LABjs على Yepnope أو أي شيء من هذا القبيل. مجرد مشاركة البيانات ...

آسف ، أرى ما تعنيه بخصوص LABjs في اختبار <script>. تم الإصلاح الآن ، بالإضافة إلى الترقية إلى LABjs.

@ artzstudio--

وبالتالي ، بدأت في مشروع علمي لمحمل البرامج النصية (Boot.getJS) للتعامل مع هذا الأمر. الفكرة هي تنزيل جميع السكربتات بشكل متوازٍ وتنفيذها بالترتيب مهما حدث وبأسرع وقت ممكن

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

على أي حال ، بقدر ما أحب التباهي بـ LABjs ، لا أعتقد أنه من الفعال أن أتعطل هذا الموضوع من خلال نوع المناقشات "انظر ، محمل البرنامج النصي الخاص بي أفضل في X". هذه المناقشات مفيدة ، ولكن في مكان آخر.

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

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

إذا اكتشفنا أن علامات البرنامج النصي هي ببساطة أفضل من تحميل البرنامج النصي ، فيمكننا حينئذٍ إيقاف كل هذا الجنون وإغلاق جميع مشاريعنا. أظن أن الأمر لن يكون كذلك. ؛-)

المهمة رقم 2 هي اكتشاف مرة واحدة وإلى الأبد ما إذا كان script-concat دائمًا أفضل من التحميل المتوازي. مرة أخرى ، تُظهر فرضيتي (والاختبارات التي أجريتها) أن تجميع جميع الملفات في ملف واحد أمر جيد ، ولكن بعد ذلك يتعين عليك تقسيم هذا الملف الكبير إلى 2-3 قطع متساوية تقريبًا وتحميل هذه الأجزاء بشكل متوازٍ. لذا ، نحتاج حقًا إلى اختبار هذه النظرية أيضًا.

إذا اكتشفنا أن script-concat هو الأفضل دائمًا ، مرة أخرى ، لا تزال أدوات تحميل البرامج النصية مفيدة عندما تفكر في أن معظم المواقع تقوم بتحميل البرامج النصية من أكثر من موقع واحد (jquery من Google CDN ، وتحليلات google من google ، وأزرار facebook / twitter / g + ، إلخ). لذلك سنحتاج بعد ذلك ، كمهمة رقم 3 ، إلى تحديد ما إذا كانت concat أفضل بكثير بحيث يجب عليك استضافة النسخ الخاصة بك من كل هذه الملفات ، مع تجميعها مع التعليمات البرمجية الخاصة بك.

كايل ، هل يمكنك عرض مصدر المثال الخاص بي وإخباري كيف يمكنني استخدام أداة LabJS لتنفيذ جميع البرامج النصية على الصفحة بالترتيب (حتى خارج السلسلة)؟ كان من الممكن أن أكون قد أخطأت في قراءة واجهة برمجة التطبيقات (كما قال بول ، برامج تحميل البرامج النصية صعبة ،٪ -).

في 10 آب (أغسطس) 2011 ، الساعة 9:09 صباحًا ، كتب [email protected] :

@ artzstudio--

وبالتالي ، بدأت في مشروع علمي لمحمل البرامج النصية (Boot.getJS) للتعامل مع هذا الأمر. الفكرة هي تنزيل جميع السكربتات بشكل متوازٍ وتنفيذها بالترتيب مهما حدث وبأسرع وقت ممكن

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

---

على أي حال ، بقدر ما أحب التباهي بـ LABjs ، لا أعتقد أنه من الفعال أن أتعطل هذا الموضوع من خلال نوع المناقشات "انظر ، محمل البرنامج النصي الخاص بي أفضل في X". هذه المناقشات مفيدة ، ولكن في مكان آخر.

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

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

إذا اكتشفنا أن علامات البرنامج النصي هي ببساطة أفضل من تحميل البرنامج النصي ، فيمكننا حينئذٍ إيقاف كل هذا الجنون وإغلاق جميع مشاريعنا. أظن أن الأمر لن يكون كذلك. ؛-)

المهمة رقم 2 هي اكتشاف مرة واحدة وإلى الأبد ما إذا كان script-concat دائمًا أفضل من التحميل المتوازي. مرة أخرى ، تُظهر فرضيتي (والاختبارات التي أجريتها) أن تجميع جميع الملفات في ملف واحد أمر جيد ، ولكن بعد ذلك يتعين عليك تقسيم هذا الملف الكبير إلى 2-3 قطع متساوية تقريبًا وتحميل هذه الأجزاء بشكل متوازٍ. لذا ، نحتاج حقًا إلى اختبار هذه النظرية أيضًا.

إذا اكتشفنا أن script-concat هو الأفضل دائمًا ، مرة أخرى ، لا تزال أدوات تحميل البرامج النصية مفيدة عندما تفكر في أن معظم المواقع تقوم بتحميل البرامج النصية من أكثر من موقع واحد (jquery من Google CDN ، وتحليلات google من google ، وأزرار facebook / twitter / g + ، إلخ). لذلك سنحتاج بعد ذلك ، كمهمة رقم 3 ، إلى تحديد ما إذا كانت concat أفضل بكثير بحيث يجب عليك استضافة النسخ الخاصة بك من كل هذه الملفات ، مع تجميعها مع التعليمات البرمجية الخاصة بك.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment -1772315

قد يعتقد المرء أن الفيزياء تقول إن concat هي الأفضل. كل اتصال HTTP جديد هو بداية بطيئة أخرى + ضريبة 100 مللي ثانية في سيناريوهات الحالة الأسوأ من CDN.

لكن الحقيقة حول المستندات هي أنها يمكن أن تكون طويلة جدًا. لذا فإن تحميل ملف BFJS واحد في الرأس قد يؤدي دون داعٍ إلى إبطاء تهيئة الوحدات. تحميله في النهاية يمكن أن يسبب FOUC مزعج. قد تكون هناك آثار متعلقة بالهاتف المحمول على الملفات الكبيرة: http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

أعتقد أن هذا هو الدافع وراء قاعدة Souders "تقسيم الحمولة" (http://oreilly.com/server-administration/excerpts/9780596522315/splitting-the-initial-payload.html). نحن بحاجة إلى القيام بما يمكن إدراكه بشكل أسرع أيضًا.

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

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

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

getify : أعلم أن هذا مجرد تبول في العرض في هذه المرحلة ، ولكن لا يزال.

إذا اكتشفنا أن علامات البرنامج النصي هي ببساطة أفضل من تحميل النص البرمجي ،
عندها يمكننا إيقاف كل هذا الجنون وإغلاق جميع مشاريعنا.
أظن أن الأمر لن يكون كذلك. ؛-)

يمكنني أن أقول الكثير من الأشياء عن زيت الثعبان ، لكن العرض التوضيحي سيعمل أيضًا:

http://jashkenas.s3.amazonaws.com/misc/snake-oil/labjs.html

http://jashkenas.s3.amazonaws.com/misc/snake-oil/vanilla.html

هذه صفحة بها 100 كيلو من النص و 10 صور و 171 كيلو من جافا سكريبت. يستخدم إصدار الفانيليا ملفًا مصغرًا واحدًا يتضمن jQuery و jQuery-UI و Underscore و Backbone ، بالإضافة إلى ملف timer.js الذي يكتب نتائج وقت التحميل. يقوم إصدار LABjs بتحميل كل ملف من ملفات JavaScript الخمسة (المصغرة بشكل منفصل) باستخدام LABjs.

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

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

بكل الوسائل ، أوقفوا الجنون.

jashkenas ممتلئ ، 100٪ ack. تقوم برامج تحميل البرنامج النصي فقط بإضافة النفقات العامة والتعقيدات ونقاط الفشل. يتم تحميل ملف واحد متسلسل من الخادم بسرعة (est) ، سواء من حيث وقت النقل الخالص أو من حيث كفاءة مترجمي JavaScript ، وكمكافأة ، يعمل gzipping بشكل أفضل إذا كان لديك ملف واحد فقط.

يجب أن أقول ، يتم تحميل إصدار LABjs _ في بعض الأحيان_ بشكل أسرع في المتصفح (مقارنة بصفحة الفانيليا) ، ولكن ليس باستمرار. أيضًا onload لا يتم إطلاقه دائمًا ، وهو ما يبدو ... غريبًا.

نعم ، يمنحك gzipping ربحًا عامًا أكبر مع طلبات HTTP أقل.

وهذا لا يتعلق بالعقيدة ، ولا يجب أن يكون ملف JS واحدًا للتطبيق بأكمله - ملفان أو ثلاثة مع defer مناسبان للتخزين المؤقت الدقيق ، كما يتم تحميل المزيد لاحقًا.

بعض الأبحاث التي أجراها فريق Google Page Speed:

http://pagespeed-velocity2011.appspot.com/#8 راجع الشرائح 8-14 ، والتي تضفي مزيدًا من عدم الحسم على المناقشة

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

miketaylr : نعم ، الرجاء تحديث كل صفحة عدة مرات للحصول على شعور عام. ستجعل فترات انتقال S3 وتحميل الصور الأمور غير متوقعة إلى حد ما - تتصرف مثل تطبيق حقيقي.

يتم تحميل Well labjs _always_ بشكل أسرع في متصفحي (Safari 5.1) حتى مع تحديث التحول أو عند تخزين العناصر مؤقتًا.

بالطبع ، سيكون استخدام أداة تحميل البرنامج النصي بدون التسلسل أبطأ من علامة البرنامج النصي المتسلسلة. لهذا السبب قام الأشخاص (YUI، needJS) بإنشاء برامج تحميل البرامج النصية التي تقوم بتحميل الملفات والخدمات المتسلسلة التي تربطها عند الطلب (https://github.com/rgrove/combohandler).

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

لدي شك خادع في أن madrobby يبالغان في تبسيط الأمور.
يقترح ستيف

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

أتفق مع jdalton : لا يوجد محمل بحجم مناسب للجميع. أنا شخصياً أستخدم برامج تحميل نصوص مختلفة بناءً على احتياجاتي ومشاريعي الفعلية. أحيانًا يكون شيء بسيط مثل yepnope أو LabJS جيدًا ، والبعض الآخر ، RequireJS هو هبة من السماء. لست متأكدًا من أن اللوح المعياري يجب أن يجبر أحدًا على الدخول. إنه أمر صعب لأن الفكرة ستكون أن تجعل اللوح المعياري من السهل التبديل إلى محمل البرنامج النصي ... لذلك لن أرمي الطفل بماء الحمام فقط بعد إما.

أيضًا ، getify ، التظاهر بأن جميع برامج تحميل البرامج النصية تستخدم نفس التقنية الموجودة تحتها هو عبارة غير

لما يستحق...
هذه

var script = document.createElement('script')
script.src = 'foo.js'
document.getElementsByTagName('head')[0].appendChild(script)

أفضل من هذا

<script src="foo.js"></script>

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

re: "إن التظاهر باستخدام جميع برامج تحميل البرامج النصية في الواقع نفس التقنية الموجودة تحتها هو عبارة غير مطلعة على الإطلاق."

إذا لم يفعلوا ذلك بالطريقة المذكورة أعلاه ، فإنهم يفعلون ذلك بشكل خاطئ

حسنًا ، لكي نكون منصفين تمامًا ، فإن استخدام appendChild لم يعد مفضلاً ...: D

ومع ذلك ، أضفت حالة الاختبار هذه إلى AssetRace

https://github.com/SlexAxton/AssetRace/blob/master/asyncconcat.html

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

ded : نحن لا نتحدث عن حظر كبير غير كفء لـ <script> في <head> هنا ... نحن نتحدث عن علامات البرنامج النصي بـ defer أو async السمة <body> ، حيث لا يوجد شيء لحظره.

@ jaubourg--

أيضًا ، getify ، التظاهر بأن جميع برامج تحميل البرامج النصية تستخدم نفس التقنية الموجودة تحتها هو عبارة غير

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

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

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

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

لا ش

تحميل الغضب!

عرض المنشور الأصلي هنا.

أيضً ا ، أي شخص ppl / أشخاص أساءوا من قبل قضيب كارتون: مرحبًا بكم في الإنترنت! أوصي بشدة أن تبدأ رحلتك هنا .

حسنًا ، لقد قمت بإنشاء 3 اختبارات لتوضيح بعض النقاط. أولاً ، علامات البرنامج النصي اليدوي (كالخط الأساسي):

http://labjs.com/dev/test_suite/test-script-tags.php

لاحظ أن DOMContentLoaded (المعروف أيضًا باسم "جاهز لـ DOM") يأتي متأخرًا ، بعد انتهاء البرامج النصية. هذا هو السئ. في حين أن وقت التحميل الفعلي للصفحة قد يكون هو نفسه الاختبارات اللاحقة ، فإن وقت التحميل المتوقع للصفحة سيكون دائمًا أبطأ بكثير إذا تم حظر DOM الجاهز (تنتظر العديد من المواقع حتى يصبح DOM جاهزًا لإرفاق سلوكيات النقر ، تطبيق التحسينات المستندة إلى JS على المحتوى ، وما إلى ذلك).

الآن ، ما يحدث هو أننا نستخدم defer في علامات البرنامج النصي لدينا:

http://labjs.com/dev/test_suite/test-script-defer-tags.php

حسنًا ، هذا جيد ، لقد أصلحنا مشكلة تأخير DOMContentLoaded ، لكن لدينا الآن مشكلة أخرى. لا تعمل كتلة البرنامج النصي المضمن مع defer . يتم تنفيذه على الفور. أووبس. راجع للشغل ، هذا ليس خطأ ، المواصفات تملي هذا على وجه التحديد.

http://labjs.com/dev/test_suite/test-LABjs.php

يحصل اختبار LABjs بشكل أساسي على نفس أرقام الأداء (أو أفضل) مقارنةً باختبار defer ، لكنه لا يفشل في تشغيل الكود المضمّن بعد انتهاء البرامج النصية.

جرب هذه الاختبارات عدة مرات في المتصفحات الحديثة (Chrome 13 ، FF5 ، إلخ). بالنسبة لي ، كان أداء LABjs دائمًا نفس الأداء أو أفضل بالنسبة لاختبار defer . في جميع محاولاتي ، لم أر قط أداء LABjs أسوأ من اختبار defer . جرب هذه الاختبارات في المتصفحات القديمة (مثل FF3.5 أو IE7) ، وسترى أن محمل البرنامج النصي يبدأ في التفوق على الاختبارات الأخرى بكميات ملحوظة.

على الرغم من أن LABjs اختبار ديه أرقام مشابهة ل defer اختبار في أحدث المتصفحات، انها الكسارة الصفقة اذا defer لا يمكن استخدامها ل defer كود ALL (يعمل فقط للرمز الذي يتم تحميله عبر ملف خارجي). تقوم الكثير من المواقع بتحميل البرامج النصية ومن ثم تحتوي على رمز مضمّن لتنشيط / تهيئة الكود الذي تم تحميله للتو. لا يقدم لنا defer أي حل لهذا الأمر.

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

getify

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

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

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

إذا قررت أخيرًا أنني أستحق ما يكفي من الرد الذكي (على عكس إعلان LabJS آخر) ، فقم بذلك على مدونتي ودعنا نحافظ على هذا الموضوع وحده. شكرا لك.

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

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

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

من الواضح أنك لم تستمع إلى 15 مرة قلت فيها إن هذا الموضوع كان له هدف أفضل وهو التركيز على الأسئلة المحددة التي طرحها بول أيرش وأليكس سيكستون: هل defer جيد بما فيه الكفاية؟ هو السيناريو concat أفضل من التحميل الموازي؟

هذه هي الأسئلة الأكثر أهمية.

لا يتم استخدام تقنية "المحمل" الأساسية. هناك منتدى مختلف وأفضل لمناقشة تقنية اللودر الأساسية. فهمت ، أنت لا تحب علامة البرنامج النصي. بخير. اذهب واقض عشرات الساعات في قائمة W3C / WHATWG في محاولة لجعل إيان وآخرين يستمعون إليك. من المحتمل أن يتثاءبوا جميعًا ويقولون "لقد قمنا بالفعل بتجزئة ذلك ، اذهب بعيدًا."

getify : إنشاء اختبارات قامة سخيفة لن يكسبك نقاطًا ، يا صديقي. نعلم جميعًا أن علامات البرنامج النصي المتسلسلة تحظر الصفحة. نحن نعلم أيضًا أن تشغيل كتل البرامج النصية المضمنة قبل البرامج النصية "المؤجلة" لا يمثل مشكلة بأي شكل من الأشكال للمواقع الحقيقية.

إذا قمت بالاختبار لتأكيد سوء فهم مسبق ... فإن اختباراتك ستؤكد دائمًا هذا الاعتقاد الخاطئ. لم يدور النقاش أبدًا حول 20 علامة نصية مقابل 20 تحميل نصي LABjs. يتعلق الأمر بقص JavaScript وتسلسله وتصغيره وتصغيره وتحميله في أقل عدد ممكن من طلبات HTTP ، ثم تخزينه مؤقتًا.

من ناحية أخرى ، لدينا نهج موثوق به ، مدعوم بالمتصفح ، تم اختباره على مدار الوقت ، ويقدم أداء أفضل بشكل واضح على صفحات العالم الحقيقي ؛ ومن ناحية أخرى ، لدينا "تقنية" تم الاختراق معًا والتي في الماضي حطمت بالفعل كل موقع يستخدمها بعد تحديث المتصفح ، وكان أداؤها أسوأ بشكل واضح في المتوسط ​​، مع تباين أكبر بكثير في البطء.

إنه خيار لا يحتاج إلى تفكير.

@ jashkenas--

نحن نعلم أيضًا أن تشغيل كتل البرامج النصية المضمنة قبل البرامج النصية "المؤجلة" لا يمثل مشكلة بأي شكل من الأشكال للمواقع الحقيقية.

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

إذا اقترحpaulirish أن defer جيد بما فيه الكفاية وأن برامج تحميل البرامج النصية ليست ضرورية ، فأنا أشعر أنه من المهم الإشارة إلى السبب في أن defer ليس جيدًا بما يكفي.

قد تهتم فقط بالمواقع المتخصصة القليلة التي تتحكم فيها ، والتي لديك القدرة الكاملة على تحسينها بشكل كبير فيما يتعلق بعمليات الإنشاء ، وما إلى ذلك. ومن ناحية أخرى ، فأنا أهتم بالمساعدة في تحسين الأداء على المواقع الطويلة للإنترنت ، تلك المواقع مع نصف دزينة من علامات البرنامج النصي (بعضها كتل نصية مضمنة!) ، حيث من المحتمل أن يؤدي استخدام نصف دزينة من المكالمات $LAB.script() في الواقع إلى تحسين الأداء. هذا ما كانت LABjs تدور حوله دائمًا. فقط لأنه ليس ما تهتم به لا يعني أنه غير مناسب.

لم يدور النقاش أبدًا حول 20 علامة نصية مقابل 20 تحميل نصي LABjs.

يدور الجدل في هذا الموضوع حول ما إذا كانت 3-4 علامات نصية (مع أو بدون defer ) تؤدي أداءً أسوأ ، أو نفس ، أو أفضل من 3-4 برامج نصية يتم تحميلها ديناميكيًا باستخدام أداة تحميل نصية متوازية. إن "اختباراتي السخيفة" في الواقع تهدف إلى اختبار ذلك بالضبط.

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

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

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

أستطيع أن أرى سبب مناقشة الناس حول استخدام أداة تحميل البرامج النصية التي لا تحل هذه المشكلات. إذا كان الأداء هو النقطة الوحيدة ، وقابل للنقاش ، فمن المؤكد. لكن استخدم أداة تحميل وحدة AMD مثل RequireJS وسيصبح النقاش غير ذي صلة. الوحدات النمطية هي مستقبل JavaScript. يعمل Dave Herman من Mozilla مع أعضاء مجلس إدارة من Apple و Google لإضافة وحدات أصلية إلى اللغة نفسها . ولكن في غضون ذلك ، يمكننا الحصول على جميع الفوائد باستخدام محمل وحدة AMD. لا يتعلق الأمر بالأداء فقط.

getify

لا يمكنك أن تتوقع من الناس أن يعاملك بشكل مختلف عن الآخرين. إن الرعاية ليست طريقة ذكية للحصول على رد فعل لائق (والله أنت ترعى) ، وكما قلت في مدونتي ، لا أعتقد أنك غبي ، أعتقد أنك مهووس (وهو ما تقوله نفسك راجع للشغل) وأنه يضعف بشكل خطير حكمك. كما قلت في منشور المدونة الخاص بي ، لا يعود الأمر إلى W3C أو WHATWG للتعامل مع هذه المشكلة ولكن EcmaScript نفسها: هذه ليست مشكلة متصفح ، إنها مشكلة لغة. الآن ، لا تقدم هذا الرد إذا كنت لا تريد ذلك ، فهذا من اختصاصك.

ربما جئت قاسية لكني فقط أدافع عما أؤمن به.

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

getify

قد تهتم فقط بالمواقع المتخصصة القليلة التي تتحكم فيها ، والتي تمتلكها
القدرة الكاملة على التحسين إلى حد كبير بشأن عمليات البناء ، وما إلى ذلك
من ناحية أخرى ، يهتم بالمساعدة في تحسين الأداء في المواقع ذات الذيل الطويل لـ
الإنترنت ، تلك التي تحتوي على نصف دزينة من علامات البرامج النصية (بعضها نصوص مضمنة
block!) ، حيث من المحتمل في الواقع استخدام نصف دزينة من مكالمات $ LAB.script ()
تحسين الأداء. هذا ما كانت LABjs تدور حوله دائمًا. فقط لأن
ليس ما تهتم به لا يعني أنه غير ذي صلة.

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

يدور الجدل في هذا الموضوع حول ما إذا كان هناك 3-4 علامات نصية (مع أو بدون تأجيل)
يؤدي أداءً أسوأ ، أو نفس ، أو أفضل من 3-4 برامج نصية يتم تحميلها ديناميكيًا باستخدام
محمل نصي موازي. في الواقع ، تهدف "اختباراتي المضحكة السخيفة" إلى
اختبار ذلك بالضبط.

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

الكمون موجود على الإنترنت. قم بتوصيل JS وتصغيره وضغطه بتنسيق gz ، وتحميله في أسفل الصفحة بأقل عدد ممكن من طلبات HTTP. قال ناف.

@ jashkenas--

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

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

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

لو كانت هذه المقالات تقول "حسنًا ، ما عليك القيام به للحصول على مزيد من الأداء هو تعيين مسؤول خادم يفهم gzip ويمكنه تثبيت ruby ​​أو node.js حتى تتمكن من القيام ببعض عمليات الإنشاء الآلية ..." هؤلاء الأشخاص قراءة تلك المقالات سوف تتأرجح وتغادر دون التفكير فيها مرة أخرى. لكني أحب أن أصدق أن عبارة "مرحبًا ، استبدل <script> بالنص ()" كانت رسالة سهلة جدًا بالنسبة لهم لفهمها والتواصل معها.

ما أردته لـ LABjs هو حل بسيط يمكن لأي شخص أن يسقطه بسهولة لاستبدال علامات البرنامج النصي الخاص به دون الكثير من التفكير. أدرك أنه إذا كان بإمكانك استشارة أحد المواقع شخصيًا واكتشاف أفضل التحسينات ، فيمكنك الضغط على الكثير من الأداء في الكثير من المواقع. لكنني أدرك أيضًا أن هذا يتجاوز بكثير قدرتي كشخص واحد لأفعله في ذيل الإنترنت الطويل ، وبالمثل فإن إخبار كل هؤلاء الأم ومواقع البوب ​​"مرحبًا ، اذهب واحصل على نظام إنشاء آلي ، وتأكد من أنه يستخدم gzip" مثل يتحدثون لغة غريبة لهم. OTOH ، لقد كان من الناجح جدًا أن تقول "مرحبًا ، خذ هذه العلامات النصية الثلاثة ، واجعلها 3 مكالمات نصية (). هل ترى كم كان ذلك سهلاً؟"

خلاصة القول ، كان أسلوبي مع LABjs هو ضرب الفاكهة المتدلية.

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

@ jashkenas--

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

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

عثر paulirish على defer :
http://hacks.mozilla.org/2009/06/defer/

انطلاقًا من منظور أداء الأجهزة المحمولة - كما قال توصيله و gzip وإرساله عبر الخط كحزمة واحدة بدلاً من الحصول على طلبات http متعددة بسبب زمن الانتقال الناتج عن اتصالات شبكة الجيل الثالث.

هناك الكثير من الأبحاث التي يتم إجراؤها في استخدام تقنيات مضمنة حيث تقوم بترميز Base64 للصور في سلاسل ثم تخزينها كمفتاح: أزواج http://channel9.msdn.com/Events يعد / MIX / MIX11 / RES04 عرضًا تقديميًا رائعًا بواسطة James Mickens من Microsoft Research.

إليك مجموعة جيدة جدًا عن أداء الأجهزة المحمولة مع طلبات http وتأثيرها على تجربة المستخدم: http://davidbcalhoun.com/present/mobile-performance/

أنا أعمل على RequireJS ، وأريد توضيح ما تهدف RequireJS إلى القيام به:

1) أظهر الطريق للتعليمات البرمجية المعيارية في JS والتي تعمل بشكل جيد في كل مكان يتم تشغيل JS فيه.
2) تحميل البرامج النصية.

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

لكن الهدف من needjs هو أن يكون الرقاقة / polyfill / أيًا كان لإظهار كيفية إنشاء وحدات الكود المعيارية والإشارة إليها والتي يمكن مشاركتها مع الآخرين بطريقة لا تشجع الكرات الأرضية وتشجع التبعيات الواضحة.

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

على وجه الخصوص ، نظرًا لطبيعة شبكة JS وعلاقتها بمستندات / تطبيقات الويب ، فإن واجهة برمجة تطبيقات أداة نماذج أولية للوحدات النمطية للانسجام ES عبر needjs loader plugin ، حتى أتمكن من فهم اقتراح الانسجام بشكل أفضل وتقديم الملاحظات.

لأصحاب الأداء :

• هناك عدد قليل من الخيارات للتحميلات التي تدعم AMD ( curl ، Dojo 1.7 ، loadrunner ، needjs) ، حتى الصغيرة جدًا التي يمكن استخدامها لتحسين "جميع البرامج النصية في ملف JS واحد" للنشر. لذلك من الممكن الحصول على أداء رائع مع تشجيع أفضل ممارسات الترميز - مشاركة أكواد أسهل عن طريق تجنب الكرة الأرضية ، باستخدام التبعيات الصريحة.
• يعمل مُحسِّن needjs بسرعة كبيرة في Node ، ويمكن تشغيله في Rhino. إنها أداة سطر أوامر ، ولكن أحدث كود فرع رئيسي يصدرها كوحدة نمطية قابلة للاستخدام في Node ، لذلك على سبيل المثال ، يمكن تشغيلها عبر خادم http المستند إلى العقدة والذي يمكنه القيام بالبناء بسرعة . لذلك يمكنك دائمًا التطوير في وضع "تنزيل نص برمجي واحد دائمًا" إذا كنت تفضل ذلك ، ولكن بعد ذلك اختر استبعاد وحدة أو وحدتين من هذا الملف المحسن ، حتى تتمكن من تصحيحها بسهولة.

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

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

لإعادة التركيز من وقت سابق ... مقارنة اختبار defer باختبار LABjs ... (وتجاهل حقيقة أن defer لا يعمل على كتل البرامج النصية المضمنة) ، هل يرى أي شخص أن أداء اختبار LABjs أسوأ من اختبار defer ؟ لقد جربته على مجموعة من المتصفحات ، وحتى على جهازي المحمول ، وما زلت أرى أرقامًا متساوية تقريبًا.

http://labjs.com/dev/test_suite/test-script-defer-tags.php

http://labjs.com/dev/test_suite/test-LABjs.php

getify

ليس لدي أي فكرة عن سبب أو كيف يمكنك تحسين هذا ، لكن لدي ، على جهاز MacBook الخاص بي الذي يبلغ عمره 3 سنوات أو أكثر ، فرق 3000 ثابت بين الاثنين ، والذي يفضل @defer .

لقد اختبرت فقط مع Firefox مع ذلك.

@ espadrine - غريب جدا. أحب أن أصل إلى الجزء السفلي من ذلك. ما هو إصدار Firefox الذي تختبره؟ هل يمكنك أن ترسل لي لقطة شاشة للنتائج؟

ما عليك سوى تجميع وتصغير كل JS و CSS وتضمينها في صفحة HTML الخاصة بك والانتهاء من ذلك. طلب HTTP واحد FTW! : ص

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

هل هناك إجماع عام من قبل الأشخاص على هذا الموضوع على أن AMD يجب أن تكون المعيار الذهبي لتنظيم كود JS؟ لم أر بالفعل خيارات أخرى ولكني أوافق على أن Boilerplate سيكون بداية رائعة لإعداد الأشخاص بشكل صحيح في تنظيم الكود.

قناة تحديث Firefox UX 8.0a1 (2011-08-07).

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

من فضلك لا تستخدم صفحة الاختبار getify لأي شيء أكثر من الضحك. يقتبس:

<script defer src = "http://labjs.xhr.me/dev/test_suite/testscript1.php؟_=4911710&delay=5"> <script defer src = "http://labjs.xhr.me/dev/test_suite /testscript2.php؟ _ = 6146431 & delay = 3 "> <script defer src =" http://labjs.xhr.me/dev/test_suite/testscript3.php؟_=9499116&delay=1 ">

getify ، إذا كنت تريد إجراء اختبار حقيقي ، فلا تتردد في تفرع

تأكد أيضًا من ربط JS فعليًا بعلامة نصية واحدة - defer أم لا. النقطة المهمة هي أن نفس المحتوى الذي يتم تقديمه عبر طلب HTTP واحد يتفوق على نفس المحتوى الذي يتم تقديمه عبر 10 طلبات HTTP.

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

ما تم توضيحه أعلاه ، هو أن LABjs تعمل بالفعل على إبطاء المواقع بشكل كبير ، من خلال جعل JS الخاصة بهم تتنافس عبر العديد من طلبات HTTP مع صورهم و CSS وأصول أخرى. getify : أود أن أرى رابطًا إلى موقع تعتقد أنه تم إثباته بشكل كبير من تحويلك إليه إلى LABjs. ربما يمكننا تنزيل نسخة من ذلك ، واستخدامها كحالة اختبار ستحترمها.

للتسجيل ، أعتقد أنه سيكون من الحكمة الحصول على المزيد من الصور في صفحة اختبار AssetRace repo. لكنه بالتأكيد خط أساس جيد في الوقت الحالي.

artzstudio تنظيم JS الخاص بك باستخدام محمل AMD هو بالفعل المعيار الذهبي ، على الأقل حتى يتم الانتهاء من وحدات Harmony ودعمها على نطاق واسع. ثم سيكون هناك مسار انتقال واضح من وحدات AMD إلى الوحدات الأصلية.

تعتبر وحدات AMD المعيار الذهبي بالتأكيد رأيًا (قد أشاركه). ومع ذلك ، هناك الكثير من الأشخاص الأذكياء (يتبادر إلى الذهن يهودا كاتز ودان ويب) الذين لا يحبون ذلك ويقدمون حلولاً أخرى.

يستطيع برنامج تحميل @ danwrong القيام بالأمرين معًا ، إذا كانت هذه هي حقيبتك أيضًا: https://github.com/danwrong/loadrunner

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

أعلم أن strobecorp يعمل على حل خاص بهم لا يتطلب الكثير من التعليمات البرمجية الإضافية التي تتطلبها وحدات AMD.

على الرغم من أنني أرغب في أن تكون AMD هي الخيار الافتراضي ، فربما لا يكون من الحكمة من منظور المكتبات المتعددة / الجديد ، بقدر ما كنت أتمنى أن تكون كذلك.

@ jashkenas--

من فضلك لا تستخدم صفحة الاختبار getify لأي شيء أكثر من الضحك.

إذا كنت لا تستطيع أن تكون متحضرًا ، فليس لدي رغبة في مناقشة أي شيء معك. أنا أتصرف بحسن نية. سأكون ممتنا قليلا من الحشمة المشتركة.

getify ، إذا كنت تريد إجراء اختبار حقيقي

أود بالتأكيد أن تشرح لماذا ما أفعله مجنون للغاية ومضحك وغير صالح. لقد اتخذت النهج مباشرة من Steve Souders ، الذي اقترح (في تجربته الكبيرة وحكمته) في جميع اختباراته أن تستخدم توقيت الخادم للتحكم في البرامج النصية ، مما يقلل من مقدار التباين في اختباراتك. هذا بالضبط ما أفعله.

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

لا تتردد في تفرع مستودع AssetRaceSlexAxton وإضافة إصدار LABjs

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

@ jashkenas--

النقطة المهمة هي أن نفس المحتوى الذي يتم تقديمه عبر طلب HTTP واحد يتفوق على نفس المحتوى الذي يتم تقديمه عبر 10 طلبات HTTP.

أعلم أنك (والآخرين) تستمرون في الصراخ هنا حول الكيفية التي يجب أن تدور بها هذه المناقشة حول concat مقابل not-concat. إذا كنت قد قرأت في وقت سابق من الموضوع ، فقد انتهيت من وجود سؤالين يجب معالجتهما. المسألتان ، على حد علمي ، orthagonal. الأول هو ما إذا كانت علامات البرنامج النصي في الترميز يمكن أن تكون جيدة (أو أفضل) من عناصر النص الديناميكي المستخدمة في محمل البرنامج النصي المتوازي. هذا السؤال هو ما ما زلت أحاول معالجته من خلال اختباراتي.

السؤال الثاني ، الذي لم نصل إليه بعد ، هو حول ما إذا كان Script-concat هو الأفضل دائمًا. أعلم أنك مقتنع بالفعل بذلك ، لكن لدي أدلة مضادة تشير إلى أنه ليس بهذه البساطة. هذا السؤال يحتاج أيضًا إلى اختبار شامل. لكن هذا ليس ما أحاول حله الآن في هذا الموضوع.

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

فيما يتعلق باختبار defer مقابل اختبار LABjs ، قمت للتو بعمل لقطة شاشة سريعة لاختبار الاثنين وجهاً لوجه في IE9 و FF8 (ليلاً) و Chrome15 (كناري).

http://www.screenr.com/icxs

للإجابة على سؤال paulirish السابق (https://github.com/paulirish/html5-boilerplate/issues/28#issuecomment-1765361) حول defer المراوغات ، انظر إلى كيفية تصرف "DOMContentLoaded" عبر IE ، Chrome و Firefox في اختبار defer .

في IE9 و Chrome15 ، يتم تعليق حدث DOMContentLoaded (محظور) ولا يتم تشغيله إلا بعد تشغيل البرامج النصية. ومع ذلك ، في FF ، لا يتم تأجيل حدث DOMContentLoaded ، ويتم تشغيله على الفور ، وتبدأ البرامج النصية في التنفيذ بعده. هذا تناقض كبير عبر المتصفحات الحديثة ، وأحد الأسباب التي تجعلني لا أعتقد أن defer كافٍ.

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

getify أنا لا أحاول أن أكون

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

المسألتان متعامدتان بالفعل (اللغة التي استخدمتها في رسالتي الأصلية).

الأول هو ما إذا كانت علامات البرنامج النصي في الترميز يمكن أن تكون جيدة (أو أفضل) من
عناصر النص الديناميكي المستخدمة في محمل البرنامج النصي المتوازي.

نحن متفقون تمامًا على هذه المسألة - لا يهم. بالطبع سيكون التحميل المتوازي أسرع من التحميل المتسلسل لأكثر من نص برمجي واحد. وبالطبع ، فإن القيام بذلك بطريقة غير محظورة ، إما في نهاية علامة <body> ، أو باستخدام defer ، أو باستخدام أداة تحميل البرامج النصية ، سيكون أفضل من الحظر في <head> .

ولكن هذا يجانب الصواب. يعد وضع علامات نصية متسلسلة بمثابة أداة للمقارنة ، لأنه لن يستخدم أي شخص يهتم بأداء JavaScript الخاص به هذا الأسلوب. خمن ما هو أسرع أيضًا من العلامات النصية المتسلسلة؟ _اى شى_.

السؤال الثاني ، الذي لم نصل إليه بعد ، هو حول ما إذا كان
النص المتسلسل هو الأفضل دائمًا.

لقد وصلنا إلى هذا السؤال. في الواقع ، إنه سؤالpaulirish في أعلى هذه الصفحة. إذا كنت لا تحاول حلها في هذا الموضوع ، فأنت بحاجة إلى ذلك. إنه يحتل صميم كل ادعاءاتك حول ما تفعله LABjs ، ليس فقط في هذا الموضوع ، ولكن على مر السنين.

هذا السؤال يحتاج أيضًا إلى اختبار شامل.

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

http://jashkenas.s3.amazonaws.com/misc/snake-oil/labjs.html

http://jashkenas.s3.amazonaws.com/misc/snake-oil/vanilla.html

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

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

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

إلى تعليق SlexAxton :

بالنسبة لـ loadrunner: ليس من الواضح بالنسبة لي أن بناء الجملة أفضل ، فقط مختلف. يدعم AMD ، لذلك لا يزال يعمل.

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

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

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

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

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

لكني أقدر وجهة نظر SlexAxton . قد يكون التوحيد القياسي على نهج AMD لـ HTML Boilerplate سابقًا لأوانه ، وأنا على ما يرام تمامًا مع ذلك. إذا قرر المشروع المعياري أنه لا يريد اختيار واحد ، فإن AMD هو خيار قوي يناسب طيفًا واسعًا من تطوير JS.

SlexAxton أنا معك. الكود الخاص بي هو AMD على طول الطريق. بينما أتمنى أن يكتب الجميع وحدات بدلاً من البرامج النصية ، لحسن الحظ يمكن لـ RequireJS تحميل البرامج النصية العادية والوحدات النمطية.

إذا كنت تشير إلى نموذج مقبض يهودا ، فهذه تعمل بشكل جيد للغاية مع RequireJS. خاصة إذا قمت بكتابة مكون إضافي يقوم بتجميع / تخزين القالب وإرجاع وظيفة القالب الخاصة به.

define(['tmpl!navigation.html'], function(nav){
   $('body').append(nav(data));
});

أنا لا أتفق مع هذا البيان ولكن:

على الرغم من أنني أرغب في أن تكون AMD هي الخيار الافتراضي ، فربما لا يكون من الحكمة من منظور المكتبات المتعددة / الجديد ، بقدر ما كنت أتمنى أن تكون كذلك.

يحتاج Newbs إلى الهيكل النظيف الذي توفره AMD أكثر من مجرد مطور متمرس ، لأنهم أكثر عرضة للتصادمات المتغيرة العالمية ، وتنظيم الكود الرهيب الذي يؤدي إلى ملفات JS الضخمة الفوضوية التي لا يريد أحد لمسها خوفًا من الاضطرار إلى التعامل مع تعارضات الدمج ، تستفيد المكتبات من الوحدات بشكل كبير ، وهذا هو سبب انتقال Dojo 1.7 و Mootools 2.0 إلى AMD. آمل أن ينضم jQuery إلى اللوحة - واحدة من أكبر شكاويها هي أنه "الكل أو لا شيء". لا يمكنك استخدام معالجة DOM الممتازة دون تحميل الرسوم المتحركة ، و ajax ، والأحداث ، وما إلى ذلك على الصفحة أيضًا. لذا ، نعم ، AMD هو الفوز. إذا أراد HTML5 Boilerplate توجيه الأشخاص إلى أفضل الممارسات ، فسيكون من العار استبعاد AMD. إنه يحل بأناقة الكثير من مشاكل JavaScript.

لنكون واضحين. أنا موافق. أتمنى أنهم استخدموا تتطلب على طول الطريق.

أنا فقط لا أعتقد أنهم سيفعلون ذلك.

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

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

@ jashkenas--

الأول هو ما إذا كانت علامات البرنامج النصي في الترميز يمكن أن تكون جيدة (أو أفضل) من عناصر النص الديناميكي المستخدمة في محمل البرنامج النصي المتوازي.

نحن متفقون تمامًا على هذه المسألة - لا يهم.

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

اقترح paulirish أن defer طريقة كافية لجعل علامة البرنامج النصي العادي OL جيدة (أو أفضل) من بديل تحميل عنصر النص الديناميكي. لا أوافق على أن defer كافٍ ، ولقد حددت الآن عدة أسباب لذلك.

لذلك ، أعتقد أنه من المناسب لنا فحص السؤال الأول ، واستكشاف ما إذا كان defer أفضل من برامج تحميل البرامج النصية. قد يكون هناك عدد قليل من الحالات المحدودة حيث يمكنك الابتعاد عن defer ، ولكن فيما يتعلق بالحالة العامة ، تتعامل أدوات تحميل البرامج النصية مع / تطبيع جميع المراوغات ، بينما يعرضك defer لهذه المشكلات.

ما زلت غير متأكد من أن الجميع يرى أو يوافق على سبب عدم كفاية defer .

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

هذه هي فرضيتك (والآخرين) للاختبار الخاطئ. لم أزعم أبدًا أن تحميل 5 نصوص بدلاً من 1 سيكون أسرع. أبدا. أبدا. هل يمكنني أن أكون أكثر وضوحا؟ لم تكن الفرضية أبدًا 5 مقابل 1.

كان الاختبار الأول هو اختبار 3 علامات نصية مقابل 3 script() مكالمات ، لأن هذا اختبار عادل. وأعتقد أن الفيديو والاختبارات توضح أن تحميل النص ، في هذا السيناريو ، مفيد.

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

ملاحظة: السبب وراء هذا السؤال هو أنه يمكنك تحميل ملف concat الفردي هذا إما بعلامة البرنامج النصي ، أو باستخدام التحميل الديناميكي من النوع document.createElement("script") . في كلتا الحالتين ، يعتبر سؤال ملف concat واحد سؤالًا صالحًا ، ولكنه منفصل عما إذا كانت علامات البرنامج النصي أو تحميل البرنامج النصي الديناميكي أفضل.

ما سمعتني أقوله عدة مرات في هذا الموضوع ، وأيضًا في العديد من السياقات الأخرى (بما في ذلك كل مؤتمري الذي يتحدث عن الموضوع ، منشورات المدونة ، إلخ) ، هو أنني أعتقد أنه من الممكن أن تتمكن من تحسين ملف JS. النهج عن طريق "التقسيم" (أي تقسيم ملف concat الكبير) إلى 2 أو 3 أجزاء (على الأكثر). إذا كانت الأجزاء متساوية في الحجم ، وتم تحميلها بشكل متوازٍ ، فمن الممكن أن يتم تحميل الصفحة بشكل أسرع ، حتى مع حمل HTTP الإضافي ، بسبب الاتصال "Keep-Alive" ، وتأثير التحميل الموازي ، وما إلى ذلك.

في الواقع ، كنت أكتب عن هذا الموضوع منذ وقت طويل ، في نوفمبر 2009 ، بعد فترة وجيزة من الإصدار الأول لـ LABjs: http://blog.getify.com/2009/11/labjs-why-not-just-concat/

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

ولكن ، أقول أيضًا أنه بمجرد أن يكون لديك ملف concat الفردي هذا ، فقد يكون من المفيد أيضًا محاولة تحميل ملفك الفردي في 2-3 أجزاء ، يتم تحميلها بالتوازي (باستخدام محمل البرنامج النصي).

لماذا قد يكون هذا أفضل؟ لقد قمت بترتيبها في منشور المدونة هذا ، ولكن باختصار:

1. تأثير التحميل الموازي حقيقي. اسأل مستخدمي bit-torrent عن هذا الأمر. عبء HTTP حقيقي أيضًا ، ويعمل على التصدي ، والقضاء على هذه الميزة. لكن هذا لا يعني أنه من المستحيل الاستفادة. باستخدام Connection Keep-Alive ، من الممكن أن تحصل على 2 أو 3 اتصالات متزامنة (بدون 2-3 عقوبات كاملة للاتصال) ، وتحميل الكود الخاص بك في فترة زمنية أقصر. هل سيكون 1/3 الوقت (60-70٪ أسرع) إذا قمت بتحميله في 3 أجزاء؟ لا لا على الاطلاق. ولكن قد يكون أسرع بنسبة 20-30٪.
2. إن تقديم كل التعليمات البرمجية الخاصة بك في ملف واحد يمنعك من عمل رؤوس ذاكرة تخزين مؤقت مختلفة لكود مختلف مدى الحياة. على سبيل المثال ، يعد jquery مستقرًا للغاية ولا يحتاج أبدًا إلى إعادة تنزيله. لكن كود UX الخاص بك على موقعك قد يكون متقلبًا للغاية (يمكنك تعديله مرة واحدة في الأسبوع أو أكثر). يعد القيام برؤوس تخزين مؤقت قصيرة على ملف concat واحد أمرًا غبيًا ، لأنه يفرض عمليات إعادة تنزيل أكثر تكرارًا للشفرة الثابتة دون داع. يعد القيام برؤوس التخزين المؤقت الطويلة في ملف concat الفردي أمرًا غبيًا أيضًا ، لأنه يجبرك على إبطال الملف المخزن مؤقتًا (معلمة نص ذاكرة التخزين المؤقت ، إلخ) وفرض إعادة تنزيل كاملة للملف بأكمله ، عندما تقوم بتعديل بايت واحد فقط من كود أكثر تقلبًا. لذا ، فإن تقسيم ملف concat الكبير إلى جزأين ، أحدهما للرمز الثابت والآخر للرمز المتغير ، يتيح لك الحصول على رؤوس تخزين مؤقت مختلفة لكل قطعة. يؤدي هذا إلى استخدام ذاكرة التخزين المؤقت بشكل أكثر فاعلية ، ويؤدي إلى أداء أفضل محتمل على مدار فترات زمنية ، حيث يأتي المستخدمون لزيارة موقعك بشكل متكرر.
3. أظهرت الدراسات أنه في المتوسط ​​، تستخدم مشاهدة صفحة واحدة أقل بكثير من 100٪ من JS التي يتم تحميلها على الصفحة (بعض التقديرات تضعها في حدود 20-30٪ من الشفرة). يؤدي تحميل كل التعليمات البرمجية في لقطة واحدة ، كل ذلك مرة واحدة ، في بداية تحميل الصفحة ، إلى تكدس الخط دون داع لدفع 70-80٪ من الملف غير المطلوب حينئذٍ (وقد "لا تكون هناك حاجة أبدًا"). إذا كان لديك الكود الخاص بك في جزأين (أحدهما هو الرمز الأكثر أهمية والآخر الأقل أهمية) ، وقمت بتحميل الجزء الأول على الفور ، وقمت بتحميل الجزء الثاني بعد ثوانٍ قليلة من تحميل الصفحة ، يمكنك تحرير الأنبوب الخاص بالصور / المغلق والمحتوى الأكثر أهمية. في الجوهر ، يسمح لك التقسيم بتحديد أولويات الكود الخاص بك.

خلاصة القول ... حول موضوع concat مقابل المتوازي ... أنا _ دائمًا أقول للناس: كلاهما.

getify قال حسنا.

يحظى Kyle's LABjs بدعمي.
بصفتي استشاريًا يساعد المواقع على تحسين الأداء ، فقد رأيت LABjs تعمل بشكل جيد عدة مرات.
لم يقتصر الأمر على تحسين الأداء بشكل كبير (ليس فقط 100 مللي ثانية ، ولكن أكثر من ثانية واحدة) ، ولكن أيضًا أحب المطورين ذلك.
سهل الفهم ، سهل التنفيذ.

وسأغتنم هذه الفرصة لأقول علنًا "شكرًا لك كايل ، على الدعم الكبير الذي قدمته في LABjs. لقد تجاوزت توقعاتي عدة مرات."

باستخدام اتصال Keep-Alive ، من الممكن أن تحصل على 2 أو 3 اتصالات متزامنة (بدون 2-3 عقوبات كاملة للاتصال)

لا يحتوي HTTP على استجابات mux / interleave ، لذا لا يمكنك إجراء تنزيلات متوازية دون فتح اتصالات متعددة أولاً. الحالة المثالية للاتصال المستمر والمتنقل تساوي التنزيل المتجاور لملف واحد (+ عدد قليل من العناوين).

@ pornel--

لقد رأيت بنفسي وتحققت من أن المتصفحات يمكنها فتح اتصالات متعددة بالتوازي مع خادم واحد ، حيث مع تشغيل Connection Keep-Alive ، يكون الحمل الزائد للاتصالات الثانية والثالثة أقل بشكل كبير من الأول. هذا هو التأثير الذي أتحدث عنه.

getify Fantastic ، أعتقد أننا توصلنا إلى نوع من الإجماع. لتحديث ذاكرتك:

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

نعم ، أوافق على أن تحميل البرامج النصية المتقلبة في ملف JS مختلف عن البرامج النصية الدائمة يعد أمرًا رائعًا. تحميل البرنامج النصي المطلوب فقط لصفحة معينة ، فقط على تلك الصفحة المحددة ، يعد أمرًا رائعًا بالمثل.

إذا كنت مطور ويب ولدي صفحة بها مجموعة من JavaScripts ، فماذا أفعل؟ استخدم LABjs ، أو ادمج البرامج النصية الدائمة في ملف واحد ، والنصوص المتغيرة الخاصة بي في ملف آخر ، وقم بتحميل كليهما في الجزء السفلي من علامة النص الأساسي باستخدام <script defer="true"> ؟

لماذا يجب أن أخضع تطبيقي لمشاكل التخزين المؤقت وعدم توافق المتصفح والسباق ضد الصور على الصفحة وبقية المشاكل التي يسببها برنامج تحميل البرامج النصية؟

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

getify بعد أن نفذت خادم ويب أكثر من مرة: لا يؤثر برنامج jashkenas أكثر من مرة ، يمثل مشكلة إذا كان لديك أصول أخرى ، مثل الصور أو ملفات css.

@ jashkenas-

إذا كنت مطور ويب ولدي صفحة بها مجموعة من JavaScripts ، فماذا أفعل؟ استخدام LABjs ، أو دمج البرامج النصية الدائمة في ملف واحد ، والنصوص المتغيرة الخاصة بي في ملف آخر ، وتحميل كليهما في الجزء السفلي من علامة النص باستخدام <script defer = "true">؟

TL ؛ DR: كلاهما

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

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

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

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

على النقيض من ذلك ، يمكنهم الحصول على "فوز سريع" في LABjs بدلاً من علامة <script> . هناك القليل الذي يتعين عليهم التفكير فيه (باستثناء document.write() ). في معظم الأحيان ، "يعمل فقط". وفي معظم الأوقات ، يلاحظون زيادة فورية في سرعة تحميل الصفحة. بالنسبة لمعظم المواقع ، يعد هذا فوزًا كبيرًا.

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

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

@ rkh--

لقد أوضحت لي (على وجه التحديد في Apache ، مع تبديل إعداد Keep-Alive) كيف تأثرت الطلبات المتوازية المتعددة (بشكل إيجابي عندما كان Keep-Alive موجودًا). لست خبيرًا في هذا المجال ، لذا فإن مناقشة التفاصيل الدقيقة لكيفية عملها أو لا تعمل بعيدًا عني. أستطيع أن أقول إن توقيت الطلب رقم 2 كان أقل من توقيت الطلب رقم 1 ، عندما كان Keep-Alive موجودًا. كيف قام المتصفح والخادم بذلك ، يمكنني فقط إجراء تخمينات مستنيرة جزئيًا في.

لا يزال الجسم المنقسم مع طلبين متتاليين مع الاحتفاظ به أكثر تكلفة من طلب واحد.

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

على سبيل التقدير ، يبدو أن الطلب رقم 1 كان X للخدمة ، وكان رقم 2 بالتوازي مع Keep-Alive الحالي 0.7X. شُرح لي أن الخادم كان قادرًا على الاستفادة من بعض تكاليف الاتصال الحالية في خدمة الطلب الثاني ، مما يجعله أرخص قليلاً. مع إيقاف تشغيل Keep-Alive ، لم يكن للطلب الثاني مثل هذا الانخفاض القابل للقياس.

كل هذا النقاش هو حفرة أرنب عميقة للغاية. أنا لست خبير خادم. ليس علي أن أكون كذلك. يمكنني فقط أن أوضح أنني رأيت بالفعل (وأنشأت اختبارات) حول هذا الموضوع بالضبط ... هل يمكنني اختبار وقت تحميل ملف واحد يبلغ 100 ألف مقابل تحميل نصفين من نفس الملف بالتوازي ، وهل سيكون الاختبار الثاني قابلاً للقياس كمية أسرع. كما قلت ، رأيت ، في مكان ما بين 15-25٪ أسرع مع الاختبار المقسم بالتوازي. كيف فعلت ذلك ، وتمكنت بطريقة ما من تجاوز تأثير "OMG HTTP RESPONSE OVERHEAD OVERHEAD MERRIBLE" وما زلت أستفيد من تحميلين متوازيين ، أعتقد أنني لست مؤهلاً لإثبات ذلك علميًا. لكنها فعلت ذلك بالتأكيد من خلال الملاحظة.

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

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

getify ، يجب عليك بالتأكيد الدفاع عن LABjs والرد على انتقادات محددة وجهها الآخرون في الموضوع ، لكن (باستثناءjashkenas) أعتقد أن أولئك الذين ينتقدون LABjs يفعلون ذلك لإثبات أنه ليس الحل الأفضل للنموذج المعياري. أنت تجادل بأن تحويل الصفحات القديمة إلى LABjs أسهل من تحويلها إلى script[defer] ، وقد يكون ذلك صحيحًا ، ولكن كيف ينطبق ذلك على ملف HTML المعياري (والذي ، بحكم التعريف ، يبدأ من الصفر)؟

أنت تقول إنه مصمم للأشخاص الذين ليس لديهم عمليات بناء رائعة ، ولكن يبدو أيضًا أنك تدعو إلى التسلسل ، والتقسيم إلى أجزاء متساوية الحجم ، والتحميل بشكل متوازٍ. أليست هذه مهمة لبناء النص؟ مرة أخرى ، يبدو أنه اختيار خاطئ للنموذج المعياري المصمم لمنح المستخدم إعدادات افتراضية ذكية. إذا أراد المستخدم زيادة السرعة المزعومة بنسبة 20-30٪ ، فيمكنه اختيار الترقية لاحقًا فوق ما يقدمه النموذج المعياري ، ولكن هذه ليست مهمة تافهة.

بعد قولي هذا كله ، إذا كنتم تريدون الاستمرار في الموضوع العام ("Script Loaders: أداة قيمة أم زيت ثعبان؟") ، فسأكون سعيدًا وأعد بعض الفشار.

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

ومع ذلك ، لا أرى أهمية Keep-Alive في هذه الحالة. _تم بدء _الطلبات _ اللاحقة على نفس الاتصال بشكل أسرع مع Keep-Alive ، ولكن هذه الطلبات متسلسلة داخل الاتصال.

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

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

البرد المتأنق

@ savetheclocktower--

أسئلة عادلة.

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

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

أدعو أولاً إلى نقل كل العشرات من علامات البرنامج النصي إلى أداة تحميل نصوص موازية مثل LABjs. هذا لا يتطلب أكثر من القدرة على تعديل الترميز الخاص بك. هذه خطوة أسهل بكثير / أقل ترويعًا من إخبار أمي وموقع البوب ​​باستخدام نظام بناء آلي يعتمد على node.js ، على سبيل المثال.

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

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

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

هذا هو السبب الوحيد لبدء المشاركة في هذا الموضوع. هذا هو السبب الوحيد الذي جعلني أعترض على تعليقpaulirish "الإيمان الأعمى"

نعم.

أعتقد أنه من الواضح أن هذه المناقشة قد تجاوزت ما إذا كان برنامج تحميل البرنامج النصي مناسبًا لمشروع h5bp. لكن هذا جيد ، لأن هذا الموضوع يستحق الاستكشاف.

بغض النظر ، أنا مهتم جدًا بحالات الاختبار القابلة للتكرار جنبًا إلى جنب مع نتائج الاختبار.

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

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

لقد قمت بإعداد تذكرة لجذب بعض الاهتمام بهذا https://github.com/paulirish/lazyweb-requests/issues/42

انضم إلي هناك إذا كنت تعمل في المهام الرائعة المتمثلة في البحث عبر webperf وتوثيق الأدلة.

دعونا نعتبر هذا الخيط مغلقًا ، أيها السادة.

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

أشعر أن هذا المنشور الذي كتبته العام الماضي يناسب موضوع: عقيدة الأداء - لا يتعلق الأمر كله بالأداء وتأكد من أنك لا تضيع وقتك في "تحسين" شيء لا يحدث أي فرق حقيقي ...

وأنا مع SlexAxton ، أريد AMD ولكن علامات البرنامج النصي البسيطة ربما تكون كافية لمعظم الناس. ربما يكون الأسلوب الصحيح هو إضافة إعداد جديد لاختيار مشروع AMD وتشغيل مُحسِّن RequireJS بدلاً من مهام _concat (مهمة

دعونا نعتبر هذا الخيط مغلقًا ، أيها السادة.

paulirish ماذا عن تضمين دعم AMD؟ أين يجب أن نناقش ذلك؟

benatkin افتح تذكرة جديدة

paulirish حسنًا ، شكرًا. jrburke هل

مسلية وغنية بالمعلومات. شكرا يا شباب.

أعتقد أن شخصًا ما يحتاج لبدء مشروع محمل نصوص جديد وأطلق عليه اسم "Issue28". :)

لأوسع توافق ، يمكن الحصول على أداء سريع عن طريق وضع النص في الأسفل ، تصغير ، gzip ، لكن لا تؤجل. على الأقل ليس حتى يصبح توافق المتصفح ثابتًا لبضع سنوات متتالية.

يمكن أن تأتي الاختناقات من الإعلانات ، والكثير من جافا سكريبت ، و HTML المتضخم ، والكثير من CSS ، والكثير من إطارات iframe ، والعديد من الطلبات ، وزمن انتقال الخادم ، وجافا سكريبت غير فعال. التطبيقات التي تستخدم الكثير من libs التابعة لجهات خارجية لديها مشاكل ليس فقط بسبب الكثير من جافا سكريبت ، ولكن أكثر من ذلك ، فإنها تميل أيضًا إلى العديد من المشكلات الأخرى ، معظمها HTML منتفخ ، HTML غير صالح ، الكثير من Css ، وجافا سكريبت غير فعال. يتبادر إلى الذهن Twitter بشكل صحيح ، مع وجود نسختين من jQuery واثنين من معالجات onscroll التي تتسبب في ارتداد العمود الأيمن عند التمرير.

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

https://github.com/BroDotJS/AssetRage

فقاعة! أغلق الأندية وأغلق الخيوط.

يا له من خيط ... نجاح باهر.

Imo ، بدأ النقاش في سياق h5bp ، والذي يُقصد به أن يكون نقطة انطلاق لمطوري الويب.
على هذا النحو ، يمكنك أن تذكر أن webdev الذي يستخدم h5bp سيحتوي فعليًا على HTML نظيف ، و CSS نظيف ، و htaccess جيد ، وما إلى ذلك ، وربما حتى _لا يعاني من عدد كبير جدًا من الصور ، و JS غير الفعال ، والكثير من JS لجهة خارجية سيئة ، إلخ. كما تعلم ، لأن مطور الويب يختار استخدام h5bp عالي الأداء ومن ثم يهتم بالأداء ، وسوف ينتبه إلى العناصر غير h5bp التي تنتقل إلى الصفحة (الصفحات).

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

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

وتعليق اخر ....
احتل "وضع البرامج النصية في الأسفل" و "ملفات JS المتسلسلة في ملف واحد" مكانة عالية في قائمة Web Perf Best Practices لسنوات عديدة. فلماذا لا يزال لدى أكثر من 90٪ من المواقع المتوسطة الموجودة هناك ، والتي تم إنشاؤها بواسطة مطورين داخليين وبواسطة وكالات العلامات التجارية الكبرى ، علامات نصية متعددة في HEAD؟ هل حقا؟ لماذا هذا؟

و 9٪ المتبقية لديهم ملف JS واحد متسلسل ... في HEAD.
نادرًا ما أرى موقعًا "عاديًا" لم يتم إنشاؤه بواسطة أحد مطوري أداء الويب الأعلى مع نص برمجي واحد في الأسفل.

يواصل المطورون بناء مواقع كما كانت منذ سنوات.
يهتم مالكو المواقع بالتصميم والميزات ، لذلك هذا هو ما يقضي المطورون وقتهم فيه.

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

لقد عملت في العديد من المواقع حيث يؤدي دمج JS في HEAD في ملف واحد وتحميله أسفل BODY إلى كسر الصفحات الموجودة على الموقع. ثم ماذا؟ في معظم الحالات ، لا يستغرق إصلاح ذلك مجرد ساعة من العمل. إعادة هيكلة جادة يجب أن تتم ... وهذا لا يحدث بسبب نقص المعرفة ، وخاصة ضيق الوقت.

(حسنًا ، الخيط مغلق ...)

نحن نتحدث عن مكتبة مبنية على jQuery و Modernizr. يقول كل شيء ، حقا. من يستخدم ذلك؟ أوه ، اللعنة ، لقد نسيت ، Twitter.com ، الذي يستخدم اثنين من jQuerys ويحتوي أيضًا في شفرة المصدر ، على ما يلي:

 السطر 352 ، العمود 6: تمت رؤية علامة النهاية div ، ولكن كانت هناك عناصر مفتوحة.
 خطأ سطر 350 ، العمود 6: عنصر غير مغلق ul.
 خطأ سطر 330 ، العمود 6: عنصر غير مغلق ul.

والمشكلة المتعلقة بتوقع أن المتصفح يصحح الخطأ هي أن HTML4 لم تحدد آليات تصحيح الأخطاء ، وبالتالي سينتهي بك الأمر مع من يعرف ماذا يعرف وأين. بالتأكيد ، تحدد HTML5 معالجة الأخطاء ، لكنها ليست بأثر رجعي - لا يزال هناك الكثير من المتصفحات "القديمة".

وبالحديث عن القرف ، هل ألقى أي شخص هنا نظرة على الحشوات jQuery ES5؟

راجع للشغل ، هل لديك أي شيء تضيفه إلى هذا البيان الخاص بك "أن webdev الذي يستخدم h5bp سيحتوي بالفعل على HTML نظيف ،" aaronpeters؟

GarrettS حسنًا ، حسنًا ، كان يجب أن أكتب "will _probably_ have clean HTML"

:- D يمكننا دائما أن نأمل!

أتغلب على حصان ميت ، أعلم ... لكن اتضح أنه في نفس الوقت الذي كنا نجري فيه هذه المناقشة المتلألئة ، كان للإصدار الحالي من LABjs خطأ تسبب في تنفيذ JavaScript بترتيب خاطئ في بعض المتصفحات: https: //github.com/getify/LABjs/issues/36

يا السخرية.

يجب. يقاوم. نشر. تماما. [غير مناسب. صورة. ل. السابق. البيان .... aggggh! سكرة!

كان الجزء المفضل لدي عندما بدأ المتأنق الذي جعل dhtmlkitchen.com (في الوقت الحالي تمامًا ) يتحدث عن أخطاء الترميز.

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

... وبعد الانتهاء من ذلك ، حاول إخراج رأسك من مؤخرتك وفهم الفرق بين موقع الويب الشخصي القديم الخاص بي (الذي لم يعد أديره) والموقع الذي تم تطويره بواسطة فريق وتمويله من قبل شركة مربحة بملايين الدولارات (على الرغم من أن Twitter قد يصل إلى AFAIK بمليارات الدولارات).

يسعدنا أن نحافظ على هذا الأناقة ، وفي الموضوع ، يا رفاق.

حصل jashkenas على أجزاء المعلومات ذات الصلة في وقت مبكر من هذه المناقشة.

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

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

وماذا يفعل أي من هذا مع تعطل dhtmlkitchen.com؟ لا شيء على الإطلاق ، من الواضح. كان ذلك مجرد ضربة ضعيفة من مفترس h5bp لا يتحمل سماع النقد.

إخوان.
يا صديق.
إخوان.

هذا الخيط مغلق. تذكر؟ ليس عليك العودة إلى المنزل ، لكن لا يمكنك الاشتعال هنا.

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