قطعا همگی با Template Engine هایی مثل Pug, Handlebars و EJS آشنایی دارید. هرکسی با توجه به سلیقه ای که داره از یکی از اینها استفاده میکنه. من خودم استایل EJS رو به دلیل سادگی و نزدیک بودن به خود #JavaScript خیلی دوست دارم. حالا یک Template Engine جدیدتر داریم به اسم ETA که شباهت خیلی زیادی به EJS داره و با #Deno و #Browser هم سازگار هست و البته حجم کمتری داره و از EJS هم سریعتر هست.

اگر دوست دارید میتونید یک نگاهی بهش بندازید.
https://eta.js.org/
#NodeJS

امروز آپدیت جدید برای #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);
}

این استایل از برنامه