07 سبتمبر 2025·7 دقيقة
ما هو jQuery ولماذا يقول الناس إنه مُنسى؟
جعل jQuery جافاسكربت أسهل عبر تبسيط التعامل مع DOM والأحداث وAJAX. تعرّف على ماهيته، لماذا تراجع، ومتى لا يزال مناسبًا اليوم.
جعل jQuery جافاسكربت أسهل عبر تبسيط التعامل مع DOM والأحداث وAJAX. تعرّف على ماهيته، لماذا تراجع، ومتى لا يزال مناسبًا اليوم.
jQuery هي مكتبة جافاسكربت صغيرة تجعل المهام الشائعة على صفحة الويب أسهل—أشياء مثل اختيار العناصر، الاستجابة للنقرات، تغيير النص، إظهار/إخفاء أجزاء من الصفحة، وإرسال طلبات إلى الخادم.
إذا رأيت شيفرة مثل $("button").click(...) فذلك jQuery. الرمز $ هو مجرد اختصار لـ "ابحث عن شيء في الصفحة وافعل به شيئًا".
هذا الدليل عملي وغير تقني: ما هي jQuery، لماذا أصبحت شائعة، لماذا المشاريع الحديثة لا تستخدمها كثيرًا، وكيف تتعامل معها إذا كان موقعك ما زال يعتمد عليها. هو أطول عمدًا حتى نتمكّن من تضمين أمثلة واضحة وإرشادات عملية بدلاً من آراء سريعة.
عندما يقول الناس إن jQuery "منسية"، فهم عادة لا يقصدون أنها اختفت. ما يقصدونه:
إذن القصة ليست "jQuery ماتت". بل: jQuery انتقلت من كونها الأداة الافتراضية للعمل الواجهات الأمامية إلى اعتماد قديم قد ترثه—وأحيانًا تختاره عن عمد.
قبل jQuery، كان العمل على الواجهة الأمامية غالبًا يعني كتابة نفس القطع الصغيرة المزعجة مرارًا—ثم اختبارها عبر متصفحات متعددة لا تتصرف بنفس الطريقة. حتى أهداف بسيطة مثل "اختر هذا العنصر"، "أرفق معالج نقر"، أو "أرسل طلبًا" كانت تتحول إلى مجموعة حالات خاصة.
كثير من جافاسكربت المبكرة كانت أقل عن بناء الميزات وأكثر عن مجابهة البيئة. تكتب شيفرة تعمل في متصفح واحد، ثم تضيف فروعًا إضافية لتعمل في آخر. احتفظت الفرق بمكتبات داخلية صغيرة للمساعدة فقط لتجاوز تغيّرات واجهة المستخدم اليومية.
النتيجة: تطوير أبطأ، أخطاء أكثر، وخوف دائم من أن تغييرًا صغيرًا سيكسر متصفحًا قديمًا يعتمد عليه المستخدمون.
المتصفحات لم تكن متفقة على تفاصيل مهمة. طرق اختيار DOM، التعامل مع الأحداث، وحتى كيفية الحصول على أحجام العناصر قد تختلف. إنترنت إكسبلورر، بشكل خاص، كان لديه APIs مختلفة للأحداث والطلبات XMLHTTP، لذا الشيفرة "القياسية" لم تكن دائمًا محمولة.
هذا مهم لأن المواقع لم تُبنَ لمتصفح واحد. إذا فشل نموذج الدفع أو قائمة التنقل أو مربع حوار شائع في متصفح مستخدم، فكان ذلك مشكلة تجارية حقيقية.
أصبحت jQuery مهمة لأنها قدمت واجهة متناسقة وصديقة وسوّت تلك الاختلافات.
جعلت المهام الشائعة أسهل بكثير:
والأهم أن أسلوب jQuery "اكتب أقل، افعل أكثر" ساعد الفرق على الشحن أسرع مع مفاجآت أقل خاصة في عصر كانت فيه "واجهات DOM الحديثة" أقل قدرة أو دعمًا.
القوة الحقيقية لـ jQuery لم تكن في أنها قدمت أفكارًا جديدة بالكامل—بل أنها جعلت المهام الشائعة في المتصفحات متناسقة وسهلة عبر المتصفحات المختلفة. إذا كنت تقرأ شيفرة واجهة أمامية قديمة، سترى عادة jQuery مستخدمة لأربع وظائف يومية.
$)دالة $() سمحت لك بـ "التقاط" عناصر باستخدام محددات شبيهة بـ CSS ثم العمل معها كمجموعة.
بدلًا من التعامل مع تعقيدات المتصفحات وAPIs الم verbose، كان بإمكانك اختيار كل العناصر، إيجاد عنصر ابن، أو الانتقال إلى عنصر أب باستخدام نداءات قصيرة قابلة للتسلسل.
جعلت jQuery من السهل الاستجابة لتصرفات المستخدم:
click للأزرار والروابطsubmit للنماذجready لتشغيل شيفرة عند تحميل الصفحةكما سوّت الاختلافات في كيفية تعامل المتصفحات مع كائنات الحدث والربط، وهو ما كان مهمًا حين كان دعم المتصفحات غير متساوٍ.
قبل أن يصبح fetch() قياسيًا، كانت $.ajax() و$.get() و$.post() في jQuery طريقة مباشرة لطلب بيانات من الخادم وتحديث الصفحة دون إعادة تحميل.
مكن ذلك أنماطًا تبدو الآن عادية—بحث حي، أزرار "تحميل المزيد"، تحديثات جزئية للصفحة—باستخدام واجهة مألوفة واحدة.
شاعت jQuery في اللمسات السريعة للواجهة مثل hide(), show(), fadeIn(), slideToggle(), و animate(). كانت هذه مفيدة للقوائم والإشعارات والانتقالات الأساسية—خصوصًا عندما كان دعم CSS أقل موثوقية.
مجتمعة، تفسّر هذه الميزات لماذا غالبًا ما تبدأ الشيفرة القديمة بـ $( ولماذا بقيت jQuery أداة افتراضية لفترة طويلة.
إن الكثير من سمعة jQuery تأتي من قلة السطور اللازمة للقيام بمهام واجهة مستخدم شائعة—خاصة عندما كان اختلاف المتصفحات مؤلمًا. مقارنة سريعة توضح ذلك.
jQuery
// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
e.preventDefault();
$('.status').text('Saved!');
});
جافاسكربت (بدون مكتبات)
// Select a button and run code when it's clicked
const saveButton = document.querySelector('#save');
const status = document.querySelector('.status');
saveButton?.addEventListener('click', (e) => {
e.preventDefault();
if (status) status.textContent = 'Saved!';
});
للوهلة الأولى، تبدو نسخة jQuery "أنظف": استدعاء واحد يلتقط العنصر، يربط المعالج، ويحدّث النص. تلك الكثافة كانت نقطة جذب رئيسية.
جافاسكربت الحديثة أكثر طولًا قليلاً، لكنها أيضًا أكثر صراحة:
querySelector وaddEventListener يخبرانك بما يحدث بالضبط.textContent خاصية معيارية في DOM (لا غلاف مكتبي).?.) والتحققات تجعل المقصود أوضح إذا لم توجد عناصر.يعتمد على السياق. إذا كنت تحافظ على قاعدة شيفرة قديمة تستخدم jQuery في كل مكان، قد تكون شيفرة jQuery أكثر اتساقًا وأسرع للعمل معها. إذا كنت تكتب شيفرة جديدة، فواجهات DOM الحديثة مدعومة على نطاق واسع، تقلل الاعتمادية، وأسهل للاندماج مع أدوات وأُطر العمل الحديثة.
لوقت طويل، كانت الميزة الأكبر لـ jQuery هي التوقّع: يمكنك كتابة طريقة واحدة لاختيار العناصر، ربط الأحداث، أو تشغيل طلب Ajax—وستعمل في معظم الأماكن.
مع مرور السنوات، طوّرت المتصفحات وموحّدت. العديد من التسهيلات التي جمعتها jQuery أصبحت الآن مدمجة في جافاسكربت نفسها، لذا غالبًا لا تحتاج لمكتبة إضافية للقيام بالأساسيات.
طرق DOM الحديثة تغطي أنماط jQuery الأكثر شيوعًا:
document.querySelector() / document.querySelectorAll() تحل محل $(...) للعديد من الاختيارات.element.classList.add() / .remove() / .toggle() تغطي تعديل الأصناف.element.addEventListener() يحل محل غلاف jQuery للأحداث في معظم الحالات.بدلًا من تذكّر مساعِدات خاصة بجQuery، يمكنك الاعتماد على APIs معيارية تعمل عبر المتصفحات الحديثة.
حيث كانت $.ajax() خيارًا شائعًا، أصبح fetch() الآن يتعامل مع العديد من الطلبات اليومية بأقل تعقيد، خاصة عند إقرانه بـ JSON:
const res = await fetch('/api/items');
const data = await res.json();
ما زال عليك معالجة الأخطاء والمهل الزمنية صراحةً، لكن الفكرة الأساسية—إجراء طلبات دون إضافة ملحق—باتت أصلية.
عرفت كثير من الناس الأساسيات غير المتزامنة عبر ردود النداء (callbacks) و$.Deferred. اليوم، تجعل الوعود (Promises) وasync/await تدفقات الأسطر غير المتزامنة أوضح، وتُسهِم وحدات ES في تنظيم الشيفرة.
ذلك الجمع—واجهات DOM الحديثة + fetch + ميزات لغة حديثة—أزال جزءًا كبيرًا من سبب اعتماد الفرق على jQuery افتراضيًا.
ترعرعت jQuery في عصر المواقع متعددة الصفحات: الخادم يولّد HTML، المتصفح يحمل الصفحة، وتضيف بعض السلوكيات فوق العلامات—معالجات النقر، التحريكات، استدعاءات Ajax.
الأطر الحديثة قلبت هذا النموذج. بدلًا من تحسين الصفحات، غالبًا ما تُولّد التطبيقات معظم الواجهة في المتصفح وتحافظ على تزامنها مع البيانات.
شاعت React وVue وAngular فكرة بناء الواجهات من مكونات—قطع صغيرة قابلة لإعادة الاستخدام تمتلك علاماتها، سلوكها، وحالتها.
في هذا الإعداد، يريد الإطار أن يكون مصدر الحقيقة لما يُعرض. يتتبع الحالة، يعيد عرض أجزاء الواجهة عند تغير الحالة، ويتوقع منك التعبير بطريقة إعلانية ("عندما يكون X صوابًا، اعرض Y").
jQuery، من ناحية أخرى، يشجع التعديل الإجرائي على DOM ("اختر هذا العنصر، غيّر نصه، أخفِه"). ذلك يمكن أن يتعارض مع دورة عرض الإطار. إن قمت بتغيير عقد DOM يدويًا التي يتحكم بها مكوّن، قد يقوم إعادة العرض التالي بالكتابة فوق تغييراتك—أو قد تنتهي بمطاردة أخطاء عدم تناسق.
مع شيوع SPAs، اعتمدت الفرق أدوات بناء ومجمّعات (مثل Webpack، Rollup، Vite). بدلاً من وضع وسوم السكربت مباشرة، تستورد وحدات، تحزم ما تستخدمه فقط، وتحسّن الأداء.
هذا التغير جعل الناس أكثر حساسية لحجم الحزم والاعتماديات. جلب jQuery "للاحتمال فقط" بدا أقل منطقية عندما أصبح كل كيلوبايت وتحديث طرف ثالث جزءًا من خط الأنابيب.
يمكنك استخدام jQuery داخل إطار، لكنه غالبًا يصبح جزيرة حالة خاصة—أصعب في الاختبار، أصعب في الفهم، وأكثر عرضة للكسر أثناء إعادة الهيكلة. لذلك اختارت كثير من الفرق أنماطًا مدمجة بالإطار بدلًا من البرمجة على نمط jQuery.
jQuery نفسها ليست "ضخمة" بالضرورة، لكنها غالبًا تأتي مع أعباء. العديد من المشاريع التي تعتمد jQuery تتراكم لديها إضافات (سلايدرز، محددات تواريخ، نوافذ منبثقة، أدوات تحقق)، كل منها يضيف شيفرة طرف ثالث إضافية للتحميل، التحليل، والتنفيذ.
المزيد من جافاسكربت يعني عادةً المزيد على المتصفح لتحميله، تحليله، وتنفيذه قبل أن تشعر الصفحة بالاستجابة. هذا التأثير يكون أوضح على الأجهزة المحمولة، الشبكات البطيئة، والأجهزة القديمة. حتى لو حصل المستخدمون على تجربة سلسة في النهاية، فإن "الوقت حتى أن يصبح الموقع قابلاً للاستخدام" قد يتأثر عندما تنتظر الصفحة سكربتات وإعتمادات إضافية.
نمط شائع في المواقع طويلة العمر هو قاعدة شيفرة "هجينة": بعض الميزات مكتوبة بجQuery، أجزاء أحدث بمكوّنات (React, Vue, Angular)، وقليل من شيفرة جافاسكربت الأصلية.
هذا الخليط يسبب ارتباك:
عندما تتعايش أنماط متعددة، تصبح التغييرات الصغيرة أكثر خطورة. يُحدِّث مطوّر مكوّنًا، ولكن سكربت jQuery القديم ما زال يتدخل في نفس الشيفرة، مما يسبب أخطاء يصعب استنساخها.
الفرق تتخلّى تدريجيًا عن jQuery ليس لأنها "تتوقف عن العمل"، بل لأن المشاريع الحديثة تُحسّن لأحجام حزم أصغر ووضوح ملكية سلوك الواجهة. مع نمو المواقع، تقليل الشيفرة الطرفية وتوحيد نهج واحد عادةً يجعل الضبط أداءً، التصحيح، والانضمام أسهل.
jQuery لم تصبح شائعة فقط—بل أصبحت الافتراضية. لسنوات، كانت أسهل طريقة لجعل الصفحات التفاعلية تعمل عبر المتصفحات، لذا انتهى بها المطاف مضمنة في قوالب، مقتطفات، دروس، وحلول نسخ‑ولصق.
بمجرد حدوث ذلك، أصبحت jQuery صعبة التجنّب: حتى لو استخدم الموقع ميزة صغيرة فقط، غالبًا ما كان يحمل المكتبة بأكملها لأن الأشياء الأخرى افترضت وجودها.
سبب كبير لاستمرار ظهور jQuery هو نجاحها جعلها "في كل مكان" في الشيفرة الطرفية. ويدجتات الواجهة، السلايدرز، المصابيح الخفيفة، محققات النماذج، وسكربتات الثيمات كانت تُكتب عادةً كملاحق jQuery. إذا اعتمد موقعك على أحد هذه المكونات، فإن إزالة jQuery قد تتطلب إعادة كتابة أو استبدال هذا الاعتماد—وليس مجرد تغيير بضعة أسطر.
WordPress مصدر كبير لـ "jQuery القديم". الكثير من الثيمات والإضافات—خاصة التي أنشئت قبل سنوات—تستخدم jQuery لسلوك الواجهة الأمامية، ولوحات إدارة WordPress تاريخيًا اعتمدت عليها أيضًا. حتى عندما تتحرك النسخ الأحدث باتجاه جافاسكربت حديثة، الذيل الطويل للإضافات القديمة يحافظ على وجود jQuery في الكثير من المواقع.
المواقع القديمة غالبًا تعطي أولوية لـ "لا تكسر ما يعمل". إبقاء jQuery يمكن أن يكون الخيار الأكثر أمانًا عندما:
باختصار، jQuery ليست دائمًا "منسية"—بل غالبًا جزء من الأساس الذي بُني عليه الموقع، والأساسات لا تُستبدل بسهولة.
jQuery ليست "سيئة"؛ لكنها أقل ضرورة الآن. هناك حالات حقيقية يبقى فيها الاحتفاظ بجزء من jQuery أو إضافتها هو الخيار العملي، خاصة عندما تكون الأولوية للوقت، التوافق، أو الاستقرار بدلًا من نقاء البنية.
إذا كانت متطلباتك تشمل متصفحات أقدم (خاصة إصدارات قديمة من Internet Explorer)، فإن jQuery لا تزال تبسّط اختيار DOM، التعامل مع الأحداث، وAJAX بطرق قد لا توفرها APIs الأصلية بدون polyfills إضافية.
السؤال الرئيسي هو التكلفة: دعم المتصفحات القديمة عادةً يعني شحن شيفرة إضافية. في هذا السياق، قد تكون jQuery جزءًا مقبولًا من حزمة التوافق.
إذا كان الموقع مبنيًا حول jQuery، فإن تعديلات واجهة المستخدم الصغيرة أسرع وأكثر أمانًا عند تنفيذها بنفس نمط الشيفرة. خلط الأنماط يمكن أن يخلق ارتباكًا (طريقتان للأحداث، طريقتان لتحديث DOM)، مما يصعّب الصيانة.
قاعدة عملية معقولة: إذا كنت تعدّل شاشة أو شاشتين فقط والتطبيق مستقر، فالتصحيح بـ jQuery مقبول—فقط تجنّب توسيع استخدامها إلى أنظمة جديدة ستحتاج لاحقًا إلى تفكيكها.
لموقع تسويقي بسيط أو أداة داخلية—بدون bundler، بدون transpiler، بدون إطار مكوّنات—يمكن أن تبقى jQuery مساعدة ملائمة بوضع سطر سكربت واحد. مفيدة خصوصًا عندما تريد بعض التفاعلات (قوائم قابلة للتبديل، سلوكيات نماذج بسيطة) ولا تريد إدخال خط أنابيب بناء.
العديد من الإضافات الناضجة (محدد التواريخ، جداول، نوافذ) بُنيت على jQuery. إذا كانت إضافة قديمة حيوية ومستقرة، قد يكون الاحتفاظ بـ jQuery أقل مخاطرة.
قبل الالتزام، تحقق إن كان هناك بديل مُدار وغير معتمد على jQuery—أو إن كان تحديث الإضافة سيُجبِر على إعادة كتابة أوسع من طاقة المشروع الحالية.
الانتقال بعيدًا عن jQuery أقل عن إعادة كتابة كاملة وأكثر عن تقليل الاعتماد دون كسر السلوك الذي يعتمد عليه الناس. النهج الأكثر أمانًا تدريجي: إبقِ الصفحات تعمل أثناء استبدال القطع أسفلها.
ابدأ بالإجابة على ثلاثة أسئلة عملية:
هذا التدقيق يساعدك على تجنّب استبدال ما لا تحتاجه ويكشف "اعتماديات مخفية" مثل إضافة تستخدم $.ajax() بصمت.
تحصل الفرق على مكاسب سريعة باستبدال الأنماط الأبسط والأكثر شيوعًا:
$(".card") → document.querySelectorAll(".card").addClass() / .removeClass() → classList.add() / classList.remove().on("click", ...) → addEventListener("click", ...)قم بذلك في PRs صغيرة ليكون من السهل مراجعته والتراجع عنه.
إذا كنت تستخدم $.ajax()، حرّك هذه المكالمات إلى fetch() (أو مساعد HTTP صغير) نقطة بنقطة. حافظ على أشكال الاستجابات حتى لا تحتاج بقية الواجهة للتغيير فورًا.
// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);
// Modern JS
fetch("/api/items")
.then(r => r.json())
.then(renderItems);
قبل إزالة jQuery، أضف تغطية حيث يهم الأمر: مسارات المستخدم الرئيسية، إرسال النماذج، وأي واجهة ديناميكية. حتى الفحوص الخفيفة (اختبارات مدخنة باستخدام Cypress أو قائمة مراجعة QA) يمكن أن تلتقط انحدارات مبكرًا. انشر التغييرات خلف علم ميزة إن أمكن، وتأكد من ثبات المقاييس/معدلات الأخطاء.
إذا أردت أمانًا إضافيًا خلال عمليات إعادة الهيكلة، يساعد استخدام أدوات تدعم أخذ لقطات ونقاط تراجع. على سبيل المثال، الفرق التي تقوم بتحديث واجهات قديمة غالبًا ما تصمم بدائل أولية ثم تستخدم سير عمليات يتيح الرجوع إلى نسخة "معروفة جيدة" أثناء التجريب.
ان احتجت مساعدة في تنظيم الخطة العامة، راجع /blog/jquery-vs-vanilla-js للحصول على معيار مقارنة يمكنك استخدامه أثناء عمليات إعادة الهيكلة.
الانتقال بعيدًا عن jQuery عادةً أقل عن "استبدال بناء الجملة" وأكثر عن فك افتراضات متراكمة لسنوات. هذه الفخاخ تبطئ الفرق—وكيفية تجنّبها.
إعادة كتابة كاملة تبدو نظيفة، لكنها غالبًا تولد فرعًا طويل الأمد، انحدارات كثيرة، وضغطًا لإصدار عمل غير مكتمل. النهج الآمن تدريجي: استبدل ميزة أو صفحة في كل مرة، حافظ على السلوك متطابقًا، وأضف اختبارات للأجزاء التي تلامسها.
إذا أدخلت React/Vue/Svelte (أو حتى نظام مكوّن خفيف) بينما jQuery ما زالت تعدّل نفس عقد DOM مباشرةً، قد تحصل على "مزاحمة واجهة": الإطار يعيد العرض ويكتب فوق تغيّرات jQuery، بينما jQuery تُحدِّث عناصر يعتقد الإطار أنها تحت سيطرته.
قاعدة عملية: اختر حدًا واضحًا. إما:
الكثير من الشيفرة القديمة تعتمد على أحداث مفوّضة مثل:
$(document).on('click', '.btn', handler)
يمكن للDOM الأصلي أن يفعل ذلك، لكن المطابقة وتوقعات this/event.target قد تتغير. أخطاء شائعة تشمل تشغيل المعالجات للعنصر الخطأ (بسبب أيقونات/عناصر داخلية) أو عدم التشغيل للعناصر المضافة ديناميكيًا لأن المستمع رُبط إلى سلف غير ثابت. عند استبدال الأحداث المفوَّضة، تأكد من:
closest() مفيد غالبًا)تأثيرات واجهة jQuery وأحيانًا التحريكات المخصّصة كانت تخفي مشكلات وصولية بالصدفة—أو تُدخلها. عند استبدال التلاشي والانزلاق، راجع:
aria-expanded)prefers-reduced-motion)التقاط هذه المشاكل مبكرًا يجعل ترحيلك أسرع وواجهتك أكثر موثوقية—حتى قبل أن يختفي آخر $().
jQuery ليست "سيئة". لقد حلت مشكلات حقيقية—خاصة حين كانت المتصفحات تتصرف بشكل مختلف وكان بناء صفحات تفاعلية يتطلب كتابة الكثير من شيفرة DOM المتكررة. ما تغيّر هو أنك عادةً لا تحتاجها بعد الآن للمشاريع الجديدة.
قوى عدة دفعتها من "الخيار الافتراضي" إلى "اعتماد قديم":
إذا كنت تحافظ على موقع قديم، قد تظل jQuery أداة معقولة—خاصةً للإصلاحات الصغيرة، الإضافات المستقرة، أو الصفحات التي لا تبرّر إعادة بناء كاملة. إذا كنت تبني ميزات جديدة، ابدأ بجافاسكربت الأصلية أولًا واحتفظ بـ jQuery فقط عندما توفر وقتًا فعليًا.
للاستمرار في التعلم بشكل يربط بالعمل الفعلي، تابع:
إذا كنت تقيم كيف تحدث التحديث أسرع، فكر في أدوات تساعدك على التجريب والإصدار تدريجيًا. يمكنك وصف السلوك المطلوب في محادثة، توليد واجهة React وواجهة خلفية عند الحاجة، وتصدير الشيفرة عند الاستعداد للاندماج مع قاعدة موجودة.
إذا كنت تقيم أدوات أو خيارات دعم، يمكنك أيضًا مراجعتها هنا: /pricing
jQuery هي مكتبة جافاسكربت تبسّط المهام الشائعة في المتصفح مثل اختيار العناصر، التعامل مع الأحداث، إجراء طلبات Ajax، وتنفيذ تأثيرات بسيطة (إظهار/إخفاء، تلاشي، انزلاق). النمط المميز لها هو استخدام دالة $() لإيجاد العناصر ثم ربط سلسلة من الإجراءات عليها.
$ هو مجرد اختصار لدالة (عادةً توفرها jQuery) تبحث عن عناصر في الصفحة—مشابهة لـ document.querySelectorAll()—وتعيد كائن jQuery يمكنك من خلاله استدعاء طرق متسلسلة.
إذا رأيت $() في شيفرة قديمة، فغالبًا ما تعني "اختر شيئًا ثم افعل به شيئًا".
لقد اكتسبت شعبية لأنها جعلت سلوك المتصفحات المختلفة يبدو متناسقًا. في الأيام الأولى، كانت أمور بسيطة مثل التعامل مع الأحداث، التنقّل في DOM، وAjax تتطلّب حلولًا خاصة بكل متصفح.
jQuery وفّرت واجهة واحدة متوقعة حتى تتمكن الفرق من الشحن أسرع مع مفاجآت أقل عبر المتصفحات.
ببساطة لأن جافاسكربت والمتصفحات "لحقت بالركب". اليوم يمكنك غالبًا استبدال مهام jQuery الكلاسيكية بميزات مدمجة:
querySelector / querySelectorAll للاختيارclassList لتعديل الأصنافلا. كثير من المواقع الحالية ما زالت تستخدمه، وهو يعمل. المقصود بـ “قديم” عادةً أنه أكثر انتشارًا في قواعد الشيفرة القديمة منه في المشاريع الجديدة.
السؤال العملي هو ما إذا كان يستحق الاحتفاظ به بناءً على الأداء، الصيانة، والاعتماديات الحالية (خاصة الإضافات).
لأنها أصبحت جزءًا من الأنظمة البيئية القديمة—خصوصًا الثيمات والإضافات. مثال شائع هو WordPress، حيث اعتمدت كثير من الإضافات والتيمات على jQuery تاريخيًا.
إذا كان موقعك يعتمد على إضافة تعمل فقط مع jQuery (سلايدر، محدد تواريخ، نافذة منبثقة، محقّق نماذج)، فإن إزالة jQuery غالبًا ما تعني استبدال تلك الإضافة وليس مجرد تعديل سطور قليلة.
نعم — في بعض الحالات العملية:
في هذه الحالات، قد تكون الاستقرارية والسرعة أهم من تقليل الاعتمادية.
ابدأ بشكل تدريجي وقيّم التأثير:
تفريغ كل شيء مرة واحدة. غالبًا ما يؤدي ذلك إلى فرع طويل الأمد، انزلاقات ومشاكل تستغرق وقتًا لإصلاحها. الأفضل أن تكون التغييرات تدريجية: صفحة أو ميزة واحدة في كل مرة مع اختبارات واضحة.
نعم — التأثيرات وإعادة كتابة DOM قد تكسر الوصولية بطريق الخطأ. عند استبدال hide()/show() أو تأثيرات الانزلاق/التلاشي، راجع:
aria-expandedprefers-reduced-motion)الحفاظ على السلوك ليس بصريًا فقط؛ بل تفاعلًا وتجربة لوحة مفاتيح أيضًا.
addEventListener للأحداثfetch + async/await للطلباتلذلك المشاريع الجديدة لا تحتاج غالبًا إلى طبقة توافقية للمهمات الأساسية.
$(".card") إلى document.querySelectorAll(".card")، من .addClass() إلى classList.add()، ومن .on("click", ...) إلى addEventListener("click", ...).$.ajax() إلى fetch() نقطة بنقطة مع الحفاظ على شكل الاستجابات.PRs صغيرة ونشر مرحلي يقللان مخاطر التراجع.