تحطيم بودكاست الحلقة 21 مع كريس فرديناندي: هل أفضل الممارسات الحديثة سيئة للويب؟

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

وتظهر الملاحظات

• صفحة كريس التي تحتوي على روابط وملاحظات للبودكاست
• كتاب الويب العجاف
• كريس فرديناندي على الويب
• كريس على تويتر
• بودكاست فانيلا جافا سكريبت

تحديث اسبوعي

• "ترجمة إطارات التصميم الشبكية إلى HTML / CSS يمكن الوصول إليها"
  بواسطة هاريس شنايدرمان
• "إنشاء تطبيقات سطح المكتب باستخدام Electron و Vue"
  بواسطة تيمي أومويني
• "تقنيات CSS الحديثة لتحسين الوضوح"
  بواسطة إدواردو كافازا
• "كيفية استخدام مكوّنات الأنماط في React"
  بواسطة Adebiyi Adedotun Lukman
• "كيف تصنع بورشه 911 برسم تخطيطي"
  بواسطة نيكولا لازاريفيتش

نسخة طبق الأصل

درو ماكليلان: مؤلف سلسلة دليل Vanilla JS Pocket Guide ، ومؤلف البرنامج التدريبي لأكاديمية Vanilla JS ، ومضيف برنامج Vanilla JS Podcast. لقد طور نشرة إخبارية للإرشادات ، يقرأها ما يقرب من 10000 مطور كل يوم من أيام الأسبوع. قام بتدريس المطورين في مؤسسات مثل Chobani و The Boston Globe. وقد تم استخدام مكونات JavaScript الإضافية الخاصة به من قبل مؤسسات مثل Apple و Harvard Business School. الأهم من ذلك كله ، أنه يحب مساعدة الناس على تعلم Vanilla JavaScript. لذلك نحن نعلم أنه يفضل اختيار Vanilla JavaScript على إطار عمل ، لكن هل تعلم أنه تم اختياره مرة واحدة في تشكيلة الشرطة باعتباره الشخص الأقل احتمالًا لارتكاب الجريمة؟ أصدقائي المحطمون ، يرجى الترحيب بكريس فرديناندي. مرحبا كريس. كيف حالك؟

كريس فرديناندي: أوه ، أنا محطم. شكرا لاستضافتي.

درو: أردت أن أتحدث إليكم اليوم عن مفهوم الويب الخالي من الهدر ، وهو شيء يثير شغفك ، أليس كذلك؟

كريس: نعم ، كثيرًا جدًا.

درو: لماذا لا تهيئ لنا المشهد؟ عندما نتحدث عن Lean Web ، ما هي المشكلة التي نحاول حلها؟

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

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

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

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

كريس: نعم.

درو: الأشخاص الذين اعتادوا تغطية Full Stack ، ثم انقسمنا إلى الواجهة الأمامية والخلفية. ثم انقسمت تلك الواجهة الأمامية إلى أشخاص يقومون بتطوير CSS أو JavaScript. وبعد ذلك بشكل متزايد داخل JavaScript ، يصبح أكثر تخصصًا. قد يعتبر شخص ما نفسه ويسوق نفسه على أنه مطور React أو مطور Angular ، وتستند هويتهم الكاملة وتوقعاتهم حول إطار عمل معين يتمتعون بمهارة عالية فيه. هل هذا الاعتماد على الأطر ، هو جوهر عملنا على الويب ، شيئا سيئا؟

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

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

درو: في الفترة التي سبقت ظهور الأطر الكبيرة ، اعتدنا على بناء واجهات مستخدم وأشياء باستخدام jQuery أو أي شيء آخر. ثم جاءت الأطر وأعطتنا المزيد من مفهوم واجهة المستخدم القائمة على الدولة.

كريس: نعم.

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

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

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

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

كريس: ليس كل ذلك ، ولكن جزء كبير من هذا الوزن مخصص لهذا الشيء الذي يسمى DOM الافتراضي. هناك بدائل تستخدم واجهات برمجة تطبيقات أو مناهج متشابهة. بالنسبة لـ React ، لديك Preact ، وهو 2.5 كيلوبايت أو حوالي 3 كيلوبايت بدلاً من 30. إنه عُشر الحجم. بالنسبة إلى Vue ، لديك Alpine JS بدلاً من ذلك ، وهو حوالي 7 كيلوبايت. لا يزال ، أصغر بكثير. الفرق الكبير بين هؤلاء ونظرائهم الأخ الأكبر هو أنهم تخلوا عن DOM الافتراضي. قد يسقطون طريقة أو اثنتين. لكن بشكل عام ، هو نفس النهج ونفس النوع من واجهة برمجة التطبيقات في طريقة العمل مع الكود ، وهما أصغر بكثير.

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

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

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

