WebAssembly (Wasm) Nedir, Ne Sunar?

Web tarayıcıları yaklaşık otuz yıl boyunca tek bir programlama dilinin mutlak tekelinde yaşadı: JavaScript. 1995 yılında Brendan Eich tarafından web sayfalarına basit etkileşimler katmak için sadece 10 günde tasarlanan JavaScript; V8 (Chrome/Node.js), SpiderMonkey (Firefox) ve JavaScriptCore (Safari) gibi modern JIT (Just-In-Time) motorlarının mucizevi optimizasyonları sayesinde devasa web uygulamalarını çalıştırabilecek bir seviyeye ulaştı. Ancak konu 4K video kurgulama, 3 boyutlu CAD modelleme, milyonlarca katmanlı vektörel grafik işleme, kriptografik hesaplama, fizik simülasyonları veya tarayıcı içi yapay zeka çıkarımı (AI Inference) gibi ağır CPU ve bellek gerektiren görevlere geldiğinde, JavaScript'in dinamik tipli doğası ve çöp toplayıcı (Garbage Collector) duraksamaları fiziksel bir duvara çarpar. İşte bu duvarı yıkmak için W3C (World Wide Web Consortium) tarafından HTML, CSS ve JavaScript'in ardından "Web'in 4. Resmi Dili" olarak standartlaştırılan teknoloji WebAssembly (Wasm) olmuştur. Üstelik bugün Wasm yalnızca tarayıcılarla sınırlı kalmamış; WASI (WebAssembly System Interface) ile bulut sunucularında ve uç bilişimde (Edge Computing) Docker konteynerlerine meydan okuyan mikrosaniye hızında bir çalışma zamanına dönüşmüştür. Uygulama ve yazılım mimarileri dünyasında geleceğin hesaplama standardı olarak kabul edilen WebAssembly ekosistemini tüm teknik derinliğiyle inceliyoruz.

1. WebAssembly (Wasm) Tam Olarak Nedir? (Ve Ne Değildir?)

İsminde "Assembly" kelimesi geçmesine rağmen WebAssembly, geliştiricilerin oturup elle MOV EAX, 1 gibi makine dili komutları yazdığı bir programlama dili değildir. WebAssembly (Wasm); yığın tabanlı bir sanal makine (stack-based virtual machine) için tasarlanmış, taşınabilir, düşük seviyeli bir ikili komut formatıdır (binary instruction format - .wasm). Bir başka ifadeyle Wasm, doğrudan insanların yazması için değil; Rust, C, C++, Go, C# (.NET Blazor), Kotlin, Swift ve Zig gibi derlenen dillerin bir derleme hedefi (compilation target) olması için tasarlanmıştır.

Geleneksel bir JavaScript dosyasının (bundle.js) tarayıcıda çalışması için şu aşamalardan geçmesi gerekir: Metin tabanlı kod indirilir, ayrıştırılır (Parsing), Soyut Sözdizimi Ağacına (AST) dönüştürülür, bayt koduna çevrilir, çalışma zamanında profili çıkarılır (Profiling) ve JIT derleyicisi tarafından sıcak döngüler makine koduna derlenir; ancak bir değişkenin tipi aniden değişirse (örneğin sayı beklenen yere nesne gelirse) JIT optimizasyonu çöpe atılır (De-optimization). Buna karşılık bir .wasm dosyası zaten derleme zamanında (Ahead-of-Time) optimize edilmiş sıkı tipli ikili (binary) formatta gelir. Tarayıcı .wasm dosyasını još indirirken (Streaming Compilation) ağdan gelen baytları saniyede yüzlerce megabayt hızla doğrudan işlemcinin (x86_64 veya ARM64) yerel makine koduna çevirir ve yerel (Native) hızın %85 ila %95'i seviyesinde deterministik bir performansla çalıştırır.

2. Tarayıcıda Yerel (Native) Performans: Figma, Adobe, AutoCAD ve Oyun Motorları

WebAssembly'nin tarayıcıda yarattığı devrimi anlamak için bugün milyonlarca tasarımcı ve mühendisin her gün kullandığı amiral gemisi uygulamalara bakmak yeterlidir. Eskiden bilgisayara gigabaytlarca boyutta kurulum dosyası indirilerek kullanılan ağır masaüstü yazılımları, Wasm sayesinde artık bir URL tıklamasıyla tarayıcı sekmesinde sıfır kurulumla çalışmaktadır.

