https://virgool.io/feed/@navidkhm fa 2026-06-16 08:36:04 https://files.virgool.io/upload/users/2302722/avatar/wy5ciV.jpg?height=120&width=120 https://virgool.io/@navidkhm https://virgool.io/@navidkhm/%D8%AA%D8%A7%D8%B1%DB%8C%D8%AE-%D8%B9%D8%AC%DB%8C%D8%A8-js-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85-js-%DA%86%D8%B7%D9%88%D8%B1-%D8%B3%D8%A7%D8%AE%D8%AA%D9%87-%D8%B4%D8%AF%D8%AA%D8%B1%D8%AC%D9%85%D9%87-%D9%88%DB%8C%D8%AF%DB%8C%D9%88-fireship-jo6vfhlo6sja تاریخ عجیب JS - بخش دوم: JS چطور ساخته شد؟(ترجمه ویدیو fireship)جاوا اسکریپت؛ امروز قراره که ما به علم کامپیوتری پشتش نگاه کنیم و بعد از تموم شدن این ویدیو شما باید بدونید که یه زبون سطح بالای، تک ثردیِ (Single Thread)، Garbage Collected، مفسری یا در لحظه کامپایل شونده‌ی (Just In Time Compiled) پروتوتایپ بیسِ چند پارادایمیِ داینامیک در کنار حلقه‌رویدادِ غیر مسدود کننده‌ی (Non-blocking Event loop) کانکارنسی مدل(Concurrency Model) چیه.هفته پیش (لینک مقاله قبلی) ما یاد گرفتیم که JS یه زبون برنامه‌نویسیه که مبناش بر اساس مشخصاتی که ECMA262 تعیین میکنه هست ولی برای اینکه بفهمیم واقعا چطوری روی یه سیستم کامپیوتری کار میکنه نیازه که تا حد خیلی زیادی پایین بریم و منظورم از این حرف خود CPU و Memory ئه. [شخصی برد کامپیوتری را نشان میدهد و در مورد چیپ‌ها صحبت میکند].وقتی شما یه برنامه‌ی جاوااسکریپتی رو چه روی مرورگر یا یه چیز سمت سروری مثل Node.js اجرا میکنید نیاز داره که حافظه‌ای رو روی مموری رمِ شما اختصاص بده تا بتونه یه چیزهایی رو برای ران‌تایم و متغیرها و آبجکت‌هایی که بهش تو کدتون اشاره میکنید ذخیره کنه بعدش علاوه بر این به یه ثرد از CPUتون هم نیاز داره تا واقعا دستوراتی که تو کدتون نوشتید رو اجرا کنه اما اینجا اون چیزی که وجود داره اینه که شما به عنوان یه توسعه دهنده جاوا اسکریپت واقعاً مجبور نیستید به این چیزا فکر کنید چون که JS یه زبان "سطح بالا"ئه ولی چیزی که واقعا منظورمونه وقتی که میگیم سطح بالا در واقع درجه‌ی انتزاع یا سادگی‌ایه که زبون برای ما نسبت به سخت‌افزار کامپیوتر داره فراهم میکنه؛ پایین‌‌ترین سطح زبون، کدِ ماشینه.کد ماشین یه زبون عددیه که میتونه مستقیما توسط CPU اجرا بشه ولی خیلی سخت میشه اگه بخوایم باهاش یه وبسایت بسازیم بخاطر اینکه باید عدد دونه‌دونه‌ی دستورالعمل‌هایی که میخواید اجرا کنید رو حفظ کنید.اگه یه سطح بالاتر بریم به اسمبلی میرسیم که یه سری سینتکس کادوپیچ داریم ولی هر زبان اسمبلی مختص به یه CPU یا سیستم‌عامله پس میتونیم یه سطح بالاتر به زبون C بریم که سینتکس مدرن و قابلیت نوشتن برنامه‌های بین‌پلتفرمی رو فراهم میکنه ولی با این حال دولوپرا همچنان باید نگران مشکلات سطح پایین مثل تخصیص حافظه تو مموری باشن.اگه یه سطح دیگه بالاتر بریم به سطح زبونایی مثل جاوااسکریپت و پایتون میرسیم که از انتراعاتی مثل Garbage Collectorها و تایپ‌های داینامیک استفاده میکنن تا راه دولوپرا برای نوشتن اپ‌هاشون ساده بشه.پس حالا که ما تو این سطحِ بالاییم بیاید ادامه بدیم و یه سری اصطاحات اساسی‌ای که به JS مرتبط میشن رو رازگشایی کنیم.خب ما ۲ راه کلی برای ترجمه‌ی کدایی که تو زبون برنامه‌نویسی مینویسیم به چیزی که CPU واقعا بتونه اجراش کنه داریم. یکیش به اسم مفسری شناخته میشه و اون یکی کامپایلری.جاوااسکریپت یه زبون مسفریه به این معنی که نیاز به یه مفسر داره تا خودِ کد رو بخونه و اجراش کنه. ما میتونیم اینو به سادگی با رفتن به مرورگر و اجرا کردن یه سری کدجاوااسکریپت تو کنسول نشون بدیم.[صدای مردی در پس‌زمینه انیمیشنی برای توضیح تفاوت مفسری و کامپایلری]: حالا توجه کنید که مفسر چطور کار میکنه؛ اون همیشه پیش شماست و هر دستورالعمل شمارو همون لحظه یکی بعد از اون یکی ترجمه میکنه.و حالا این با یه زبون کامپایلری مثل جاوا یا سی که تمام کد شما رو از قبل به صورت ایستا تجزیه و تحلیل میکنه و بعدش اون را به شکل باینری کامپایل می کنه که در واقع می توانید روی ماشین اجرا کنید فرق میکنه.[صدای مردی در پس‌زمینه انیمیشنی برای توضیح تفاوت مفسری و کامپایلری]: اون لیست کامل دستورالعمل‌هارو ازتون میگیره و بدون هیچ مقدمه‌ای کل اون رو ترجمه میکنه و بعد میره و شمارو به حال خودتون تنها میذاره.جاوااسکریپت هیچ‌وقت برای اینکه یه زبون کامپایلری باشه طراحی نشده بود ولی تا چند دقیقه دیگه میبینیم که چطور موتورهای امروزی جاوااسکریپت میتونن از قابلیتای یه کامپایلر استفاده کنن تا عملکردای اضافی زبان رو از بین ببرن.حالا یه چیز دیگه که شاید شنیده باشید اینه که جاوااسکریپت یه زبون تایپ‌متغیره(Dynamic Type) که معمولا یه ویژگی مشترک با زبونای سطح بالای مفسریه و این ینی اینکه ما از هیچ تعریف صریحی برای تایپ(منظور نوع متغیره) تو کد جاوااسکریپتمون استفاده نمیکنیم. ما میتونیم این تفاوتو با مقایسه یه سری کدِ تایپ‌ثابتِ Dart با یه سری کد تایپ‌متغیر جاوااسکریپت ببینیم. تو کد Dart متوجه میشید که ما چیزایی مثل عدد یا رشته بودن رو اشاره میکنیم ولی تایپای JS ناشناخته(unknown) یا implicit هستن و این بخاطر اینه که تایپ با مقدار در زمان اجرا مرتبطه و نه با خود متغیر یا فانکشنِ توی کد.تفاوت زبان تایپ‌متغیر مثل JS با زبان تایپ‌ثابت مثل Dartحالا ممکنه شما اینم شنیده باشید که جاوااسکریپت یه زبون چندپارادایمیه؛ تعداد قابل توجهی از زبونای برنامه‌نویسیِ همه‌منظوره چند پارادیمی‌ان که به شما اجازه میدن تا استایل‌های رویکرد اعلانی فانکشنال (declarative functional) یا دستوری شی‌گرا (imperative object-oriented) رو با هم ترکیب کنید.حالا یکی از چیزای عجیب‌تری که خواهید شنید اینه که جاوااسکریپت بر اساس وراثت پروتوتایپیه (Prototypal Inheritence). این کورس یه ویدیو فقط مخصوص برای همین مفهوم داره ولی ایده کلی اینه که هر چیزی تو جاوااسکریپت یه آبجکته و هر آبجکت یه لینک به پروتوتایپش داره و این یه زنجیره پروتوتایپی ایجاد میکنه که آبجکت‌ها میتونن رفتارهارو از آبجکتای دیگه به ارث ببرن؛ این میتونه یه چیز عجیب باشه که بخواید بهش عادت کنید اگه که با وراثت برپایه کلاس آشنا باشید ولی این یکی از مفهومای سطح پایینیه که جاوااسکریپت رو یه زبون خیلی منعطف چندپارادایمی میکنه. حالا بیاید یه لحظه مرور کنیم ما میدونیم که JS یه زبونِ سطح بالای مفسریِ تایپ‌متغیرِ چند پارادایمیِ پروتوتایپ بیسه ولی همینطور یه زبون تک ثرده، Garbage Collected، غیر مسدودکننده با یه حلقه رویداده که میتونه درلحظه(Just In Time) کامپایل بشه.مجموعه اول تعریفا بیشتر به ظاهر JS بر اساس چیزی که ECMA262 مشخص کرده برمیگرده ولی اون مشخص نمیکنه که مفسر چطور باید پیاده‌سازی بشه یا چطوری مموری رو مدیریت کنه و حتی اسمی از حلقه رویداد هم تو کل ۸۰۰ صفحه داکیومنتش نمیاره پس جزییات این پیاده‌سازیا به مرورگرا برمیگرده که بخوان چطوری هندلش کنن و ۲ تا از مهم‌ترین پیاده‌سازیا Spider Monkey از موزیلا و V8 از گوگله و نحوه‌ی کارشون یکم با هم متفاوته ولی هر دوشون یه کاری به اسم کامپایل در لحظه(Just In Time Compilation) رو انجام میدن.در مورد V8، برخلاف مفسر معمولی که خط به خط کد رو تبدیل به بایت‌کد میکنه اون میاد کل JS شمارو قبل از اجرا به کد Native ماشین تبدیل میکنه.پس این موتورهای JS از پایه نحوه نوشتن کدای دولوپرارو تغییر نمیدن ولی کامپایل در لحظه به بهبود پرفورمنس تو مرورگرا و Node کمک میکنه ولی مسئله اینجاست که JS تک ثرده و میتونه فقط یه محاسبه در لحظه انجام بده. چیزی که همین الان ازتون میخوام انجام بدید اینه که تو همین مرورگرتون تب کنسول رو باز کنید و یه لوپ همیشه صادق بسازید(While true loop) که هیچ‌وقت تموم نمیشه و میبینید که دیگه هیچی تو این تب کار نمیکنه؛ حالا اگه سعی کنید رو یه چیزی کلیک کنید اون رویداد هیچ‌وقت ضبط نمیشه بخاطر اینکه اون تک ثرد، تو لوپ همیشه صادق گیر کرده و نمیتونه به رویداد(Event) بعدی بره. برید به بخش مدیریت تسک کروم و باید ببینید که اون تب مرورگر تقریبا ۱۰۰٪ منابع اون هسته‌ی CPU رو داره مصرف میکنه، ادامه بدید و تسک رو ببندید(تب بسته میشه با این کار) و بعدش دوباره برگردید اینجا (صفحه ویدیو) منو ببینید که بهتون بگم چرا این اتفاق افتاد؟وقتی کد JSتون اجرا میشه ۲ بخش از حافظه به ماشینتون اختصاص داده میشه یکی CallStack (پشته تماس که به دلیل سخت‌فهم بودن من همون کال‌استک استفاده می‌کنم) و heap.کال‌استک طراحی شده تا یه حافظه‌ی با راندمان بالای تو فضای‌ پشت‌سرهم باشه تا برای اجرای فانکشن‌هاتون استفاده بشه؛ وقتی یه فانکشن رو صدا میزنید یه فریم تو کال استک میسازه که شامل کپیِ متغیرای محلیِ اون فانکشنه. اگه یه فانکشن داخل اون فانکشن کال کنید یه فریم دیگه به استک اضافه میکنه ولی اگه return کنید (برگردونید) همون فریم رو از استک برمیداره؛ من فکر میکنم بهترین راه برای فهمیدن کال استک اینه که برید تو کد خودتون و فریم به فریم نگاه کنید. میتونید به تب sources تو کروم devtool برید و اجرای کد اسکریپت رو متوقف کنید و بعدش میتونید قدم به قدم کال استک رو دنبال کنید.اگه به این پایین این تصویر نگاه کنید میبینید که این فانکشن CurrentStatus رو داریم صدا میزنیم، وقتی صداش میزنیم به داخل کدش میره که با یه کنسول شروع میشه و کنسول یه عملیات "یکبار برای همیشه" است و به استک اضافه میشه و بلافاصله بعدش هم برداشته میشه ولی بعدش اگه به خط بعدی بریم میبینید که یه فانکشن برمیگردونه که خودش به عنوان آرگومان ورودیش یه فانکشن صدا میزنه پس قدم بعدی اینه که فانکشن happy به عنوان ورودی فانکشن mood صدا زده بشه و شما میتونید ببینید که به استک اضافه میشه و این فانکشن happy متغیرای محلی خودشو به اسم foo داره که میتونیم تو قسمت اسکوپ محلیِ این فریم ببینیم و یه چیز باحال دیگه اینه که میتونیم Context عبارت This رو ببینیم که تو این مورد Window هست.پس کال استک تا جایی که نیاز داشته باشه فریم اضافه میکنه و بعد وقتی کدها روی ماشین اجرا میشن شروع به برداشتنشون میکنه اما چه اتفاقی میوفته اگه تو یه موقعیتی باشیم که کال استک هیچ‌وقت به عبارت return نرسه (پایان فانکشن) مثلا یه فانکشن بازگشتی (Recursive).تو فانکشن stackOverflow ما به ازای هر فریم تو کال استک یه دونه به متغیر count اضافه میکنیم و در نهایت کروم ارور بیشتر شدن سایز کال استک رو میده (call stack size exceeded) ولی یه نکته جالب توجه اینه که هر فریم تو کال استک یه کپی از متغیر count خودش داره که میتونیم با پیمایش کال استک بررسی‌ش کنیم.ولی چی میشه اگه ما بریم سر وقت یه چیز یکم پیچیده‌تر مثل: یه آبجکت که توسط چندتا فانکشن بهش ارجاع داده شده و خارج از اسکوپ لوکال فانکشنا هم تعریف شده؟ اینجا جاییه که هیپ وارد بازی میشه. هیپ تقریبا یه استخر حافظه‌ی بدون ساختاره که ما چیزایی مثل آبجکت یا مقادیر اصلیِ (Primitive Values) داخل یه کلوژر(Closure) رو درش نگه میداریم.تو این مثال از کد ما یه آبجکت به اسم myCounter داریم و با هر بار صدا زدن فانکشن یه دونه به مقدارش اضافه می‌کنیم از اونجا به تب مموریِ کروم میریم و یه اسنپ‌شات از هیپ میگیریم و بعدش میتونیم دنبال اسم متغیرمون بگردیم و تو هیپ پیداش کنیم.چیز به‌خصوصی که در مورد هیپ وجود داره اینه که هیپ Garbage Collected هست که ینی V8 یا ران‌تایم JS سعی میکنه وقتی که به متغیر جایی تو کدتون ارجاع داده نشده حافظه رو پاکسازی کنه و فضا آزاد کنه. این به این معنی نیست که دیگه شما نیازی به نگرانی در مورد حافظه ندارید بلکه فقط به این معنیه که نیاز نیست مثل اون چیزی که تو زبون C انجام میدید خودتون دستی بیاید حافظه رو اختصاص بدید و آزاد کنید.حالا که میدونید کال استک و هیپ چیه میتونیم حلقه رویداد رو معرفی کنیم. تا اینجا ما دیدیم که چطوری یه لوپ همیشه صادقِ ساده میتونه یه زبون تک ثردی رو خراب کنه پس سوالی که پیش میاد اینه که ما چطوری میتونیم هر نوع تسکی که اجراش طولانیه رو هندل کنیم. جوابش حلقه رویداده (Event loop).پس بیاید بریم و از اول مال خودمون رو بنویسیم. تو نگاه ابتدایی این فقط یه لوپ While هست که منتظر پیام‌ها از Queueئه تا بعدش دستورات هم‌روند(Synchronous) رو تا پایانشون اجرا کنه.تو مرورگر، شما همین حالاشم دارید تمام مدت اینکارو بدون اینکه حتی بهش فکر کنید انجام میدید. ممکنه یه شنونده رویداد (Event listener) برای کلیک روی دکمه تعریف کرده باشید. وقتی کاربر اون دکمه رو کلیک کرد یه پیام به Queue میفرسته و بعدش ران‌تایم میاد هر کد جاوااسکریپتی‌ای که به عنوان کال‌بک برای اون رویداد تعریف کردید رو اجرا میکنه و این چیزیه که JS رو غیرمسدود کننده (Non-blocking) میکنه بخاطر اینکه تنها اتفاقی که میوفته اینه که به رویدادها گوش میده و کال‌بک‌هاشون رو هندل میکنه پس اون درواقع هیچ‌وقت منتظر مقداری که از فانکشن برمیگردونیم نمیمونه(این جمله رو خودم اصلا مطمئن نیستم منظورش چیه و خیلی منطقی به نظرم نمیاد.شمام احتیاط بیشتری کنید). تنها چیزی که واقعا منتظرش میمونه CPU هست که کدای هم‌روندتون رو اجرا ‌می‌کنه و تقریبا برای بیشتر چیزا این وایسادن در مقیاس میلی‌ثانیه‌س. حالا بیاید اولین دورِ حلقه‌ی رویداد رو تصور کنیم.حلقه، اولش میاد و تمام کدای هم‌روند(Synchronous) اسکریپت رو هندل میکنه و بعد از اینکه کارش تموم شد میاد چک میکنه که آیا پیام یا کال‌بکی تو Queue آماده اجرا شدن هست یا نه؛ ما میتونیم این رفتارو خیلی ساده با اضافه کردن یه setTimeout با زمان ۰ ثانیه به بالای اسکریپت نشون بدیم.حالا شما ممکنه به طور شهودی فکر کنید که این تایم‌اوت باید اول اجرا بشه چرا که اول فایلمونه و یه تایم‌اوت با تاخیر زمانیِ صفر ثانیه‌س ولی در حقیقت حلقه رویداد تا زمانی که اولین دورِ اجرای کدای هم‌روند رو تموم نکرده باشه سر وقت اون نمیره.حالا چیزی که حلقه رویداد رو خاص میکنه اینه که میتونید کارای طولانی رو به یه استخر ثرد کاملا جدا بسپارید. تو مرورگر، شما ممکنه یه ریکوئست HTTP بزنید که چند ثانیه طول میکشه تا پاسخ بده یا تو Node.js ممکنه بخواید با فایل‌سیستم(File System) کار کنید و با این حال شما میتونید اینکارارو بدون اینکه ثرد اصلی JS رو بلاک کنید انجام بدید و این تقریبا تمام چیزیه که نیاز دارید از حلقه رویداد بدونید ولی JS پیش میره و اوضاعو با معرفی پرامیس‌ها(قول‌ها) و micro task queue یکم بیشتر عجیب میکنه.اگه ما برگردیم به کدمون و بعد از تایم‌اوتمون یه پرامیس بذاریم که بلافاصله پاسخ میده ممکنه فکر کنید که ما دوتا عملیات غیر‌همروند(Asynchronous) با تاخیر ۰ داریم پس setTimeout اول اجرا میشه و پرامیس دوم ولی در واقع اینجا اون micro task queue برای پرامیس‌ها رو داریم که اولویت بالاتری نسبت به task queue اصلی‌ای داره که برای DOM API و setTimeout و چیزای این شکلی استفاده میشه که این به این معنیه که کال‌بکی که برای پرامیس نوشتیم اول اجرا میشه.وقتی که حلقه رویداد داره دور میزنه اول کدای هم‌روند رو اجرا میکنه بعد میره سروقت micro task queue و هر کدوم از کال‌بکایی که بعد از پاسخ پرامیس آماده اجران رو اجرا میکنه و در نهایت میره سروقت کال‌بکایی از setTimeout یا DOM API که آماده اجرا شدن رو اجرا میکنه و این جوریه که JS کار میکنه حدس میزنم.اگه اینا به نظرتون برگ‌ریزون میاد خیلی نگران نباشید بخاطر اینکه خیلی نیازی به دونستن اینا برای شروع ساخت چیز میز با JS ندارید.منبع: لینک ویدیو navidkhm navidkhm Fri, 12 Jul 2024 12:41:14 +0330 https://virgool.io/@navidkhm/%D8%AA%D8%A7%D8%B1%DB%8C%D8%AE-%D8%B9%D8%AC%DB%8C%D8%A8-js-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-%D8%AA%D8%B1%D8%AC%D9%85%D9%87-%DB%8C%D9%88%D8%AA%DB%8C%D9%88%D8%A8-fireship-bi2m3ts8ewke احتمالا ویدیوهای fireship رو تو یوتیوب دیده باشید من از مدل کاراش و مختصر و مفید بودن ویدیوهاش لذت میبرم و متاسفانه نمیشد بهشون زیرنویس فارسی اضافه کرد و گفتم حداقل فقط متن رو ترجمه کنم و اینجا قرار بدم که جامعه‌ی فارسی‌زبان ازش استفاده کنه:"روز کریسمس ۱۹۹۰ دنیا اولین مرورگر وب که توسط Sir Tim Breners-lee توسعه داده شده رو روی سیستم کامپوتری NeXT می‌بینه و اگه این کافی نیست این شخص کسیه که در همون زمان‌ها اولین وب سرور رو هم توسعه میده فقط یه مشکل کوچیک وجود داشت اونم اینکه هیچکس تا اون زمان نمیدونست اینترنت چیه! مجری برنامه تلویزیونی: آلیسون اینجاست، میتونی توضیح بدی اینترنت چیه؟آلیسون:‌ یه شبکه بزرگ کامپوتریه که ساخته شده از شروعش در در، این یه بیلبورد کامپیوتریه ولی خطی این این یسری دانشگاهن که همه چیشون به خوبی به هم متصله و بقیه هم میتونن بهش دسترسی داشته باشن.امروز قراره که به گذشته بریم و تکامل JavaScript رو نگاه کنیم و اینکه چطور از یه زبون اسکریپتی ساده که معروفه به اینکه تو ده روز نوشته شده رسیده به تکنولوژی‌ای که تقریبا روی هر انسانی روی زمین اثر گذاشته. [توضیحات سابسکرایب چنل]داستان ما از دسامبر ۱۹۹۱ شروع میشه وقتی که Al Gore اینترنت رو اختراع کرد.صدای Al Gore: در طول خدمتم در کنگره ایالات متحده آمریکا من اقدام به ایجاد اینترنت کردم.کاری که در واقع اون کرد این بود که لایحه Gore رو معرفی کرد که تامین‌کننده اعتبار برای اولین مرورگر اصلی یعنی "Mosaic"(موزاییک) بود.موزاییک توسط Marc Andreessen و Eric bina در دانشگاه ایلینویز توسعه داده شده و برای سیستمای UNIX در ژانویه ۱۹۹۳ منتشر شده بود و تو پایان همون سال هم پورت‌های مکینتاش و ویندوزش وجود داشت و موزاییک واقعا اولین مرورگر وب بود که اینترنت رو به یه جریان اصلی تبدیل کرد ولی هنوز JavaScriptای در کار نیست و فقط DOM یا Document Objet Model که همینم به استاندارد شدن حتی نزدیک هم نشده بود.در سال ۹۳ Andreessen بعد از فارغ‌التحصیلی به کالیفرنیا نقل مکان کرد تا Netscape رو تاسیس کنه(co-found) و در عرض چندسال ناوبر(Navigator) Netscape تونست کنترل 80% مارکت مرورگرها رو به دست بگیره.تو همین موقعا بود که Andreessen متوجه شد که مرورگرها نیاز دارن تا بیشتر داینامیک بشن و دیزاینرهای وب به یه جور زبون چسبی نیاز دارن تا وبسایتاشونو بیشتر تعاملی کنه پس طبیعتا اولین چیزی که بهش رو میارن زبان خیلی ترند "جاوا" از Sun Microsystems بود ولی اونا خیلی زود به این نتیجه میرسن که اون ایده خیلی بد بوده و پلن B این بوده که این آقا به اسم Brendan Eich رو استخدام کنن که کارش این بود که زبان برنامه نویسی Scheme رو به مرورگر اضافه کنه اما سینتکسش رو همچنان شبیه Java نگه‌ داره و اون باید این کارو تا دیروزش انجام میداد. [ویدیو میم‌طور در این مورد]فقط ۱۰ روز بعدش اولین نسخه از JavaScript به دنیا اومد ولی هنوز بهش جاوااسکریپت نمیگفتن بلکه "موکا" بود. سینتکسی(دستخطی) یه زبون کروشه‌ای({}) شبیه جاوا یا سی بود ولی تو بطنش خیلی از فیچرهایی که تو جاوااسکریپت مدرن میشناسیم و دوست داریم رو داشت مثل:‌ توابع کلاس اول (First-class functions)، تایپ‌های داینامیک و ارث‌بری پروتوتایپی (prototypal inheritance) که در واقع از زبان برنامه نویسی Self الهام گرفته شده بود که خود این زبون هم، توسط Sun Microsystems توسعه داده شده بود.حالا نوشتن یه زبون برنامه‌نویسی بی‌نقص تو ۱۰ روز اساسا نشدنی بود و Brendan Eich هم اینو خوب میدونست پس کاری که نکرد این بود که بیاد یه زبون خیلی اختصاصی شده برای مرورگرای دهه ۹۰ بنویسه و در عوض اون یه زبان منعطف چندپارادایمی نوشت که همچنان دولوپرا میتونستن الگوهای زبانی خودشونو بهش اعمال کنن اما هنوزم احتمال خیلی خوبی وجود داشت که این زبون شکست بخوره و هیچ راهی نبود که اون پیش‌بینی کنه دولوپرا در طول 20 سال آینده این زبونو تا کجا پیش میبرن و به چه اندازه قراره ازش استفاده کنن.قانون Atwood: هر اپلیکیشنی که میتونه به زبان JavaScript نوشته بشه در نهایت به زبان JavaScript نوشته میشه.اما بیاید خودمونو جلو نندازیم، این زبون هنوز اسمش JavaScript هم نیست. سپتامبر ۹۵ موکا اسمش شد liveScript و به اولین نسخه بتای ناوبر نت‌اسکیپ ۲ انتقال پیدا کرد ولی چندماه بعدش تو دسامبر تصمیم گرفتن که اسمش رو به JavaScript تغییر بدن چون که شبیه به نسخه‌ی خفنِ جمع‌وجور Java که اون زمان خفن‌ترین زبون برنامه‌نویسی روز دنیا بود به نظر بیاد.جاوااسکریپت از همون روز اول شروع به تاثیرگذاری روی تجربه کاربرا کرد،‌بیشتر با پاپ‌آپ‌های اعصاب‌خوردکنش. تو همین زمانا یه شرکت بود که خیلی معروف شده بود و اونا داشتن مرورگر خودشونو میاوردن بالا، به اسم Internet Explorer. پس طبیعتا اونا جاوااسکریپت رو مهندسی معکوس کردن و تیم حقوقی یا به عبارتی تیم بازاریابی اونو به اسم JScript صدا کردن.پس تا اینجای کار تو سال ۱۹۹۶ ما دو تا زبون تقریبا یکسانِ JavaScript و JScript داریم و هر چقدر سرعت رشد اینترنت بیشتر میشد احساس نیاز به استاندارد کردن JavaScript هم بیشتر میشد پس نت‌اسکیپ به انجمن اروپایی سازندگان کامپوتر (ECMA*) رو آورد که از سال ۱۹۶۱ به عنوان یه عضو بی‌طرف برای تعیین استانداردهای صنعت IT خدمت‌رسانی میکرد و تو ژوئن ۱۹۹۷ ما اولین نسخه از ECMA262 یا اسمی که الان باهاش شناخته میشه ECMAScript رو داشتیم که به ارائه‌دهنده‌های مرورگر و اپ‌های سمت سرور مشخصات یا مجموعه‌ای از دستورالعمل‌ها برای پیاده‌سازی زبان جاوااسکریپت رو ارائه ‌می‌کرد.خود داکیومنت تقریبا صدصفحه بود و خیلی شبیه جاوااسکریپت امروزی به نظر میومد با این تفاوت که خیلی چیزارو نداشت مثل هندل‌کردن Exceptions با try و catch یا عبارات باقاعده (Regular Expressions) و تساوی سخت‌گیرانه (strict equality operator, "===").یکی از عجیب‌ترین بخشای جاوااسکریپت و همینطور یکی از بزرگترین تاسف‌های Brendan Eich نحوه کارکرد تساویه؛ بعضی از طراحای اولیه وب برای تست جاوااسکریپت فکر میکردن که اگه یه عدد میتونست با یه رشته برابر باشه میتونه مفید باشه تا جاوااسکریپت بیشتر توسط کسایی که برنامه‌نویس نیستن مورد استفاده قرار بگیره و این عملگر برابری رو پیاده‌سازی کردن (==) ولی خیلی نگران نشید چون تو چندسال آینده راهی برای درست کردنش پیدا می‌کنیم.بیاید سریع بریم به دسامبر ۱۹۹۹ که یکی از جالب‌انگیزناک ترین سال‌های تاریخ tech بوده.صدای شخصی در مصاحبه: به طور کلی من این رو به عنوان یه حباب توصیف نمی‌کنم بلکه فقط یه پدیده با سهام اینترنتی در مقابل سایر سهام‌هایی که دوباره اعاده شده‌اند وجود دارد. (اشاره به حباب .com) [جمله‌ی کوتاه دیگه‌ای هم از یه نفر دیگه گفته میشه که ارزش ترجمه‌ای نداشت ]و در همون زمان هم همه داشتن برای پایان دنیا آماده میشدن.صدای گوینده در تلویزیون: یک فاجعه ساخته دست بشر که نه تنها تهدیدی برای ایالات متحده آمریکا که حتی تمام دنیا است.فردی در مصاحبه تلویزیونی: مشکل کامیپوتر در سال ۲۰۰۰ بدون شک پیچیده‌ترین مشکلیه که تا حالا بشر باهاش روبرو بوده. [مشکل Y2K که به مشکل تفسیر تاریخ اشاره میکنه]ولی خوشبختانه درست قبل از مشکل Y2K و سقوط ارزش سهام ما نسخه ECMA3 رو دریافت کردیم که شامل بهبود هندل‌کردن ارورها و همینطور تساوی سخت‌گیرانه (===) بود که باعث میشد مقایسه تساوی یکم کمتر عجیب غریب به نظر برسه.بنابراین جاوااسکریپت به رشد و تکامل خودش به خوبی ادامه میده ولی اوضاع قراره ناجور بشه و ما تا ۱۰ سال بعد یه نسخه دیگه از ECMAScript رو نخواهیم دید.تنها سه ماه بعدش تو مارس 2000، حباب فناوری شروع به ترکیدن کرد، Nasdaq بیش از یک تریلیون دلار از ارزش خودش رو تنها تو اون ماه از دست داد و شرکت‌های مطرح شروع به سقوط کردن اما اینترنت اومده بود که بمونه و تو این نقطه ما یه استاندارد قوی برای جاوااسکریپت داریم ولی Netscape کمپانی‌‌ای که حمایت میکرد، یکسال قبل توسط AOL خریده شد.[تبلیغ شرکت AOL]و سهم مارکت مرورگرا داشت توسط اینترنت اکسپلورر بلیعده میشد و مایکروسافت واقعا به پیروی از قوانین بازی اهمیتی نمیداد. در اوایل دهه ۲۰۰۰ IE حداقل 80 درصد از سهم بازار مرورگرها رو کنترل می‌کرد و مایکروسافت کلا کار خودش رو میکرد و اکستنشن‌های خودش رو برای جاوا اسکریپت پیاده سازی می‌کرد و خب این باعث تیکه تیکه شدن جاوااسکریپت شد که ما هنوزم امروزه برای ساپورت کردن از این نسخه‌های legacy باید باهاش دست و پنجه نرم کنیم ولی همین موضوع به بعضی فیچرهای خیلی انقلابی مثل AJAX هم ختم شد که به جاوااسکریپت اجازه میداد به صورت غیرهمزمان(Asynchronous) پیاده‌سازی بشه که ماده‌اولیه‌ ساخت برنامه‌های تک صفحه‌ای(Single Page Application) بود [این ویدیو سال ۲۰۱۹ منتشر شد و ۱۵ ژوئن ۲۰۲۲ IE از ساپورت مایکروسافت خارج شد]حالا تو اوایل دهه ۲۰۰۰ کار روی نسخه ECMA4 شروع شده و به سمتی می‌رفت که بیشتر شبیه تایپ‌اسکریپت امروزی با ویژگی‌هایی مثل optional type annotations، کلاس‌ها، اینترفیس‌ها و مجموعه ای از ویژگی‌های دیگه باشه که طراحی شده بودن تا بشه تو مقیاس سازمانی از جاوااسکریپت استفاده کرد ولی یکی از اعضای کمیته از یاهو Douglas Crockford بود که سال ۲۰۰۳ JSON رو خلق کرده بود و خیلی نگران این بود که پیشنهاداتی که برای ES میدادن داشت خیلی بزرگ و خارج از کنترل میشد.مایکروسافت هم با کراکفورد موافقت کرد و در نهایت از داشتن کوچکترین نقشی تو پیشنهادات ES4 خودداری کرد. این باعث شد که ۲ تا پروپوزال متفاوت به صورت همزمان پیش گرفته بشه.ES3.1ES4نسخه ۳.۱ خیلی ساده‌تر بود و هیچ تغییر اساسی‌ای تو زبان نداشت. این حماسه تا سال 2008 ادامه داشت تا اینکه سرانجام ES4 برای همیشه کنار گذاشته شد اما در واقع راه خودشو به مارکت به عنوان یه زبان اسکریپتی به اسم ActionScript که توسط Adobe دولوپ شده و توسط Flash هم ساپورت میشد پیدا کرد و همه هم میدونیم چی به سر Flash اومد.[میم ویدیویی در مورد مرگ فلش]اوایل تا اواسط دهه ۲۰۰۰ دوران تاریک جاوااسکریپت بود ولی اون داشت آماده‌ی ورود به رنسانس میشد، دولوپرا اواسط دهه ۲۰۰۰ خیلی از ساخت وب‌اپلیکیشن‌هایی که روی همه مرورگرا اجرا شن ناامید بودن ولی ما تو سال ۲۰۰۶ با انتشار jQuery شاهد یه جهش بزرگِ رو به جلو بودیم و این کتابخونه سزاوار اعتبار بسیار بیشتری نسبت به اون چیزی که بهش داده شده‌س.JQuery یکی از اولین کتابخونه‌های JSئه که مستندات بسیار خوبی داره و به دولوپرا این امکان رو میداد که برنامه‌های پیچیده‌تر و تعاملی‌تری بسازن که با اطمینان بیشتری روی همه مرورگرها کار کنه. پس JQuery واقعا یه پدیده بود ولی ما یه اتفاق مهم دیگه هم تو سال ۲۰۰۸ دیدیم، گوگل کروم و موتور V8 هر دو ۲ سپتامبر ۲۰۰۸ منتشر شدن و V8 به طور کامل نحوه کامپایل و تفسیر جاوااسکریپت رو تغییر داد و اون رو به گزینه‌ای مناسب برای برنامه‌های کاربردی با کارایی بالا هم در سمت مرورگر و هم در سمت سرور تبدیل کرد.کمتر از یه‌سال بعد، در می ۲۰۰۹ Ryan Dahl، نودجی‌اس Node.js رو معرفی کرد، یه ران‌تایمِ(runtime) سمت سرور برای جاوااسکریپت که روی V8 ساخته شده بود و همچنین شامل یه event loop میشد که تا اون زمان یه مفهوم جدید بود و به شما اجازه میداد که کدهای رویدادمحورِ (event driven) غیرمسدود کننده (non blocking) بنویسید و به دلیل این ویژگی‌ها node.js به عنوان یه راه‌حل عالی برای ساخت وب‌اپ‌هایی که scale میشن شناخته شد و همینطور این امکان رو برای دولوپرها فراهم کرد که تمام وب‌اپی که میسازن روی یه تکنولوژی‌ سوار باشه که به عنوان "پارادایم جاوااسکریپت همه‌جا" شناخته میشه.تو همون زمان هم متخصصای جاوااسکریپت بالاخره خودشونو برای نسخه بعدی جمع و جور کردن؛ طرف‌ها در اسلو، نروژ متحد شدند و تصمیم گرفتن که ES3.1 را به عنوان نقطه شروعی برای ES5 در نظر بگیرن که در نهایت تو دسامبر 2009 منتشر شد،ینی دقیقاً 10 سال بعد از آخرین مشخصه رسمی. از نقطه نگاه فنی ES5 یسری فیچرای خیلی مهمی داشت مثل: JSON Support، Object Methods، strictmode ،‌accessors و خیلی چیزای دیگه.حالا بریم تا سال ۲۰۱۰، اینجا ما داریم فریمورکای جاوااسکریپتی رو میبینیم که اختصاصا برای برنامه‌های تک‌صفحه‌ای (SPA) طراحی شدن؛ دو تا از معروف‌تریناشون backbone و angular.js بودن که هر دوشون اکتبر ۲۰۱۰ بیرون اومدن و هر دوشون سعی میکردن یه مشکل مشابهو حل کنن ولی اینکارو از راه‌های متفاوت انجام دادن. Backbone سبک بود و آپدیت DOM رو به شیوه برنامه‌نویسی دستوری (Imperative programming) هندل میکرد در حالی‌که انگولار یکم جامع‌تر بود و از شیوه برنامه‌نویسی اعلانی (Declarative programming) استفاده می‌کرد و سازنده بک‌بون Jeremy Ashkenas اسطوره‌ی این دوره‌س و کسیه که Underscore.js و CoffeeScript رو ساخته و صحبت از CoffeeScript بخش مهمی از تاریخ جاوااسکریپته بخاطر اینکه اولین زبانی بود که باعث شد Transpiling تبدیل به یه جریان بشه و خود این مسئله هم در نهایت به ایده اصلی برندون برمیگرده وقتی که تو سال ۱۹۹۵ داشت یه زبان برنامه‌نویسی میساخت که قابل انعطاف باشه؛ Transpilerها تو نسخه بعدی جاوااسکریپت ES6 یا ES2015 خیلی مهم شدن و تعداد زیادی هم فیچرهای جدید تو این نسخه به‌کار گرفته شدن چیزایی مثل:Promiselet and constarrow functionsspread syntaxdestrucuringاین ویژگی‌های جدید یه پیشرفت عظیم برای توسعه دهنده‌ها بودن ولی برای توسعه‌دهنده‌ها واقعا سخت بود که بخوان از اینا استفاده کنن چون روی خیلی از مرورگرای قدیمی ساپورت نمیشدن و این دلیلیه که ما امروزه کاربرد پررنگ چیزایی مثل Babel و Typescript رو می‌بینیم بخاطر اینکه میتونن به هر نسخه‌ای از جاوااسکریپت برسن، از نسخه‌های امروزی تا ES3.هم‌زمان که دولوپرا هنوزم میتونن کداشونو با مدرن‌ترین فیچرها بنویسن [کدهای امروزی مارو به نسخه‌های قابل فهم برای مرورگرای قدیمی که فقط تا ES4 مثلا میتونستن متوجه شن تبدیل میکنن که روی اونها هم اجرا بشه]و یه اتفاق مهم دیگه هم در سال ۲۰۱۵ خیزش React.js بود که یسری از مفاهیم Angular با declarative UI (رابط کاربریِ اعلانی) رو گرفت اما با unidirectional dataflow (جریان داده یکطرفه)، immutability (عدم تغییرپذیری) و استفاده از VirtualDOM بهبودشون داد و واقعاً React فریم‌ورکیه که الگوهای امروزیِ declarative UI رو تثبیت کرده. اما در این بین فریمورکای دیگه‌ای مثل Angular, Vue, Svelte هم هستن که برای جلب توجه دولوپرا رقابت میکنن.همچنین تو همون دوره زمانی ما ابزارایی برای مدیریت پیچیدگی‌های این اپ‌های سنگین جاوااسکریپتی دیدیم، چیزایی مثل Rollup و Webpack برای باندل dependencies (وابستگی‌ها) و چیزایی شبیه typeScript و flow برای اضافه کردن type systems به جاوااسکریپت و بعدش شما یه چیزایی مثل immutableJs و rxJS داری که کمک میکنن که functional pattern (الگوهای تابعی)رو تو کدت استفاده کنی و اینا واقعا فقط نوک کوه یخِ پیچیدگی‌های اکوسیستم امروزی جاوااسکریپته و این ما رو به امروز میرسونه تابستون ۲۰۱۹،‌ TC39 یا کمیته‌ای که مسئول تغییرات ECMAScriptئه تو این نقطه یه برنامه زمانی منظم برای آپدیت جاوااسکریپت داره پس ما باید تقریبا به زودی ES2019 رو ببینیم که قراره با خودش فیچرای جدیدِ باحالی به زبون اضافه کنه. ولی یه توسعه‌ی خیلی جالب دیگه هم Web Assemblyئه که به خودیِ خود فقط یه فرمت باینریه که زبون سطح پایینی مثل C++ میتونه کامپایلش کنه تا بتونه اپ‌هایی با پرفورمنس بالا به وب ارائه بده؛ وب‌اسمبلی یه جایگزین برای جاوااسکریپت نیست ولی میتونه یه راه کاملا جدید برای ساخت وب‌اپ‌ها رو بهمون نشون بده و قطعا روی آینده جاوااسکریپت تاثیر بذاره ولی اگه یه چیز رو تو طول سالها یاد گرفته باشم اینه که همیشه روی جاوااسکریپت شرط ببندم، جاواسکریپت یه زبونیه که مداوما تکامل پیدا کرده، حتی از همون زمان نمونه‌ی اولیه‌ش و برخلاف بقیه زبونای برنامه‌نویسی جامعه‌ی بزرگ و متنوعی داره. من میخوام تمومش کنم، ممنون از تماشاتون و تو ویدیوی بعدی باهاتون حرف میزنم."امیدوارم براتون مفید بوده باشه و اگه نکته‌ای یا پیشنهادی در مورد این مدل ترجمه‌ها یا کارا به ذهنتون میرسه خوشحال میشم بگید.* European Computer Manufacturers Associationمنبع:لینک ویدیو navidkhm navidkhm Thu, 14 Mar 2024 13:41:17 +0330 https://virgool.io/@navidkhm/%D8%AA%D9%81%D8%A7%D9%88%D8%AA-require-%D9%88-import-%D8%AF%D8%B1-js-%DB%8C%D8%A7-%D9%85%D8%AE%D8%AA%D8%B5%D8%B1%DB%8C-%D8%A7%D8%B2-%D9%85%D8%A7%DA%98%D9%88%D9%84-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7-%D8%AF%D8%B1-js-esue9bhygzxt آقا من تلاش کردم که تا جای ممکن فارسی بنویسم و فکر کنم تو عنوان جالب نشده پس سریع انگلیسیشو میگم که جا بیوفته.منظورم از ماژول سیستم‌ها همون Module System هستش که احتمالا میدونید چیه فقط شاید به این اسم نمیدونید و الان میگم.CJS vs ESM in JSماژول و ماژول سیستم در JSاینکه من بخوام منطق‌هامو بشکنم و چندتا فایل کنم و بعد یه فایلی رو توی یه فایل دیگه بیارم ازش استفاده کنم میگیم ماژول و در JS به‌خاطر اینکه در طول زمان تغییرات داشته و یکپارچه هم نبوده(مثل پایتون نبوده مثلا یه تیم پشتش باشه ورژن بده) ما چند روش داریم برای اینکه ماژول‌هامون رو تو یه فایل وارد کنیم(فراخوانی میگیم بهش) که دو تا از مهم‌ترین سینتکس‌هاش همون Require و import هستن که در واقع require نماینده CJS(Common JS) و import نماینده (ECMAScript Module)ESM.اون اوایل که تازه میخواستن از ماژول استفاده کنن سریع راه‌حلی که دادن این بود که require استفاده کنیم و در واقع گویا Node.js هم این راه‌‌حلو داد و بهش گفتن CommonJS و بعدها هم ECMAScript راه حل دیگه‌ای داد که یکم بهتر بود و اسمش شد ECMAScript Module که مرسوم‌تره و با همون import استفاده می‌کنیم ازش و یکی از مهم‌ترین فرقاشون اینه که require وایمیسه که کل فایل لود بشه (در واقع Synchronous هستش) و بعد میره خط بعدی اما import اینطوری نیستش و میتونه همزمان کدای فایل اصلی رو اجرا کنه و وقتی اون ماژولی که فراخونده بود لود شد اونم بیاره تو بازی که خب طبیعتا سریعتره.پسوندهای هر کدوم هم اینطوریه:CJS --> .cjsESM --> .mjsاین دوتا البته مرسوم‌ترین ها هستن و انواع دیگه از جمله AMD, UMD هم داریم که لینک توضیحات مختصر اونا هم پایین اینجا میذارم.دوپارگی(چندپارگی) مسئله همیشگی در JSحالا یه نکته مهم اینه که این دو تا سیستم عملا اکوسیستم JS رو دوپاره کرده‌ن و برای پکیج نوشتن دقت کرده باشید معمولا دو نسخه از این دو تا سیستم رو میذارن که هر کس از هر کدوم که داره استفاده میکنه به مشکل نخوره.مثالی از قرار دادن هر دو شیوه مرسوم ماژول سیستم در پکیج‌هانحوه فراخوانی هر یک از ماژول‌ها با ماژول سیستم دیگرتوی ESM خیلی ساده میتونیم فایل .cjs رو فراخوانی کنیم ولی تو CJS چون گفتیم synchronous هست با لطائف‌الحیل باید کاری کنیم تا .mjs فراخوانی شه:Importing ESM(.mjs) into CJSconst example = await import(&quot./example.mjs&quot)Importing CJS(.cjs) into ESMimport example from &quot./example.cjs&quotدر واقع چون برای فراخوانی ESM در CJS به شکل عادی ناتوانیم مجبوریم به جای require از فانکشن import استفاده کنیم و await هم میکنیم تا لود شه و بعد مابقی کد اجرا شه که CJS ناراحت نشه.ESM یا CJS ؟؟پیشنهاد میشه که همه از ESM استفاده کنن و یه قرارداد باشه تا کم‌کم کل اکوسیستم به این سمت بره(یکپارچه) و کدهای با استایل سیستم CJS بازنویسی بشنمسئله باندلرهاامااااا قبلا اگه باندلرهاتون رو بعد از بیلد نگاه کرده بودید میدیدید که شما ماژول رو import کردید ولی خروجی دارید require میبینید(البته بستگی به کانفیگی که مثلا روی وب‌پکتون انجام دادید هم داشت و الخ) که چندان کار جالبی نبود ولی بخاطر پشتیبانی مرورگرا اینکارو میکردن که خیالشون از اجرای کد راحت باشه ولی بعضا میتونه تو فایلای بزرگ توی کارکرد تاثیراتی بذاره اما چون دیگه تقریبا همه مرورگرا ESM رو پشتیبانی میکنن الان کمتر این تغییرو توی بیلد میبینید.تبدیل import به require بعد از بیلد توسط باندلرکوفته برنجی و ادعای پاسخ به مسئله‌ی قدیمیحالا این وسط کوفته‌برنجی پر سروصدا (Bun) هم اومده گفته من این مشکل رو حل کردم و دیگه نگران اینکه ماژولتون ESM هست یا CJS نباشید که اگه واقعا اینکارو کرده باشه بعد از شاید یک‌دهه به این مشکل عجیب پایان داده و دست و جیغ و هورا !!حالا یه نکته پایانی هم بگم اگه از هر دو نوع ماژول سیستم‌ها برای فراخوانی استفاده کنیم میتونه مشکل‌ساز بشه که بهش میگن Dual Package Hazard :)Dual Package Hazard یا فراخوانی یک ماژول با دو ماژول سیستم منابع و تشکر :)ایده‌ی زیبا و توضیح زیباتر این مفاهیم رو بیشتر و در ابتدا از "Matt Pocock" در ویدیویی که لینکش رو میذارم فرا گرفتم و مابقی رو پراکنده از لینک‌هایی که پیدا کردم که اونا هم میذارم. https://www.youtube.com/watch?v=6_JNPmjSevohttps://adamcoster.com/blog/commonjs-and-esm-importexport-compatibility-examplesجهت مطالعه‌ی مختصر باقی ماژول سیستم‌ها:https://medium.com/@halilatilla/differences-between-javascript-modules-cjs-amd-umd-and-esm-f60124de131b#:~:text=CommonJS%20(CJS)%3A,and%20provides%20a%20simple%20syntax navidkhm navidkhm Fri, 06 Oct 2023 19:12:52 +0330 https://virgool.io/@navidkhm/%D8%AD%D8%A7%D9%81%D8%B8%D9%87-%D9%88-%D9%86%D8%AD%D9%88%D9%87-%D8%B0%D8%AE%DB%8C%D8%B1%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%D8%AF%D8%A7%D8%AF%D9%87-%D9%87%D8%A7-%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%AF%D8%A7%D8%AF%D9%87-%D8%AF%D8%B1-js-%D8%A8%D8%AE%D8%B4-%DB%B1-wbez43xwlfzu برای همه‌مون دیدن ارور زیر پیش اومده :ارور Maximum call stack size exceededو خب تقریبا همه‌مون هم میدونیم که معنی‌ش چیه(بیشترین مقدار از کال استک پر شده) و احتمال زیاد یه جایی از کدمون داره infinite loop (چرخه‌ی بی‌نهایت) میخوره که در نهایت اپ از کار افتاده و به ما اینو میگه.حالا یکم قراره جزئی‌تر بدونیم و ببینیم وقتی کدی رو می‌نویسیم متغیرهامون دقیقا چجوری ذخیره میشن :Stack and Heap Memory:ما داخل حافظه (اینجا داریم در مورد RAM حرف میزنیم نه Disk Drive) دو بخش داریم.یکی Stack و اون یکی Heap و اگه ساختمان داده یادتون باشه یه بحث بامزه‌ای این وسط هست که آیا واقعا این دوتا بخش تو حافظه همون دو نوعِ ساختمان داده هستن؟؟ که اینجا بهش نمی‌پردازیم و صرفا همون دو بخشِ مختلف از حافظه رو که توش داده ذخیره میشه میگیم استک و هیپ؛ دقت کنید جفتشون توی RAM هستن.استک و هیپ دو بخش مختلف از حافظه (فقط شکل گولتون نزنه مقدار استک خیلیییی کمتر از هیپه)نحوه ذخیره‌سازی داده در استک و هیپاستک جاییه که توش میتونیم مقدار تعیین‌شده‌ای از داده رو پشت سر هم ذخیره کنیم یعنی :تو تصویر بالا ما یه متغیر نوشتیم و مقدارش رو برابر یه عدد گذاشتیم و مقداری هم که عدد تو حافظه جا میگیره ۸ بایته(تقریبا) و زبون ما اینو میدونه پس میگه آقا متغیر (a) ۸ بایت جا میخواد پس میذارمش تو استک و استک هم ۸ بایت از حافظه‌ای که داره رو پر میکنه و پوینتر ۸ واحد جلوتر میره و میتونه متغیر بعدی رو ذخیره کنه و چون دقیقا میدونه چقدر فضا باید به داده‌ی ما بده خیلی سریع اینکارو انجام میده؛ به این حالت میگیم Static Memory Allocation (تخصیص حافظه‌ به شکل ثابت). از اونطرف هم هیپ رو داریم که متغیری که داخلش ذخیره می‌کنیم سایز مشخصی نداره و میتونه بزرگ و کوچیک شه یاااا اینکه مقدار متغیرم بزرگه و خیلی راحت‌تره که توی هیپ انداخته بشه بخاطر اینکه گفتیم مقداری که استک از سیستم‌عامل (OS) میگیره خیلی محدوده (در حد 1Mb یا تهش چند مگ)*.حالا فرض کنید که یه آبجکت دارم که چندتا پراپرتی داره و قراره بره توی هیپ ذخیره بشه، اگه بخوام خیلی مختصر بگم زبونمون اول میره میپرسه آقا کجاها از حافظه خالیه؟ لیستشو میگیره و بعد میره متغیرمون رو تو یکی از اون فضاها ذخیره میکنه و اون آدرسی از حافظه رو که توش متغیرمون رو ریخته (که طولش رو میدونیم چون یه عدده :دی) تو استک ذخیره میکنه و وقتی ما میخوایم آبجکتمون رو فراخوانی کنیم برنامه میره روی اون بخش از استک و میبینه یه آدرس از حافظه اونجا ذخیره شده و میره اون آدرس رو میخونه و مقداری که میخوایم رو برگردونه. یه نکته هم ‌که گفتم اینه که هیپ میتونه زیاد بشه یعنی بنا به نیاز برنامه طولش رو زیاد کنه و مثل استک محدودیت نداره**شماتیک داده‌ی ذخیره‌شده در استک و هیپ انواع داده در JSتا اینجا فهیمدیم که دو مدل فضا تو RAM داریم و چجوری کار میکنن ولی وقتی ما یه سرچ تو اینترنت میزنیم در مورد انواع ذخیره‌سازی داده‌ تو JS میگن دو مدل داده (Data Type) داریم: 1.Primitive Type (نوع اولیه)***2.Reference Type (نوع ارجاعی)نوع اولیه اونایی‌ن که خودِ مقدارشون مستقیم توی استک قرار میگیره و ارجاعی‌ها(Reference Type) هم از اسمشون معلومه آدرس حافظه‌شون(پوینتر در واقع) تو استک قرار میگیره که تو شکل بالا هم نشون دادیم.بعد هم میگن آبجکت و تابع و آرایه(۴*) از نوع ارجاعی هستن پس میرن توی هیپ و مابقی انواع داده میرن توی استک ذخیره می‌شن :))) و خب واقعا این چه طرز توضیحه!!!این حرف تا حدی مسئله‌سازه چرا که عملا ما دیگه فکر میکنیم همه‌جا اینطوریه و کلا هر جا آرایه‌ دیدیم پس میفهمیم که مقدارش توی هیپ ذخیره میشه.اما جای قشنگش اینه که تو زبونای سطح پایین مثل C و ++C ما میتونیم تعیین کنیم که کدوم متغیر توی هیپ بره مثلا من یه متغیر عددی تعریف میکنم ولی میگم تو برو و مقدارتو توی هیپ ذخیره کن مثل کد زیر:تعریف یک متغیرِ ارجاعی و مقداردهی اون با عدد در زبان C [اون تیکه malloc که نوشته شده داره میگه به من فلان قدر(نوشته به اندازه طول یه عدد) فضا داخل هیپ بده.] یا حتی برعکسش، میگم من یه آرایه دارم و طولش انقدره و میره توی استک ذخیره‌ش میکنه ولی خب تو زبونای سطح بالاتر این رو خودشون مدیریت میکنن که چیا برن توی هیپ ذخیره بشن و چیا توی استک و برای JS هم اون تعریف نوع ارجاعی و اولیه هم برای این ارائه میدن که بگن این تایپ‌ها آدرسشون تو استک ذخیره میشن و این یکی‌ها خود مقدارشون.به نوعی اگه بخوایم با توضیح اولمون بگیم چون داده‌های نوع اولیه سایز مشخصی دارن میتونیم توی استک ذخیره‌شون کنیم ولی آبجکت و ... چون سایزشون قابل تغییره میرن داخل هیپ.پس دیدیم همیشه اینطور نیست که هرجا آرایه دیدیم پس خودبخود میپره توی هیپ و همههههه‌ی عددا میرن توی استک.(۵*)حالا که تا حد خوبی از انواع داده و انواع حالت ذخیره‌سازیشون اطلاعات پیدا کردیم بریم و علت ارور رو بررسی کنیم:در مورد اون پشته‌ی فراخوانی(Call Stack) میخوام بعدا مفصل بنویسم ولی فعلا در این حد بگم که هر تابعی که تو JS اجرا می‌کنیم به جایی به اسم Call Stack اضافه میشه و وقتی هم که تموم بشه از پشته حذف میشه (چون ساختارش (FILO) هست؛ آخرین چیزی که وارد میشه اولین چیزیه که خارج میشه مثل استوانه قرص جوشان).گفتیم که تو اون ارور احتمالا یه تابعی داره مدام خودشو صدا میزنه و فضا به استک اضافه می‌کنه(بهش میگن Stack Frame) و انقدر داره خودشو صدا میزنه و هی تو استک متغیر میریزه که عملا ما به ارور محبوب قلوب یعنی Stack Overflow میرسیم :) یعنی اینکه به مرز استک رسیدیم و برنامه دیگه نمیتونه متغیری تو استک ذخیره کنه.جمع‌بندیِ پایانی:فضای رم به ۲ بخش استک و هیپ تقسیم میشه و نحوه ذخیره‌سازی توی استک اینطوره که سایز متغیر رو میدونه و به همون اندازع پوینترش میره جلو و متغیر رو ذخیره میکنه و توی هیپ ساختار منظم نیست و داده‌ها همینطور پراکنده ذخیره میشن همچنین توی زبونای سطح بالا مثل JS خود زبان(۶*) تصمیم میگیره چیا برن توی هیپ و چیا توی استک که تو JS بهشون میگیم نوع داده‌ی اولیه و ارجاعی (ارجاعی از اسمش معلومه میره توی هیپ ذخیره میشه و آدرسش میره داخل استک و اولیه هم خود مقدارش میره توی استک)امیدوارم تونسته باشم مفهومو تا حد خوبی رسونده‌ باشم و لطفا لطفا اگه جایی ایراد فنی داره یا با اطلاعات دیگه‌تون تداخل داره بهم بگید که منم بدونم و یاد بگیرم. 3>* اگه خیلی دوست دارید بدونید بعضی از زبونا میشه مقداری که از سیستم‌عامل میخواید برای استک رو خودتون دستکاری کنید :)** البته تا زمانی که RAM پر نشه دیگههه :) که معمولا نمیشه.*** تو بعضی از زبونا مثل #C بهشون میگن نوع مقداری (Value type & Reference type)۴* در واقع آرایه و فانکشن خودشون آبجکت محسوب میشن :)۵* البته تو خود JS هم مثلا رشته‌ها میتونن توی هیپ ذخیره شن و همیشه اینطور نیست که برن توی استک :)۶* توی JS مسئله یکم متفاوت‌تره چون engine ها هم میتونن نحوه پیاده‌سازیشون فرق کنه مثلا V8 بگه من اینطوری میکنم داده رو که بره توی هیپ و SpiderMonkey یه کار دیگه کنه.منابع:https://youtu.be/_8-ht2AKyH4https://youtu.be/5OJRqkYbK-4https://felixgerschau.com/javascript-memory-management/https://felixgerschau.com/javascript-heap-out-of-memory-error/https://www.youtube.com/watch?v=wJ1L2nSIV1shttps://www.youtube.com/watch?v=iNuTwvD6ciIhttps://www.youtube.com/watch?v=Hci9Bb4_fkA navidkhm navidkhm Fri, 09 Jun 2023 17:21:33 +0330 https://virgool.io/@navidkhm/%D8%AF%D8%B1-%D9%85%D9%88%D8%B1%D8%AF-transpilers-%D9%88-polyfills-%D8%AF%D8%B1-js-z1duprhhuljc قبل از اینکه بخوایم وارد بحث بشیم نیازه که دوتا چیزو روشن کنیم و امیدوارم خیلیی طولانی به نظر نیاد.Backward & Forward compatibility:خب BC ینی کدی که مینویسیم نسبت به ورژنای قبلی و قدیمی‌ترش بتونه همچنان کار کنه و مثلا اینطوری نباشه که فلان سینتکس که تو نسخه ES5 اومده دیگه تو نسخه ES12 حذف شده یا ... و اگه این قابلیت روی js نباشه وقتی من کد قبلی رو میام روی ورژن جدید ران بگیرم همه چی میره رو هوا (مثلا توی react و vue ما اینو تجربه کردیم که بعضی چیزا با آپدیت نسخه (major) باید تغییر کنن و برنامه به شکل قبلی ممکنه قابل اجرا نباشه) و خب این واقعا کار سختیه که تو اگه یه روزی یه جایی به یه نسخه‌ایت یه چیزی اضافه کردی دیگه نمیتونی حذفش کنی* =))مخصوصا بیشتر سخت میشه که تو یه تاریخچه‌ی تقریبا ۲۰ و خورده‌ای ساله داشته باشی و فیچرای سال ۳۰ام نباید هیچ تداخلی با سال ۱ داشته باشن و هر کدوم باید درست کار کنن و شعار TC39 هم همینه که "ما وب رو خراب نمی‌کنیم" و فیچرای جدیدی که به js می‌افزاییم تداخلی تو وبلاگ نوید که وقتی نوجوان بود مینوشت نخواهد داشت و اون سایت مثل بنز کماکان کار خواهد کرد و همچنان کلی از سایتای زیرخاکی قابل استفاده هستند به خاطر این نوع برخورد.تو صنعت یه همچین گارانتی‌ای رو خیلی سخت بشه پیدا کرد ولی js اینکارو کرده :)از اون طرفم FC دقیقا بر عکس BC میشه اینطوری که فیچرای بعدی میان و ماشین قدیمی میتونه نادیده‌شون بگیره و با همون سینتکسی که بلده کارشو ادامه بده که خب میدونیم js اینطوری نیست و کرش میکنه ولی HTML و CSS اینطوری هستن و پارسر میتونه اون بخشی که بلد نیست رو اسکیپ کنه.بیشتر بخوام مثال بزنم اینطوری که من لبتاب قدیمی سال ۲۰۰۶م** رو پیدا میکنم و میرم با IE7 یه سایت خفن(که از transpiler و polyfill استفاده نمیکنه، دیگه داریم میرسیم بهشون) و مرورگرم وقتی میاد HTML رو پارس کنه چون HTML4 رو میشناسه وقتی به تگ section میرسه ایگنورش میکنه (چندتا حالت اینجا وجود داره و بعضی مرورگرا یه div در نظر میگیرنش و بعضی وقتام واقعا کرش میکنه و گند میزنه به مثالی که میخوام بزنم? ولی ما فرض میگیریم کلا رندرش نمیکنه مثلا) ولی صفحه کرش نمیکنه و اونایی رو که میشناسه پارس میکنه برای CSS هم همینطور ولی وقتی میریم توی JS میاد میبینه let و const داره و اصلا نمیدونه اینا چی‌ن و کلا کرش میکنه :)عوضش اون دوتا از نعمت BC بهره‌مند نیستن.حالا بریم سر اصل مطلب Transpiler و Polyfill:گفتم چون js قابلیت FC نداره و مرورگر قدیمی ما تا یه جایی سینتکسش رو بلده بخونه، گفتن نمیشه که به اون ایرانی بدبختی که هنوزم با pc قدیمی‌ش(که وسط هاله و کاور میکشن روش) میاد وب بگیم اکه میخوای این سایتو ببینی باید مرورگرت رو آپدیت کنی پس به جاش میایم کدای سینتکس جدید js رو به یه سینتکس قدیمی‌تری که دیگه ۹۹٪(عدد فرضی می‌باشد) مرورگرا ساپورتش میکنن تبدیل میکنیم مثلا سال اولی که ES6 اومده و ما هم const نوشتیم برای متغیرمون، میاد و تبدیلش میکنه به var که مرورگر پیرا نترسن یه وقت.مثال معروفش Babel خودمونه.از اونور Polyfill(یسریا بهش shim هم میگن مثلا تو webpack ما shimming داریم) کارش اینه اگه یه متدی چیزی که دیگه فقط سینتکس نیست، جدیدا اضافه شده بود، بیاد چک کنه ببینه مرورگر ساپورتش میکنه یا نه؟ اگه نمیکرد خودش میاد به اون زبونی که میفهمه بهش توضیح میده مثلا میگه اگه نمیدونی ()isNan چیه این چند خط کد جوابته اینطور ران کن.پلی‌فیل رو برخلاف ترنسپایلر خودمونم میتونیم بنویسیم برای یه سری متدا و APIهای خاص ولی ممکنه همه جوانبشو ندیده باشیم و اینا و بهتره از لایبرری مخصوصش استفاده کنیم(core-js یکی از خفن‌ترین و معروف‌تریناشه).امیدوارم که دید بهتری بهتون داده باشه و اگرم جایی به لحاظ فنی خطایی بوده حتما بهم بگید که یاد بگیرم منم 3>* گویا یه جاهای خیلیییی کوچیک و کمی که آسیبی به وب نمیزده رو حذف کرده یا تغییر داده‌ن.** سال ۲۰۰۶ ES3 داشتیم و HTML4 navidkhm navidkhm Fri, 17 Mar 2023 21:15:41 +0330