مسؤول تطوير جافا سكريبت الجزء 1

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



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

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

ألقِ نظرة ، على سبيل المثال ، على هذا المشروع البسيط الخاص بي. أثناء تحميل الصفحة ، يتم نقل حوالي 23 كيلوبايت من رمز JS غير المضغوط إلى العميل. يقوم Chrome الذي يعمل على MacBook Pro ، والذي تم إصداره في منتصف عام 2017 ، بمعالجة هذا الكم الصغير من الكود في حوالي 25 مللي ثانية. على هاتف Nokia 2 Android الذكي ، ومع ذلك ، فإن رقم مماثل يمتد إلى 190 مللي ثانية. هذا لا يعني أنه صغير جدًا ، ولكن على أي حال ، تصبح الصفحة تفاعلية بسرعة كافية.

الآن ، سؤال مهم. ما رأيك ، كيف يدير الهاتف الذكي Nokia 2 البسيط متوسط ​​الصفحات الحديثة؟ في الواقع - مجرد فظيعة. تصفح صفحات الويب ، حتى على اتصال إنترنت سريع ، يفرض على المستخدم التحلي بالصبر ، لأن العمل مع الصفحات المحملة برمز JavaScript لا يصبح ممكنًا إلا بعد فترة انتظار كبيرة.


نظرة عامة على الأداء من Nokia 2 عند عرض صفحة تحتوي على كمية كبيرة من كود JS ، والتي تعالج معالجة الخيط الرئيسي

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

مقارنة أيديولوجية "المواقع" و "التطبيقات"

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

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

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

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

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

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

لا تدع الأطر تفرض أنماطًا غير عقلانية عليك

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

import React, { Component } from "react"; import { validateEmail } from "helpers/validation"; class SignupForm extends Component {  constructor (props) {    this.handleSubmit = this.handleSubmit.bind(this);    this.updateEmail = this.updateEmail.bind(this);    this.state.email = "";  }  updateEmail (event) {    this.setState({      email: event.target.value    });  }  handleSubmit () {    //      -      if (validateEmail(this.state.email)) {      // ...    }  }  render () {    return (      <div>        <span class="email-label">Enter your email:</span>        <input type="text" id="email" onChange={this.updateEmail} />        <button onClick={this.handleSubmit}>Sign Up</button>      </div>    );  } } 

هنا يمكنك العثور على العديد من المشكلات البارزة المتعلقة بإمكانية الوصول إلى المشروع:

1. نموذج لا يستخدم عنصر <form> لم يعد نموذجًا. في الواقع ، يمكنك إصلاح هذا ببساطة عن طريق تحديد دور = "نموذج" للعنصر <div> الأصلي ، ولكن إذا قمت بإنشاء نموذج ، وما نراه يشبه بالتأكيد نموذجًا ، فاستخدم العنصر <form> ، وقم بتعيينه وفقًا لذلك سمات action method . تلعب سمة action دورًا مهمًا هنا ، لأنها تتيح للنموذج القيام بشيء على الأقل حتى لو لم يكن JavaScript متاحًا (بشكل طبيعي ، إذا تم تقديم المكون على الخادم).
2. <span> ليست بديلاً <label> ، والتي توفر بعض الميزات فيما يتعلق بتوفر المشروعات التي لا تملك <span> .
3. عنصر <button> بدون سمة type="submit" هو مجرد زر ، والنقر فوق الذي يستدعي معالج الأحداث المرتبط به. إذا كنا نريد القيام بشيء ما مع البيانات قبل إرسال النموذج ، فنحن بحاجة إلى تعيين السمة type="submit" إلى الزر ونقل الرمز من معالج أحداث onClick إلى معالج أحداث نموذج onSubmit .
4. بالمناسبة ، لماذا تستخدم JavaScript للتحقق من عناوين البريد الإلكتروني ، بينما يضع HTML5 عناصر تحكم تحت تصرفنا تدعم التحقق من بيانات الإدخال في جميع المتصفحات تقريبًا - حتى IE10؟ نرى هنا فرصة ضائعة للاستفادة من الوظائف الموجودة بالفعل في المتصفح وتطبيق نوع العنصر المناسب ، وكذلك السمة المطلوبة . ومع ذلك ، باستخدام مثل هذه الإنشاءات ، ضع في اعتبارك أن إعداد تفاعلها الطبيعي مع قارئات الشاشة سيتطلب بعض الجهد .

بالنظر إلى ما تقدم ، نعيد تشكيل رمز المكون:

 import React, { Component } from "react"; class SignupForm extends Component { constructor (props) {   this.handleSubmit = this.handleSubmit.bind(this); } handleSubmit (event) {   //    ,         XHR   // (      ,     ,     JS).   event.preventDefault();   //  … } render () {   return (     <form method="POST" action="/signup" onSubmit={this.handleSubmit}>       <label for="email" class="email-label">Enter your email:</label>       <input type="email" id="email" required />       <button type="submit">Sign Up</button>     </form>   ); } } 

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

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

اعتمد على قوة منصة الويب وامنح مشاريعك مستقبلًا مشرقًا

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

تطبيقات صفحة واحدة

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


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

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

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

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

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

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


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

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

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

ava جافا سكريبت غير مصمم للتخطيط

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

 /*   , ,   ,        CSS Grid. */ /*  @supports  ,     CSS Grid,     . */ @supports (display: grid) { /*      */ @media (min-width: 40em) {   /*       CSS Grid */ } } 

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

خلاصة القول: لن أصبح قاتل JavaScript

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

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

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

أعزائي القراء! هل تعتقد أن الشبكة الحديثة محملة فعلاً برمز JavaScript؟