Skip to content
~/sph.sh

WebAssembly 101: Üç Bahis, Tek Bytecode

Stack'ten bağımsız bir WebAssembly haritası (tarayıcıda performans, sunucuda WASI runtime, edge'de compute) üç farklı bahsi ayırarak hangi konuşmanın hangisinden bahsettiğini anlamanı sağlar.

WebAssembly konuşmaları sürekli birbirini ıskalıyor; çünkü tek bir kelime üç çok farklı mimari bahsi örtüyor. Frontend geliştirici "web'i hızlandırır" diye düşünüyor, backend geliştirici "container'ların yerine geçer" diye okuyor, platform geliştirici "edge'i çalıştırır" diye varsayıyor ve üçü de kısmen haklı. Bu yazı üç bahsi ayırıyor; böylece sonraki Wasm sohbetinde hangisinin masada olduğunu anlayabilesin.

30 Saniyede WASM

Yazının tezi, herhangi bir ekseni açmadan önce: Tek bytecode, üç ayrı bahis. Tarayıcıda performans, sunucuda WASI runtime, edge'de compute. Her biri farklı bir soruya cevap.

Rust, C, C++, Go, AssemblyScript ve Zig gibi kaynak diller ikili bir talimat formatına derleniyor: .wasm dosyası. Bu bytecode stack tabanlı, bellek güvenli, varsayılan olarak sandbox'lanmış ve neredeyse yerel hıza yakın çalışacak şekilde tasarlanmış. Hangi host üstünde çalışacağı onun umurunda değil. Host'tan bağımsızlık zaten olayın kendisi; yazının geri kalanı hangi host'u seçtiğinin hikâyesi. Bir tarafta tarayıcı; diğer tarafta sunucu ve edge. Aynı ikili farklı kapılardan giriyor.

Yazının geri kalanının cevapladığı soru: bu üç host'tan hangisi seni gerçekten ilgilendiriyor ve neden?

Bahis 1: Tarayıcıda Performans

Tarayıcı bahsinin cevapladığı soru net: JavaScript bu CPU yoğun iş için yeterince hızlı değil; mevcut C++ veya Rust kod tabanını tarayıcıya taşıyabilir miyim? Cevap evet ve 2017'den beri evet. Üretim kanıtı da çoktan birikmiş durumda.

Üç somut örnek bu bahsi gerçek kılıyor. Figma, 2017'de WebAssembly'i devreye aldı ve editör yüklenme süresini yaklaşık 3× kısalttığını raporladı; C++ render motorunu derleyip tarayıcı içinde çalıştırdılar. Google Earth, 3D render'ını ve coğrafi matematik işlerini Wasm'e taşıyarak masaüstü deneyimini web'e getirdi. Photoshop Web, Adobe ile Chrome ekibinin yıllara yayılan ortak çalışmasının ürünü; Photoshop'un C++ çekirdeği Emscripten üstünden derleniyor ve 2021'de web'de kamu betası açıldı. Üç örnek de masaüstü sınıfı uygulamanın tarayıcıda yaşayabileceğini gösterdi.

Adlandırmaya değer sınır: Wasm'in doğrudan DOM erişimi yok. Wasm kodu bir DOM düğümüne, bir özelliğe veya bir event'e her uzandığında çağrı bir JavaScript ↔ Wasm köprüsünden geçiyor. Bu köprü bedava değil; "JavaScript yerine Wasm kullanalım" yanlış zihinsel modeli bu yüzden. Wasm uygulamanın içindeki hesaplama için; arayüz hâlâ JavaScript'in alanı. İki tarafı birbirinin yerine koymak değil, yan yana koymak doğru okuma.

Bu üç bahis içinde en olgunu. Dört büyük tarayıcının hepsi destekliyor. Açık tasarım soruları Emscripten, bellek düzeni ve SharedArrayBuffer üstünden çoklu thread hakkında; platformun çalışıp çalışmadığı hakkında değil.

Bahis 2: Sunucuda Runtime (WASI)

Sunucu bahsi farklı bir soruyu cevaplıyor: Tam bir container açmadan, Docker'ın sunduğundan daha küçük bir sandbox ve daha soğuk-başlangıç profiliyle izole, çok dilli iş yüklerini çalıştırabilir miyim? Cevap "evet, ama ekosistem container'lardan daha genç." Bu genç oluş, hem fırsat hem de kısıt.

Bir kere tanıtıp geçmek gereken terimler. WASI (WebAssembly System Interface), Wasm kodunun altındaki OS'u umursamadan dosyalarla, saatlerle, soket'lerle ve ortam değişkenleriyle konuşmasını sağlayan standart yüzey. İki aktif sürümü var. Preview 1, hâlâ yaygın kullanılan eski POSIX'e yakın API. Preview 2, 25 Ocak 2024'te yayınlandı; Component Model üstüne yeniden inşa edildi ve WASI'yi syscall'lar yerine tiplenmiş arayüzler kümesi olarak yeniden düşünüyor. Preview 3 (WASI 0.3) Wasmtime üstünde release-candidate olarak çoktan akıyor; async desteği ve yerel thread'ler kapsamda, 1.0 kesimi 2026 sonu ile 2027 başı arasında bekleniyor. Üç sürüm aynı standart, farklı soyutlama seviyeleri.

