تحطيم بودكاست الحلقة 19 مع آندي بيل: ما هو CUBE CSS؟

اليوم ، نتحدث عن CUBE CSS. ما هو وكيف يختلف عن مناهج مثل BEM و SMACSS و OOCSS؟ تحدثت إلى مبتكرها ، آندي بيل ، لمعرفة ذلك.

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

• CUBE CSS
• بيكاليلي
• تعلم Eleventy من الصفر - وفر 40٪!
• آندي بيل وبيكاليلي على تويتر

ملاحظة : يمكن للمستمعين في Smashing Podcast توفير 40٪ من دورة Andy's Learn Eleventy From Scratch التدريبية باستخدام الرمز SMASHINGPOD .

تحديث اسبوعي

• "ماذا يمكن أن يعلمنا فيتروفيوس عن تصميم الويب"
  بواسطة فريدريك أوبراين
• "مقدمة إلى SWR: خطافات التفاعل لجلب البيانات عن بُعد"
  بواسطة إبراهيما نداو
• "كيف يمكن لمصممي الويب مساعدة المطاعم على الانتقال إلى الخبرات الرقمية"
  بواسطة سوزان سكاكا
• "دليل عملي لاختبار تطبيقات التفاعل بدافع الدعابة"
  بواسطة Adeneye David Abiodun
• "أضواء على Django: الأصول الثابتة للجدل وملفات الوسائط (الجزء 4)"
  بواسطة فيليب كيلي

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

درو ماكليلان: هو مدرس ومصمم ويب مستقل مقيم في المملكة المتحدة وعمل في صناعات الويب المصممة لأكثر من عقد من الزمان. في ذلك الوقت ، عمل مع بعض أكبر المنظمات في العالم ، مثل Harley-Davidson و BSkyB و Unilever و Oracle و NHS. إلى جانب Heydon Pickering ، هو مؤلف مشارك لـ Every Layout ، بالإضافة إلى تشغيل Front-End Challenges Club الذي يركز على تعليم أفضل ممارسات تطوير الواجهة الأمامية من خلال تحديات قصيرة وممتعة.

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

درو: أصدقائي المحطمون ، أهلا وسهلا بكم ، آندي بيل. مرحبا اندي كيف حالك

آندي بيل: أنا محطمة ، شكرًا. كيف حالك؟

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

آندي: هذا سؤال جيد وصعب البدء به ، درو. نقدر ذلك ، شكرا لك!

درو: مرحبًا!

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

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

درو: إذن فهو تطبيق للعملية لكيفية تصميمك وكتابتك لـ CSS ، وهو ليس أي شيء يعتمد على الأدوات أو أي نوع آخر من التكنولوجيا ، إنه مجرد نوع من تدفق العمل. لذلك هناك الكثير من الأساليب المختلفة المتاحة. لقد ذكرت BEM. هناك SMACSS و OOCSS و Atomic CSS. وبعد ذلك لديك هذا النوع من مناهج أطفال الحب غير العادية مثل ABEM. هل رايت ذلك؟

آندي: بلى.

درو: لماذا تنشر ما يخصك؟

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

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

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

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

درو: إذاً فإن المادة الدراسية التي كنت قد جمعتها تستخدم CUBE CSS كمنهجيتها ، أليس كذلك؟

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

درو: إذا كان هناك شخص ما يفهم بالفعل BEM وربما يستخدم بالفعل BEM ، كمثال ، لأنه من المحتمل أن تكون واحدة من أوسع المنهجيات المعتمدة ، أليس كذلك؟ لذا إذا كان لديهم بالفعل فهم لـ BEM وهم يأتون إلى CUBE ، فهل هذا شيء سيجدون أنه من السهل اعتماده؟ هل هناك أوجه تشابه كثيرة أم أنها مختلفة تمامًا؟

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

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

آندي: ثم هناك العناصر المميزة للتصميم بالكامل ، الأشياء التي فعلتها Jina مع نظام Lightning Design System الذي بدأنا جميعًا في اعتماده الآن. بدأت مواد فئة المنفعة بالفعل في فهم هذا النهج. لذلك قمت نوعًا ما بالتخلص من كل الأشياء التي أحبها في عمل الآخرين ودمجها في عملي بدلاً من ذلك.

