ATM Logo
ATMATM Team

© 2026 ATM. جميع الحقوق محفوظة

الStrict Mode : كيف اصلحت JavaScript عيوبها ؟ دون ان تكسر الويب

الStrict Mode : كيف اصلحت JavaScript عيوبها ؟ دون ان تكسر الويب
Author's profile picture
algerian tech makers

5/15/2026

في المقال السابق تحدثنا عن أحد أهم المبادئ التي حافظت على استقرار الويب لعقود، وهو مبدأ التوافق العكسي (Backward Compatibility).

ورأينا كيف أن JavaScript لا تستطيع ببساطة حذف السلوكيات القديمة أو تغييرها جذريا، لأن ذلك قد يؤدي إلى تعطّل ملايين المواقع القديمة.
لكن هنا تظهر مشكلة مثيرة للاهتمام...
ماذا يحدث إذا كانت بعض هذه السلوكيات القديمة سيئة أصلا؟
في السنوات الأولى من JavaScript، كانت اللغة متساهلة جدا مع الأخطاء، لدرجة أنها كانت أحيانا "تخفي" المشاكل بدل أن تمنعها.
على سبيل المثال:
toml
name = "Ali";
هذا الكود يبدو عاديا، لكن في JavaScript القديمة إذا نسيت كتابة var أو let أو const، فإن اللغة تقوم تلقائيا بإنشاء متغير عالمي (Global Variable) دون أي تحذير!
وهذا النوع من السلوكيات كان سببا في عدد هائل من الأخطاء والمشاكل، خاصة في المشاريع الكبيرة.
لكن هنا اصطدمت JavaScript بمشكلتها المعتادة:
لا يمكن إصلاح هذا السلوك مباشرة، لأن هناك مواقع قديمة تعتمد عليه بالفعل.
وهنا ظهرت فكرة الـ Strict Mode سنة 2009 مع إصدار ES5.
بدل أن تغيّر JavaScript قواعد اللغة على الجميع وتكسر الويب، أضافت "وضعا اختياريا" يمكن للمطور تفعيله بنفسه:
rust
"use strict";
وعند تفعيل هذا الوضع، تصبح JavaScript أكثر صرامة مع الأخطاء والسلوكيات الخطيرة.
فالكود السابق مثلا:
rust
"use strict";
name = "Ali";
سيتحول الآن إلى خطأ حقيقي:
text
ReferenceError
لأن المتغير لم يتم تعريفه بشكل صحيح.
ولم يكن هذا التغيير مجرد "تشدد" بلا فائدة، بل كان الهدف منه جعل الكود:
- أكثر أمانا
- أسهل للصيانة
- أقل غموضا
- وأسهل لمحركات JavaScript حتى تقوم بتحسينه (Optimization)
فالـ Strict Mode لم يكن عقابا للمطورين، بل محاولة لدفعهم نحو كتابة JavaScript بطريقة أكثر جودة.
ومن أشهر التغييرات التي أضافها أيضا طريقة تعامل this.
في JavaScript القديمة:
javascript
function test() {

    console.log(this);

}

test();
كانت this تشير تلقائيا إلى الكائن العالمي (window في المتصفح)، وهو سلوك تسبب في أخطاء كثيرة يصعب اكتشافها.
أما في الـ Strict Mode:
javascript
"use strict";

function test() {

    console.log(this);

}

test();
فستصبح قيمة this هي:
text
undefined
مما يجعل الخطأ واضحا وصريحا بدل أن يحدث بصمت.
لكن السؤال الأهم هنا:
إذا كان الـ Strict Mode أفضل فعلا... فلماذا لم تجعل JavaScript هذا السلوك هو الافتراضي منذ البداية؟
والإجابة تعيدنا مرة أخرى إلى التوافق العكسي.
لو قررت المتصفحات فجأة تشغيل الـ Strict Mode على كل الأكواد القديمة، فهناك احتمال كبير أن تتوقف ملايين المواقع عن العمل بسبب اعتمادها على السلوكيات القديمة.
ولهذا بقي الـ Strict Mode اختياريا لسنوات طويلة.
لكن المفارقة المثيرة أن JavaScript وجدت طريقة ذكية لجعل الـ Strict Mode "الوضع الافتراضي عمليا" دون كسر المواقع القديمة.
كيف؟
مع ظهور ES6 Modules وكتابة الأكواد الحديثة باستخدام:
javascript
import

export
أصبحت الملفات التي تعمل كنظام Modules تعمل تلقائيا في Strict Mode دون الحاجة حتى لكتابة:
rust
"use strict";
أي أن JavaScript لم تغيّر سلوك الكود القديم حفاظا على التوافق العكسي، لكنها جعلت "الطريقة الحديثة" لكتابة JavaScript أكثر أمانا بشكل افتراضي.
وهكذا استطاعت اللغة التطور دون أن تكسر الماضي.
في النهاية...
الـ Strict Mode ليس مجرد ميزة صغيرة داخل JavaScript، بل مثال ممتاز على الفلسفة التي بُنيت عليها اللغة:
"نحن لا نحطم القديم... لكننا نحاول توجيه الجديد نحو الأفضل."
#ATM_Team #هندسة_البرمجيات
الStrict Mode : كيف اصلحت JavaScript عيوبها ؟ دون ان تكسر الويب