Üç somut platform sunucu bahsini gerçek kılıyor. Wasmtime, referans sunucu tarafı runtime; Bytecode Alliance tarafından yürütülüyor ve Cranelift kod üretici ile çalışıyor. Wasmer, kendi paketleme ve dağıtım modelini taşıyan alternatif bir runtime. wasmCloud, Wasm bileşenleri ve NATS mesajlaşması üstüne kurulu daha üst seviye bir platform. wasmCloud ve NATS etrafındaki bileşen-taşınabilirliği tezine daha derin bir bakış için wasmCloud + NATS: bir event-bus taşınabilirlik bahsi yazısına bakabilirsin.

Adlandırmaya değer sınır: Component Model hâlâ stabilize oluyor. Preview 2 stabil kilometre taşı; Preview 3 çoktan Wasmtime'a release-candidate olarak iniyor. Solomon Hykes'ın 2019'daki "WASM+WASI 2008'de olsaydı Docker'a ihtiyacımız olmazdı" sözü güzel bir uzun vadeli çerçeve ama bir vizyon ifadesi, 2026 için anahtar teslim bir yedek değil. Kütüphane kapsamı, dil desteği ve araç zinciri runtime'a göre değişiyor. Bugün sunucu tarafında Wasm'e yönelen bir ekip, container eşdeğeri bir ekosistem devralmıyor; olgunlaşmakta olan bir ekosisteme bahse giriyor.

Bahis 3: Edge Compute

Edge bahsi üçüncü soruyu cevaplıyor: Kullanıcılarım coğrafi olarak dağınık; her isteğe özel kodun onlara yakın, container soğuk-başlangıç maliyetini ödemeden çalışmasını istiyorum. Wasm burada doğal oturuyor; çünkü soğuk başlangıcı saniyelerle değil milisaniyelerle ölçülüyor ve sandbox'ı istek başına ucuza ayağa kalkıyor.

Üç somut platform bu bahsi çerçeveliyor. Cloudflare Workers, V8 izolatları ile Wasm modüllerini eşleştiriyor; resmi Rust yolu workers-rs crate'i üstünden geçiyor. Fastly Compute, önünde V8 katmanı olmayan saf Wasm tabanlı bir edge runtime; bu ona farklı bir izolasyon hikâyesi ve farklı bir performans profili veriyor. Shopify Functions, satıcıların Rust, JavaScript veya AssemblyScript'ten derlenmiş Wasm modülleri göndererek Shopify checkout ve indirim yollarında inline çalıştığı müşteri-genişletilebilir ticaret mantığı platformu. Üç platform da aynı bytecode'u farklı sözleşmelerle paketliyor.

Adlandırmaya değer sınır: Bytecode taşınabilir; host binding'leri değil. Her edge platformu kendi KV deposunu, kuyruğunu, binding ABI'sını ve runtime şeklini sunuyor. Cloudflare Workers için derlenmiş bir Wasm modülü Fastly Compute veya Shopify Functions'a drag-and-drop gitmiyor. Taşınabilirlik vaadi talimat düzeyinde yaşıyor; platform düzeyinde değil. Binding'lerin kilitlenmeyi nereye sakladığı, wasmCloud + NATS taşınabilirlik yazısının derinlemesine işlediği tam da bu gerilim. CPU-yoğun bir modülü V8-artı-Wasm edge'ine göndermenin pratikte nasıl göründüğüne — ve üç sert limitin nerede ısıracağına — uygulamalı bir bakış için: Cloudflare Workers'a WASM Görsel Yeniden-Boyutlama Modülü Yüklemek.

Hangi Eksen Hangi İş İçin

Üç bahis isimlendirildikten sonra karar kısa bir ağaca dönüşüyor. Kök soru "Wasm kullanmalı mıyım?" değil; o çerçeveleme seni alışverişe gönderir. Kök soru, mevcut mimarini üç farklı problemden hangisinin tarif ettiği.

"Hiçbiri" dalı bu yazının duruşu. Üç sorudan hiçbiri mevcut şeklini tarif etmiyorsa, Wasm bugünkü problemin cevabı değil ve şimdi devreye almak henüz kullanım senaryosu olmayan bir platform bahsini omuzlamak demek. Üç bahis gerçek, ama üçü de evrensel değil.

Kapanış

Tarayıcı zaten günlük yüzeyindeyse ve JavaScript motorunun yutamadığı CPU yoğun bir ağrın varsa Bahis 1 ile başla; üç bahis içinde en olgunu ve en net geri dönüşü veren o. Üç sorudan hiçbiri mevcut mimarine uymuyorsa WebAssembly bugünkü problemin cevabı değil. WASI Preview 3 release-candidate aşamasından stabil sürüme geçip sunucu tarafı ekosistemi kalınlaştığında tekrar bak.

Kaynaklar

webassembly
wasm
wasi
edge-computing
architecture

İlgili Yazılar