درو: أنت تتحدث مع BEM ، نوع نهج التعديل الذي يخرج عن نطاق السيطرة. هل كانت تلك إحدى نقاط الألم الرئيسية مع BEM التي يحاول CUBE معالجتها؟

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

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

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

درو: لذلك دعونا ندخل CUBE بعد ذلك. لذا فإن CUBE تعني استثناء كتلة الأداة المساعدة للتكوين. هل هذا صحيح؟

آندي: بلى. هذا هو.

درو: ماذا يعني ذلك على الأرض؟

آندي: أوه ، يا صاح ، كان يجب أن تسمعه من قبل! كنت أقوم بعمل حديث العام الماضي. لقد أجريت حديثًا ، وكان يسمى الحفاظ على البساطة مع CSS الذي يتسع ، وهناك قدمت نوعًا ما إصدارًا سابقًا منه يسمى CBEUT ، والذي كان رمز الأداة المساعدة Cascade Block Element. كان قمامة. كرهت اسمها لقد فعلت ذلك عدة مرات ، هذا الحديث العام الماضي ، ولم يعجبني الاسم حقًا. ثم عندما جئت للقيام بهذه الأشياء هذا العام ، فكرت ، "أنا بحاجة حقًا للتفكير في ماهيتها بالفعل وما يسمى." أعتقد أن CUBE أقل نفايات قليلاً. أعتقد أن هذه هي أفضل طريقة يمكنني وصفها.

آندي: لكن بعد ذلك ، الأسماء دائمًا ما تكون هراء لهذه الأشياء ، أليس كذلك؟ أعني ، مثل BEM ، يا له من اسم هراء! ولكننا جميعا نفعل ذلك. انظر إلى Jamstack: هذا اسم فظيع أيضًا ، أليس كذلك؟

درو: شفتاي مختومة!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

درو: إذن هذا هو التكوين C. بعد ذلك لدينا U ، وهي المنفعة. إذن ماذا نعني بالمنفعة؟

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

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

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

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

درو: حسنًا ، لقد تحدثت كثيرًا في المقالة عن الرموز المميزة للتصميم ، وهو شيء تحدثنا عنه في Smashing Podcast مع Jina Anne في الحلقة الثالثة ، أعتقد أنه كان كذلك. لذلك يبدو أن رموز التصميم هي بالفعل جانب أساسي.

آندي: بلى. أوه ، الله ، أجل. أتذكر بوضوح عندما كانت Jina تقوم بأشياء Lightning Design System لأنني كنت أقوم ببناء نظام تصميم في ذلك الوقت ، أو شيء يشبه نظام التصميم ، وكنا نكافح للحصول على موافقة تنفيذية عليه. عندما ظهر نظام تصميم Lightning ، أرسلت لهم رابطًا تلو الآخر وقلت ، "هذا ما نفعله. نحن نبني نظام تصميم. هذا ما تستخدمه Salesforce حاليًا من أجله ". أتذكر أن عملها في ذلك الوقت ساعدني بالفعل في تمرير الأشياء عبر الباب.

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

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

درو: هل تنفيذ رموز التصميم هذه مهم بشكل خاص مع النهج؟ هل هي دائمًا خصائص مخصصة لـ CSS؟

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

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

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

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

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

درو: لذلك يمكن أن يكون صغيرًا مثل الارتباط التشعبي.

آندي: بلى.

درو: ولكن يمكن أن يكون أيضًا مجموعة مركبة من الكتل الأخرى؟

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

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

درو: أنا بالتأكيد بحاجة إلى الكثير من التسامح حول CSS الخاص بي!

آندي: أعرف أنك تفعل!

درو: في صحتك! هذا هو ب. آخر شيء هو E: E هو الاستثناء. الآن نحن لا نتحدث عن رسائل الخطأ ، أليس كذلك؟

آندي: لا ، لا. إنه نوع من-

درو: نحن لا نتحدث عن استثناءات JavaScript.

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

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

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

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

آندي: بلى. هذه طريقة جيدة لقول ذلك ، أجل. لقد وجدت أنه من المفيد جدًا العمل بهذه الطريقة.

