تاریخچه مختصری از ماژول های ES

Summarize this content to 400 words in Persian Lang
احتمالاً از ماژول‌های ES در توسعه جاوا اسکریپت مدرن استفاده کرده‌اید، اما آیا تاریخچه پشت تکامل آنها را می‌دانید؟ درک سفر از شیوه‌های اولیه جاوا اسکریپت تا سیستم ماژول امروزی به شما کمک می‌کند تا درک کنید که چقدر پیشرفت کرده‌ایم و چرا ماژول‌های ES یک تغییر دهنده بازی هستند.

روزهای اولیه: آغاز جاوا اسکریپت

سال 1995 است، چهار سال پس از ایجاد اولین صفحه وب. اکثر وب سایت ها ساده بودند – صفحات ایستا با متن و حداقل تعامل. با این حال، توسعه دهندگان به سرعت به دنبال راه هایی برای پویایی بیشتر صفحات وب بودند.

در این محیط، نت اسکیپ (مرورگر وب غالب در آن زمان) برندن ایچ را استخدام کرد تا یک زبان برنامه نویسی ایجاد کند که مستقیماً در مرورگر اجرا شود. این منجر به تولد جاوا اسکریپت شد، زبانی که برای ساده و در دسترس بودن طراحی شده بود، به ویژه برای غیر برنامه نویسان مانند طراحان وب. و همینطور انجام داد و اولین نسخه را تکمیل کرد 10 روز.

در اصل، جاوا اسکریپت برای افزودن پیشرفت‌های کوچک به صفحات وب، مانند اعتبارسنجی فرم، بدون نیاز به داده‌های رفت و برگشت به سرور بود. با این حال، با تعامل بیشتر وب سایت ها، جاوا اسکریپت به سرعت از هدف اصلی خود فراتر رفت.

دامنه جهانی و راه حل های اولیه

در روزهای اولیه، همه کدهای جاوا اسکریپت در گستره جهانی زندگی می کردند. همانطور که توسعه دهندگان بیشتری کد را به همان صفحه اضافه کردند، خطر برخورد نام افزایش یافت. اگر چندین اسکریپت از یک متغیر یا نام تابع استفاده کنند، کد ممکن است به روش‌های غیرمنتظره‌ای شکسته شود.

برای مدیریت این امر، توسعه دهندگان به قراردادهای نامگذاری برای جلوگیری از برخورد متوسل شدند. اگر قرار بود یک قطعه کد فقط یک بار اجرا شود، توسعه دهندگان اغلب آن را در یک IIFE (Immediately Invoked Function Expression) قرار می دادند. این کار توابع و متغیرها را در محدوده تابع نگه می دارد و از آلوده کردن فضای نام جهانی جلوگیری می کند.

(function init() {
function getData(){
// …
}
})()

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این در آن زمان به اندازه کافی خوب بود زیرا اکثر وب سایت ها در سمت سرور با منطق بسیار کمی سمت مشتری ارائه می شدند.

CommonJS: ماژول های سمت سرور

در سال 2008 رایان دال Node.js را ایجاد کرد، یک زمان اجرا جاوا اسکریپت برای ساخت برنامه های سمت سرور. این یک دنیای کاملاً جدید از امکانات را باز کرد، اما فقدان یک سیستم ماژول به این معنی بود که توسعه‌دهندگان برای مدیریت پایگاه‌های کد بزرگ تلاش می‌کردند.

در سال 2009 CommonJS برای حل این مشکل برای سمت سرور معرفی شد. سیستم ماژول CommonJS به توسعه دهندگان این امکان را می داد که ماژول ها را تعریف کنند، عملکردها را در معرض دید قرار دهند و ماژول های دیگر را وارد کنند. در اینجا مثالی از نحوه کار آن آورده شده است:

const math = require(“./math”);

function subtract(a,b) {
return math.add(a,-b);
}

