WebAssembly از مرورگر خارج شد. حالا داخل Shopify، Cloudflare و کلاستر Kubernetes شما اجرا می‌شه

WebAssembly در سال ۲۰۱۷ به عنوان راه‌حلی برای یک مشکل مرورگر متولد شد: JavaScript برای کدهای حیاتی از نظر عملکرد کند بود و پلاگین‌های بومی هم خطرناک. پاسخ یک فرمت باینری فشرده بود که می‌تونست کد نزدیک به بومی را داخل یک محیط sandbox شده در مرورگر اجرا کنه — امن، قابل حمل و سریع. جواب داد. ویرایشگرهای ویدیو، ابزارهای CAD و شبیه‌سازی‌های علمی به وب نقل مکان کردند. عملکرد Figma سه برابر بهتر شد وقتی موتور رندر خود را به C++ که به WASM کامپایل شده بود منتقل کرد.

بعد یه اتفاق غیرمنتظره افتاد. مهندس‌ها شروع کردند به این سوال که آیا یک فرمت باینری سریع، sandbox شده و مستقل از زبان می‌تونه جایی غیر از مرورگر هم مفید باشه. جواب بله بود و اکوسیستمی که دور این جواب ساخته شده حالا به اندازه کافی بالغ شده تا در تولید استفاده بشه.

Component Model: قطعه گمشده‌ای که رسید

مشخصات اولیه WebAssembly یک محدودیت اساسی برای استفاده سمت سرور داشت: دو ماژول WASM که از زبان‌های مختلف کامپایل شده بودند نمی‌تونستند بدون کد چسب مدیریت حافظه دستی و مستعد خطا با هم ارتباط برقرار کنند. یک کتابخانه Rust و یک سرویس Go در فضاهای حافظه جداگانه زندگی می‌کردند و هیچ سیستم نوع مشترکی نداشتند. این موضوع معماری‌های polyglot قابل ترکیب را غیرعملی می‌کرد.

Component Model WebAssembly که در سال ۲۰۲۵ تثبیت شد، این مشکل را با یک رابط باینری مشترک (ABI) و یک زبان توصیف رابط مستقل از زبان به نام WIT حل می‌کند. یک فایل WIT اعلام می‌کند که یک کامپوننت چه توابع و نوع داده‌هایی را صادر یا وارد می‌کند، بدون فرضیات حافظه‌ای وابسته به زبان. ابزارها — wit-bindgen، wasm-tools، jco — کد یکپارچه‌سازی را به طور خودکار تولید می‌کنند. نتیجه عملی: یک parser پرسرعت Rust، یک pipeline یادگیری ماشین پایتون و یک frontend تایپ‌اسکریپت می‌توانند به عنوان کامپوننت‌های WASM بدون نیاز به FFI دست‌نویس ترکیب شوند. WASM 3.0 در سپتامبر ۲۰۲۵ به عنوان استاندارد W3C تصویب شد که garbage collection، حافظه ۶۴ بیتی، SIMD منعطف و exception handling را همراه با Component Model شامل می‌شود.

WASI: لایه واسطی که قابلیت حمل را واقعی می‌کند

اجرای WASM خارج از مرورگر نیاز به راهی دارد که ماژول با سیستم میزبان تعامل کند — خواندن فایل‌ها، باز کردن سوکت‌های شبکه، نوشتن روی خروجی استاندارد. رابط سیستمی WebAssembly (WASI) این APIها را در یک مدل امنیتی مبتنی بر capability تعریف می‌کند: یک ماژول فقط دسترسی‌ای را دریافت می‌کند که در زمان instantiation به صراحت به آن اعطا شده باشد. هیچ چیز دیگری قابل دسترس نیست.

