نظرة موضوعية على حرب المكتبات: React مقابل Vue

من أين أتينا؟ من نحن؟ إلى أين نحن ذاهبون؟

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

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

يمكن استبدال تطبيقات الهاتف المحمول بسهولة بالأدوات المستخدمة لتطوير الويب - انظر React أصليو NativeScript. بالإضافة إلى ذلك، لدينا PWA، والتي "تحاكي" بسهولة تشغيل تطبيقات الهاتف المحمول. بالإضافة إلى ذلك، المكونات التي تشغل تطبيقًا مكتوبًا بلغة Vue أو React يمكن بسهولة مشاركة مختلف الكود العناصر بين المنصات.

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

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

الانفجار الكبير في واقع الإنترنت

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

أفضل مثال يمكن الاستشهاد به هو مكتبة jQuery - التي كانت في ذلك الوقت واحدة من أكثر الحلول شيوعًا للتعامل مع الأحداث البسيطة. فبمساعدتها، تم تنفيذ العديد من القوائم المنسدلة والانتقالات والرسوم المتحركة والآلات الحاسبة والآليات المشابهة.

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

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

الخطوات الأولى نحو أطر العمل المعروفة

وبمرور الوقت، بدأت تظهر في الأفق أولى أطر الواجهة الأمامية التي تهدف إلى هيكلة البنية لتطبيقات أكثر تعقيدًا.

استندت هذه الأطر بشكل أساسي على نمط MVC - اقترح بعضها نهجًا يدويًا أكثر، مثل Backbone.js، بينما ارتبط البعض الآخر، مثل Knockout.js، بربط البيانات في اتجاهين.

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

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

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

هذا هو السبب الوحيد الذي يجعلنا اليوم قادرين على بناء تطبيقات الويب وتطويرها بطريقة سهلة وغير مؤلمة للغاية.

معلومات أساسية ومقارنة طفيفة

بدلاً من رمي اللحم، كما هو معتاد على الإنترنت، دعونا نلقي نظرة على كلتا المكتبتين ونجمع المعلومات عنهما ونقارن بينهما - نظريًا وعمليًا.

ملاحظة: وصف الآليات التي تعمل في Vue يشير تحديدًا إلى الإصدار 2. يقدم الإصدار 3 الكثير من التغييرات الهامة، ولكنه ليس منافسًا حقيقيًا لـ React في الوقت الحالي، ولو فقط بسبب نضجها - تاريخ إصدار Vue 3: 18 سبتمبر 2020.

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

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

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

● هناك جانب آخر مثير للاهتمام وهو JSX، وهي طريقة "متذبذبة" لقالب المحتوى المقدم باستخدام React. لها آراء مختلفة في مجتمع المطورين.

من ملاحظاتي يبدو أن المطورين الذين يستخدمون بيئة أخرى غير JS، على سبيل المثال PHP أو C#، أكثر ميلًا إلى قوالب المشاهدات بطريقة Vue يفعل.

خلاصة القول - القوالب المعروفة من Vue تسمح بتعريف وجهات النظر بطريقة واضحة وأنيقة للغاية، بينما تسمح JSX الخاصة بـ React ببنائها في كثير من الحالات بشكل أسرع، ومصممة خصيصًا لتلبية احتياجات محددة وغالبًا ما تتطلب كودًا أقل لبناء هياكل متنوعة;

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

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

يشير هذا الرمز إلى المكونات المرتبطة بدقة، وهي قوة التطبيقات التي تم إنشاؤها باستخدام React أو Vue;

● من الأمور المهمة، خاصة بالنسبة للأشخاص الذين لا يتمتعون بخبرة كبيرة في بيئة JS، مستوى الدخول إلى مكتبة معينة. بمعنى آخر - مدى تعقيد الأداة، والتي تتكون من الوقت المباشر الذي تحتاج إلى إنفاقه على فهم آلياتها.

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

ماذا تقول الإحصائيات؟

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

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

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

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

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

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

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

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

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

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

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

أفضل اختيار للمطور

في وقت سابق، ذكرت في وقت سابق الحد الأدنى للدخول إلى Vue - في الواقع، يسمح لك بالتركيز بشكل أسرع قليلاً على التطوير الفعلي للتطبيق، باستخدام الأداة وتقليل الوقت اللازم للتعرف على البيئة والميكانيكا وحالات الاستخدام المختلفة إلى الحد الأدنى.

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

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

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

لا يمكنني اقتراح أي المكتبتين أفضل للمطورين الأكثر أو الأقل إلمامًا بـ JavaScript. لكنني أعرف شيئًا واحدًا - إذا أردت أن تكون لديك فكرة حقيقية عن كيفية التطوير باستخدام كلتا الأداتين "من الداخل" - حاول كتابة التطبيقات في كل منهما. سيعطيك هذا فكرة، ويسمح لك بمعرفة الآليات التي تروق لك أكثر وما هو الخيار الأفضل بالنسبة لك.

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

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

أفضل اختيار لـ CTO

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

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

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

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

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

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

اعرض عليهم ما هو متوقع من التطبيق، وما هو الوقت المتاح لدينا لتسليمه والسماح بتبادل الآراء بشكل فضفاض حول رأيهم في كلا الحلين قبل أن نتخذ القرار النهائي.

الاستنتاجات

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

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

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

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

الخيار النهائي بين يديك. ومع ذلك، إذا كانت لديك أي شكوك أو كنت ترغب فقط في مناقشة قضيتك مع The Codest - لا تتردد في الاتصال بنا!

اقرأ المزيد:

لماذا يجب عليك (على الأرجح) استخدام Typescript

كيف لا تقتل مشروعاً بممارسات الترميز السيئة؟

استراتيجيات جلب البيانات في NextJS