قصة لماذا ما زلت أستخدم jQuery

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

مواقع مثل قد لا تحتاج إلى jQuery (YMNJQ) تروج لفكرة أن jQuery من السهل جدًا التخلص منه. لكن المثال الأول على هذا الموقع يوضح سبب وجيه لاستخدام jQuery. هناك ، يتم استبدال سطر بسيط من رمز jQuery بـ 10 أسطر من JS العادية!

معظم واجهات برمجة التطبيقات JavaScript ، خاصة تلك التي تركز على العمل مع DOM ، تسيء إلى حسي الجمالية. هذا ، بعبارة ملطفة ، موقفي تجاههم. التحدث مباشرة ، أعتقد أن واجهات برمجة التطبيقات هذه كابوس كامل. على سبيل المثال ، بناء el.insertAdjacentElement('afterend', other) يعمل بالتأكيد. ولكن يبدو أجمل بكثير $(el).after(other) . على الرغم من أنني لم أحب أبدًا شكل الدالة $() ، إلا أنها أفضل من مثيلاتها التي توفرها لنا واجهات برمجة التطبيقات القياسية للعمل مع DOM. أعلم أنه بدلاً من $() يمكنك استخدام شيء مثل jQuery(sel) أو window.jq = jQuery . لكنني لا البرنامج في الفضاء الخالي من الهواء. لذلك ، أفضل استخدام التقنيات القياسية. لا أعرف ما إذا كان هذا جيدًا أم سيئًا ، ولكن المعيار لاستخدام jQuery هو بناء $() .

حاول أن تتذكر بسرعة كيفية الحصول على عنصر مجاور لعنصر آخر باستخدام DOM. ما الذي يجب استخدامه لهذا - nextSibling أو nextElementSibling ؟ ما الفرق؟ وما المتصفحات التي تدعم هذه الطريقة أو تلك؟ بينما تحاول أن تتذكر هذا وتنظر إلى MDN ، تفحص نفسك ، أنا ، باستخدام jQuery ، فقط اكتب next() أو prev() .

أداء العديد من العمليات المشتركة المنفذة في JavaScript API غير مريح. يمكنني أن أقدم هنا قائمة كاملة من هذه العمليات ، لكن بالنسبة لي تم ذلك على صفحة YMNJQ.

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

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

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

يمكنك هنا معرفة مقدار الجهد المبذول لإزالة jQuery من Bootstrap والتحول إلى JS منتظم.

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

أنا أفهم أسباب ترجمة Bootstrap إلى JS منتظم. على سبيل المثال ، يريد المطورون استخدام Bootstrap مع Vue.js ، أو شيء مشابه. و Vue.js و jQuery في مشروع واحد بالفعل جزء من تمثال نصفي. أنا مؤيد كبير لتقليل مقدار الشفرة غير الضرورية على الويب ( وإليك بعض المواد حول هذا). ولكن هنا أقترح أن ننظر إلى الوضع من وجهة نظر واقعية وواقعية. هل تضمين رمز jQuery 17 كيلوبايت في Bootstrap - هل هذا سيء؟ عندما أقول أنه لعرض مواقع مثل Medium أو New York Times ، يلزمك تنزيل أكثر من ميغابايت من شفرة JavaScript ، من أجل حماية هذا الموقف ، يسألونني إذا كنت جالسًا على أي خط مودم سعة 56 كيلو بايت. ميجابايت JS على ما يرام. هل مسج 17 كيلوبايت ثقيل حقًا؟
هناك أسباب وجيهة لعدم استخدام مسج. على سبيل المثال ، ليست هناك حاجة jQuery إذا كنت تكتب التعليمات البرمجية التي تريد مشاركتها مع الآخرين ، أو إذا كنت تقوم بإنشاء بعض الوظائف الصغيرة. ولكن لماذا تتحول من الداخل فقط حتى لا تستخدم jQuery؟ لماذا كل هذا الجهد إذا كنت تستطيع فقط كتابة $() ؟ لا أعتقد أنه يجب استخدام jQuery في كل مكان ودائمًا ، لكنني لا أعتقد أن الرفض المتعصب لـ jQuery هو الصحيح.

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

قد يتساءل العديد من القراء عما يمكنني قوله ، في سياق هذه المادة ، عن Vue.js و React والأطر الحديثة الأخرى. لكن الهدف من هذا المقال هو تعيين جافا سكريبت عادي و jQuery ، بدلاً من تقديم للمجتمع "Grandiose General Frontend Development Theory".

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

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

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

أعزائي القراء! هل تستخدم مسج؟