WebAssembly چیست؟ معماری، کارایی، امنیت و WASI

WebAssembly دکمهٔ «سریع‌ترش کن» نیست. یک Loop عددی می‌تواند از آن سود ببرد، اما همان برنامه ممکن است به‌دلیل فایل بزرگ، کپی میان JavaScript و حافظهٔ Wasm، کار روی Main thread یا فراخوانی‌های ریزِ مرزی کندتر شود. Sandbox نیز به معنی «کد امن» نیست؛ Host import پرقدرت، Dependency آلوده یا مصرف بی‌حد CPU همچنان ریسک می‌سازد.

این راهنما WebAssembly یا Wasm را از تعریف تا تصمیم معماری توضیح می‌دهد: Core module، JavaScript API، حافظه و Thread، WASI ۰.۳، Component Model، امنیت، Performance budget، Deploy و Proof of Concept. وضعیت استانداردها و ابزارها در ۱۵ مرداد ۱۴۰۵ / ۶ اوت ۲۰۲۶ بازبینی شده است؛ پشتیبانی Runtime و مرورگر را هنگام اجرا دوباره کنترل کنید.

پاسخ کوتاه: WebAssembly چیست؟

WebAssembly یک قالب کد سطح‌پایین، قابل‌حمل و فشرده با نمایش باینری .wasm و نمایش متنی WAT است. Module پس از Decode و Validation در یک Host مانند مرورگر یا Runtime مستقل Instantiate می‌شود. Wasm خودِ DOM، فایل، Socket یا سیستم‌عامل را تعریف نمی‌کند؛ تعامل با بیرون فقط از طریق Importهایی است که Host در اختیار آن می‌گذارد.

توسعه‌دهنده معمولاً C/C++، Rust، C#، Go یا زبان دیگری را به Wasm کامپایل می‌کند. JavaScript در وب می‌تواند Module را Load و Exportهای آن را فراخوانی کند. انتخاب خوب زمانی است که Workload قابل‌پروفایل، محاسباتی یا کتابخانهٔ قابل‌استفادهٔ مجدد دارید؛ نه صرفاً چون Wasm «نزدیک Native» توصیف می‌شود.

Snapshot استانداردها در اوت ۲۰۲۶

Core WebAssembly 3.0

سند جاری W3C برای Core WebAssembly نسخهٔ ۳.۰ را در ۲۷ مهٔ ۲۰۲۶ به‌صورت Candidate Recommendation Draft توصیف می‌کند. Working Group آن را به‌شکل Candidate Recommendation زنده نگه می‌دارد؛ بعضی بخش‌ها می‌توانند تغییر کنند. Core ۳.۰ مفاهیمی مانند Vector، Reference/Heap type، Exception، Memory و Module را پوشش می‌دهد، اما Web API یا دسترسی سیستم را تعریف نمی‌کند.

WASI 0.3

طبق صفحهٔ رسمی Releaseهای WASI، WASI ۰.۳ Stable است و Native async را با async func، stream<T> و future<T> به Component Model می‌آورد. نسخه ۰.۲ نیز Stable و ۰.۱ Legacy است؛ اما خود مستند می‌گوید ۰.۱ در Runtimeهای بیشتری به‌طور عملی پشتیبانی می‌شود. «Stable» را با «همه‌جا نصب است» یکی نگیرید.

Component Model

Component Model روی Core module لایه می‌سازد تا Typeهای غنی، Interfaceهای WIT و Composition میان زبان‌ها فراهم شود. Component و Core module فرمت یکسانی نیستند و Toolchainها سطح حمایت متفاوت دارند. برای Production، نسخهٔ Runtime، Target، Adapter و Interface را Pin و Compatibility test کنید.

Feature Status رسمی WebAssembly وضعیت Proposalها را بر Browser، Runtime و Tool نشان می‌دهد. نام Feature در Roadmap به معنی قابل‌استفاده‌بودن همگانی نیست؛ Stage، Engine و Version را ثبت کنید.

پنج لایه‌ای که نباید با هم اشتباه شوند