2.1. Gerçek Dünya Endüstriyel Başarı Öyküleri

• Figma: Kullanıcı arayüzü (araç çubukları, katman panelleri) React ve TypeScript ile yazılmışken, yüz binlerce vektörel objeyi saniyede 60 kare (60 FPS) hızla çizen asıl grafik motoru C++ ile yazılmış ve WebAssembly'ye derlenmiştir. Figma, asm.js'ten WebAssembly'ye geçtiğinde büyük tasarım dosyalarının yüklenme süresi 3 kat (300%) hızlanmıştır.
• Adobe Photoshop & Lightroom Web: Otuz yıldan uzun süredir C++ ile geliştirilen milyonlarca satırlık orijinal Photoshop kod tabanı, sıfırdan JavaScript ile yeniden yazılmak yerine Emscripten derleyici araç zinciri, WebAssembly SIMD (Single Instruction, Multiple Data) ve WebAssembly Threads (Çoklu İş Parçacığı) kullanılarak doğrudan tarayıcıya taşınmıştır.
• AutoCAD, Google Earth ve Unity / Unreal Engine: Onlarca yıllık C++ mühendislik ve 3B oyun motorları, WebGL / WebGPU grafik API'leri ve WebAssembly birleşimiyle tarayıcıda yerel masaüstü uygulamalarından ayırt edilemeyecek akıcılıkta çalışmaktadır.
• İstemci Taraflı Veri ve Medya İşleme (FFmpeg.wasm, SQLite-Wasm, DuckDB-Wasm): Artık bir kullanıcının yüklediği videoyu kırpmak veya formatını değiştirmek için videoyu bulut sunucunuza yükleyip pahalı GPU/CPU sunucuları kiralamanıza gerek yoktur! FFmpeg.wasm sayesinde video doğrudan kullanıcının kendi tarayıcısında, kullanıcının işlemcisi kullanılarak dönüştürülür; böylece SaaS ve bulut altyapı maliyetleri dramatik biçimde düşerken kullanıcı verisi cihazdan dışarı çıkmadığı için %100 gizlilik sağlanır. Aynı şekilde DuckDB-Wasm ile tarayıcı içinde milyonlarca satırlık Parquet/CSV dosyaları üzerinde milisaniyeler içinde analitik SQL sorguları çalıştırılabilmektedir.

2.2. WebAssembly JavaScript'i Öldürecek mi?

Kesinlikle hayır. WebAssembly, JavaScript'in yerini almak için değil, onunla simbiyotik bir ortaklık kurmak için tasarlanmıştır. Modern bir web mimarisinde DOM yönetimi, kullanıcı etkileşimleri, yönlendirme (Routing) ve genel uygulama akışı JavaScript / TypeScript (React, Vue, Svelte, Next.js) ile yönetilirken; görüntü işleme, şifreleme, veri sıkıştırma, ses sentezi veya ağır matematiksel algoritmalar gibi "sıcak döngüler" (hot paths) Rust veya C++ ile yazılıp bir Wasm modülü olarak JavaScript içinden await WebAssembly.instantiateStreaming() ile çağrılır.

3. Doğrusal Bellek (Linear Memory) ve Kum Havuzu (Sandbox) Güvenlik Mimarisi

Geleneksel olarak C veya C++ ile yazılmış bir ikili (binary) programı internetten indirip bilgisayarınızda çalıştırmak büyük bir siber güvenlik riskidir; çünkü program işletim sisteminin tüm dosya sistemine, ağ kartına ve bellek adreslerine erişebilir. Peki tarayıcılar bir web sitesine girdiğinizde arka planda indirilen .wasm dosyasını bilgisayarınıza zarar vermeyeceğinden emin olarak nasıl çalıştırır?

WebAssembly, tasarımının en temelinde Varsayılan Olarak reddet (Deny-by-Default) ve Bellek İzolasyonu (Memory-Safe Sandboxing) ilkelerine dayanır:

• Doğrusal Bellek (Linear Memory): Her Wasm modülü, ana sistemin (Host) RAM'inden tamamen yalıtılmış, bitişik (contiguous) bir bayt dizisi olan kendi sanal Doğrusal Belleği içinde çalışır. Modül içindeki işaretçiler (pointers) gerçek fiziksel RAM adresleri değil, bu dizinin 0'dan başlayan indeks numaralarıdır. Modül kendi bellek sınırının dışına taşmaya çalıştığı anda (Out-of-Bounds) sanal makine işlemi anında durdurur (Trap).
• Kontrol Akışı Bütünlüğü (Control Flow Integrity - CFI): Wasm'da çağrı yığını (Call Stack), doğrusal veri belleğinden tamamen ayrı ve Wasm kodunun doğrudan erişimine kapalı tutulur. Bu sayede C/C++ dünyasının en klasik siber saldırı yöntemi olan Buffer Overflow (Tampon Taşması) ile dönüş adresini değiştirip zararlı kod çalıştırma (ROP - Return-Oriented Programming) saldırıları mimari olarak etkisiz hale getirilir. Even yapay zeka destekli tersine mühendislik ve zafiyet analizi senaryolarında bile bir Wasm modülünün kendi kum havuzundan (sandbox) dışarı kaçması (sandbox escape) son derece katı matematiksel doğrulama (formal verification) kurallarıyla engellenmiştir.
• Sıfır Ortam Yetkisi: Bir Wasm modülü kendisine açıkça ana bilgisayar (tarayıcı veya sunucu) tarafından bir fonksiyon import edilmediği sürece ne ekrana bir piksel çizebilir, ne bir dosyayı okuyabilir, ne ağa bir HTTP paketi gönderebilir ne de sistem saatini öğrenebilir!

4. Tarayıcının Ötesi: WASI (WebAssembly System Interface) ve Sunucu Taraflı Wasm

2019 yılında Mozilla öncülüğünde başlatılan ve Bytecode Alliance (Fastly, Microsoft, Intel, Red Hat, Fermyon) tarafından geliştirilen WASI (WebAssembly System Interface), WebAssembly'yi tarayıcıdan çıkarıp sunucu, bulut, Kubernetes ve IoT dünyasına taşıyan devrimsel standarttır.

Tarayıcı dışında çalışan bir Wasm modülünün veritabanına bağlanması, ortam değişkenlerini okuması veya soket açması için işletim sistemi çekirdeğiyle (POSIX benzeri standart bir arayüzle) güvenli şekilde konuşması gerekir. WASI bunu Yetenek Tabanlı Güvenlik (Capability-Based Security) modeliyle sağlar: Bir Wasm uygulamasını Wasmtime, WasmEdge veya Spin çalışma zamanında başlatırken wasmtime --dir=/var/log/app app.wasm şeklinde açıkça hangi dizine veya hangi IP adresine erişebileceğini parametre olarak verirsiniz; uygulama bilgisayarınızdaki diğer hiçbir klasörün varlığından bile haberdar olamaz.

4.1. Docker kurucusu Solomon Hykes Neden "2008'de Wasm+WASI Olsaydı Docker'ı Yaratmazdık" Dedi?

Docker'ın kurucusu Solomon Hykes'ın 2019 yılında attığı ünlü tweet yazılım dünyasında deprem etkisi yaratmıştı: "Eğer 2008 yılında WASM ve WASI var olsaydı, Docker'ı yaratmamıza hiç gerek kalmazdı. WebAssembly bu kadar önemli. Sunucudaki WebAssembly, bilişimin geleceğidir." Bu iddianın arkasında üç somut mühendislik gerçeği yatmaktadır:

1. Gerçek Platform Bağımsızlığı (Write Once, Run Anywhere): Bir Docker imajı derlendiği işletim sistemi ve işlemci mimarisine bağımlıdır; linux/amd64 için derlenmiş bir Docker imajını doğrudan ARM64 (Apple Silicon / AWS Graviton) veya Windows çekirdeğinde emülasyon olmadan çalıştıramazsınız. Oysa tek bir .wasm ikili dosyası; Linux, macOS, Windows, iOS, Android, x86 ve ARM işlemcilerde yeniden derlenmeden %100 aynı şekilde çalışır.
2. Boyut Farkı (MB/GB vs. KB): Basit bir mikroservisi Docker konteyneri içine koyduğunuzda, temel Linux dağıtımı (Alpine/Debian kütüphaneleri) ve çalışma zamanıyla birlikte imaj boyutu 50 MB ila 800 MB arasındadır. Aynı mikroservis Rust veya TinyGo ile Wasm olarak derlendiğinde yalnızca 300 KB ila 2 MB boyutundadır!
3. Soğuk Başlatma Süresi (Cold Start: Saniyeler vs. Mikrosaniyeler): Sunucusuz (Serverless / AWS Lambda) mimarilerde en büyük sorun "Cold Start" gecikmesidir; trafik olmadığında sıfıra inen (Scale-to-Zero) bir konteynerin ilk istek geldiğinde ayağa kalkması 200 milisaniye ile 3 saniye arasında sürer. Oysa Wasmtime, Fermyon Spin veya Cloudflare Workers üzerindeki bir Wasm modülü 0.5 milisaniyenin (500 mikrosaniye) altında sıfırdan başlar! Bu sayede sunucular boşta beklerken gerçekten sıfır kaynak tüketir ve istek geldiği anda ağ paketinin ulaşma süresinden daha hızlı bir şekilde uyanır.