كريس: بالتأكيد.

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

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

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

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

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

كريس: الأشياء الصغيرة مثل Preact أو Alpine ، هم في الواقع يفعلون ذلك بشكل مباشر. إنهم يقومون بتحويل السلسلة التي تقدمها لهم لما يجب أن تبدو عليه واجهة المستخدم إلى عناصر HTML. ثم يقارنون كل عنصر بالجزء المقابل له في DOM الحرفي. عندما ينتهي بك الأمر مع واجهات مستخدم تصبح أكبر وأكبر وأكبر ، يمكن أن يكون لذلك تأثير ضمني على الأداء لأن الاستعلام عن DOM مرارًا وتكرارًا يصبح مكلفًا. إذا كنت ترغب في التعرف على نوع الواجهة حيث تصبح هذه مشكلة ، فانقر بزر الماوس الأيمن وافحص العنصر الموجود على زر "المفضلة" على Twitter ، أو زر "أعجبني" على Facebook. وألقِ نظرة على تداخل divs الذي ينقلك إلى هذا العنصر. إنه عميق جدًا. إنها مثل دزينة أو نحو ذلك من divs ، متداخلة داخل الأخرى فقط لتلك التغريدة المنفردة.

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

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

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

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

درو: قد يقول البعض ، قد يجادلون بأن هذه الأطر ، أشياء مثل Vue ، React مُحسَّنة للغاية للأداء بحيث تحصل على الكثير من الفوائد هناك مما يجعل بالتأكيد مجرد إقران ذلك مع مدير الحزم في المجمع للتأكد من أنك إعادة إرسال الرمز الذي تريده فقط. بالتأكيد ، أنت متقدم بالفعل بمجرد القيام بذلك؟

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

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

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

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

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

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

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

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

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

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

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

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

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

كريس: أليكس راسل مطور في فريق Chrome. كتب هذا المقال قبل عامين بعنوان The Developer Bait and Switch ، حيث تحدث عن حجة الرجل القشة للأطر. هذه الفكرة هي أن هذه الأدوات تتيح لك التحرك بشكل أسرع وبسبب ذلك ، يمكنك التكرار بشكل أسرع وتقديم تجارب أفضل. إنها فكرة أن تجربة مطور أفضل تعني تجربة مستخدم أفضل. أعتقد أن هذا مثال واضح جدًا على كيف أن هذه الحجة لا تعمل دائمًا بالطريقة التي يعتقدها الناس. إنها تجربة أفضل لبعض الناس ، وليس للجميع.

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

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

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

درو: CSS في JS هو نهج عام ، ولكن قد تنتقل من مشروع إلى آخر ويتأثر تمامًا بطريقة مختلفة تمامًا. حتى لو كنت شخصًا في CSS وتعلمت نهجًا معينًا في مشروع ما ، فقد لا يمكن نقل هذه المهارات على أي حال. من الصعب جدًا رؤية كيف يجب على شخص ما استثمار الكثير من الوقت في تعلم ذلك إذا لم يكن مرتاحًا بشكل خاص لـ JavaScript.

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

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

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

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

كريس: هناك أدوات يمكنك استخدامها لتدقيق HTML الخاص بك وسحب الأنماط التي لا يتم استخدامها حتى بدون استخدام CSS و JavaScript. يمكنك كتابة CSS "بالطريقة القديمة" مع الاستمرار في فحص الأنماط غير المستخدمة. هناك طرق تأليف لـ CSS تمنحك CSS في إخراج شبيه بـ JS وتحافظ على ورقة الأنماط صغيرة دون نبث أسماء الفئات غير القابلة للقراءة البشرية هذه التي تحصل عليها باستخدام CSS و JS أحيانًا. مثل X2354ABC ، ​​أو مجرد هذه الكلمات الهراء التي تنفث.

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

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

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

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

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

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

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

