استاندارد JavaScript  - بخش دوم

گردآوری و تالیف : عرفان کاکایی
تاریخ انتشار : 13 آبان 1397
دسته بندی ها : جاوا اسکریپت

در این بخش، به ادامه مبحث استاندارد JavaScript خواهیم پرداخت. برای مطالعه قسمت اول این مقاله میتوانید به مقاله استاندارد JavaScript - بخش اول  سر بزنید

ECMAScript به عنوان یک استاندارد حکمران

با گذراندن ۱۰ ده سال بدون توجه به تغییرات قابل ملاحظه به این مشخصه زبان پس از ES3 و چهار سال زمان مورد نیاز برای ES6 تا تحقق یابد، واضح بود که روند TC39 نیاز به پیشرفت داشت. هر تاخیری در رسیدن اجماع،‌ باعث بروز مدت زمان‌های صبر طولانی میان اصلاحات میشد، که خود موجب تاخیرهای بیشتر می‌شدند. اصلاحات جزئی توسط موارد اضافه شده بزرگ به این مشخصه تاخیر می‌خوردند، و موارد اضافه شده بزرگ در جهت نهایی شدن با فشار مواجه می‌شدند، تا اصلاحیه مورد نظر به جلوگیری از بروز تاخیرهای بیشتر ختم شود.

از زمانی که ES6 منتشر شد، TC39 روند اصلاح پیشنهادی خود را ساده کرده است و آن را به گونه‌ای تغییر داده است که با انتظارات مدرن همخوان باشد: نیاز به تکرار بیشتر و هموارتر و دموکراتیزه کردن توسعه مشخصه‌ها. در اینجا TC39 از یک جریان قدیمی به استفاده از Ecmarkup و درخواست‌های GetHub Pull رسید، و به خوبی تعداد پیشنهادهای ساخته شده به عنوان یک مشارکت از طرف افراد غیر عضو را افزایش داد.

Firefox، Chrome، Edge، Safari و Node.js همگی بیش از 95 درصد سازگاری با مشخصه ES6 را فراهم کردند، و ما پس از انتشار هر کدام از این امکانات، توانسته‌ایم در این مرورگرها از آن‌ها استفاده کنیم.

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

هر صحبت، ایده یا پیشنهادی برای تغییر یا اضافه کردن که از پیش به عنوان یک پیشنهاد رسمی تایید نشده باشد، یک پیشنهاد «strawman» (سکوی ۰) در نظر گرفته می‌شود و نیاز به هیچ تقبلی ندارد. در زمان نوشتن این مقاله، بیش از ۱۰ پیشنهاد سطح صفر فعال وجود دارد.

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

پیشنهاد در سکوی دوم، یک پیش‌نویس اولیه درباره مشخصه مورد نظر فراهم می‌کند. تا به اینجا، منطقی است که شروع به آزمایش پیاده‌سازی‌های واقعی در runtime نماییم. این پیاده‌سازی می‌تواند در قالب pollyfil، کد کاربر که باعث می‌شود runtime به پیشنهاد بپیوندد، یک پیاده‌سازی موتور، پشتیبانی بومی برای پیشنهاد مورد نظر، یا کمپایل شده در چیزی که موتور‌های موجود بتوانند اجرا کنند و استفاده از build-timeها برای تغییر شکل سورس کد بیاید.

پیشنهاد‌های در سکوی سوم، موارد توسعه شده به عنوان کاندیدا هستند. تا به اینجا، پیاده‌سازان علاقه خود نسبت به این پیشنهاد را بیان کرده‌اند. پیشنهادها در عمل با حداقل یک پیاده‌سازی مرورگر، یک polyfill امیدوارکننده یا پشتیبانی شدن توسط یک کمپایلر build-time مانند Babel به این سکو منتقل می‌شوند. در این سکو، احتمال این که یک پیشنهاد فراتر از برطرف سازی مشکلات تشخیص داده شده تغییر داده شود، کم است.

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

پس از ES6، از نسخه‌های جدید مشخصه‌ها انتظار می‌رود که هر روزه منتشر شوند. برای تطبیق با برنامه انتشار سالانه، حال نسخه‌ها با استفاده از سال انتشار خود تحت اشاره قرار خواهند گرفت. از این رو ES6 تبدیل به ES2015، ES7 تبدیل به ES2016‌ و.. می‌شوند. ES7 قبل از این که این قانون نام‌گذاری تغییر کند، معرفی شد و از این رو گاهی اوقات با نام ES2016 شناخته می‌شود.

انتظار می‌رود که از این پس ES2017 دیگر با قانون نامگذاری قدیمی تحت اشاره قرار نگیرد.

پشتیبانی مرورگر و ابزار مکمل