درو: هذا مثير جدًا للاهتمام. لا أعتقد أنني رأيت أي منهجيات أخرى تتبع هذا النهج. هل هذا فريد تمامًا بالنسبة لـ CUBE ، وهو يفعل ذلك؟

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

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

درو: إذن لا يوجد شيء مثل مكعب نقي؟

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

درو: بصرف النظر عنك ، لا أحد يستطيع أن يقول ، "هذا ليس كتابًا CUBE."

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

درو: هل يمكنك خلط ومطابقة نهج CUBE مع منهجيات أخرى؟ هل يمكنك استخدام أجزاء من BEM؟

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

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

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

درو: هل يمكن تطبيق نهج CUBE على المشاريع الحالية التي يوجد بها بالفعل CSS أم أنه شيء تحتاجه حقًا للبدء في مشروع جديد؟

أندي: هذا يعتمد كثيرًا. لذا ، إذا كنت قد حصلت على وظيفة تمهيدية وكان لديك آلاف من سطور CSS المخصصة ، والتي شاركت فيها بالتأكيد من قبل ، فأعتقد أنك ربما تحاول إطفاء حريق بزجاجة ماء في ذلك الوقت نقطة. But if you… say, for instance, if you've got a rough BEM setup and it's gone a bit layer-y, you could use CUBE to refactor and actually pull it back into shape again.

Andy: It depends, the answer to that one. But it's doable, as with everything. If you really want it to work, Drew, you can do it if you want, can't you? The world is our oyster!

Drew: Especially if your BEM site's gone layer-y.

Andy: Yeah. Nothing worse than a layer-y BEM site!

Drew: I've noticed in the examples that you've given… and I've got an eagle eye, I've seen you've been doing this for a while… a lot of your class values in the HTML attribute are wrapped in square brackets.

Andy: Oh, God, yeah. Tell you what, Drew-

Drew: What is that about? ما هذا؟

Andy: I'll tell you what, if there's ever one thing that I've done in my whole career that's just been absolutely outrageously controversial… and you follow me on Twitter, you've seen what comes out of my mouth… it's those bloody brackets! My, God! People either love them or hate them. They're Marmite, they are.

Andy: The reason I do them is a grouping mechanism. So if you look at the way that they're structured, the way I do it is, block at the start and then I'll do a utilities after that. Then what I might do is, in between a block group and a utility group, there might be another block class. So a good example of that would be… we'll go back to the card again. But then say that there's a specific block called a CTA, like a call to action. You might have that applied to the card as well, and then your utilities are enforcing the design attributes, so the colors and all that business. So then you've got three groups of stuff.

Andy: When you come to it, if you've got that order in your head each time, you know, okay, right, this first group's blocks. Oh, that's looks like another block. I've got that one. Then it's like, right, they're definitely utility classes. Then what I might even do is, if there's a lot of design token implementation, have that in a separate group. So it's just very clear what each group is doing, and there's a separation inside of the classes there as well. I've found it really helpful. Some people find it incredibly offensive. It's definitely a do it if you want to do it. Definitely you don't have to do it.

Andy: It's quite funny, when I published that article, so many people finished halfway through to ask me, “What is it with these brackets?” I was like, “Did you finish the article? Because there's a big section at the end where it explains exactly what they're doing,” to the point where I actually had to write a bit in the middle of the article of, “If the brackets are essentially doing your head in, click here and I'll skip you all the way down to that explanation bit so you can just read about them.” It can be quite controversial.

Andy: When I've worked on really, really complex front-ends… and we did a little bit of stuff together, didn't we, last year?

درو: نعم.

Andy: You've seen the sort of design implementation on that project that we were on. It requires that sort of grouping because there's just so much going on at the time, there's so much different stuff happening. I've just found it really, really useful over the years, and also get lots of questions about it, to the point where I was almost going to write just one page on my website that I could just fire people to to answer the question for them.

Drew: Slash, what's with the brackets?

Andy: Yeah. Slash, brackets. Have you seen that new Hey Email thing that's just come out? They've bought a domain of itsnotatypo.com, just to answer the whole Imbox, like im with an M rather than an in. Basically, I was like, “I think I need to do that,” like, whatswiththebrackets.com, and just do a one-pager about it.

