وباسمبلی از مرورگر فرار کرد. در سال ۲۰۲۶، بی‌سروصدا در حال تبدیل شدن به Runtime همه‌چیز است.

وقتی وباسمبلی در سال ۲۰۱۷ عرضه شد، توضیح آن ساده بود: یک فرمت دستورالعمل باینری که مرورگرهای وب می‌توانستند آن را با سرعت نزدیک به بومی اجرا کنند و برنامه‌هایی را ممکن می‌ساخت که جاوااسکریپت به تنهایی از عهده آن برنمی‌آمد. فیگما موتور رندر خود را به WASM منتقل کرد و نرم‌افزار طراحی پیچیده را در مرورگر عملی ساخت. AutoCAD Web از آن برای اجرای کد C++ قدیمی بدون بازنویسی استفاده کرد. مورد استفاده در مرورگر واقعی بود و فناوری نتیجه داد.

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

چگونه WASM از Sandbox خارج شد

تحول کلیدی WASI بود — رابط سیستم وباسمبلی که بوسیله Bytecode Alliance در سال ۲۰۱۹ پیشنهاد شد و در سال ۲۰۲۴ به مشخصات پایدار ۲.۰ رسید. WASI به ماژول‌های وباسمبلی یک رابط استاندارد برای تعامل با سیستم میزبان داد: خواندن فایل‌ها، برقراری اتصالات شبکه، دسترسی به متغیرهای محیطی. این موضوع پیش پا افتاده به نظر می‌رسد، اما پیامد عمیقی داشت: یک ماژول WASM که با پشتیبانی WASI کامپایل شده باشد، می‌تواند در هر جایی که یک WASI runtime وجود دارد اجرا شود — نه فقط در مرورگر، بلکه روی سرور، در لبه شبکه، روی یک دستگاه IoT، در موتور پایگاه داده.

سلیمان هایکس، خالق Docker، اهمیت این موضوع را در پستی که به طور گسترده نقل شد، به وضوح بیان کرد: "اگر WASM+WASI در سال ۲۰۰۸ وجود داشت، نیازی به ایجاد Docker نداشتیم. این نشان می‌دهد که چقدر مهم است." وعده یک باینری قابل حمل همگانی بود — یک بار کامپایل کنید، همه جا اجرا کنید، با یک Sandbox امنیتی داخلی.

WASM در سال ۲۰۲۶ در کجا اجرا می‌شود

Edge computing و توابع بدون سرور. Cloudflare Workers از سال ۲۰۱۸ از WASM پشتیبانی می‌کند، اما در سال ۲۰۲۶ این runtime اصلی برای توابع حساس به عملکرد در لبه شبکه است. Fastly Compute، Fermyon Spin و Wasmer Edge همگی بارهای کاری WASM را در گره‌های توزیع‌شده در لبه شبکه اجرا می‌کنند. جذابیت آن ترکیبی از زمان راه‌اندازی (شروع سرد زیر میلی‌ثانیه، در مقابل ۵۰ تا ۲۰۰ میلی‌ثانیه برای یک تابع Node.js)، ایزولاسیون امنیتی (هر ماژول در Sandbox خود با مجوزهای صریح اجرا می‌شود) و قابلیت حمل (استقرار همان باینری در هر ارائه‌دهنده) است.

قابلیت توسعه پایگاه داده. SingleStore، DuckDB و چندین پایگاه داده دیگر اکنون از توابع تعریف‌شده توسط کاربر که به عنوان ماژول‌های WASM نوشته شده‌اند پشتیبانی می‌کنند. این امکان به منطق سفارشی اجازه می‌دهد تا در داخل موتور query با دسترسی به عملیات‌های برداری و بدون سربار رفت‌و برگشت به یک فرآیند خارجی اجرا شود. پشتیبانی از WASM UDF در PostgreSQL، که در سال ۲۰۲۵ پایدار شد، این قابلیت را برای پرکاربردترین پایگاه داده منبع‌باز در جهان باز کرد.

سیستم‌های پلاگین. Zed (ویرایشگر کد)، Extism (یک فریم‌ورک پلاگین که توسط ده‌ها اپلیکیشن استفاده می‌شود) و تعداد فزاینده‌ای از ابزارهای توسعه‌دهنده از WASM به عنوان runtime پلاگین خود استفاده می‌کنند. مزیت نسبت به سیستم‌های پلاگین سنتی بومی، ایزولاسیون است: یک پلاگین بدرفتار نمی‌تواند فرآیند میزبان را کرش کند یا به منابع خارج از مجوزهای خود دسترسی پیدا کند. این مدلی است که Shopify برای برنامه‌های افزودنی سفارشی خود و Figma برای اکوسیستم پلاگین خود استفاده می‌کند.