module.exports = {
subtract: subtract
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

با CommonJS، هر فایل به عنوان ماژول خاص خود در نظر گرفته می شود و ماژول ها با استفاده از آن وارد می شوند require تابع و با استفاده از صادرات module.exports.

برخی از ویژگی های کلیدی CommonJS عبارتند از:

پسوند فایل در صورت نیاز به یک ماژول اختیاری است (به عنوان مثال، require('./math') بطور خودکار به دنبال math.js می گردد).
بارگذاری ماژول همزمان است، به این معنی که برنامه قبل از ادامه اجرا منتظر می ماند تا ماژول بارگذاری شود.

در ادامه مقاله خواهیم دید که چرا رایان دال از این 2 تصمیم طراحی پشیمان شده است.

AMD: بهینه سازی مرورگر

تقریباً در همان زمان، سیستم ماژول دیگری به نام AMD (تعریف ماژول ناهمگام) توسعه یافت. در حالی که CommonJS در درجه اول بر جاوا اسکریپت سمت سرور متمرکز بود، AMD برای مدیریت جاوا اسکریپت سمت سرویس گیرنده در مرورگر طراحی شده بود.

ویژگی کلیدی AMD توانایی آن در بارگذاری ماژول ها به صورت ناهمزمان بود. این به مرورگر اجازه می‌داد فقط جاوا اسکریپت مورد نیاز برای یک صفحه را در هر زمان بارگیری کند و با کاهش زمان بارگذاری اولیه صفحه، عملکرد را بهبود بخشد. همچنین مشکلات مربوط به تفکیک وابستگی را حل می‌کند و تضمین می‌کند که یک ماژول فقط زمانی اجرا می‌شود که وابستگی‌های آن بارگیری شوند.

مزایای AMD عبارتند از:

فایل‌های جاوا اسکریپت کوچک‌تر بر اساس درخواست بارگیری می‌شوند.
خطاهای بارگذاری صفحه کمتر به دلیل بارگذاری قابل پیش بینی بیشتر ماژول.
بهینه سازی عملکرد از طریق بارگذاری ناهمزمان

با افزایش npm در سال 2010 (یک مدیر بسته برای جاوا اسکریپت سمت سرور)، نیاز به اشتراک گذاری کد در مرورگر و سرور آشکار شد. Browserify را وارد کنید، ابزاری که به توسعه‌دهندگان اجازه می‌دهد از ماژول‌های CommonJS در مرورگر با تبدیل کد برای سازگاری با محیط مرورگر استفاده کنند.

UMD: بهترین های هر دو دنیا… به نوعی

با 2 استاندارد رقیب CommonJS و AMD. نیاز به یک سیستم واحد واحد وجود داشت که بتواند در همه جا بدون نیاز به مرحله ساخت کار کند. و در سال 2011، تعریف ماژول جهانی (UMD) معرفی شد.

UMD بهترین های هر دو دنیا را ترکیب کرد و به توسعه دهندگان این امکان را داد که ماژولی بنویسند که می تواند در موارد زیر اجرا شود:

Node.js (با استفاده از CommonJS).
مرورگرها (با استفاده از AMD).
دامنه جهانی (اگر نه CommonJS و نه AMD وجود نداشت).

UMD در میان نویسندگان کتابخانه بسیار محبوب شد و کتابخانه های قابل توجهی مانند Lodash، Underscore.js، Backbone.js و Moment.js آن را به کار گرفتند. با این حال، UMD دارای نقاط منفی قابل توجهی بود. در حالی که مشکل سازگاری را حل کرد، با پیچیدگی مدیریت هر دو سیستم همراه بود و مشکلات AMD و CommonJS را به ارث برد.

ماژول های ES: استاندارد ماژول های نهایی

در سال 2015، ماژول های ES (ESM) به عنوان بخشی از استاندارد ECMAScript معرفی شدند و در نهایت یک سیستم ماژول بومی را برای جاوا اسکریپت ارائه کردند. تا سال 2017، همه مرورگرهای اصلی از ماژول های ES پشتیبانی می کردند و در سال 2020، Node.js نیز پشتیبانی را اضافه کرد.

بیایید ببینیم که چرا ماژول های ES بهترین هستند:

1. نحو مناسب

کد UMD زیر:

(function (root, factory) {
if (typeof define === ‘function’ && define.amd) {
// AMD
define([], factory);
} else if (typeof module === ‘object’ && module.exports) {
// CommonJS
module.exports = factory();
} else {
// Global
root.add = factory();
}
}(this, function () {
function add(a, b) {
return a + b;
}

return add;
}));

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اکنون می توان به موارد زیر کاهش داد:

export function add(a, b) {
return a + b;
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اگر منصف باشیم، هیچ کس در واقع UMD را اینطور ننوشته است. آنها از ابزارهایی مانند umdify برای تولید آن کد استفاده کردند. اما با ساخت ماژول‌های ES می‌توانیم از مرحله ساخت رد شویم و اندازه بسته‌ای کوچک‌تر داشته باشیم.

2. بهینه سازی بهتر

ماژول های ES ثابت هستند، به این معنی که ابزارها می توانند ساختار کد را در زمان کامپایل تجزیه و تحلیل کنند تا مشخص کنند کدام کد استفاده می شود و کدام نه. این امکان تکان دادن درخت را فراهم می کند، جایی که کد استفاده نشده از بسته نهایی حذف می شود.

از آنجایی که ماژول‌های CommonJS و AMD پویا هستند (در زمان اجرا ارزیابی می‌شوند)، تکان دادن درخت در این سیستم‌ها کارآمدتر است و اغلب منجر به بسته‌های بزرگ‌تر می‌شود.

3. کد واضح تر

هنگام وارد کردن یک ماژول با CommonJS، تعیین پسوند فایل اختیاری است.

// load math.js file
const math = require(‘./math’)

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اما در واقع ریاضی به چه چیزی اشاره دارد؟ آیا این یک فایل جاوا اسکریپت است؟ یک فایل JSON؟ یک فایل index.js در یک فهرست ریاضی؟

هنگام استفاده از ابزارهای تجزیه و تحلیل ایستا مانند ES Lint، تایپ اسکریپت یا زیباتر، هر نیاز به یک بازی حدس زدن تبدیل می شود.math.js هست؟math.jsx است؟math.cjs هست؟math.mjs هست؟math.ts است؟math.tsx است؟math.mts است؟ریاضیات است؟math/index.js هست؟math/index.jsx هست؟

شما ایده را دریافت می کنید.

خواندن یک فایل گران است. عملکرد بسیار کمتری نسبت به خواندن از روی حافظه دارد. واردات math/index.js منجر به 9 عملیات IO به جای 1 می شود! و این بازی حدس‌زنی سرعت ابزارسازی ما را کاهش می‌دهد و به تجربه توسعه‌دهندگان آسیب می‌زند.

در ماژول های ES با اجباری بودن پسوند فایل از این آشفتگی جلوگیری می کنیم.

4. بارگذاری ناهمزمان

بر خلاف CommonJS که ماژول ها را به صورت همزمان بارگیری می کند (کل فرآیند را تا زمانی که ماژول بارگذاری شود مسدود می کند)، ماژول های ES ناهمزمان هستند. این به جاوا اسکریپت اجازه می‌دهد تا زمانی که ماژول در پس‌زمینه بارگذاری می‌شود، به اجرا ادامه دهد و عملکرد را بهبود بخشد – به ویژه در محیط‌هایی مانند Node.js.

چالش های مهاجرت: چرا اینقدر طول کشید؟

با وجود مزایای واضح، استفاده از ماژول های ES کار ساده ای نبود. در اینجا دلیل طولانی شدن این انتقال است:

1. مهاجرت پرهزینه

تغییر از CommonJS به ماژول های ES یک تغییر بی اهمیت نبود، به خصوص برای پروژه های بزرگ. تفاوت های نحوی، همراه با نیاز به پشتیبانی ابزار، مهاجرت را به یک تلاش قابل توجه تبدیل کرد.

2. عدم پشتیبانی Node.js

node.js 5 سال طول کشید تا به طور کامل از ماژول های ES پشتیبانی کند. در طول این مدت، توسعه دهندگان باید سازگاری با ماژول های CommonJS (روی سرور) و ES (در مرورگر) را حفظ می کردند. این پشتیبانی دوگانه اصطکاک زیادی در اکوسیستم ایجاد کرد.

3. مسائل مربوط به سازگاری

حتی پس از اینکه Node.js از ماژول‌های ES پشتیبانی کرد، ماژول‌های CommonJS نتوانستند ماژول‌های ES را بارگیری کنند. در حالی که ماژول‌های ES می‌توانستند ماژول‌های CommonJS را بارگیری کنند، این دو سیستم به طور کامل با هم سازگار نبودند و باعث ایجاد دردسرهای اضافی برای نویسندگان بسته‌ها می‌شد که مجبور بودند از هر دو سیستم پشتیبانی کنند.

آینده: ماژول های ES اینجا هستند تا بمانند

آینده ماژول های جاوا اسکریپت روشن است، و در اینجا چند پیشرفت کلیدی وجود دارد که ماژول های ES را به سیستم غالب در حال حرکت رو به جلو تبدیل می کند:

1. Node.js 23

در Node.js 23 بالاخره توانایی بارگذاری ماژول های ES از CommonJS را داریم.یک هشدار کوچک وجود دارد: ماژول ES که از انتظار سطح بالا استفاده می کند را نمی توان به CommonJS وارد کرد، زیرا انتظار فقط در توابع ناهمزمان قابل استفاده است و CommonJS همگام است.

2. JSR (رجیستری جاوا اسکریپت)

یک رجیستری بسته جاوا اسکریپت جدید که با npm رقابت می کند. مزایای زیادی نسبت به npm دارد که در اینجا به آن نمی پردازم. اما نکته جالب این است که شما فقط مجاز به آپلود بسته های ماژول های ES هستید. نیازی به حمایت از استانداردهای قدیمی نیست.

نتیجه گیری

سفر از هک‌های دامنه جهانی به ماژول‌های مدرن ES نحوه ساختار جاوا اسکریپت را تغییر داده است. پس از سال‌ها آزمایش با CommonJS، AMD و UMD، ماژول‌های ES به‌عنوان استاندارد واضح‌تر ظاهر شده‌اند و نحو ساده‌تر، بهینه‌سازی بهتر و عملکرد بهبود یافته را ارائه می‌کنند.

در حالی که مهاجرت به ماژول های ES چالش برانگیز بوده است، به خصوص با پشتیبانی Node.js و سازگاری با اکوسیستم، مزایای آن غیرقابل انکار است. با بهبود قابلیت همکاری Node.js 23 و ابزارهای جدیدی مانند JSR که یک سیستم ماژول یکپارچه را ترویج می کند، ماژول های ES قرار است به طور پیش فرض برای جاوا اسکریپت تبدیل شوند.

با ادامه پذیرش ماژول‌های ES، می‌توانیم منتظر کدهای تمیزتر، سریع‌تر و قابل نگهداری‌تر باشیم که دوره جدیدی از ماژولار بودن در توسعه جاوا اسکریپت را رقم بزند.

(function init() {
    function getData(){
        // ...
     }
})()

const math = require("./math");

function subtract(a,b) {
    return math.add(a,-b);
}

module.exports = {
    subtract: subtract
}

(function (root, factory) {
  if (typeof define === 'function' && define.amd) {
    // AMD
    define([], factory);
  } else if (typeof module === 'object' && module.exports) {
    // CommonJS
    module.exports = factory();
  } else {
    // Global
    root.add = factory();
  }
}(this, function () {
  function add(a, b) {
    return a + b;
  }

  return add;
}));

export function add(a, b) {
  return a + b;
}

// load math.js file
const math = require('./math')