Drew: It strikes me that the approach with brackets actually could be something that might be useful when using things like Tailwind or something that has a lot of classes because that can-

Andy: Yeah. Oh, God, yes.

Drew: You have classes that are addressing your break points and what have you, and then you'll have things that are for layout, things that are for color or type, or what have you. So it might also be a useful way of dealing in situations like that.

Andy: I'd definitely agree with that. A good analogy… not analogy. A good bit of info about Tailwind is that I actually quite like Tailwind. I've used that on very big projects. The one thing that really opened my eyes to Tailwind though was when I saw a junior developer try to work out what was going on, and it was really, really eye-opening because they just didn't have a clue what was happening.

Andy: I think that's one problem I've found with these sort of over-engineered approaches, which I think it's fair to say Tailwind is, is that there's a certain skill level that is required to work with it. I know the industry tends to have an obsession with seniority now, but there's still people that are just getting into the game that we need to accommodate, and I think having stuff that's closer to the language itself is more helpful in those situations because they're probably learning material that is the language as it is. So I think it's just a bit more helpful. Especially having a diverse team of people as well. Just food for thought for everyone.

Drew: People might look at all the different methodologies that are out there and say, “This is evidence that CSS is terrible and broken, that we need… all these problems have to be solved by hacking stuff on top. We need tools to fix bits of CSS. We need strict procedures for how we implement it, just to get it to work.” Should the platform be adapting itself? Do we need new bits of CSS to try and solve these problems or are we all right just hacking around and making up funny acronyms?

Andy: I think the power of CSS, I think, is its flexibility. So if you're going to program CSS, a lot of the knowledge is less of the syntax and more of the workings of a browser and how it works. I think that might be a suggestion, that the problem is that people might not have learnt CSS quite as thoroughly as they thought they might have learnt it, who created these problems. I've seen that in evidence myself. I spotted a spacing mechanism that had been invested, which was very complicated, and I thought, “This person has not learnt what padding is because padding would actually fix this problem for them, understanding how padding works and the box model.” That's not to be snidey about it.

Andy: We work in an industry now that moves at an even faster pace than it has done previously and I think there's a lot less time for people to learn things in detail. But, on that front, I think CSS still does have work to do in terms of the working group, who I think do a bloody good job. A great, shining example of their work was the Grid spec which was just phenomenal. The way that rolled out in pretty much every browser on day one, I thought that was so good.

Andy: But we've got more work to do, I think, and I think maybe the pace might need to increase a little, especially with stuff like container queries, we all love talking about them. Stuff like that I think would help to put CSS in a different light with people, I think. But I think CSS is brilliant, I love it. I've never had a problem with it in lots of years really. I do find some of the solutions a bit odd, but there you go.

Drew: What's the response been like to CUBE since you published the article?

Andy: Mind-blowing. I honestly published it as just supporting material, and that's all I expected it to be, and it's just blown up all over the place. A lot of people have been reading it, asking about it, been really interested about it. There's definitely more to come on it.

Andy: I did say in the article, I said, “Look, if people are actually quite interested in this, I'll expand on this post and actually make some documentation.” I've got bits of documentation dotted around all over the place, but to sort of centralize that, and then I was thinking of doing some workshops and stuff. So there's stuff to go. It's how Every Layout started as well. We both had these scattered ideas about layout and then we sort of merged them together. So something like that, I suppose, will come in the future.

Drew: Are there any downsides that you're aware of to using CUBE? Are there problems that it doesn't attempt to solve?

Andy: Yeah. This accent, Drew, it just won't go way, no matter what I do! In all seriousness, I think CUBE's got as close as I can get to being happy with the front-end, which is saying a lot, I think. You never know, things might change again. This has evolved over more recent years. Give it another five years, I'll probably be struggling with this and trying something else. I think that's the key point, is to just keep working on yourself and working on what you know and how you approach things.