کدی که برای wasm32-unknown-unknown و Web API ساخته شده، لزوماً Component سازگار با WASI ۰.۳ نیست. «خروجی Wasm» فقط Format را می‌گوید؛ Target، ABI، Importها و Runtime تعیین می‌کنند کجا اجرا شود.

داخل یک Core module چیست؟

• Function: کد با پارامتر و نتیجهٔ Typeشده؛
• Linear memory: آرایهٔ پیوستهٔ Byte برای داده؛
• Table: مجموعهٔ Referenceها برای Call غیرمستقیم و سناریوهای دیگر؛
• Global: مقدار Mutable یا Immutable؛
• Import: Capability یا Function ارائه‌شده از Host؛
• Export: Function/Memory/Table/Global قابل‌مصرف؛
• Custom section: Metadata مانند Name یا اطلاعات Toolchain.

سه فاز مفهومی مهم‌اند: Decode، Validation و Execution. Execution نیز شامل Instantiation و Invocation است. Validation Type و ساختار را کنترل می‌کند؛ درستی Business logic، مجوز داده و کیفیت Algorithm را ثابت نمی‌کند.

چرخهٔ اجرا در مرورگر

1. Source با Target و Feature مشخص Build می‌شود.
2. Bundler یا Server فایل Wasm و Glue لازم را منتشر می‌کند.
3. Browser Response را Fetch می‌کند.
4. Module Decode، Validate و Compile می‌شود.
5. با Import object یا Wrapper Instantiate می‌شود.
6. JavaScript Export را فراخوانی و داده ردوبدل می‌کند.
7. Output در DOM، Canvas، WebGL/WebGPU، Audio یا Worker مصرف می‌شود.

مستند MDN برای WebAssembly.instantiateStreaming() این API را مسیر بهینهٔ Streaming می‌داند و تأکید می‌کند Response فایل باید MIME صحیح application/wasm داشته باشد. CSP سخت‌گیرانه نیز می‌تواند Compile/Execution را مسدود کند.

const imports = {
  host: {
    log_i32(value) {
      console.log(value);
    },
  },
};

async function loadCalculator() {
  const response = await fetch("/assets/calculator.v3.wasm", {
    credentials: "same-origin",
  });

  if (!response.ok) {
    throw new Error(`Wasm download failed: ${response.status}`);
  }

  const { instance, module } =
    await WebAssembly.instantiateStreaming(response, imports);

  return { api: instance.exports, module };
}

این مثال Production کامل نیست: Timeout، Abort، Feature detection، Error telemetry، Version، Integrity strategy و Fallback باید بر اساس Risk اضافه شوند. Compile/Link/Runtime error را جدا ثبت کنید.

WebAssembly یا JavaScript؟ مسئله را درست قاب بگیرید

JavaScript امروز JIT، TypedArray، Worker، WebGL/WebGPU و اکوسیستم بالغ دارد. Wasm نیز Compiler optimization و Typeهای سطح‌پایین دارد. فقط Benchmark همان Algorithm با ورودی و Device واقعی تصمیم می‌دهد.

چه زمانی WebAssembly انتخاب خوبی است؟

• Bottleneck با Profiler داخل محاسبهٔ CPU دیده شده است.
• Library بومی بالغ دارید و Port کامل JavaScript پرهزینه است.
• ورودی بزرگ را یک‌بار وارد و چند عملیات سنگین اجرا می‌کنید.
• خروجی کوچک است و Boundary chatty نیست.
• تأخیر Server یا Privacy انتقال داده، پردازش Client را توجیه می‌کند.
• Plugin isolation یا Portability میان Runtimeها ارزش محصول دارد.
• تیم Toolchain، Memory، Debug و Security آن را مالک می‌شود.

چه زمانی استفاده نکنیم؟

• هیچ Baseline یا Bottleneck اندازه‌گیری‌شده ندارید.
• بیشتر زمان در DOM، Network، Database یا Third-party می‌گذرد.
• فایل و Runtime لازم، Startup روی موبایل را بدتر می‌کند.
• داده در هر Frame چند بار بین JS و Wasm کپی می‌شود.
• Team bus factor یک است و On-call/Debug plan ندارید.
• Browser/Runtime هدف Feature لازم را پشتیبانی نمی‌کند.
• Fallback و Progressive enhancement ممکن نیست و Reach حیاتی است.