درو: أعتقد أنه من الصواب ، أليس كذلك ، أن منصة الويب تتحرك ببطء وحذر. تعتقد أنه قبل خمس سنوات ، كنا جميعًا نضع JavaScript Carousels على صفحاتنا. كانوا في كل مكان. كان الجميع يطبق JavaScript Carousels. إذا قفزت منصة الويب ونفذت حلاً دائريًا لتلبية هذه الحاجة ، فلن يكون موجودًا ولا يستخدمه أحد لأن الناس لم يعد يفعلوا ذلك مع Carousels بعد الآن. لأنها كانت مجرد موضة ، اتجاه تصميمي. لمواجهة ذلك وإيقاف النظام الأساسي نفسه من أن يصبح منتفخًا وأن يصبح مشكلة تحتاج إلى حل ، يجب أن يتحرك بوتيرة أكثر ثباتًا. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. هل توافق على ذلك؟

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. إطلاقا. إطلاقا. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.

Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.

Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn't have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.

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

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

كريس: على جانب CSS للأشياء ، فإن أشهر مكوِّن إضافي لـ Vanilla JS هو هذه المكتبة التي تتيح لك تحريك التمرير لأسفل إلى روابط الربط. إنه كبير جدا. إنه أصعب جزء من الكود اضطررت إلى كتابته. والآن يتم استبداله بالكامل بسطر واحد من CSS ، وسلوك التمرير بسلاسة. إنه أكثر أداء. من الأسهل الكتابة. من الأسهل تعديل سلوكه. إنه مجرد حل أفضل بشكل عام.

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

كريس: في المواقف التي يكون فيها هذا غير واقعي بالنسبة لك ، حيث تحتاج إلى المزيد من JavaScript ، فأنت بحاجة إلى نوع من المكتبات ، وربما إلقاء نظرة على الأساليب الأصغر والأكثر نمطية أولاً بدلاً من مجرد البحث عن عمالقة الصناعة. بدلاً من React ، هل سيعمل Preact؟ بدلاً من الزاوي ... أعني ، بدلاً من Vue ، هل سيعمل Alpine JS؟ يوجد أيضًا مترجم مسبق مثير للاهتمام يسمى الآن Svelt ، والذي يمنحك تجربة تشبه إطار العمل ثم يقوم بتجميع كل التعليمات البرمجية الخاصة بك في Vanilla JavaScript. لذلك تحصل على هذه الحزم الصغيرة حقًا التي تحتوي على ما تحتاجه تمامًا ولا شيء آخر. بدلاً من CSS وجافا سكريبت ، هل يمكنك تثبيت لينتر CSS لجهة خارجية والذي سيقارن HTML الخاص بك بـ CSS الخاص بك ويسحب الأشياء التي تركت هناك عن طريق الصدفة؟ هل ستعمل طريقة مختلفة لتأليف CSS ، مثل CSS الموجهة للكائنات بواسطة Nicole Sullivan ، بدلاً من ذلك؟ لم نتحدث عن ذلك حقًا ، لكنه أمر رائع حقًا يجب على الناس التحقق منه.

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

كريس: الأشياء التي نبنيها اليوم لا تصلح دائمًا للجميع ، وهذا أمر سيء للغاية. لأن رؤية الويب ، الشيء الذي أحبه فيه ، هو أنه منصة للجميع تمامًا.

درو: إذا أراد المستمعون معرفة المزيد حول هذا النهج ، فقد تناولت الكثير من التفاصيل في كتابك ، The Lean Web. وهذا متاح على الإنترنت. هل هو كتاب ورقي أم كتاب رقمي؟

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

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

درو: هذا رائع. شكرا لك. لقد تعلمت كل شيء عن Lean Web. ما الذي كنت تتعلم عنه مؤخرًا يا كريس؟

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

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

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

درو: لقد كنت مطور ويب لمدة 22 ، 23 عامًا ، ولا بد لي من استخدام خصائص مختلفة لـ Flexbox في Google في كل مرة. على الرغم من أنني كنت أستخدم ذلك لمدة 23 عامًا. لكن نعم ، بعض الأشياء فقط ... من المحتمل أن يكون هناك المزيد منها مع تقدمي في السن.

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

درو: هذه ليست فكرة سيئة.

كريس: هذا هو نوع الكسل الذي أنا عليه. سأقوم بإنشاء موقع ويب كامل لإنقاذ نفسي مثل ثلاث ثوانٍ من Googling.

درو: إذا كنت المستمع يود سماع المزيد من كريس ، يمكنك العثور على كتابه على الويب على leanweb.dev ، والنشرة الإخبارية لمطوره "Tips" والمزيد في gomakethings.com. كريس موجود على Twitter في Chris Ferdinandi. ويمكنك التحقق من البودكاست الخاص به على موقع vanillajspodcast.com أو في أي مكان تحصل فيه عادةً على ملفات البودكاست الخاصة بك. شكرا لانضمامك إلينا اليوم ، كريس. هل عندك كلمات فراق؟

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