Karşılaştırma Kriteri	JavaScript (Tarayıcı / V8)	Docker Konteyneri (Linux)	WebAssembly (Wasm / WASI)
Başlatma Süresi (Cold Start)	5 - 50 milisaniye (V8 Isolate)	300 milisaniye - 3 saniye	< 1 milisaniye (Mikrosaniyeler)
Tipik Dağıtım Boyutu	100 KB - 5 MB (JS Bundle)	50 MB - 1.5 GB (OS + Katmanlar)	100 KB - 5 MB (Saf Binary)
CPU Performansı	Orta / Yüksek (JIT ısınması gerekir)	Yerel (Native %100)	Yerele Çok Yakın (%85 - %95)
Güvenlik ve İzolasyon	Tarayıcı / V8 Kum Havuzu	Linux cgroups & namespaces (Kernel paylaşılır)	Yetenek Tabanlı Doğrusal Bellek Sandbox
Donanım ve OS Taşınabilirliği	Tam Taşınabilir	Mimarilere özel derleme gerekir (x86 vs ARM)	Tam Taşınabilir (Evrensel Binary)
Desteklenen Diller	JavaScript / TypeScript	Tüm Diller	Rust, C/C++, Go, C#, Zig, Kotlin, Python, JS

5. Bileşen Modeli (WASI 0.2 Component Model), Eklenti Sistemleri ve Web3

WebAssembly ekosisteminin en heyecan verici yeniliği WASI 0.2 (Preview 2) ve Component Model (Bileşen Modeli) mimarisidir. WIT (Wasm Interface Types) adı verilen arayüz tanımlama dili sayesinde, artık farklı programlama dillerinde yazılmış kütüphaneler aynı uygulama içinde birbirini doğrudan çağırabilmektedir. Örneğin yüksek performanslı kriptografi modülünüzü Rust ile, görüntü işleme kütüphanenizi C++ ile, iş kurallarınızı ise Go veya Python ile yazıp her birini birer Wasm bileşeni haline getirebilir ve tek bir ikili dosya olarak birleştirebilirsiniz (Language-Agnostic Modularity).

Ayrıca Wasm bugün üç stratejik alanda daha endüstri standardı haline gelmiştir:

• Güvenli Eklenti (Plugin) Mimarileri (Extism, Envoy Proxy, Shopify Functions): Shopify, e-ticaret müşterilerinin ödeme ve indirim hesaplama mantığını özelleştirebilmesi için eski Ruby betikleri yerine Wasm tabanlı Shopify Functions mimarisine geçmiştir. Böylece üçüncü parti geliştiricilerin yazdığı eklenti kodları Shopify'ın ana sunucularında 5 milisaniye sınırıyla ve %100 güvenli kum havuzu içinde çalıştırılır. Benzer şekilde Envoy Proxy (Proxy-Wasm) ve veritabanları (SingleStore, PostgreSQL pg_tle) kullanıcı tanımlı fonksiyonları Wasm içinde koşturmaktadır.
• Kodsuz / Düşük Kodlu Platformlar: No-Code ve Low-Code B2B bayi portali platformlarında müşterilerin yazdığı özel iş kuralları sunucu güvenliğini tehlikeye atmadan Wasm izolasyonuyla çalıştırılır.
• Web3 ve Akıllı Sözleşmeler (CosmWasm, Polkadot, Arbitrum Stylus, NEAR): Web3 ve merkezsiz blokzincir ağlarında geleneksel Ethereum Sanal Makinesinin (EVM) yavaşlığı ve Solidity kısıtlamalarını aşmak için Wasm tabanlı sanal makineler (WasmVM) kullanılmaktadır. Geliştiriciler akıllı sözleşmelerini Rust ve C++ ile yazarak 10 kata kadar daha düşük gaz (gas) maliyeti ve çok daha yüksek işlem hızı (TPS) elde etmektedir.

