امروز آپدیت جدید برای #BunJS یعنی 1.1 منتشر شد. بزرگترین خبر مربوط به این آپدیت اضافه شدن ساپورت برای #Windows هست. کلی ویژگی های جدید دیگه بوده و کلی بهبود برای سازگاری بهتر با API مربوط به #NodeJS انجام گرفته.
درکل امسال قراره تابستون خیلی داغی 🔥 برای کامینیوتی #BackEnd و #JavaScript داشته باشیم باتوجه به این که #Deno داره خودش رو برای نسخه ۲ آماده میکنه و در یک ماه آینده ظاهرا باید انتظار منتشر شدن نسخه 22 LTS برای #NodeJS باشیم و ببینیم آیا میتونه #BunJS که مدعی این هست که جای #NodeJS در سال 2024 میخواد بگیره میرسه یا نه؟

https://twitter.com/bunjavascript/status/1732945030007099510

باتوجه به Drama های پیش اومده و کل کل بین runtime های مختلف شاهد رقابت خیلی سنگین تری بنظرم امسال هستیم به طوری که این رقابت داره تبدیل به مبارزه UFC میشه 🥊.

نظر شخصی :
به شخصه با #BunJS در حال حاظر حال نمیکنم به دلایل زیر
- سال گذشته حاشیه و Drama در کامینیوتی زیاد ایجاد شد و بخشیش از طرف #BunJS بود.
- هنوز بنظرم خیلی فاصله داره تا بگیم production ready هست. ( همه چیز سرعت نیست و stability بنظرم خیلی مهم تره )

این وسط #Deno میانه روی کرده و آروم و بی سر صدای اضافه خودش رو بهتر کرده و با حرکت آخرش یعنی jsr.io به نظر من خیلی جایگاه بهتری داره ( برای من ). تنها مشکلی که به نظرم داره کامینیوتی کوچیکش هست که برای پروژه زدن یکم کار رو سخت میکنه.

و این که #NodeJS که عنوان Rocket Turtle 🚀 🐢 رو یدک میکشه هم سال قبل با توجه به آپدیت هایی که داد به صورت جدی اعلام کرد که قصد نداره بازار رو به راحتی تسلیم کنه و کنار بکشه به طوری که به صورت مرتب شاهد improvement هستیم.

همونطور که در عکس میبینید #CPP یک زبان Multi-paradigm هست. انجین اصلی #NodeJS و موتور #V8 که کار Parse کردن #JavaScript رو انجام میده در حقیقت یک برنامه پیچیده هستن که با #CPP نوشته شده. حالا این موضوع باعث ایجاد یکی از بزرگترین کنجکاوی ها برای من هست و هنوز جواب دقیق رو نمیدونم و فقط براساس حدس هست.

اگر یکم با زبان هایی مثل #C و #CPP کار کرده باشید مخصوصا C قشنگ با استایل procedural و imperative آشنا میشید. حالا اگر به #NodeJS نگاه کنیم که یک سیستم Event-Driven هست سوال برای ما ایجاد میکنه که چطور این تغییر و شیفت در نوع پارادایم ایجاد شده؟
بزارید ساده تر بگم یعنی چطور با استفاده از یک سیستم procedural یا imperative یا OOP یک سیستم Event-Driven طراحی میکنیم؟ به نظر من قطعا اینجا به نوعی با Observer pattern طرف هستیم ( که ظاهرا میشه همون Event-loop در js )

یک مثال ساده تر در توسعه #FrontEnd میبینیم. که از #JavaScript که imperative هست به سیستمی مثل #React رسیدیم که declarative هست.

درکل این شیفت بین پارادایم ها موضوع جالبی برای مطالعه هست و قسمت سخت سوال پیدا کردن خط مرزی بین اونا هست که چطور انجام میشه.

باتوجه به این که Array هم در #JavaScript یک Object هست کاملا این syntax درسته. یعنی فانکشن ما میتونه با استفاده از this اگر به عنوان یکی از index های array تعریف شده باشه به خود array اورجینال که در حقیقت یک object هست دسترسی داشته باشه.

const myArr = [
  function myfn() {
    console.log(this[1]);
  },
  2,
];
myArr[0]();

این نکات رو بیشتر از زاویه fun fact یا عمیق تر شدن نگاه کنید. هیچ کد پروداکشنی پیدا نمیکنید این استایل کد ببینید.

یکی از نکاتی که به برای بچه های #BackEnd و #FrontEnd به اندازه هم میتونه کاربردی باشه استفاده از static method های Array.from و Array.fromAsync. این نکته هم بگم که Array.fromAsync به تازگی با توجه به آپدیت #V8 در نسخه 22 برای #NodeJS منتشر شده و در نسخه های قبل در دسترس نیست.
حالا کار این متد ها به چه شکل هست با .from شروع میکنیم. شما اگر یک iterable obj داشته باشید شاید بخواید این Object رو تبدیل به Array کنید و معمولا از این تکنیک استفاده میشه.

const arr = [];
for (const v of iterableObj) {
  arr.push(v);
}

این استایل از برنامه نویسی بیشتر به نوعی imperative programming محسوب میشه و در زبان های procedural programming خیلی دیده میشه. با این حال که #JavaScript یک زبان Multi-paradigm هست و این استایل کد زدن مجاز هست ولی خیلی در کامینیوتی مرسوم نیست و کلا بیشتر کد های declarative و ترکیب OOP و Functional استفاده میشه. ( هرچند Functional خالص سخت هست در #JavaScript )
حالا اگر بخوایم کد بالا رو یطوری داشته باشیم که مرسوم تر باشه بین برنامه نویس های #JavaScript، در این سناریو متد های Array.from و Array.fromAsync به کمک ما میاد تا کد ما declarative تر بشه.
حالا برای تبدیل کد بالا کافی هست این کار رو کنید و بووم تمام!

const arr = Array.from(iterable);

اگر بخوام درمورد Array.fromAsync هم بگم این هست که دقیقا به همین شکل کار میکنه و تنها تفاوتش این هست که با async iterable ها و generator ها سازگار هست.

const arr = [];
for await (const v of asyncIterable) {
  arr.push(v);
}

حالا همین رو به این شکل تبدیل میکنیم.

const arr = await Array.fromAsync(asyncIterable);

هنوز یک قسمت جالب از داستان مونده بزارید با مثال بهتون نشون بدم.

Array.fromAsync(
  new Set([Promise.resolve(1), Promise.resolve(2), Promise.resolve(3)]),
).then((array) => console.log(array));
// [1, 2, 3]

اگر اینجا دقت کنید میبینید که میتونه سناریو مناسبی برای استفاده از Promise.all باشه ولی استفاده نشده به نظرتون تفاوت چیه؟
با استفاده از Promise.all تمام Promise ها به صورت همزمان تلاش به resolve شدن دارن یعنی داره concurrent انجام میشه اما در این سناریو بدون بلاک شدن event loop به ترتیب Promise ها resolve میشن.
راستی این ویژگی هم از نسخه 1.38 روی #Deno در دسترس بوده و این برای من خیلی جذابه که تیم #Deno اینقدر خوب دارن عمل میکنن. مدتی هست هر حرکتی در اکوسیستم اتفاق میافته #Deno از پرچم داران در سرعت آپدیت و رو به جلو حرکت کردن هست.
#Tip