WASI 0.2 که در ژانویه ۲۰۲۴ منتشر شد، پایه تولید پایدار را قفل کرد — I/O فایل، سوکت‌های شبکه و یکپارچه‌سازی با Component Model. WASI 0.3 که پشتیبانی بومی async با stream و primitiveهای future را اضافه می‌کند، در اوایل ۲۰۲۶ در حال تکمیل کارهای مشخصات بود. نسخه ۱.۰ — اولین انتشار «پایدار برای همیشه» — برای اواخر ۲۰۲۶ یا اوایل ۲۰۲۷ برنامه‌ریزی شده. این مسیر به نویسندگان کتابخانه یک ABI پایدار برای هدف‌گیری می‌دهد و به اپراتورها یک نقشه راه روشن برای آنچه تضمین‌های قابلیت حمل نهایتاً پوشش خواهند داد.

محل استقرارهای تولیدی در حال حاضر

بارزترین نمونه در مقیاس بزرگ Shopify Functions است. از سال ۲۰۲۲، Shopify به توسعه‌دهندگان شخص ثالث اجازه داده منطق checkout، تخفیف و حمل‌ونقل را با استقرار ماژول‌های WASM که داخل یک runtime اختصاصی در زیرساخت Shopify اجرا می‌شوند سفارشی کنند. هر ماژول در یک بودجه ۵ میلی‌ثانیه‌ای سخت اجرا می‌شود؛ تأخیرهای اندازه‌گیری شده واقعی معمولاً بین ۰.۸ تا ۲.۵ میلی‌ثانیه است. توسعه‌دهندگان به زبان‌های Rust، جاوااسکریپت (از طریق کامپایلر Javy شاپیفای که یک موتور V8 لختی را در یک باینری WASM بسته‌بندی می‌کند)، Zig یا TinyGo می‌نویسند. مرز امنیتی مهم است: کد تجاری غیرقابل اعتماد در تولید با مقیاس Shopify بدون دسترسی به منابع سیستم میزبان اجرا می‌شود. هیچ فرار از sandbox رخ نداده. تا ژوئن ۲۰۲۶، سیستم قدیمی Scripts که Functions جایگزین آن شد کاملاً بازنشسته شده است.

در سمت edge computing، Compute@Edge فستلی یک محیط اجرایی خالص WASM است که cold starts میکروثانیه‌ای برای پردازش درخواست در لبه شبکه ارائه می‌دهد. Cloudflare Workers از ماژول‌های WASM پشتیبانی می‌کند و در ژوئن ۲۰۲۵ پشتیبانی Container را برای بارهای کاری ترکیبی اضافه کرد. مهمترین سیگنال صنعت در اواخر ۲۰۲۵ زمانی رخ داد که Akamai شرکت Fermyon — شرکت پشت فریم‌ورک Spin برای میکروسرویس‌های WASM بدون سرور — را خرید و Fermyon Wasm Functions را در نوامبر ۲۰۲۵ به صورت عمومی در edge توزیع شده جهانی Akamai در دسترس قرار داد. وقتی بزرگترین CDN روی کره زمین یک شرکت WASM بدون سرور را خریداری می‌کند، شرط بندی روی آینده فناوری نهادی است، نه آزمایشی.

چشم‌انداز runtimes

چهار runtime برای موارد استفاده مختلف غالب هستند. Wasmtime، پیاده‌سازی مرجع از Bytecode Alliance، در آوریل ۲۰۲۵ وضعیت Core Project را به دست آورد و حدود ۸۲٪ عملکرد بومی را در بنچمارک‌های محاسباتی ارائه می‌دهد. این انتخاب پیش‌فرض برای WASM سمت سرور با اهداف عمومی است. Wasmer 6.0 که در آوریل ۲۰۲۵ منتشر شد، ادعای ۹۵٪ عملکرد بومی دارد و Edge.js را معرفی کرد که برنامه‌های Node.js را داخل یک sandbox WASM اجرا می‌کند — پل جالبی برای تیم‌هایی با زیرساخت Node موجود. WAMR (WebAssembly Micro Runtime) دستگاه‌های embedded و IoT را هدف می‌گیرد و روی سخت‌افزار با حداقل ۲۵۶ کیلوبایت حافظه با ۸۰ تا ۹۰٪ عملکرد بومی با کامپایل AOT اجرا می‌شود. WasmEdge برای بارهای کاری AI بهینه شده و با Docker Engine به عنوان یک shim کانتینر در کنار Wasmtime یکپارچه می‌شود.