کاندیدای سکوی سوم، با فراهم شدن ۲ پیاده‌سازی مستقل در موتورهای JavaScript، بیشترین احتمال برای تبدیل شدن به یک مشخصه در مرحله بعد را دارد. پیشنهادهای سکوی سوم به طور موثر، امن در نظر گرفته می‌شوند تا در برنامه‌های واقعی استفاده شوند؛ چه در یک پیاده‌سازی موتور آزمایشی، یک polyfill، یا با استفاده از یک کمپایلر. پیشنهادهای سکوی دوم و پیش‌تر هم توسط توسعه‌دهندگان JavaScript در نظر گرفته می‌شوند، و حلقه بازخورد میان پیاده‌سازی و مشتریان را تنگ‌تر می‌کنند.

Babel و کمپایلرهای مشابه که کد را به عنوان ورودی گرفته، و یک خروجی بومی پلتفرم وب (HTML، CSS و JavaScript) را تولید می‌کنند، معمولا تحت عنوان «transpiler» شناخته می‌شوند. وقتی که ما می‌خواهیم از یک پیشنهاد که به طور گسترده در موتورهای JavaScript در کد ما پیاده‌سازی نشده است استفاده ببریم، کمپایلرهایی مانند Babel می‌توانند بخش‌هایی از کد را با استفاده از آن پیشنهاد جدید، به چیزی که بیشتر توسط پیاده‌سازی‌های JavaScript فعلی پشتیبانی می‌شود، تغییر شکل دهند.

این تغییر شکل می‌تواند در هنگام ساخت انجام شود، تا مشتریان کدی را دریافت می‌کنند که توسط runtime جاوااسکریپت آن‌ها به خوبی پشتیبانی می‌شود. این مکانیزم، خط مقدم پشتیبانی runtime را ارتقا می‌دهد، و به توسعه دهندگان JavaScript این قابلیت را می‌دهد که از امکانات و سینتکس‌های جدید زبان استفاده ببرند. همچنین این مسئله به طرز قابل توجهی برای نویسندگان و پیاده‌سازان مشخصه سودمند است؛ زیرا آن‌ها را قادر می‌سازد تا بازخوردهای مربوط به پایداری، مطلوبیت و باگ‌های احتمالی را دریافت کنند.

یک transpiler می‌تواند سورس کد ES6ای که می‌نویسیم را بگیرد و کد ES5ای تولید کند که مرورگر می‌تواند به طور هموارتری تفسیر کند. این روش، قابل اعتمادترین روش برای اجرای کد ES6 در تولید امروزی است: استفاده از یک build step برای تولید کد ES5 که هر مرورگر مدرنی می‌تواند اجرا کند.

همین مسئله نسبت به ES7 و فراتر از آن هم صدق می‌کند. همینطور که نسخه‌های جدید‌تری از مشخصه زبان به صورت سالانه منتشر می‌شوند، می‌توانیم از کمپایلرها انتظار داشته باشیم که ورودی ES2017، ES2018 و... را پشتیبانی کنند. به طور مشابه همینطور که پشتیبانی مرورگر بهتر می‌شود، می‌توانیم از کمپایلرها انتظار داشته باشیم که پیچیدگی خروجی ES6، ES7 و... ما را کاهش دهند. در این مفهوم، می‌توانیم به transpilerهای JavaScript به JavaScript، به عنوان یک پنجره حرکت فکر کنیم که کد نوشته شده با استفاده از آخرین معنی‌های در دسترس زبان را می‌گیرد و مدرن‌ترین کدی که مرورگر پشتیبانی می‌کند را تولید می‌کند.

آینده JavaScript

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

منبع

مقالات پیشنهادی

استاندارد JavaScript - بخش اول

JavaScript از یک شوخی تبلیغاتی در سال 1995 برای به دست آوردن برتری تاکتیکی، به یک تجربه برنامه‌نویسی هسته‌ای در پس استفاده‌ترین پلتفرم برنامه در سال 2...

وب سایت های الهام بخش برای طراحی - سری هفتم

امروز قصد داریم یک سری وبسایت های خارجی که بطور کاربردی ، زیبا و قدرتمند طراحی شدن رو براتون قرار بدیم تا شما بتونین با طریقه طراحی اونها آشنا بشین یا...

وب سایت های الهام بخش برای طراحی - سری ششم

امروز قصد داریم یک سری وبسایت های خارجی که بطور کاربردی ، زیبا و قدرتمند طراحی شدن رو براتون قرار بدیم تا شما بتونین با طریقه طراحی اونها آشنا بشین یا...

10 طراحی مناسب از سربرگ و پابرگ وبسایت - بخش دوم

در بخش اول این مطلب ۵ سربرگ بسیار کاربردی و مفید را بررسی کردیم، حال در این بخش قصد داریم تا ۵ پابرگ یا Footer مناسب برای وبسایت را نیز بررسی نماییم.