انتخاب زبان و Toolchain

«Rust بهترین زبان Wasm است» حکم عمومی نیست. Library موجود، Skill تیم، Debugging، ABI، Binary size، License، Runtime target و Long-term maintenance را Score کنید. مستندات قدیمی Tutorial را منبع وضعیت ابزار امروز ندانید.

مرز JavaScript و Wasm؛ جایی که Performance گم می‌شود

Core Wasm Typeهای پایه و Reference دارد، اما String، Object و Collection زبان‌ها نیازمند Convention، Glue یا Component ABI هستند. عبور داده می‌تواند Allocation، Encoding، Copy و Serialization بسازد.

اصول Interface کم‌هزینه

• Callهای ریز در Loop را Batch کنید.
• دادهٔ بزرگ را در یک سمت نگه دارید و Handle بدهید.
• ورودی/خروجی را Flat و Versioned کنید.
• مالکیت Buffer، Lifetime و Error را Contract کنید.
• Copy byte و Allocation count را اندازه بگیرید.
• Boundary را برای Correctness تست کنید، نه فقط Throughput.

مثلاً به‌جای فراخوانی تابع Wasm برای هر Pixel، Buffer تصویر را یک‌بار در Memory قرار دهید، Operation را Batch و نتیجهٔ کوچک یا همان Buffer را بازگردانید. Zero-copy ادعای پیش‌فرض نیست؛ از Profiler اثبات کنید.

Linear memory، GC و Memory growth

Linear memory یک فضای Byte مجزا با Bound check در مرز Region است. این مدل جلوی خروج مستقیم از حافظهٔ Module را می‌گیرد، اما C/C++ ناامن هنوز می‌تواند Objectهای مجاور داخل همان Linear memory را خراب کند. Memory-safe در سطح Sandbox با Memory-safe بودن Source program یکی نیست.

• Initial و Maximum memory را آگاهانه تعیین کنید.
• رشد Memory و Peak RSS را روی Device ضعیف اندازه بگیرید.
• Allocation hot path و Fragmentation را Profile کنید.
• Buffer پس از memory.grow() می‌تواند نیازمند Refresh view باشد.
• GC proposal وجود دارد، اما Language/runtime و Browser matrix تعیین می‌کند چگونه استفاده شود.
• Memory64 یا Multi-memory را فقط با Feature detection و نیاز واقعی فعال کنید.

Thread، SIMD و Worker

SIMD برای Vectorizable workload مفید است؛ Thread برای Parallelizable workload. هیچ‌کدام Latency شبکه یا DOM را درمان نمی‌کند. Thread در وب معمولاً با Worker و Shared memory همراه است.

راهنمای MDN برای COEP توضیح می‌دهد قابلیت‌هایی مانند SharedArrayBuffer به Cross-origin isolation نیاز دارند؛ معمولاً COOP same-origin و COEP require-corp یا credentialless. این Headerها می‌توانند Embed، Popup، Asset ثالث و Integration پرداخت را تغییر دهند. در Report-only/محیط آزمایشی Inventory کامل بگیرید.

مدل Performance؛ فقط Runtime را نسنجید

Total user latency = Download + Decode/Compile + Instantiate + Data transfer + Compute + Render

Wasm ممکن است Compute را ۴۰٪ کم کند اما Download را ۸۰۰ ms بالا ببرد؛ کاربر اولین نتیجه را دیرتر می‌بیند. Cold و Warm را جدا اندازه بگیرید.

برای LCP، INP، CLS، RUM و Performance budget، راهنمای Core Web Vitals را به Pilot وصل کنید. Runtime benchmark روی لپ‌تاپ توسعه، تجربهٔ موبایل کاربر ایرانی نیست.

طراحی Benchmark منصفانه

