گلوگاه جاوااسکریپت و نیاز به عملکرد بومی
فراگیر شدن وب در دهه گذشته، تقاضا برای اجرا در محیطهای مرورگر را به شدت افزایش داد. برنامههای حسگرهای پیچیده، ادیتورهای ویدیویی تحت وب، و موتورهای بازیسازی به پردازش سمت کلاینت نیاز داشتند. اما جاوااسکریپت، به عنوان تنها زبان بومی این محیط، در برابر کدهای بهینهشده برای معماریهای سختافزاری محدودیتهای واضحی نشان میداد. سرعت تفسیر، مدیریت حافظه پویا، و نبود دسترسی مستقیم به CPU، اجرای پروژههای سنگین را با کندی مواجه میکرد.
این معضل، موجی از تلاشها را در اواسط دهه 2010 ایجاد کرد. مهندسان به سمت رویکرد کامپایل به جاوااسکریپت حرکت کردند. در این مدل، کدهای نوشتهشده به زبانهای دیگر در سمت سرور به جاوااسکریپت ترجمه میشدند تا در مرورگر قابل اجرا باشند. این روش اگرچه راهگشا بود، اما همواره با هزینههای بالای حجم فایل و افت قابلتوجه عملکرد همراه بود.
asm.js: آزمایشی که استانداردهای مرورگر را تغییر داد
در مارس 2013، تیمی از مهندسان موزیلا به رهبری لوک واگنر و آلن زاکای، ایدهای رادیکال را معرفی کردند. آنها زیرمجموعهای جدید از جاوااسکریپت را با نام asm.js تعریف کردند که در آن، نویسنده کد بهصورت ضمنی اطلاعات نوع ایستا (Static Type) فراهم میکرد. به دلیل ساختار سفتوسخت این زیرمجموعه، بهینهسازهای موتورهای مرورگر میتوانستند به راحتی کد را شناسایی و آن را به کدهای ماشین بهینه کنند.
واگنر خود این روش را یک «آزمایش بیشازحد دستودلبازانه» توصیف کرد. با این حال، نتایج شگفتانگیز بودند. کدهای C و C++ میتوانستند با سرعتی نزدیک به اجرای بومی در مرورگر اجرا شوند. استفاده از ابزار زنجیرهای Emscripten در کنار asm.js، دروازهای را برای توسعهدهندگان بازی و نرمافزارهای مهندسی گشود. اما در ذات خود، این راهحل همچنان روی سینههای جاوااسکریپت سوار بود و به یک پلتفرم مستقل تبدیل نشده بود.
پل زدن بین رقبای مرورگر و تولد وباسمبلی
همزمان با تلاشهای موزیلا، گوگل مسیری متفاوت را در پیش گرفت. پروژههای Native Client و PNaCl برای اجرای کد بومی در کروم طراحی شده بودند. ژان-فرانسوا باستین، از توسعهدهندگان ارشد کروم، اشاره میکند که PNaCl اگرچه محیطی امن و ایزوله (Sandbox) فراهم میکرد، اما در تعامل با مدل برنامهنویسی وب دچار مشکل بود. وابستگی شدید به APIهای پیامرسان غیرهمگام (Asynchronous)، دسترسی به گرافیک و صدا را پیچیده میکرد و این فناوری را از روح اصلی وب فاصله میداد.
نقطه عطف زمانی رقم خورد که مهندسان ارشد موزیلا، گوگل، اپل و اینتل در جلسات فنی مشترک گرد هم آمدند. آنها دریافتند که تداوم رقابت روی روشهای غیرسازگار، تنها منجر به تجزیه اکوسیستم وب خواهد شد. ایده مشترک شکل گرفت: نیاز به یک فرمت باینری جدید که نه توسط انسان نوشته شود و نه در قالب جاوااسکریپت باشد. فرمتی که امنیت محیط اجرایی وب را حفظ کند، مستقیماً توسط موتورهای مرورگر تفسیر شود و به سرعت در کنار جاوااسکریپت اجرا گردد.
وباسمبلی: بایتکدی مشترک و آیندهمحور
خروجی این همکاری، مشخصات وباسمبلی (WebAssembly) بود که اولین نسخه آن در سال 2015 منتشر شد و در نهایت در دسامبر 2019 به عنوان استاندارد رسمی کنسرسیوم وب (W3C) پذیرفته شد. در این معماری، کامپایلرهای سطح بالا (مانند Rust، Go و C++) کد خود را به یک فرمت باینری متراکم تبدیل میکنند. این بایتکد مستقیماً در محیط مرورگر بارگذاری شده و به عنوان یک همنشین قدرتمند برای جاوااسکریپت عمل میکند. جاوااسکریپت همچنان مدیریت DOM و رویدادها را بر عهده دارد و وباسمبلی محاسبات سنگین پردازشی را انجام میدهد.
امروز، وباسمبلی از مرزهای مرورگر عبور کرده است. با معرفی رابط سیستمی وباسمبلی (WASI)، این بایتکد توانسته است در سرورها، محیطهای ابری، دستگاههای تعبیهشده و حتی استنتاج مدلهای هوش مصنوعی در لبه شبکه (Edge) اجرا شود. ادوبی، فیگما، گوگل و مایکروسافت سالانه میلیاردها دلار را صرف بهینهسازی ابزارهای این استاندارد میکنند تا تجربه کاربری وب به سطح برنامههای دسکتاپ نزدیک شود.
چشمانداز تکنولوژی در دهه آینده
وباسمبلی دیگر یک پروژه آزمایشی مرورگر نیست. این استاندارد به یک هسته رایانش مشترک تبدیل شده که پلتفرمهای مختلف را به یک سینک میرساند. پیشرفتهای اخیر در پشتیبانی از SIMD و Threadها، پتانسیل اجرای همزمان محاسبات موازی را در محیطهای امن فراهم کرده است. آینده این فناوری احتمالاً به سمت یکپارچهسازی کامل با سیستمعاملهای متنباز و محیطهای مجازیسازی پیش میرود به طوری که مرزهای بین وب، اپلیکیشن نیتیو و سرور به تدریج محو خواهد شد.
