أطر العمل الأمامية: حلول أم مشاكل متضخمة؟

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

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

تطوير الويب للواجهة الأمامية في الماضي

يجب أن أبدأ بالقول ما هو واضح: العالم لم يكن كما كان قبل 10 سنوات. (صادم ، أعرف.) الشيء الوحيد الذي يبقى ثابتًا هو التغيير. في الماضي ، كان لدينا عدد قليل جدًا من المتصفحات ، ولكن كان هناك الكثير من مشكلات التوافق. اليوم ، لا ترى أشياء مثل "أفضل عرض على Chrome 43.4.1" كثيرًا ، ولكن في ذلك الوقت ، كانت شائعة جدًا. لدينا الآن المزيد من المتصفحات ، لكن مشاكل التوافق أقل. لماذا ا؟ بسبب مسج . استوفى jQuery الحاجة إلى وجود مكتبة قياسية مشتركة تسمح لك بكتابة كود JavaScript الذي يتعامل مع DOM دون الحاجة إلى القلق بشأن كيفية تشغيله على كل متصفح وعلى كل إصدار من كل متصفح - وهو كابوس حقيقي في العقد الأول من القرن الحادي والعشرين .

يمكن للمتصفحات الحديثة التعامل مع DOM كمعيار ، لذلك تضاءلت الحاجة إلى مثل هذه المكتبة بشكل كبير في السنوات الأخيرة. لم تعد هناك حاجة لـ jQuery ، ولكن لا يزال بإمكاننا العثور على عدد من المكونات الإضافية المفيدة للغاية التي تعتمد عليها. بمعنى آخر ، قد لا تكون أطر الويب ضرورية ، لكنها لا تزال مفيدة بما يكفي لتكون شائعة ومستخدمة على نطاق واسع. هذه سمة مشتركة في معظم أطر عمل الويب الشائعة ، من React و Angular و Vue و Ember إلى نماذج النمط والتنسيق مثل Bootstrap.

لماذا يستخدم الناس الأطر

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

إذن ما هي بعض الفوائد والخصائص الفريدة لاستخدام إطار عمل تطوير الويب؟

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

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

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

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

عندما تفشل الأطر

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

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

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

يمكن أن يؤدي وجود الكثير من التعليمات البرمجية التي لا تستخدمها إلى تأخير وقت تحميل موقعك ، والذي يصبح أكثر أهمية مع كل مستخدم إضافي. هناك مشكلة أخرى وهي أن عقلية "مقاس واحد يناسب الجميع" تؤدي إلى رمز غير فعال. خذ على سبيل المثال $('sku-product').html('SKU 909090'); ، وهو كود jQuery الذي ، في النهاية ، نعلم جميعًا أنه سيتم ترجمته إلى شيء مثل document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

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

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

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

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

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

الأطر لها آراء وهي قوية ؛ React ، على سبيل المثال ، يجبرك على استخدام JSX بطريقة معينة. يمكنك رؤية الكود يتم استخدامه بهذه الطريقة في كل مكان. هل يوجد بديل؟ نعم. لكن من يستخدمها؟ هذا ليس شيئًا سيئًا دائمًا ، ولكن إذا كنت بحاجة إلى أداء رسوم متحركة معقدة ، فقد تحتاج فقط إلى إطار عمل للرسوم المتحركة وليس React بالكامل. لقد رأيت أشخاصًا يقومون بأشياء مجنونة مثل إضافة jQuery إلى صفحة فقط لإلحاق عقدة بعنصر ، وهو أمر يمكن إنجازه في Vanilla JS باستخدام document.getElementById('id_of_node').appendChild(node); .

إيفال هو الشر ، ولكن .innerHTML ميكافيلي

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

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

أكبر الخرافات حول الترميز بدون أطر

الوقت قيم. نعم ، سأعيد هذا المفهوم من قبل. يشعر الكثير من الناس أنه إذا توقفوا عن استخدام إطار عمل ويب شائع ، فسننتقل على الفور إلى الإنترنت في التسعينيات ، عندما كانت <marquee> هي العلامة المفضلة للجميع ، وكانت صور GIF المتناوبة على موقع Geocities مفعمًا بالحيوية والحيوية ، وكانت Alta Vista هي الهدف- لبحوث الويب ، وكانت عدادات النقر في كل مكان.

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

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

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

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

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

أريد إثبات

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

الكود التالي يستخدم jQuery المكافئ لـ .innerHTML :

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

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

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

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

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

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

لنلقِ نظرة على React:

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

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

لكل مثال ، ستكون النتائج مختلفة. في بعض الأحيان ، سيكون jQuery أقصر. في بعض الأحيان ، تفوز React. هناك أوقات يمكن أن تكون فيها Vanilla JS أقصر من كليهما. على أي حال ، لم يكن الهدف هنا إثبات أن أحدهما متفوق بطبيعته على الآخر ، ولكن لإثبات أنه لا يوجد فرق كبير بين استخدام Vanilla JS واستخدام إطار عمل عندما يتعلق الأمر بطول الكود.

خاتمة

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

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