CLIهای قابل حمل و ابزارها. مدل کامپوننت WASM (استاندارد شده در سال ۲۰۲۴) امکان ترکیب‌پذیری را فراهم کرد: می‌توان یک ابزار CLI را به عنوان مجموعه‌ای از کامپوننت‌های WASM که رابط‌های تایپ‌شده را ایمپورت و اکسپورت می‌کنند، ساخت و سپس آن‌ها را بدون توجه به زبانی که در ابتدا در آن نوشته شده‌اند، کنار هم قرار داد. یک کامپوننت Rust می‌تواند رابط یک کامپوننت Python را فراخوانی کند بدون اینکه هیچ‌کدام از زبان پیاده‌سازی دیگری بداند. این امکان نسل جدیدی از ابزارهای مستقل از زبان را فراهم می‌کند.

مدل کامپوننت محاسبات را تغییر می‌دهد

مدل کامپوننت WASM شایسته توجه ویژه است زیرا مشکلی را حل می‌کند که دهه‌ها نرم‌افزارهای چندزبانه را آزار داده است. قبلاً، اگر می‌خواستید یک کتابخانه نوشته شده در Rust را از Python فراخوانی کنید، باید با FFI، حافظه مشترک، سربار سریال‌سازی یا فراخوانی زیرفرآیند دست و پنجه نرم می‌کردید. مدل کامپوننت همه این موارد را با یک زبان تعریف رابط (WIT — WebAssembly Interface Types) ایمن از نظر نوع و مستقل از زبان جایگزین می‌کند که کامپایلرهای Rust، Python، JavaScript، Go، C و دیگران می‌توانند آن را هدف قرار دهند.

نتیجه این است که یک توسعه‌دهنده می‌تواند یک کتابخانه پردازش رشته با کارایی بالا در Rust بنویسد، آن را به عنوان یک کامپوننت WASM با یک رابط WIT تایپ‌شده expose کند و از Python بدون boilerplate FFI فراخوانی کند. باینری در یک Sandbox اجرا می‌شود، رابط در مرز بررسی نوع می‌شود و همان کامپوننت در همه جاهایی که runtime WASM وجود دارد کار می‌کند.

چه چیزی هنوز کم است

رشد WASM خارج از مرورگر با محدودیت‌های واقعی همراه است. پشتیبانی از Garbage Collection تنها در سال ۲۰۲۴ به وضعیت پایدار رسید که قبلاً آن را برای زبان‌هایی مانند Python و Java که به GC وابسته هستند، ناخوشایند می‌کرد. Threads و حافظه مشترک کار می‌کنند اما نکات احتیاطی در مورد عملیات‌های اتمی دارند که در پلتفرم‌های مختلف متفاوت است. داستان ابزارها به طور چشمگیری بهبود یافته است — wasm-pack، cargo-component و componentize-py همه وجود دارند — اما تجربه هنوز از نظر دیباگ، پروفایلینگ و پیام‌های خطا از توسعه بومی عقب است.

عملکرد برای کارهای محدود به CPU نزدیک به بومی است اما برای بارهای کاری که به شدت به سرویس‌های سیستم عامل وابسته هستند، اینگونه نیست: I/O فایل از طریق WASI کندتر از حالت بومی است و مجوزهای امنیتی مدل قابلیت در مقایسه با فراخوانی مستقیم سیستم، سربار اضافه می‌کند. برای مسیرهای حساس به تاخیر، این شکاف‌ها اهمیت دارند.

مسیر حرکت

خط روند واضح است. Wasmtime (توسط Bytecode Alliance نگهداری می‌شود) در حال تعبیه شدن در همه چیز از ارائه‌دهندگان ابری گرفته تا ابزارهای CLI و پایگاه‌های داده است. مدل کامپوننت سریع‌تر از هر مشخصات قبلی WASM در حال پذیرش است. فروشندگان مرورگر در مورد ویژگی‌های آینده از جمله Garbage Collection، Stack Switching برای Coroutines و بهبود مدیریت استثنا همسو هستند.

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