1. Question را بنویسید: Latency، Throughput، Startup یا Size؟
2. نسخه‌های Release/Optimized و Algorithm هم‌ارز بسازید.
3. I/O، Validation و Error handling یکسان باشد.
4. ورودی کوچک/متوسط/بزرگ و بدترین حالت واقعی را پوشش دهید.
5. Cold/Warm، Cache hit/miss و Device tier را جدا کنید.
6. Boundary و Render را داخل End-to-end اندازه بگیرید.
7. Confidence interval، Regression و Raw artifact را نگه دارید.
8. نتیجه را به همان Workload محدود کنید.

Microbenchmark یک Function ممکن است نتیجهٔ Product را وارونه نشان دهد. PoC باید JavaScript baseline، Wasm variant و در صورت ارتباط Worker/GPU variant را مقایسه کند.

Binary size، Streaming و Cache

• Release build و Optimization هدف Size/Speed را آگاهانه انتخاب کنید.
• Debug symbol را از Artifact عمومی جدا و در Symbol server امن نگه دارید.
• Dead code و Featureهای غیرضروری Runtime را حذف کنید.
• Brotli/Gzip، MIME و CDN cache را تست کنید.
• فایل را Content-hash و نسخه را با Glue هماهنگ کنید.
• Module غیرضروری را Lazy-load و Preload را فقط با Evidence اضافه کنید.
• Cache قدیمی و Glue تازه را با Atomic deploy/manifest کنترل کنید.

Streaming اجازه می‌دهد Compile پیش از پایان دریافت آغاز شود، اما دانلود و CPU را حذف نمی‌کند. برای بازار چندمنطقه‌ای و Cache key، راهنمای CDN بین‌المللی را ببینید.

مدل امنیتی WebAssembly؛ دقیق، نه تبلیغاتی

مستند امنیت رسمی WebAssembly Module را در Sandbox جدا از Host توصیف می‌کند، اما صریحاً می‌گوید Race، Timing side-channel و خطاهای داخل Linear memory ممکن‌اند. Core spec نیز Ambient access نمی‌دهد؛ Host فقط از طریق Importها Capability می‌دهد.

Least capability

Import object را API امنیتی بدانید. به Plugin فقط Functionهایی بدهید که لازم دارد؛ نه File system ریشه، Network آزاد، Secret یا Database handle. Input و Output را Validate، Rate limit و Audit کنید. در WASI، Preopen directory یا Socket permission را Scope کنید.

کنترل‌های Browser

• CSP را ابتدا Report و سپس Enforce کنید؛ اجازهٔ Compile را بیش از نیاز باز نکنید.
• CORS/CORP و Origin فایل Wasm را درست تنظیم کنید.
• Third-party Module را مانند Dependency اجرایی حساس مدیریت کنید.
• Secret را داخل Binary قرار ندهید؛ قابل استخراج است.
• Authorization و مبلغ/مجوز حساس را در Client نهایی نکنید.
• Crash، Compile error و Version mismatch را Monitor کنید.

برای Inventory، AuthZ، Token و Third-party API، راهنمای امنیت API مکمل Threat model است.

WASI چیست و چه چیزی نیست؟

WASI مجموعه‌ای از Interfaceهای استاندارد است که Host می‌تواند به Component یا Module ارائه کند: CLI، Clock، Random، Filesystem، Sockets/HTTP و موارد دیگر بسته به نسخه. WASI یک Kernel یا سیستم‌عامل کامل نیست و Runtimeها همهٔ Interfaceها را یکسان پیاده نمی‌کنند.

Target را در Manifest/ADR بنویسید: مثلاً «Component برای WASI ۰.۳، Runtime X نسخه Y، Interfaceهای cli/http مشخص». فایل .wasm بدون این Context قابل‌عملیات نیست.

Component Model و WIT

راهنمای Component Model توضیح می‌دهد Core functionها Typeهای محدود دارند و زبان‌ها String/Record/Variant را متفاوت نمایش می‌دهند. Component از WIT و Canonical ABI برای Interface غنی و Interop استفاده می‌کند.

package mindio:image-tools@1.0.0;

interface resize {
  record request {
    width: u32,
    height: u32,
    quality: u8,
  }