Andy: This definitely won't work for everyone as well, I know that for a fact. I know that from my comments. I don't expect it to work for everyone. I don't expect anything to work for everyone. It's the same with JavaScript stuff: some people like the reactive stuff and some people don't. هو كما هو. We're all people at the end of the day, we all have different tastes. It's all about communicating with your teammates at the end of the day, that's the important thing.

Drew: I know you as a very talented designer and developer and you, like many of us, you're just working on real projects all day, every day. But you've recently started publishing on this site, Piccalilli, which is where the CUBE CSS introduction article was. So Piccalilli is kind of a new venture for you, isn't it? What's it all about?

Andy: Very kind of you to say, Drew. You've actually worked with me, so that's high praise. But the Piccalilli thing is an evolution. So I'm a freelancer. I do client work, but I think this has become apparent with the pandemic, that that is not the most sustainable thing in the world in some industries. I think freelancing can be very, very tough, as a developer and designer. It's something that I've been doing it for so long now, 10 years… well, 12 years now actually.

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

درو: إذن ما الذي سيأتي بعد ذلك لبيكاليلي؟ هل لديك أي شيء خرجت منه؟

أندي: شكرا لفتح الباب هناك ، درو! بحلول الوقت الذي يخرج فيه هذا التسجيل ، ستكون الدورة التدريبية الأولى مباشرة: Learn Eleventy From Scratch ، وهذا هو المكان الذي نتعلم فيه كيفية إنشاء موقع Gatsby على الويب! لا ، أنت تتعلم كيفية بناء موقع Eleventy. لذلك تبدأ بدليل فارغ تمامًا ، لا يوجد فيه شيء ، إنه فارغ ، ثم في نهايته ستنتهي مع موقع الوكالة الجميل هذا حقًا. نتعلم كل الأنواع فيه. تتعلم كيف تذهب حقًا إلى المدينة مع Eleventy. نقوم بسحب البيانات البعيدة من الأماكن. نستخدم CUBE CSS لبناء واجهة أمامية لطيفة حقًا لذلك.

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

آندي: لذا قم بشرائه ، وسأقوم بعمل كود خصم ، أحب smashingpod بخصم 40٪ ، ويمكنك الحصول عليه عندما يخرج.

درو: مذهل. سنقوم بربط ذلك. هل اكتشفت كيفية تهجئة Piccalilli بشكل موثوق حتى الآن؟

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

درو: حسنًا ، ما زلت أعاني ، سأخبرك كثيرًا!

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

درو: لقد تعلمت كل شيء عن CUBE CSS. ما الذي كنت تتعلم عنه مؤخرًا ، (آندي)؟

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

آندي: اعتدت تشغيل هذا الشيء المسمى Front-End Challenges Club وعندما قمت بإطلاقه لأول مرة انهار ومات على نفسه لأن MySQL كانت رديئة على أقل تقدير. لذلك كنت أتعلم حقًا كيفية القيام بذلك لأنني لست شخصًا خلفيًا على الإطلاق ، أنا متحمس للبكسل. لذلك بالتأكيد ليس من اختصاصي. هذا هو عنقك من الغابة ، أليس كذلك؟ أجده رائعًا حقًا ، MySQL. أنا في الواقع أحب كتابته. إنها لغة تعليمية لطيفة حقًا ، أليس كذلك؟

درو: إنه رائع. لقد تعلمت SQL في المدرسة.

آندي: واو!

درو: نحن نتحدث منذ 20 عامًا الآن.

آندي: هل كان لديهم أجهزة كمبيوتر في تلك الأيام؟

درو: لقد فعلوا ، نعم. كان علينا الرياح-

آندي: هل كان عليك كتابتها باليد؟

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

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

درو: إذا كنت ، عزيزي المستمع ، ترغب في سماع المزيد من آندي ، فيمكنك متابعته على Twitter حيث يوجد في hankchizljaw. يمكنك العثور على Piccalilli على piccalil.li ، حيث ستجد أيضًا المقالة التي تصف CUBE CSS ، وسنضيف أيضًا روابط إلى كل تلك الموجودة في ملاحظات العرض ، بالطبع.

درو: شكرًا لانضمامك إلينا اليوم ، آندي. هل لديك اي كلمات فراق؟

آندي: ابق آمنًا ، وارتدي قناعك.