لماذا يختار المطورون مرة أخرى كتابة أكوادهم الخاصة بدلاً من منصة الويب

التاريخ والعادة

الحجج الرئيسية لاستخدام وظائف المتصفح بدلاً من JavaScript الخاص هي الأداء وسهولة الاستخدام وإمكانية الوصول، لكن دمجها لم يكن سهلاً دائمًا. في معظم تاريخ الويب، كانت المتصفحات تتخلف عن نظام الويب البيئي الأوسع. مكتبات مثل jQuery كانت تسد ثغرات كبيرة، وكان المطورون غالبًا يضطرون للانتظار حتى يتم التخلي عن المتصفحات القديمة مثل IE6 قبل استخدام واجهات API الجديدة. في هذه البيئة، كان البناء فوق المتصفح استجابة منطقية. ولا تزال العادة مهمة: مطورو React المعتادون على البحث عن المكونات في npm قد يبحثون عن حزمة قبل النظر في CSS أو واجهة API الخاصة بالمتصفح. تجعل الـ Wrappers وظائف المنصة غير المألوفة أكثر فهمًا، وغالبًا ما كانت وثائق الحزمة أسهل في العثور عليها من المعلومات المبعثرة لمنصة الويب. أصبح MDN لاحقًا اتجاه التوثيق المركزي، بينما قُدم web.dev كجهد تعليمي أحدث من Google.

جاذبية البناء

بالنسبة لبعض المطورين، يكفي التنفيذ بنفسهم. قد يبدأ الحوار النمطي بتحديد الموضع المرئي وتمرير الخلفية، ثم يصبح من الضروري معالجة زر Escape وفخ التركيز واستعادة التركيز. يمكن للمطورين إضافة رسوم متحركة أو سمات أو زر إغلاق قبل تحويل النتيجة إلى حزمة قابلة لإعادة الاستخدام. يطلق المصدر على هذا تأثير IKEA، لأن الكود المكتوب يدويًا يمكن أن يوقظ رغبة في الحفاظ عليه وتخصيصه. قد تكون الأدوات الخاصة أيضًا طريقًا للتعلم: عمل المؤلف على أدوات التخزين المرتبطة بـ IndexedDB و WebSQL و PouchDB، ولاحقًا ساهم حتى في مواصفات IndexedDB. ساعدت عيوب المنصة المبكرة في ظهور الـ polyfills والـ shims والمكتبات، مما ساعد في بناء خبرة المنصة.

مشاكل المعرفة وسلوك المنصة

ليس كل حل مخصص يعكس تسوية مدروسة؛ بعضها يأتي من معرفة غير مكتملة. كانت وظائف CSS مثل float و clear fix و min-width: 0 صعبة الفهم، بينما بقيت الاحتياجات الشائعة، بما في ذلك تقييد الأسطر وتغيير حجم textarea وإخفاء شريط التمرير، بدون حلول مباشرة أصلية لسنوات. كان بإمكان المطورين التعبير عن السلوك المطلوب بسهولة أكبر في JavaScript. قدمت مثال ClickHouse نفس النتيجة. قام مطور بضغط JSON كبير قبل التخزين، بينما وضعه آخر في مخزن key-value منفصل واحتفظ بالمفاتيح فقط في ClickHouse. بعد مراجعة الوثائق والقياسات، اكتشفوا أن ClickHouse يضغط بالفعل البيانات العمودية ويوفر ضغطًا أفضل بين الصفوف، مما يجعل النظام المنفصل أبطأ وأكثر تعقيدًا.

قد يغير الذكاء الاصطناعي التوازن

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