- WebAssembly (Wasm) hâlâ çeşitli gerçek ürünlerde temel bir teknoloji olarak kullanılıyor ve oyun motorları, tasarım araçları, web container'ları gibi alanlarda önemli bir rol üstleniyor
- Dilin kendisi, donanıma verimli biçimde eşlenen bir yapıya sahip ve güvenlik ile taşınabilirlik odağında tasarlanmış
- Güvenlik modeli, 'varsayılan olarak reddetme (deny-by-default)' yapısıyla süreç düzeyinde yalıtım ve hızlı yürütme sağlıyor
- Eklenti ekosistemi ve diller arası destek sayesinde çeşitli ortamlarda kullanılıyor, ancak tarayıcının tamamını değiştirecek düzeyde bir benimsenme henüz yok
- Bugün WebAssembly, kütüphane ve çalışma zamanı düzeyinde derin biçimde entegre durumda ve standardizasyon ile özellik genişletmeleri hızla ilerleyen bir teknoloji
Gerçek kullanım örnekleri
- WebAssembly, Godot, Figma, Stackblitz, Squoosh.app, Zellij, Ruffle gibi ürünlerde temel işlevleri üstleniyor
- Godot web için oyun derlemelerinde, Figma ise C++ kodunu tarayıcıda çalışabilecek bir biçime dönüştürmede kullanıyor
- Stackblitz web container'larında, Ruffle ise bir Flash emülatörü olarak Wasm'den yararlanıyor
- Ancak web'in tamamını Wasm tabanlı kuran büyük ölçekli siteler nadir; çoğu kullanım belirli özelliklerle sınırlı
WebAssembly'nin tanımı ve hızı
- WebAssembly, bir dil (language) ve hız kavramı doğrudan dilin kendisine değil motor performansına bağlı
- JavaScript'te olduğu gibi çalışma zamanı motoru (V8, SpiderMonkey vb.) yürütme hızını belirliyor
- WebAssembly, modern donanıma verimli biçimde eşlenen bir yapıya sahip; hem derlenerek hem de yorumlanarak çalıştırılabiliyor
Verimli eşleme yapısı
- Wasm, assembly diline yakın bir bytecode olup çoğu donanıma kayıpsız biçimde derlenebiliyor
- WAT (WebAssembly Text), Wasm'in metin gösterimi ve neredeyse 1:1 dönüştürülebiliyor
- JVM bytecode'una benziyor, ancak API'si küçük ve güvenlik garantileri daha güçlü
- Bellek erişimi açıkça tanımlı ve yalnızca host ortamın izin verdiği kaynaklar kullanılabiliyor
Derleme hedefi olarak Wasm
- Rust, C, Zig, Go, Kotlin, Java, C# gibi birçok dil Wasm'e derlenebiliyor
- Python, PHP, Ruby gibi yorumlamalı diller de Wasm derlemeleriyle çalıştırılabiliyor
- Tarayıcılar varsayılan olarak Wasm motoru içeriyor; ayrıca Wasmtime, WasmEdge, Wasmer gibi bağımsız çalışma zamanları da var
- Tek bir Wasm artefact'ı donanımdan bağımsız yürütme sağlayabiliyor
Güvenlik yapısı ve kullanım alanları
- WebAssembly, 'deny-by-default' güvenlik modelini benimser; dış erişim yalnızca açıkça tanımlanan import'larla mümkündür
- Gizli kontrol akışı yığını, lineer bellek ve sınırlı komut kümesi sayesinde güçlü yalıtım sağlar
- Cloudflare, V8 isolate kullanarak Wasm tabanlı kod çalıştırmayı yalıtırken, Fermyon milisaniyenin altındaki başlatma süreleri sunuyor
- Ruffle Flash içeriğini güvenli biçimde geri getiriyor, Pyodide Python'ı Wasm üzerinde çalıştırıyor, Figma ise Wasm tabanlı QuickJS ile eklentileri çalıştırıyor
Taşınabilirlik ve gömme
- Wasm çalışma zamanları hafif ve Zellij, Envoy, Lapce gibi projeler eklenti sistemlerinde Wasm'i benimsiyor
- JavaScript motorunun bulunduğu ortamlarda da görüntü işleme, OCR, fizik motorları, render etme, medya araç takımları, veritabanları, parser'lar gibi çeşitli Wasm kütüphaneleri kullanılabiliyor
- Çoğu durumda kullanıcılar Wasm kullanıldığını fark etmiyor; teknoloji kütüphanelerin içinde şeffaf biçimde çalışıyor
Hız ve boyutun yeniden değerlendirilmesi
- Tarayıcılar Wasm'i JS ile aynı pipeline üzerinden çalıştırıyor; motor mimarisi nedeniyle performans sınırları mevcut
- Verimlilik, dilin tip sistemi ve derleyici optimizasyon düzeyine göre değişiyor
- Host-program sınırı maliyeti ve ikili dosya boyutunun büyümesi dezavantaj olarak gösteriliyor
- WASI standardı bunu hafifletmeye çalışsa da string type standardizasyonu henüz tamamlanmış değil
- Zig en küçük Wasm binary'lerini üretiyor
- Native ortamlarda threading, IO ve bellek kullanımı nedeniyle performans düşüşü yaşanabiliyor
Dil ve standart geliştirme eğilimleri
- Wasm standardizasyonu W3C Working Group ve Bytecode Alliance tarafından paralel biçimde yürütülüyor
- İkincisi WIT, Component Model gibi araç odaklı geliştirmelere öncülük ediyor
- Yeni özellik önerileri hızla benimseniyor ve bazı kesimlerde hız ile yön konusunda tartışmalar sürüyor
- Wasm, JavaScript'in yerine geçmekten çok iç entegrasyon teknolojisi olarak yayılıyor
- Blazor, Leptos gibi framework'ler JS'yi doğrudan ele almadan Wasm'den yararlanıyor
- Bugün Wasm, özellikle kütüphane geliştiricileri tarafından benimseniyor; genel geliştiriciler iç işleyişi bilmeden de kullanabiliyor
- Eğitim materyallerinin zorlayıcı yapısı öğrenme eşiği olarak gösteriliyor ve 'watlings' gibi öğrenme projeleri örnek veriliyor
1 yorum
Hacker News görüşleri
Wasm oluşturulurken konan hedeflerin çoğuna ulaştığını düşünüyorum
Kişisel olarak onlarca projede Wasm’ı çekirdek bir bileşen olarak kullandım
JS motorları çok hızlı, ama Wasm hâlâ CPU üzerinde daha yüksek düzeyde kontrol sağlıyor ve performansı mükemmel
Yine de JS+HTML+CSS’nin yerini tamamen alacağı beklentisini karşılamadı. Bence bunun büyük nedeni DOM binding eksikliği
Yew gibi Wasm framework’lerini de kullandım ama JS’nin üstüne eklenmiş garip bir katman gibi hissettirdi
Blazor’u henüz kullanmadım ama ben hâlâ JS ile yazmayı daha rahat buluyorum
Yine de Wasm sessizce birçok yerde çalışıyor ve bence gerçek başarının kanıtı da bu
Örneğin tarayıcıda ses hızı ayarlama özelliği, ancak C++ kütüphanesini Wasm’da çalıştırarak mümkün olan bir performans düzeyi sunuyor
Düzgün bir DOM binding geldiği anda JS, 10 yıl içinde frontend’den itilecektir
C#, backend ve frontend kodunu paylaşmayı kolaylaştırıyor ve Razor template için IDE desteği de iyi
Ama .NET CLR ve BCL’yi komple taşımak gerektiği için bundle boyutu büyük
DOM erişimi zor olduğundan Blazor, JS tarafında küçük bir Virtual DOM renderer bulunduran bir yapıya sahip
Performansı fena değil ama elle yazılmış JS’den hâlâ daha yavaş
F# tabanlı Bolero da ilginç ama ekibi ikna etmek zor
DOM ile etkileşim kurmak için buna uygun yüksek seviyeli bir dil gerekiyor
JS bu rolü iyi oynuyor ve HTML/CSS/JS kombinasyonu zaten UI geliştirmede ortak dil hâline geldi
Tarayıcı rendering’ini bırakıp canvas tabanlı yola giden girişimler de var ama bunlar hâlâ niş alanlar
Basit bir web sitesinde bile birkaç MB’lık runtime indirmek zorunda kalınan bir dünya korkunç olurdu
Gerçek yavaşlığın nedeni JS değil, DOM. Sonuçta yine DOM ile etkileşim kurmak gerekiyor
Birkaç yıldır WebAssembly ile çalışıyorum ve yakında Wasm tabanlı bir framework yayımlayacağım
Ekosistem hızla gelişirken bir anda yavaşladı ve WASI ile Component Model’in devreye alınması kafa karışıklığı yarattı
Her motorun destek seviyesi farklı olduğu için sürekli dokümantasyon, kod ve issue’lar arasında gidip gelmek gerekiyor
En büyük sorun JS/TS desteği. Şu anda hack’e yakın entegrasyon yöntemleri kullanılıyor, bu yüzden kararlı değil
Web Containers iyileşme getirdi ama birçok geliştirici çoktan Bun’a geçti
Wasm’ın potansiyeli muazzam
Teorik olarak tüm platformlar için ortak bir derleme hedefi olabilir
Ama gerçekte Figma’nın bazı özelliklerini hızlandırmak düzeyinde kalması biraz hayal kırıklığı yaratıyor
Komite merkezli geliştirme yapısı nedeniyle yavaş ilerlemesi de ayrı bir sınırlama
Native Client döneminde native hızında uygulamalar mümkündü, şimdi Wasm ondan daha yavaş
JS binding yapısı Wasm’a da uygulanabilirdi ama bu fırsat kaçtı
Üstelik Wasm, JS’den de daha hızlı değil
HTML/CSS/JS zaten faydasını kanıtlamışken Wasm hâlâ yabancı bir teknoloji yığını olarak duruyor
Docker merkezli ekosistem ayak bağı oluyor
JS ekosistemindeki birçok build aracı Rust ile yazılıyor ve bazıları tarayıcıda Wasm olarak çalışıyor
React veya npm ekosistemi de içeride Wasm kullanıyor
Wasm ortadan kalkarsa JS frontend dünyası ciddi biçimde sarsılır
Ancak native Wasm UI framework’leri hâlâ yetersiz
DOM ve CSS’ye bağımlı olunması ve tarayıcı API’lerine JS üzerinden erişilmesi verimsizlik yaratıyor
Rust ya da Kotlin ile DOM kontrol edilebilse de Rust, frontend için fazla düşük seviyeli
Mobil cross-compile kullanımı giderek artıyor ve JetBrains Compose Multiplatform bunun bir örneği
Wasm’ın gelişimini engelleyen şey tooling
Debugging hâlâ
printfseviyesinde ve Chrome’un DWARF eklentisi de uzun zamandır güncellenmiyorDillere göre .wasm dosyası üretip import/export ayarlamak karmaşık
GC desteği de tam olmadığı için .NET gibi ekosistemler kendi GC’lerini taşımak zorunda
WIT, başka bir COM/CORBA/gRPC denemesi gibi görünüyor
Emscripten karmaşık ve kararsız, wasi-sdk ise özellik bakımından yetersiz
Hem LLVM hem motor tarafında optimizasyonlar zayıf ve Rust’ın Wasm tooling’i de fiilen durmuş durumda
JS’den Wasm modülünü standart bir şekilde import etmenin bile bir yolu yok
Multithread desteği için COOP/COEP header ayarı gerekiyor, bu yüzden GitHub Pages’de kullanılamıyor
Tooling “teknoloji demosu” düzeyini aşmış olsaydı çok daha yaygın kullanılırdı
Şirketimiz Leaning Technologies, Wasm’ı aktif olarak kullanıyor
WebVM ile tarayıcıda x86 binary’leri çalıştırıyor,
BrowserCraft ile Java uygulamalarını (Minecraft dahil) çalıştırıyor,
BrowserPod ile Node.js container’larını tarayıcıda çalıştırıyor
Çok güçlü ama ileri düzey kullanıcılar için bir araç. Genel frontend mantığını Wasm’a derlemek verimsiz
CheerpJ’nin gelişim hızı etkileyici; 10 yıl önce çıkmış olsaydı web platformu farklı olurdu görüşü paylaşıldı
JS’yi sevmeyenler için JS’siz web siteleri yapmak Wasm’ın asıl çekiciliği
Rust tabanlı Wasm framework’ü Dioxus üzerinde çalışıyorum
Frontend Wasm’da bundle splitting, hot reload, debug symbol ve asset entegrasyonu gibi temel araçların eksikliği sorun olmuştu
2025’te bunların çoğu iyileştirildi ve Vite benzeri araçlarla entegrasyon da daha iyi hâle geldi
Yapay zeka araçları sayesinde Rust geliştirme hızı da arttı; ileride Wasm framework’lerinin daha fazla ilgi göreceğini düşünüyorum
Wasm’ın binary boyutunun çok büyük olduğuna dair eleştiriler vardı
DSL ortamlarında indirme süresi birkaç saniyeden birkaç dakikaya kadar çıkabiliyor
İddiaya göre JS daha küçük ve indirme sırasında da çalıştırılabiliyor
Rust ile derlendiğinde 10~100KB seviyesine indirilebilir
JS indirme sırasında çalışmaz; Wasm ise streaming compile sayesinde daha hızlı başlayabilir
Bu, tarayıcının zaten sunduğu işlevleri tekrar uygulamak anlamına geliyor
Örneğin FSHistory, x86 emülasyonunu 24KB ile gerçekleştiriyor
Ancak native ekosistemler kod boyutu optimizasyonuna alışkın değil
Yazıdaki “Wasm ile yapılmış büyük web siteleri yok” sözü benim deneyimimle örtüşmüyor
Wasm projelerinin amacı hiçbir zaman tüm web uygulamasını değiştirmek değildi
İnsanlar yanlış beklentilere girip sonra “neden olmadı?” diye soruyor gibi görünüyor
Wasm’ı gerçekten çeşitli gerçek dünya kullanım örneklerinde uyguladım
Gerekli kısımlar backend’de ayıklanarak işlenebilir