تعزيز تدريجي لجافا سكريبت؟

Question

يتحدث معظم الناس عن التحسين التدريجي في الوقت الحالي كتقديم متصفحات مع JavaScript (الإصدار المحسن) ، والمتصفحات بدون JavaScript (إصدار بسيط).

ولكن هناك فرق كبير في أداء JavaScript بين المتصفحات بحيث قد يكون من المفيد تطبيق هذا المصطلح لدعمه للاختيار بين الميزات القائمة على JavaScript بين المتصفحات.

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

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

Answer 1

هذا يبدو وكأنه كابوس الصيانة.

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

IE أقل أداءً من Safari و Chrome و FF عندما يتعلق الأمر بـ JS - لكن هل قمت حقًا بتطوير صفحة غير صالحة للاستعمال في IE مع تشغيل JS؟ أنا فقط لم أرها - في البرية أعتقد أن تطبيقات JS المختلفة سريعة بما فيه الكفاية.

Answer 2

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

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

لا شك أن تطبيقًا سريعًا لـ 99 ٪ من المستخدمين أفضل من تطبيق سريع ل 30 ٪ فقط من المستخدمين. والسؤال الوحيد هو الأهم - تجربة المستخدم ، أو وقت التطوير الخاص بك (وأخذ في الاعتبار أنه في غضون بضع سنوات ، سيقوم المستخدم العادي بتشغيل متصفحات أسرع على أجهزة الكمبيوتر أسرع)

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

جانبا ، Lombardi Blueprint له نهج مثير للاهتمام للغاية ، على الرغم من أنه من غير المحتمل أن يكون غير عملي خارج GWT. لديهم خوارزميات تخطيط مكتوبة في Java ، مكتوبة بحيث يمكن تشغيلها على جانب العميل (عبر GWT) وجانب الخادم (عبر JVM قياسي). وبالتالي ، استنادًا إلى الأداء القياسي لمتصفحك ، يمكنهم التبديل ديناميكيًا بين إجراء التخطيط على جانب العميل (للمتصفحات السريعة) مقابل إجراء التخطيط على جانب الخادم (للمتصفحات الأبطأ).

Answer 3

مشكلتان مختلفتان مع المتصفحات هذه الأيام:

1. سرعة. كانت تجربتي أن IE 7 تعمل بشكل جيد ، أبطأ بكثير من البقية. الإصلاح الخاص بي هو إعطاء المزيد من تحديثات تقدم واجهة المستخدم بشكل متكرر للمستخدمين. نظرًا لأن تحديث واجهة المستخدم يستغرق وقتًا ، أقوم بتقليل التحديثات على المتصفحات الأسرع. على سبيل المثال ، أنا أقوم بتحديث الشاشة بمزيد من التعليقات بعد معالجة 50 حدثًا آخر. للمتصفحات الأخرى ، بعد معالجة 200 حدث.

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

HTH ،

لاري

Answer 4

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

إذا كنت أرغب في استخدام علامة القماش ، فيمكنني إضافة ذلك في ملف مختلف ، لأن IE و Firefox/Opera/Safari تختلف في كيفية إنشاء عنصر القماش.

هذه ليست فرحة للصيانة ، ولكن إذا كنت أرغب في استخدام ميزات HTML/JavaScript الجديدة ، فقد يبدو أن هذا هو أفضل نموذج.

Answer 5

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

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

Answer 6

لذلك دعنا نقول أنك تبني تطبيقًا لائقًا. لديك وفرة تنشئة المتصفح لتحديد الميزات التي سيتم تشغيلها والتي سيتم إيقافها. لقد استنشقت من أجل Opera 9.x ، والآن (اليوم بالفعل) تخرج Opera 10. عليك أن تذهب وتحديث كل sniffer في كل صفحة. ثم يخرج متصفح آخر قريبًا ... وآخر. ستقضي كل وقتك ، وتحديد المتصفحات التي تدعمها وما هي الميزات التي تدعمها.

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

أيضًا ، هناك ما هو أكثر من سرعة تشغيل قطعة من JavaScript أكثر من المتصفح. لا يزال لدي Pentium قديم يركض Firefox 3.5. في بعض الأحيان ، يمكن أن يكون بطيئا بشكل مؤلم.

Answer 7

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

وبعبارة أخرى ، أعط طبقات موقعك من الميزات ، فول فئة HTML أساسية ، والطائرة الثانية هي تحسينات قابلية استخدام JavaScript ، والثالثة هي JavaScript Animation Eye Candy.

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