JavaScript کی پیدائش اور موت
JavaScript براؤزر میں کم اختیارات (low privileges) کے ساتھ چلتی ہے۔ اس کے باوجود یہ سرورز، بلڈ ٹولز اور پائپ لائنز کو چلا رہی ہے۔ یہ کوئی منصوبہ نہیں تھا۔ یہ 1995 کے ایک فیصلے پر لگائے گئے پیچز (patches) کا ایک سلسلہ تھا۔
یہ سمجھنا کہ ایسا کیوں ہوا، آج آپ کے اسٹیک (stack) کے ڈیزائن کرنے کے طریقے کو بدل دیتا ہے۔
گیری برن ہارڈٹ (Gary Bernhardt) کی 2014 کی گفتگو محض ماضی کی یادوں (nostalgia) کے بارے میں نہیں ہے۔ یہ آرکیٹیکچرل رگڑ (architectural friction) کی تشخیص ہے۔ انہوں نے ایک طنزیہ صورتحال کی نشاندہی کی: JavaScript ایک کھلونا زبان (toy language) تھی جو اس لیے زندہ رہی کیونکہ براؤزر پر اس کی اجارہ داری (monopoly) تھی۔ اسی اجارہ داری نے اسے دنیا کی سب سے زیادہ استعمال ہونے والی زبان بنا دیا۔
کشیدگی سادہ ہے۔ براؤزر کو کوڈ کو محفوظ طریقے سے اور تیزی سے چلانا چاہیے۔ یہ دونوں مقاصد ایک دوسرے کے خلاف ہیں۔
2014 میں، یہ اندازہ لگایا گیا تھا کہ WebAssembly، JavaScript کی جگہ لے لے گا۔ ایسا مکمل طور پر نہیں ہوا۔ WebAssembly مستحکم ہے اور Figma یا Google Earth جیسی چیزوں کے لیے مفید ہے۔ لیکن اس نے ایک ایپلی کیشن لینگویج کے طور پر JavaScript کی جگہ نہیں لی۔
اس کے بجائے، JavaScript میں تبدیلی (mutate) آئی۔ TypeScript، بنڈلرز (bundlers) اور Bun جیسے نئے رن ٹائمز (runtimes) ان رکاوٹوں کو دور کرنے کے لیے موجود ہیں جن کی نشاندہی برن ہارڈٹ نے کی تھی۔
اس گفتگو کو JavaScript سیکھنے سے بچنے کے لیے استعمال نہ کریں۔ اسے کارکردگی (performance) کے مسئلے کے بغیر WebAssembly کی طرف چھلانگ لگانے کے جواز کے طور پر استعمال نہ کریں۔
اسے اپنے اسٹیک کے لیے ایک چیک لسٹ کے طور پر استعمال کریں:
- کیا میں اسے اس لیے استعمال کر رہا ہوں کیونکہ یہ بہترین ٹول ہے؟
- یا اس لیے کہ یہاں صرف یہی کام کرتا ہے؟
- کیا ٹولز کا اضافی بوجھ (overhead) رکاوٹ کو حل کرتا ہے یا صرف اسے دوسری جگہ منتقل کر دیتا ہے؟
- اگر میں آج بالکل شروع سے آغاز کرتا، تو کیا میں اسے منتخب کرتا؟
- کیا کارکردگی کی حد (performance ceiling) میرے استعمال کے کیس کے لیے قابل قبول ہے؟
TypeScript کمپائل ٹائم (compile time) پر ٹائپس (types) میں مدد کرتا ہے۔ یہ آپ کے ٹائپس اور نیٹ ورک کے ذریعے آنے والے ڈیٹا کے درمیان فرق کو ختم نہیں کرتا۔ آپ کو اب بھی رن ٹائم ویلیڈیشن (runtime validation) کی ضرورت ہوتی ہے۔
سب سے اہم سبق یہ ہے: یہ جانیں کہ آیا آپ کی ٹیکنالوجی اپنی خوبیوں کی وجہ سے موجود ہے یا کسی اجارہ داری کی وجہ سے۔
2014 کی پیش گوئی کی بنیاد پر اپنا رن ٹائم تبدیل نہ کریں۔ اسے اس وقت تبدیل کریں جب آپ کے پاس پیمائش شدہ ڈیٹا (measured data) موجود ہو جو کسی رکاوٹ (bottleneck) کو ظاہر کر رہا ہو۔
ماخذ: https://dev.to/jtorchia/the-birth-and-death-of-javascript-2014-what-still-holds-and-what-doesnt-2hae