تحطيم بودكاست الحلقة 45 مع جيريمي واغنر: ما هي جافا سكريبت المسؤولة؟

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

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

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

• موقع ويب JavaScript مسؤول
• اشتر الكتاب من A Book Apart
• موقع جيريمي الشخصي
• جيريمي على تويتر

تحديث اسبوعي

• قانون فيتس في عصر اللمس بقلم ستيفن هوبر
• تم تصميم الويب بشكل جيد: بلا هدف تمامًا بقلم فريدريك أوبراين
• كل ما تريد معرفته حول إنشاء واجهات مستخدم صوتية كتبها نيك بابيتش وجليب كوزنتسوف
• تداعيات انضمام WordPress إلى بروتوكول Block الذي كتبه ليوناردو لوسوفيز
• خواطر في Markdown كتبها كنوت ميلفار

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

درو ماكليلان: هو كاتب تقني ، ومهندس أداء الويب ، ومطور ومتحدث ، ويعمل حاليًا في Google. لقد كتب لمجلة A List Apart و CSS-Tricks and Smashing Magazine ، وهو مؤلف عنوان جديد ، وهو Responsible JavaScript for A Book Apart. لذلك نحن نعلم أنه فني ماهر ومتواصل ، لكن هل تعلم أنه يريد أن يبحر حول العالم على لوح مجداف واقٍ؟ أصدقائي الرائعين ، من فضلكم رحبوا بجيريمي واغنر. مرحبا جيريمي كيف حالك

جيريمي واجنر: أنا محطم. كيف حالك؟

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

جيريمي: أنا أتحدث حرفيا عن استخدام جافا سكريبت بطريقة مسؤولة. لذلك وفقًا لأرشيف HTTP ، شهدنا زيادة في المتوسط ​​بنسبة 58٪ تقريبًا في كمية JavaScript التي تم تنزيلها بواسطة الأجهزة المحمولة من 290 كيلو بايت تقريبًا إلى 500 كيلو بايت تقريبًا في العام الماضي.

درو: واو.

جيريمي: لذلك عندما أتحدث عن استخدام جافا سكريبت بطريقة مسؤولة ، فمن النوع الأول للمستخدم أن يقول ... لتقييم نقدي لما نقوم ببنائه وهدف ما نبنيه تخدمه ممارسات تطوير الويب الحديثة ، لذلك ليتحدث. وأعتقد أن هذا نوع من ... ربما ليس لسانًا في الخد ، لكنني لم أتطرق إلى تطوير الويب الحديث ، ولكن أحد النتائج الثانوية لتطوير الويب الحديث هو أنه من السهل جدًا إضافة التبعيات إلى المشاريع. كل شيء هو تثبيت MPM بعيدًا وكل تثبيت MPM له تكلفة ، وتختلف هذه التكلفة. ولكن ما نراه هو أنه في بيانات أرشيف HTTP هذه ، النسبة المئوية 95 ... مما يعني أن 5٪ من التجارب هي الأبطأ ... أو ليست الأبطأ ، ولكن تلك التي تشحن معظم JavaScript ، والتي ارتفعت في العام الماضي بنحو 875 كيلو بايت إلى حوالي 1.4 ميغا بايت.

درو: واو.

جيريمي: إذن يتم نقل كمية هائلة من JavaScript ولها آثار على أداء التحميل وأداء وقت التشغيل.

درو: لقد ذكرت الأداء هناك. يبدو أن تجربة الويب الحديثة من وجهة نظري مثل 10٪ HTML و CSS و 90٪ JavaScript. ويجب أن يكون هناك نوع من اعتبارات الأداء لذلك. أعني ، لقد تحدثت عن نوع من كمية البيانات التي ننقلها ، ولكن هناك اعتبارات أخرى تتعلق بالأداء مع وجود الكثير من جافا سكريبت.

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

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

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

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

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

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

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

جيريمي: والفكرة من وراء هذا المقال هي أنه إذا تمكنا من التركيز على تلك الشريحة المئوية التسعين أو 95 ، فنحن ... ونحسن تلك التجربة لهؤلاء الأشخاص ، فنحن نبني شبكة ويب أسرع للجميع ، بما في ذلك أولئك الذين يستخدمون الأجهزة السريعة. وهاجم نقطة بيانات على ذلك في الولايات المتحدة وهذا فقط من موقع statcounter.com. ما يقرب من 28 نقطة ... حوالي 28٪ من الأشخاص يستخدمون جهاز iOS تلتقطه هذه الأداة. وحوالي 21٪ منهم من Android. ويميل Android إلى تمثيل جزء كبير من هذا الذيل الطويل من الأجهزة ، لأن Android ليس متجانساً. العديد من مصنعي الأجهزة يصنعون هواتف Android ، ولكن على النقيض من ذلك مع العالم ، نظرًا لأن العالم أكثر من مجرد الولايات المتحدة ، فإن حوالي 16 ٪ من الأشخاص يستخدمون iOS وحوالي 41 ٪ من الأشخاص الذين يستخدمون Android. لذلك من المفيد حقًا إعطاء الأولوية لتلك التجارب الأبطأ أو التي يحتمل أن تكون أبطأ.