  resize: func(input: list<u8>, options: request)
    -> result<list<u8>, string>;
}

world image-worker {
  export resize;
}

WIT Contract را خواناتر می‌کند، اما Copy، Allocation، Semantics، Versioning و Compatibility را جادویی حل نمی‌کند. Contract test، Error model و Resource limit همچنان لازم‌اند.

WebAssembly یا Container؟

«Wasm از Docker امن‌تر و سریع‌تر است» سؤال ناقص است. Threat model، Image/Module، Runtime، Workload، Cold start، Density، Network و Operational controls را در PoC مقایسه کنید. معماری سرویس را مستقل از Packaging با راهنمای مونولیت و میکروسرویس بسنجید.

سناریوهای خارج مرورگر

Plugin و Extension

Fit خوب وقتی است که Host API کوچک و Capability محدود دارید. Versioned interface، Deadline، Fuel، Memory، Cancellation، Tenant isolation و Audit ضروری‌اند.

Edge/Serverless function

Startup کم می‌تواند مفید باشد، اما Vendor runtime، WASI version، Network/Storage API، Secret، Region و Observability محدودیت می‌سازند. Benchmark را روی Provider و Region هدف اجرا کنید.

سرویس Server-side

برای Compute خالص، Multi-tenant extension یا Library قابل‌حمل مناسب است. برای Application با Driver، Native dependency و OS API زیاد، Container/Process ممکن است ساده‌تر باشد.

UDF و Policy engine

اجرای Logic محدود داخل Host جذاب است، اما Determinism، Resource budget، Side effect و Upgrade contract را تعریف کنید. Code upload کاربر را بدون Scan و Capability limit اجرا نکنید.

معماری Web app با Wasm

برای AR، 3D و Viewer، راهنمای WebAR و 3D فروشگاهی نمونهٔ Workloadهای سنگین و Performance budget را پوشش می‌دهد.

DOM، Canvas و رابط کاربری

Core Wasm DOM ندارد. Host می‌تواند Web API را از طریق JavaScript/Binding در اختیار Module بگذارد. فراخوانی DOM برای هر Node از Wasm معمولاً Interface شلوغ می‌سازد. محاسبه را Batch و Rendering را در لایهٔ مناسب نگه دارید.

• متن، Form و Navigation را Semantic HTML نگه دارید.
• Canvas-only UI برای Keyboard، Screen reader، Copy و SEO مشکل می‌سازد.
• Focus، Label، Error و Reduced motion را مستقل QA کنید.
• Main thread را با Compute طولانی Block نکنید؛ Worker را ارزیابی کنید.
• Fallback برای Compile failure و Device ضعیف داشته باشید.

SEO، PWA و Discoverability

Wasm سیگنال رتبه‌بندی نیست. اگر متن و لینک فقط در Canvas یا پس از Execution سنگین ظاهر شوند، Crawler و کاربر اولیه ممکن است محتوا را نبینند. HTML اولیه، URL مستقل، Status، Canonical، Metadata و لینک واقعی را حفظ کنید.

Service Worker می‌تواند Version mismatch میان HTML، Glue و Wasm بسازد. Cache migration، Activate strategy، Rollback و Offline behavior را تست کنید. برای Crawl/Render/Cache، راهنمای سئو PWA را اجرا کنید.

API و Contract

Wasm مرز REST/GraphQL را حذف نمی‌کند. Module Client هنوز با Backend، Auth، Retry، Cache و Schema evolution روبه‌روست. Error Wasm را به HTTP status یا Business error کورکورانه Map نکنید.

برای انتخاب Contract خارجی و کنترل N+۱/Cache/Version، مقایسه GraphQL و REST را ببینید. Interface داخلی WIT و API شبکه دو Contract جدا هستند.

Observability و Debugging

Source map و Symbol را با Artifact version هماهنگ کنید. PII یا Buffer خام را در Log نریزید. Trap را از Business error و Host error جدا کنید. Sampling باید Slow tail و Failure را حفظ کند.

Testing و CI/CD

