🎍 🕓 💝 سعر أطر JavaScript 👩🏿‍🤝‍👩🏽 🙌🏽 🐸

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

قم بتنزيل ملف عبر الشبكة.
تحليل وتجميع كود المصدر غير المعبأ بعد التحميل.
تنفيذ كود جافا سكريبت.
استهلاك الذاكرة.

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

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

ساعدني مشروع أرشيف HTTP في معرفة ذلك .

البيانات

يتتبع مشروع أرشيف HTTP إجمالاً 4308.655 رابطًا لمواقع عادية مخصصة لأجهزة سطح المكتب و 5،484،239 رابطًا لمواقع الجوال. من بين العديد من المؤشرات المرتبطة بهذه الروابط ، هناك قائمة بالتقنيات الموجودة في المواقع المعنية. وهذا يعني أنه يمكننا بناء عينة من آلاف المواقع التي تستخدم أطر عمل ومكتبات مختلفة ، ومعرفة مقدار الرمز الذي يرسلونه إلى العملاء ، ومقدار تحميل أنظمة المستخدم لهذا الرمز.

لقد جمعت البيانات لشهر مارس 2020 ، وكانت هذه أحدث البيانات التي تمكنت من الوصول إليها.

قررت مقارنة بيانات أرشيف HTTP المجمعة لجميع المواقع ببيانات المواقع التي تم فيها الكشف عن تفاعل و Vue و Angular ، على الرغم من أنني فكرت في استخدام مواد مصدر أخرى.

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

تمثل الروابط الموجودة في أرشيف HTTP المواقع التي اكتشفت استخدام التقنيات التي تهمنا

الإطار أو المكتبة	روابط لمواقع الجوال	روابط لمواقع عادية
مسج	4615474	3714643
تتفاعل	489827	241023
فيو	85649	43691
الزاوي	19423	18088

آمال وأحلام

قبل أن ننتقل إلى تحليل البيانات ، أود أن أتحدث عما أود أن أتمنى.

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

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

يجب أن تعمل أفضل الأطر على حد سواء: إعطاء قاعدة جيدة ، وفرض قيود على العمل ، مما يسمح بتحقيق نتيجة لائقة.

لن يعطينا تحليل قيم البيانات المتوسطة المعلومات الضرورية. وفي الواقع ، فإن مثل هذا النهج يترك الكثير من الأهمية خارج اهتمامنا . بدلاً من ذلك ، استنتجت من مؤشرات البيانات الخاصة بي المعبر عنها بالنسب المئوية. هذا هو 10 ، 25 ، 50 (متوسط) ، 75 ، 90 في المائة.

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

أحجام كود جافا سكريبت

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

كمية كود JavaScript (Kb) المنقولة إلى الأجهزة المحمولة

	10	25	50	75	90
	93.4	196.6	413.5	746.8	1201.6
jQuery-	110.3	219.8	430.4	748.6	1162.3
Vue-	244.7	409.3	692.1	1065.5	1570.7
Angular-	445.1	675.6	1066.4	1761.5	2893.2
React-	345.8	441.6	690.3	1238.5	1893.6

JavaScript-,

JavaScript- (),

	10	25	50	75	90
	105.5	226.6	450.4	808.8	1267.3
jQuery-	121.7	242.2	458.3	803.4	1235.3
Vue-	248.0	420.1	718.0	1122.5	1643.1
Angular-	468.8	716.9	1144.2	1930.0	3283.1
React-	308.6	469.0	841.9	1472.2	2197.8

مقدار رمز JavaScript الذي تم نقله إلى أجهزة سطح المكتب

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

وتجدر الإشارة في هذه البيانات إلى أن بعض الأطر والمكتبات يمكن اعتبارها نقطة بداية أكثر نجاحًا للمشروع من غيرها. مواقع JQuery تبدو أفضل. في إصدارات سطح المكتب من المواقع ، تحتوي على جافا سكريبت أكثر بنسبة 15٪ من جميع المواقع ، وعلى إصدارات الجوال - 18٪ أكثر. (يجب أن أعترف أنه يمكنك هنا ملاحظة بعض التشويه للبيانات. والحقيقة هي أن jQuery موجود في العديد من المواقع ، لذلك من الطبيعي أن تكون هذه المواقع أقرب من غيرها إلى العدد الإجمالي للمواقع. ولكن هذا لا يؤثر على الطريقة يتم عرض بيانات المصدر لكل إطار عمل.)

على الرغم من أن الزيادة في الشفرة بنسبة 15-18٪ هي رقم مهم ، ومقارنتها بالأطر والمكتبات الأخرى ، يمكننا أن نستنتج أن "الضريبة" التي تفرضها jQuery منخفضة جدًا. ترسل المواقع على زاوية الشريحة المئوية العاشرة بيانات بنسبة 344٪ إلى أجهزة سطح المكتب أكثر من جميع المواقع ، وإلى الهواتف الجوالة - بزيادة 377٪. مواقع رد الفعل ، التالية من حيث الشدة ، ترسل رمزًا بنسبة 193 ٪ إلى أجهزة سطح المكتب أكثر من جميع المواقع ، و 270 ٪ أكثر إلى أجهزة الجوال.

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

