JavaScript کی پیدائش اور موت
JavaScript براؤزر میں بہت کم مراعات (privileges) کے ساتھ چلتی ہے۔ اس کے باوجود، یہ سرورز، بلڈ ٹولز، اور یہاں تک کہ ڈیٹا بیسز کو بھی چلا رہی ہے۔ یہ کوئی منصوبہ نہیں تھا۔ یہ 1995 کے ایک فیصلے پر مبنی پیچز (patches) کا ایک سلسلہ تھا۔
2014 میں، گیری برن ہارڈٹ (Gary Bernhardt) نے "The Birth and Death of JavaScript" کے عنوان سے ایک تقریر کی۔ بہت سے لوگ اسے ایک ناکام پیش گوئی کے طور پر دیکھتے ہیں۔ میں اسے آرکیٹیکچرل رگڑ (architectural friction) کے لیے ایک تشخیصی ٹول کے طور پر دیکھتا ہوں۔
برن ہارڈٹ نے ایک طنزیہ راستے کی وضاحت کی۔ JavaScript ایک کھلونا زبان (toy language) کے طور پر شروع ہوئی تھی۔ یہ اس لیے زندہ رہی کیونکہ براؤزر میں یہی واحد زبان تھی۔ اس اجارہ داری نے اسے زمین پر سب سے زیادہ چلائی جانے والی زبان بنا دیا، چاہے یہ بہترین تکنیکی انتخاب نہ بھی ہو۔
بنیادی تناؤ سادہ ہے۔ براؤزر کو کوڈ کو محفوظ طریقے سے اور تیزی سے چلانے کی ضرورت ہوتی ہے۔ یہ دونوں مقاصد اکثر ایک دوسرے کے خلاف ہوتے ہیں۔
2014 میں، یہ پیش گوئی کی گئی تھی کہ WebAssembly، JavaScript کی جگہ لے لے گا۔ ایسا نہیں ہوا۔ WebAssembly مستحکم ہے اور Figma یا Google Earth جیسی چیزوں کے لیے مفید ہے۔ تاہم، اس نے ایک ایپلی کیشن زبان کے طور پر JavaScript کی جگہ نہیں لی۔
اس کے بجائے، JavaScript میں تبدیلی (mutate) آئی۔ TypeScript، bundlers، اور Deno یا Bun جیسے نئے runtimes، برن ہارڈٹ کی نشاندہی کردہ رکاوٹوں کو دور کرنے کی کوششیں ہیں۔
اس تقریر کو JavaScript سیکھنے سے بچنے کے لیے استعمال نہ کریں۔ اسے اس وقت تک WebAssembly پر منتقل ہونے کے جواز کے طور پر استعمال نہ کریں جب تک کہ آپ کو کارکردگی (performance) کا کوئی حقیقی مسئلہ درپیش نہ ہو۔
اسے اپنے اسٹیک (stack) کے بارے میں یہ سوالات پوچھنے کے لیے استعمال کریں:
• کیا میں یہ ٹول اس لیے استعمال کر رہا ہوں کیونکہ یہ اس مسئلے کا بہترین حل ہے؟ • کیا میں اسے اس لیے استعمال کر رہا ہوں کیونکہ اس سیاق و سباق میں یہی واحد چیز کام کرتی ہے؟ • کیا میرے ٹولز کی پیچیدگی کسی حقیقی مسئلے کو حل کرتی ہے یا اسے صرف کہیں اور منتقل کر دیتی ہے؟ • اگر میں آج بالکل شروع سے آغاز کروں، تو کیا میں اسے منتخب کروں گا؟
اگر آپ سرور پر TypeScript استعمال کرتے ہیں، تو آپ کو ٹائپ سیفٹی (type safety) حاصل ہوتی ہے لیکن کمپائلیشن کا بوجھ (compilation overhead) بڑھ جاتا ہے۔ اگر آپ Next.js استعمال کرتے ہیں، تو آپ کو فیچرز ملتے ہیں لیکن کیشنگ (caching) کی پیچیدگی بڑھ جاتی ہے۔ یہ حقیقی توازن (trade-offs) ہیں۔
سب سے عام غلطی زبان کو موردِ الزام ٹھہرانا ہے جبکہ مسئلہ دراصل ناقص استعمال ہوتا ہے۔ اگر آپ بھاری سنکرونس (synchronous) کوڈ لکھتے ہیں جو ایونٹ لوپ (event loop) کو بلاک کر دیتا ہے، تو مسئلہ آپ کا ہے، JavaScript کا نہیں۔
کسی جادوئی متبادل کی تلاش بند کریں۔ اپنی اصل رکاوٹوں (bottlenecks) کی پیمائش کرنا شروع کریں۔