چارچوب‌بندی Docker عمدی است: «WASM و کانتینرها» نه «WASM در مقابل کانتینرها». Docker Engine شیم‌های بومی برای Wasmtime و WasmEdge ارائه می‌دهد، بنابراین ماژول‌های WASM را می‌توان با دستورات استاندارد docker run از یک Dockerfile scratch مستقر کرد. ابزارها همگرا می‌شوند، نه رقابت. SpinKube، یک پروژه CNCF که روی فریم‌ورک Spin فرمیون ساخته شده، WASM را به یک نوع بار کاری درجه یک در Kubernetes تبدیل می‌کند — قابل استقرار در کنار podهای کانتینری با همان primitives orchestration.

بحث امنیتی

مدل امنیتی WASM «رد پیش‌فرض» در سطح باینری است. یک ماژول هیچ دسترسی به سیستم میزبان ندارد مگر اینکه میزبان یک capability خاص را در زمان instantiation به صراحت اعطا کند. این از نظر معماری با کانتینرها متفاوت است که هسته میزبان را به اشتراک می‌گذارند و برای محدود کردن دسترسی بار کاری به namespace و cgroup isolation متکی هستند. در WASM، sandbox در runtime اجرا می‌شود، صرف‌نظر از زبانی که ماژول از آن کامپایل شده است.

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

تصویر عملکرد صادقانه

WASM روی runtimes سمت سرور حدود ۷۵ تا ۹۵٪ سرعت بومی را در بارهای کاری محاسباتی دارد — اعداد معتبر برای بیشتر موارد استفاده، با ملاحظات. عملیات شامل اعداد صحیح ۱۲۸ بیتی و برخی primitives رمزنگاری ۲ تا ۷ برابر کندتر از بومی هستند. بارهای کاری I/O-bound هیچ مزیت معناداری نمی‌بینند؛ مزیت در محاسبه است. Cold starts ۱ تا ۵ میلی‌ثانیه هستند در مقایسه با ۵۰ تا ۵۰۰ میلی‌ثانیه برای کانتینرها — این عددی است که WASM را برای استقرارهای بدون سرور و edge جذاب می‌کند جایی که تأخیر cold start مستقیماً روی تجربه کاربری تأثیر می‌گذارد.

زمان توسعه واقعاً طولانی‌تر است. ساختن در Rust برای WASM نیاز به درک مدیریت حافظه و یک گردش کار debug متفاوت از چیزی دارد که بیشتر توسعه‌دهندگان وب دارند. Component Model و ابزارهای WASI به طور قابل توجهی بهبود یافته‌اند اما debug در سراسر مرز زبان همچنان سخت‌تر از debug درون یک stack تک‌زبان است. اکوسیستم تقریباً جایی است که JavaScript در سال‌های اولیه Node.js بود: قدرتمند، پربازده و نیازمند سرمایه‌گذاری برای استفاده خوب.

سوال «آیا باید به جای کانتینر از WASM استفاده کنم؟» در سال ۲۰۲۶ پاسخ تمیزتری نسبت به دو سال پیش دارد: از WASM استفاده کنید وقتی تأخیر cold start مهم است (edge و serverless)، وقتی نیاز به اجرای sandbox شده کد غیرقابل اعتماد دارید، یا وقتی ترکیب کامپوننت مستقل از زبان می‌خواهید. از کانتینرها استفاده کنید وقتی به یک محیط کامل لینوکس، سازگاری گسترده کتابخانه یا دسترسی GPU نیاز دارید. از هر دو استفاده کنید وقتی بار کاری شما لایه‌هایی دارد که از هرکدام سود می‌برند — که به طور فزاینده همان چیزی است که ابزارهای زیرساخت برای پشتیبانی از آن طراحی شده‌اند.