• Unit test در Source language؛
• Golden test بر Native و Wasm output؛
• Property/Fuzz test برای Parser و Boundary؛
• Contract test Import/Export یا WIT؛
• Browser matrix و Runtime matrix؛
• Performance regression بر Size/Startup/Throughput/Memory؛
• SBOM، License، Vulnerability و provenance؛
• Canary، Kill switch و Rollback Artifact؛
• Compatibility test روی Glue قدیم/جدید و Cache state.

Gate را با Budget عددی بنویسید: مثلاً Compressed size، p95 first operation، Peak memory و Failure rate. «Build موفق» برای Artifact اجرایی کافی نیست.

ملاحظات WebAssembly برای کاربران ایران

شبکه و Bundle

روی 4G ناپایدار و Android میان‌رده/ضعیف آزمایش کنید. Download، Retry، CDN داخل/خارج، MIME و Cache را از چند اپراتور بسنجید. Lazy-load باید با User intent هماهنگ باشد؛ Module چندمگابایتی را برای همه Preload نکنید.

Toolchain و Supply chain

دسترسی Registry، Package mirror، Image، Compiler و CI خارجی ممکن است ناپایدار باشد. Version/Checksum، Cache داخلی، Artifact repository، SBOM و Build reproducible را طراحی کنید. Binary ناشناخته را فقط برای رفع محدودیت دانلود وارد زنجیره نکنید.

Browser و Device matrix

فقط Chrome Desktop را Target نکنید. نسخه‌های Android WebView، Safari/iOS بازار هدف و Device memory را از Analytics خودتان استخراج کنید. Feature detection بر User-Agent حدسی مقدم است.

Cross-origin isolation و پرداخت

COOP/COEP برای Thread می‌تواند Popup، iframe، Script یا Asset ثالث را Block یا جدا کند. Login، SSO، درگاه پرداخت، نقشه، Chat و Analytics را در Matrix تست کنید. Thread را اگر Integration حیاتی می‌شکند، بدون طرح جداگانه فعال نکنید.

پردازش محلی و Privacy

پردازش Client می‌تواند ارسال تصویر/صوت را کم کند، اما Data هنوز در حافظهٔ Browser و Importهای Host است. ادعای «داده از دستگاه خارج نمی‌شود» را با Network inspection، Dependency audit و Telemetry ثابت کنید.

Scorecard انتخاب WebAssembly

امتیاز را با وزن سناریو محاسبه کنید. اگر Performance value نامشخص یا Compatibility بحرانی است، ابتدا Benchmark/Pilot؛ نه مهاجرت کامل.

PoC چهارهفته‌ای

هفته اول: Baseline و Contract

• Hot path را با Profiler تأیید کنید.
• JavaScript/Native baseline و Dataset واقعی بسازید.
• Target، Browser/Runtime و Interface را مشخص کنید.
• Budget Size/Startup/Latency/Memory و Guardrail تعیین کنید.

هفته دوم: دو Variant

• حداقل Kernel Wasm را Build کنید.
• Boundary را Batch و Error contract را Version کنید.
• Fallback و Kill switch بسازید.
• Instrumentation یکسان اضافه کنید.

هفته سوم: Lab و Security

• Cold/Warm و Network/Device matrix را اجرا کنید.
• Fuzz، Resource limit و Supply chain را بررسی کنید.
• COOP/COEP و Third-party integration را در صورت نیاز تست کنید.
• Accessibility و SEO/HTML fallback را QA کنید.

هفته چهارم: Canary و ADR

• درصد کوچکی از Traffic را Canary کنید.
• RUM، Failure، Fallback و Outcome را مقایسه کنید.
• TCO و Team ownership را برآورد کنید.
• ADR با Adopt/Pilot/Reject و شرط بازبینی بنویسید.

نقشهٔ ۹۰روزه Production

1. روز ۱–۳۰: PoC، Threat model، Contract و Budget.
2. روز ۳۱–۶۰: Harden، CI matrix، Observability، Fallback و Load test.
3. روز ۶۱–۷۵: Canary مرحله‌ای با Segment/Device/Network.
4. روز ۷۶–۹۰: Scale یا Rollback، Actual TCO، Runbook و Review date.