6. Sıkça Sorulan Sorular (SSS)

1. WebAssembly geliştirmek için hangi programlama dilini öğrenmeliyim?

WebAssembly ekosisteminde birinci sınıf (first-class) desteğe, en küçük ikili dosya boyutuna ve çöp toplayıcı (Garbage Collector) gerektirmediği için en yüksek performansa sahip dil açık ara Rust'tır (wasm-pack ve wasm-bindgen araç zinciriyle). Eğer zaten JavaScript/TypeScript geliştiricisiyseniz ve yeni bir sistem dili öğrenmeden hızlıca Wasm modülleri yazmak istiyorsanız, TypeScript sözdizimini doğrudan Wasm'a derleyen AssemblyScript harika bir başlangıç noktasıdır. Mevcut C/C++ kodları için Emscripten, Go geliştiricileri için TinyGo, .NET geliştiricileri içinse Blazor WebAssembly olgun çözümler sunar.

2. WebAssembly doğrudan HTML DOM nesnelerine (örneğin `document.getElementById`) erişebilir mi?

Doğrudan erişemez. Güvenlik ve taşınabilirlik tasarımı gereği WebAssembly'nin yerleşik bir DOM API'si yoktur. Bir Wasm modülünün ekrandaki bir HTML elementini değiştirmesi veya fetch ile ağ isteği atması gerektiğinde, ana bilgisayardaki (Host) JavaScript köprüsü (JavaScript Glue Code - örneğin Rust'taki web-sys kütüphanesi) üzerinden ilgili tarayıcı API'sini çağırır. Ancak Wasm GC (Garbage Collection) ve Component Model standartlarının tarayıcılarda yerleşik hale gelmesiyle birlikte bu köprü geçiş maliyeti neredeyse sıfıra indirilmiştir.

3. Kubernetes içinde hem Docker konteynerlerini hem de Wasm iş yüklerini birlikte çalıştırabilir miyiz?

Evet! SpinKube, Krustlet ve containerd-shim-spin (runwasi) projeleri sayesinde mevcut Kubernetes kümenizi hiç bozmadan, aynı düğüm (Node) üzerinde veritabanlarınızı ve ağır servislerinizi standart Docker/containerd konteynerleri olarak çalıştırırken, olay güdümlü (event-driven) API uç noktalarınızı ve sunucusuz fonksiyonlarınızı Wasm Pod'ları olarak dağıtabilirsiniz. Böylece Kubernetes altyapı yönetiminden vazgeçmeden mikrosaniye hızında ölçeklenen hibrit bir mimari elde edersiniz.

4. Python veya PHP gibi yorumlanan (interpreted) diller de WebAssembly üzerinde çalışır mı?

Evet, Pyodide (Tarayıcıda CPython ve NumPy/Pandas) veya Fermyon/VMware tarafından geliştirilen sunucu taraflı Wasm çalışma zamanları sayesinde Python ve PHP de Wasm üzerinde çalışabilmektedir. Burada yapılan işlem, Python yorumlayıcısının (C ile yazılmış olan CPython motorunun) kendisini WebAssembly'ye derlemek ve sizin yazdığınız .py betiğini bu Wasm kum havuzu içinde koşturmaktır. Bu yöntem Rust kadar küçük boyutlu olmasa da tarayıcı içinde sunucusuz veri bilimi (JupyterLite) ve güvenli kod çalıştırma ortamları için muazzam bir kolaylık sağlar.

5. Her web uygulamasında veya her mikroserviste WebAssembly kullanmalı mıyız?

Hayır. Eğer yaptığınız iş standart bir CRUD uygulamasıysa (formdan veri al, JSON API'ye gönder, tabloda listele), standart JavaScript/TypeScript ve geleneksel arka uç servisleri fazlasıyla yeterlidir; bu senaryoda Wasm kullanmak gereksiz derleme karmaşıklığı yaratır. WebAssembly'yi; tarayıcıda ağır hesaplama, görüntü/ses/video işleme, 3B görselleştirme, şifreleme ve yerel kütüphane taşıma ihtiyaçlarında; sunucu tarafında ise uç bilişim (Edge Computing), sıfır soğuk başlatma gerektiren Serverless fonksiyonlar ve çok kiracılı güvenli eklenti (Plugin) motorları inşa ederken tercih etmelisiniz.