ومن المثير للاهتمام أن مواقع jQuery تتبع هذه الفكرة. على الرغم من أنها ، في المستوى المئوي العاشر ، أثقل قليلاً من جميع المواقع (15-18٪) ، إلا أنها ، في المستوى المئوي 90 ، أخف قليلاً من الكل - بنحو 3٪ في كل من إصدارات سطح المكتب والجوّال. لا يمكن القول أن هذا يمثل فائدة كبيرة جدًا ، ولكن يمكن القول أن مواقع jQuery على الأقل لا تختلف في الحجم الكبير لرمز جافا سكريبت ، حتى في أكبر إصداراتها.

ولكن لا يمكن قول الشيء نفسه عن الأطر الأخرى.

كما هو الحال مع المئين العاشر ، تختلف المواقع المئوية 90 على الزاوي والتفاعل عن المواقع الأخرى ، ولكنها للأسف تختلف للأسوأ.

عند النسبة المئوية 90 ، ترسل مواقع Angular بيانات أكثر بنسبة 141٪ إلى أجهزة الجوّال من جميع المواقع ، و 159٪ أكثر إلى أجهزة سطح المكتب. ترسل مواقع رد الفعل 73٪ أكثر إلى أجهزة سطح المكتب من جميع المواقع ، و 58٪ أكثر إلى الأجهزة المحمولة. حجم الشفرة لمواقع التفاعل على النسبة المئوية 90 هو 2197.8 كيلوبايت. وهذا يعني أن هذه المواقع ترسل بيانات أكثر إلى 322.9 كيلوبايت إلى الأجهزة المحمولة من أقرب منافسيها استنادًا إلى Vue. الفجوة بين مواقع سطح المكتب على أساس Angular و React ، وبين المواقع الأخرى ، أكبر. على سبيل المثال ، ترسل مواقع React لسطح المكتب 554.7 كيلوبايت من كود JS للأجهزة أكثر من مواقع Vue المماثلة.

الوقت المستغرق في معالجة كود JavaScript في الخيط الرئيسي

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

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

تحتوي قاعدة بيانات أرشيف HTTP على معلومات عن مقدار الوقت الذي تستغرقه معالجة تعليمات JavaScript البرمجية في السلسلة الرئيسية لمحرك V8. هذا يعني أنه يمكننا جمع هذه البيانات ومعرفة مقدار الوقت الذي يستغرقه مؤشر الترابط الرئيسي لمعالجة JavaScript للمواقع المختلفة.

وقت وحدة المعالجة المركزية (بالمللي ثانية) المتعلق بمعالجة النصوص البرمجية على الأجهزة المحمولة

المئويات	10	25	خمسون	75	90
جميع المواقع	356.4	959.7	2372.1	5367.3	10485.8
مواقع مسج	575.3	1147.4	2555.9	5511.0	10349.4
مواقع Vue	1130.0	2087.9	4100.4	7676.1	12849.4
مواقع الزاوي	1471.3	2380.1	4118.6	7450.8	13296.4
تفاعل المواقع	2700.1	5090.3	9287.6	14509.6	20813.3

وقت CPU المتعلق بمعالجة النصوص البرمجية على الأجهزة المحمولة

وقت CPU (بالمللي ثانية) المتعلق بمعالجة النصوص على أجهزة سطح المكتب

المئويات	10	25	خمسون	75	90
جميع المواقع	146.0	351.8	831.0	1739.8	3236.8
مواقع مسج	199.6	399.2	877.5	1779.9	3215.5
Vue-	350.4	650.8	1280.7	2388.5	4010.8
Angular-	482.2	777.9	1365.5	2400.6	4171.8
React-	508.0	1045.6	2121.1	4235.1	7444.3

وقت وحدة المعالجة المركزية المتعلق بمعالجة النصوص على أجهزة سطح المكتب

هنا يمكنك رؤية شيء مألوف للغاية.

بالنسبة للمبتدئين ، تنفق المواقع التي تحتوي على jQuery أقل بكثير على معالجة JavaScript في سلسلة المحادثات الرئيسية من غيرها. في الشريحة المئوية العاشرة ، مقارنة بجميع المواقع ، تقضي مواقع jQuery على أجهزة الجوّال وقتًا أطول بنسبة 61٪ في معالجة شفرة JS في سلسلة المحادثات الرئيسية. في حالة مواقع jQuery المكتبية ، يزداد وقت المعالجة بنسبة 37٪. عند المستوى المئوي التسعين ، تكون مقاييس موقع jQuery قريبة جدًا من المقاييس المجمعة. على وجه التحديد ، تقضي مواقع jQuery على أجهزة الجوّال وقتًا أقل بنسبة 1.3٪ في ساحة المشاركات الرئيسية مقارنة بجميع المواقع ، وعلى أجهزة سطح المكتب - وقت أقل بنسبة 0.7٪.

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