درو: قرأت في كتابك عن الاختناق الحراري للجهاز ، وهو أمر لم أفكر فيه من قبل. ما هي المخاوف هناك؟

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

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

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

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

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

درو: لذلك نحن نكتب JavaScript لمجموعة كاملة من الأجهزة من أحدث Apple M1 Max هو المعالج الجديد ، أليس كذلك؟ أجهزة الكمبيوتر المحمولة وصولاً إلى الأجهزة التي بالكاد لديها نوع كافٍ من ذاكرة الوصول العشوائي (RAM) العاملة لعرض صفحة ويب. لكن الويب لم يبدأ على هذا النحو ، فقد يهتم المستمعون الأصغر سنًا بمعرفة أننا اعتدنا على بناء تجارب ويب تفاعلية بدون أي JavaScript على الإطلاق. سيكون إطار عملنا الكبير والثقيل بمثابة التراجع عن عملنا.

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

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

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

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

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

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

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

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

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

جيريمي: هذا سؤال صعب. وبالتالي-

درو: كان من الصعب علي أن أقول.

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

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

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

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

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

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

درو: إنه نوع من القيثارات التي تعود قليلاً إلى الأيام التي كنا نقوم فيها بتضمين جزيرة فلاش أو-

جيريمي: أجل.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

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

جيريمي: لقد قمت مؤخرًا بتحديث مدونة. هذا هو ... أنا مهووس كبير في لعبة Final Fantasy ، مثل Final Fantasy II ، لقد قمت بإعادة العرض وهكذا ، هناك 15 منهم و 16 سيخرجون في وقت ما ، لكنه نوع من مجال الرجعية. لذلك كنت أستخدم CSS paint API لإنشاء عشوائي عبر العالم باستخدام مربعات مختلفة. لذلك هناك مثل الأنهار والأشياء التي مثل الجري من خلالها وبلاط العشب والأشجار وهذا النوع من الأشياء. وتحديد المعلمات كما لو كان المستخدم يزور موقع الويب الخاص بي في الوضع المظلم ... سيتم عرض أعمال الطلاء هذه كما لو كانت ليلاً. سيكون لها نوع من التراكب عليها وهذا النوع من الأشياء.

جيريمي: لكن API اللوحة مذهلة. يجب أن أعطي صيحة لتيم هولمان. لقد رأيته في JSConf Australia وتحدث عن الأعمال الفنية التوليدية. كان هذا حقًا فقط ، لقد جعلني مهتمًا حقًا. ثم تحدث سام ريتشارد ، في ذلك في CSSConf في اليوم السابق عن واجهة برمجة تطبيقات لوحة CSS ، عندما اجتمع هذان الشيئين معًا ، كان الأمر تمامًا مثل ، "رائع ، هذا رائع جدًا." وهكذا فعلت شيئًا يسمى Paintlets! إنه Paintlets.Herokuapp.com إذا قمت بزيارة و Chrome وعليك ، لسوء الحظ ، لأنه ليس مدعومًا جيدًا حتى الآن. يمكنك أن ترى مثل مجموعة من الأعمال الفنية العشوائية المختلفة التي تم إنشاؤها عشوائيًا و .. نعم ، لقد قمت فقط ... هذا ما كنت فيه ، آسف. حكاية طويلة عن ذلك.

درو: مذهل. هذا يبدو رائعًا.

جيريمي: أجل. نعم.

درو: إذا كنت ، عزيزي المستمع ، ترغب في سماع المزيد من جيريمي ، فيمكنك العثور عليه على Twitter حيث هوmalchata والعثور على عروضه التقديمية ومقاطع الفيديو والمشاريع الكتابية على موقعه الشخصي ، jeremy.codes ، JavaScript مسؤول متاح الآن من A احجز بصرف النظر. ويمكنك العثور على مزيد من المعلومات حول ذلك على موقع Responsjs.dev. شكرا لانضمامك إلي اليوم جيرمي ، هل لديك أي كلمات فراق؟

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