اگر Wasm فقط Microbenchmark را بهتر و User outcome را بدتر کرد، آن را متوقف کنید. هزینهٔ Sunk دلیل Scale نیست.

چک‌لیست نهایی WebAssembly

• Bottleneck با Profiler ثابت شده است.
• Module، Component، WASI و Host از هم تفکیک شده‌اند.
• Core/WASI/Runtime/Feature version Pin شده است.
• JavaScript یا معماری فعلی Baseline منصفانه دارد.
• Download، Compile، Instantiate، Boundary، Compute و Render سنجیده می‌شوند.
• Binary size، MIME، Cache و Atomic deploy درست‌اند.
• Main thread، Memory، Battery و Device ضعیف Guardrail دارند.
• Importها Least-capability و Resourceها محدودند.
• Dependency، SBOM، provenance و License کنترل می‌شوند.
• COOP/COEP با Integrationهای ثالث تست شده است.
• Fallback، Kill switch، Telemetry و Rollback موجودند.
• HTML معنایی، Accessibility و SEO قربانی Canvas نشده‌اند.
• PoC روی شبکه و Device کاربران ایران اجرا شده است.
• TCO، Owner و تاریخ بازبینی ADR مشخص‌اند.

سؤالات متداول WebAssembly

آیا WebAssembly جایگزین JavaScript می‌شود؟

خیر. در Browser، Wasm معمولاً Kernel محاسباتی یا Library را اجرا می‌کند و JavaScript/Web API مسئول Load، DOM، Event و Integration است. انتخاب مرز به Workload و Benchmark وابسته است؛ UIهای عادی اغلب از JavaScript ساده‌تر سود می‌برند.

آیا WebAssembly همیشه از JavaScript سریع‌تر است؟

خیر. Download، Compile، Runtime، Algorithm، Boundary call، Copy، Memory و Device نتیجه را می‌سازند. یک Function می‌تواند سریع‌تر باشد اما First task کل محصول کندتر شود. End-to-end و Cold/Warm را روی داده واقعی بسنجید.

آیا Sandbox وب‌اسمبلی امنیت را تضمین می‌کند؟

Sandbox Ambient access را محدود و Linear memory را از Host جدا می‌کند، اما Import پرقدرت، Supply chain، Logic flaw، CPU/Memory DoS، Race و Side channel باقی می‌مانند. Least capability، Resource limit، Fuzz، Patch و Monitoring ضروری‌اند.

تفاوت WASI ۰.۱، ۰.۲ و ۰.۳ چیست؟

WASI ۰.۱ مدل Legacy مبتنی بر Core module و API قدیمی دارد و هنوز حمایت Runtime گسترده‌ای دارد. ۰.۲ پایه Stable Component/WIT است؛ ۰.۳ از ژوئن ۲۰۲۶ Stable و Native async/stream/future اضافه کرده است. Target را با Runtime matrix انتخاب و نسخه را Pin کنید.

آیا Wasm جای Docker و Container را می‌گیرد؟

به‌طور عمومی نه. Wasm Contract و Sandbox سبک‌تری می‌تواند برای Plugin، Edge یا Compute مناسب باشد؛ Container محیط OS و Tooling عملیاتی بالغ‌تری دارد. Startup، Compatibility، Isolation، I/O، Observability و TCO همان Workload را PoC کنید.

جمع‌بندی

WebAssembly یک Target قابل‌حمل برای محاسبه و Component است، نه پیش‌گویی آیندهٔ همهٔ وب. Core ۳.۰، WASI ۰.۳ و Component Model دامنهٔ آن را گسترش داده‌اند، اما هر لایه Contract و Compatibility خودش را دارد. Hot path را پیدا کنید، Boundary و Startup را اندازه بگیرید، Capability را محدود و Fallback را حفظ کنید. اگر PoC روی Device و شبکهٔ واقعی User outcome یا TCO را بهتر نکرد، JavaScript، Worker، GPU یا معماری فعلی انتخاب حرفه‌ای‌تری است.