عند النسبة المئوية العاشرة ، تقضي المواقع الزاوية لسطح المكتب 230٪ من وقت سلسلة المحادثات الرئيسية لمعالجة شفرة JS أكثر من جميع المواقع. بالنسبة لمواقع الجوال ، هذا الرقم هو 313٪. مواقع رد الفعل لديها أسوأ أداء. على أجهزة سطح المكتب ، يقضون 248 ٪ وقتًا أطول في معالجة التعليمات البرمجية مقارنة بجميع المواقع ، وعلى أجهزة الجوال - 658 ٪ أكثر. 658٪ ليس خطأ مطبعي. عند النسبة المئوية العاشرة ، تقضي مواقع التفاعل 2.7 ثانية من وقت سلسلة المحادثات الرئيسي لمعالجة الشفرة التي لديها.

تبدو النسبة المئوية 90 ، عند مقارنتها بهذه الأرقام الضخمة ، أفضل قليلاً على الأقل. تقضي المشاريع الزاويّة ، مقارنة بجميع المواقع ، بمزيد من الوقت بنسبة 29٪ على أجهزة سطح المكتب في سلسلة المحادثات الرئيسية ، و 27٪ على الأجهزة المحمولة. في حالة مواقع التفاعل ، تبدو المؤشرات المماثلة ، على التوالي ، 130٪ و 98٪.

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

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

وقت وحدة المعالجة المركزية (بالمللي ثانية) المتعلق بمعالجة النصوص البرمجية على الأجهزة المحمولة في المواقف التي تستخدم فيها المواقع إطار عمل واحد فقط أو مكتبة واحدة فقط

المئويات	10	25	خمسون	75	90
, jQuery	542.9	1062.2	2297.4	4769.7	8718.2
, Vue	944.0	1716.3	3194.7	5959.6	9843.8
, Angular	1328.9	2151.9	3695.3	6629.3	11607.7
, React	2443.2	4620.5	10061.4	17074.3	24956.3

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

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

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

هذا غريب بعض الشيء ، لكنني ما زلت أحاول البحث عن تفسير لهذا الغريب.

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

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

الفجوة بين الأجهزة المحمولة وأجهزة سطح المكتب

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

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

الزيادة في الوقت (بالنسبة المئوية) المتعلقة بمعالجة النصوص البرمجية على الأجهزة المحمولة مقارنة بسطح المكتب

المئويات	10	25	خمسون	75	90
جميع المواقع	144.1	172.8	185.5	208.5	224.0
مواقع مسج	188.2	187.4	191.3	209.6	221.9
مواقع Vue	222.5	220.8	220.2	221.4	220.4
مواقع الزاوي	205.1	206.0	201.6	210.4	218.7
تفاعل المواقع	431.5	386.8	337.9	242.6	179.6

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

ملخص

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

لا يبدو أن هذا ينطبق على أداء مشاريع الويب (وعلى ما يبدو ، على مدى توفرها ).

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

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

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

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

لكن لدينا سبب للتفاؤل. يشجعني مدى تفاعل مطوري Chrome عن قرب مع بعض أدوات الواجهة الأمامية التي راجعناها في محاولة للمساعدة في تحسين أداء هذه الأدوات.

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

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

اختبر نفسك من حيث الفطرة السليمة. هل تحتاج حقًا إلى استخدام الإطار المختار؟ إن JavaScript النقي قادر على تحقيق الكثير اليوم.
هل هناك بديل أسهل للإطار المختار (مثل Preact أو Svelte أو أي شيء آخر) يمكن أن يمنحك 90٪ من إمكانات هذا الإطار؟
إذا كنت تستخدم بالفعل نوعًا من إطار العمل ، فكر فيما إذا كان هناك شيء يوفر خيارات قياسية أفضل وأكثر تحفظًا (على سبيل المثال ، Nuxt.js بدلاً من Vue و Next.js بدلاً من React وما إلى ذلك).
ما هي ميزانية أداء JavaScript الخاصة بك ؟
كيف يمكنك الحد من عملية التطوير من أجل تعقيد تنفيذ كمية أكبر من شفرة جافا سكريبت في المشروع مما هو ضروري للغاية؟
إذا كنت تستخدم إطار العمل لراحة التطوير ، ففكر فيما إذا كنت بحاجة إلى إرسال رمز إطار العمل إلى عملائك. ربما يمكنك حل جميع المشاكل على الخادم؟

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

القراء الأعزاء! كيف ترى إطار عمل JavaScript المثالي؟