Wasm yeni CGI’dır
(roborooter.com)- Wasm, CGI protokolü değil;
cgi-binin yaptığı gibi web uygulamalarının çalıştırma birimini ve dağıtım biçimini değiştirecek bir sonraki uygulama modeli olarak görülebilir - CGI, FastCGI, Rack/WSGI ve serverless’ın tamamı istek işleme ve sunucu yönetimini yeniden tasarladı; ortak hedefleri yüksek performanslı uygulamaları daha kolay geliştirmek ve sürdürmekti
- Wasm modülleri host runtime içinde çalışır; izole bellek ve snapshot’lar sayesinde temiz bir çalışma durumu korurken başlatma maliyetini azaltabilir
- Native thread eksikliği, JIT’in mümkün olmaması, veri kopyalama maliyeti, Interface Types ve module linking’in olgunlaşmamış olması Wasm tabanlı sunucu çalıştırma modelinin başlıca kısıtlarıdır
- Serverless function’lar ve edge function’lar Wasm çalışma ortamıyla birleştiğinde cold start ve izolasyon maliyetlerini düşürebilir, farklı dillerdeki modülleri daha hafif biçimde bir araya getirebilir
CGI’dan serverless’a uzanan web uygulaması modeli
- CGI’ın özü, Common Gateway Interface protokolünün kendisinden çok,
cgi-binklasörüne konan script’leri veya çalıştırılabilir dosyaları URL üzerinden çağıran uygulama modelindeydi - Bu yaklaşım, web’i belge arşivinden etkileşimli uygulama ağına dönüştüren erken dönem web uygulaması modeliydi
- Her istek için yeni bir process çalıştıran bir yapı olduğundan, günümüz ölçütleriyle process başlatma ve script parse etme maliyeti büyük bir darboğaz haline gelir
FastCGI ve dile özgü web sunucularındaki değişim
- FastCGI, CGI’ın performans sorunlarını azaltmak için uzun ömürlü process’lerin CGI isteklerini işlediği bir model getirdi
- Web sunucusu her istek için yeni process başlatmak yerine bir veya daha fazla uzun süre çalışan process ile iletişim kurar
- Mevcut CGI uygulamaları, isteğin ardından process’in sonlanacağı varsayımıyla yazıldığından, uzun süre çalışan ortamlarda kaynak sızıntılarına yatkındı
- Daha sonra dil tabanlı web sunucuları yerleşik bir pratik haline geldi ve uygulamalar istek/yanıt modeli etrafında geliştirildi
- Apache veya nginx gibi özellikli ve kendini kanıtlamış web sunucularının arkasına yerleştirerek uygulamayı yavaş isteklerden ve HTTP ayrıntılarından ayırmak yaygındı
- Sunucu implementasyonları, her istek için fork, OS veya dil thread’leri, event ya da reactor modeli gibi çeşitli process yönetimi stratejileri kullandı
- Ruby topluluğundaki Rack arayüzü, Python’un Flask uygulama sunucusunu ve WSGI spesifikasyonunu da etkiledi
- Basitleştirirsek istek; HTTP metodu, header hash map’i, giriş byte string’i veya stream’den oluşur
- Yanıt; status code, header nesnesi, yanıt byte string’i veya stream’den oluşur
Cloud autoscaling ve serverless’ın ödünleşimleri
- Fiziksel sunucu veya sanal sunucu tabanlı modellerde çalışan sunucu sayısını doğrudan yönetmek gerekiyordu
- Trafik yüksek olduğunda uygulama sunucusu yavaşlayabilir
- Trafik düşük olduğunda birçok bilgisayar boşta kalabilir
- Cloud’daki autoscaling, CPU, bellek yükü ve saat dilimine göre uygulama sunucusu sayısını ayarlamayı mümkün kıldı
- Yeni bir bilgisayarı ölçekleyip devreye almak, uygulama ve yapılandırmaya bağlı olarak 2-20 dakika sürebilir
- Ölçekleme, cloud hosting region’ındaki mevcut kaynaklara da bağlıdır
- Amazon Lambda ile API Gateway birleşiminden oluşan serverless compute, sunucular yerine function’ların yönetildiği bir model yarattı
- Her istek için tek bir process, izole CPU ve izole bellek garanti eder
- Process birkaç saate kadar yeniden kullanılabilir, ancak kullanılmazsa askıya alınır veya kaldırılır
- AWS, istek hacmine göre saniyeler içinde ölçeği büyütüp küçültebilir
- Serverless’ın belirgin trade-off’ları vardır
- Yeni process maliyeti nedeniyle eşzamanlı istekler ölçeklenirken bazı istekler cold start yaşar
- Yanıtın ardından process askıya alınabildiği için istekler arasında kalıcı TCP bağlantılarını yönetmek zordur
- HTTP tabanlı veritabanı API’leri, çok sayıda bağlantıyı kaldırabildiği ve function’larla birlikte kolayca büyüyüp küçülebildiği için serverless modelde popülerdir
- Her istek için ayrılmış CPU ve bellek sağlama özelliği, workload’a göre avantaj da dezavantaj da olabilir
- Bazı workload’lar kaynak yönetimini azaltıp maliyet ve ölçekleme kaygılarını düşürebilir
- Diğer workload’lar, tek bir process’in çok sayıda isteği işlemesi ya da paylaşımlı bellekle batching ve caching’den yararlanması durumunda daha verimli olabilir
- CMS tabanlı bir web uygulamasını serverless’a taşıyarak maliyeti %90 azaltan örnekle, event analytics servisini sunucu tabanlı modele taşıyarak maliyeti %90 azaltan örnek birlikte sunuluyor
Sunucuda Wasm çalıştırma modeli
- Wasm başlangıçta tarayıcıda yüksek performanslı kod çalıştırmak için geliştirildi ve asm.js gibi girişimlerle de bağlantılıdır
- WebAssembly, stack tabanlı bir sanal makine için binary instruction format’tır ve çeşitli programlama dilleri için taşınabilir bir compile target olarak tasarlanmıştır
- Web’in istemci ve sunucu uygulama dağıtımını mümkün kılar
- Boyut ve yükleme süresi açısından verimli bir binary format olarak encode edilecek şekilde tasarlanmıştır
- Farklı platformların ortak donanım özelliklerinden yararlanarak native hıza yakın çalışmayı hedefler
- Günümüzde birçok dil Wasm instruction’larına derlenip hem tarayıcıda hem sunucuda çalıştırılabilir
- Tarayıcının gerektirdiği izolasyon ve güvenlik modeli, sunucu uygulamaları için de faydalıdır
- Güvenilmeyen kodu VM veya Docker container’dan çok daha hafif biçimde izole edebilir
- Node.js, Cloudflare Workers ve Deno gibi V8 tabanlı serverless ortamlar, tarayıcıda birikmiş Wasm çalıştırma yetkinliğinden yararlanır
- Fastly, Shopify ve Suborbital gibi Wasm-native ortamlar da mevcuttur
Modül, host, bellek, snapshot
- Wasm modülleri sanal makine komutları olduğundan çalışmak için bir runtime gerektirir
- Runtime, genel Wasm’ı yerel mimariye uygun şekilde derler ve çalışma ortamını sağlar
- Bazı ortamlar Linux sistemlerinin POSIX API’sine benzer arayüzler sağlar
- Bazı ortamlar yalnızca host sistemin belirli function’larını sağlar ve modülün export function’larının çalıştırılmasını sağlar
- WebAssembly programları modules birimleri halinde yapılandırılır; modülü çalıştıran VM’e host denir
- Modül; dağıtım, yükleme ve derleme birimidir
- Type, function, table, memory ve global value tanımlarını bir araya getirir
- import ve export bildirebilir; data segment, element segment ve start function biçiminde initialization sağlayabilir
- Wasm’daki “memories”, kesintisiz ardışık byte array’ler olarak temsil edilir ve host tarafından instantiation sırasında ayrılır
- Her guest modül bellek izolasyonu elde eder
- Bu bellek sanal makinenin RAM’i gibi davranır
- Boş olarak sağlanabilir veya data segment’lerle önceden doldurulabilir
- Modül izolasyon yöntemi sayesinde modül askıya alınabilir ve bellek data segment olarak kaydedilebilir
- Bu, sanal makine snapshot’ına benzer bir kavramdır
- Askıya alınmış modülün birden fazla kopyası başlatılabilir
- Wizer, Wasm modülünü instantiate eder, initialization function’ını çalıştırır ve ardından instance durumunu kaydedip Wasm binary’sini yeniden yazar
- Global value’ların durumunu doğrudan initialize eder
- Sıfır olmayan bellek bölgelerini kaydeder
- Mevcut data segment’leri kaldırır ve kaydedilen bellek bölgelerine ait data segment’lerle değiştirir
- Bu yöntem, yeni process gibi temiz bir çalışma sağlarken yeni process’in başlatma maliyetinden kaçınır
- CGI’ın dezavantajları olmayan CGI’a yakındır
- Modern ifadeyle cold start’sız serverless’a yakındır
Wasm’ın kısıtları ve avantajları
- Wasm, native yapılandırmada thread içermez
- Blocking işler host method’larına taşınmalıdır
- Host, dosya veya ağ arayüzü okuma/yazma wrapper’ları sağlayabilir, modülü askıya alabilir veya callback handler sağlayabilir
- Reactor modeli veya blocking model kurulabilir; ancak thread proposal uygulanana kadar çalışma ortamı tasarımı büyük önem taşır
- Güvenlik gerekçesiyle dinamik Wasm kod üretimine izin verilmediğinden JIT compilation mümkün değildir
- Runtime’da kodun kendisi adres olarak ele alınamaz
- Performansı JIT’e dayanan V8, CRuby gibi çalışma ortamları Wasm VM içinde çalışamaz ya da JIT’ten vazgeçmek zorunda kalır
- Script’ler için optimize runtime’ı build aşamasında çıktı olarak üreten “pre-jit” yaklaşımı önerilmiştir, ancak yaygın kullanılmamıştır
- Wasm modülü ile host arasındaki temel arayüz bellek olduğundan veri taşıma kopyalama gerektirebilir
- Memory chunk paylaşımı mümkündür, ancak mümkün veya önerilir olup olmadığı runtime’ın bellek modeline göre değişir
- Çoğu runtime’da modül ile I/O işleri arasında zero-copy iletişim zor kabul edilir
- Streaming veriyi Wasm modülünün içine ve dışına taşımak, host’ta işlemekten daha yavaş olabilir
- Wasm VM, kullanım kontrolü açısından yüksek denetim sağlar
- Bazı runtime’lar Wasmtime fuel concept gibi CPU instruction sayısını sayarak CPU limitini zorlayabilir
- VM bellek ve wall clock süresini sınırlayabilir
- Interface Types ve module linking, modül boyutunu azaltıp I/O hızını ve kullanılabilirliği iyileştirebilir
- Interface Types kullanılabilir, ancak henüz onaylanmış bir standart değildir
- Module linking’in çalışan prototipleri vardır, ancak standart yaklaşım henüz yoktur
- Wizer şu anda module linking ile çakışabilir; bunu çözen custom yaklaşımlar olsa da net bir kazanan yoktur
- Interface Types, dil bağımsız nesnelerin Wasm bellek sınırından pahalı encode/decode işlemleri olmadan geçebilmesini hedefler
- Günümüzde yaygın yöntem JSON’u belleğe kopyalayarak içeri ve dışarı taşımaktır
- Wasm modülleri varsayılan olarak yalnızca kendilerine verilenlere erişebildiği için güvenlik modeli küçük ve nettir
- Güvenilmeyen Wasm kodunu çalıştırmak genel olarak oldukça güvenlidir
- VM’in attack surface’i Docker veya diğer izolasyon modellerinden daha küçüktür
- Host donanımında çevrilmiş instruction’lar çalıştırıldığı için timing attack mümkündür, ancak azaltıcı önlemler vardır
- Wasm native binary’ye de derlenebilir, ancak attack surface daha da büyür
Edge function’lar ve Wasm tabanlı function çalıştırma
- Wasm çalışma ortamları ve geliştirme araçları yaygınlaşırsa script dilleri de Wasm runtime ve Wizer gibi preboot yaklaşımlarını edinmeye zorlanabilir
- Teorik olarak uygulamalar her istek için snapshot alınmış bir kopyadan devam ederek mevcut diğer modellerden daha hızlı çalışabilir
- Yerel CLI de Ruby ile yazılıp snapshot alınmış Wasm modülü olarak dağıtılır ve Wasm Ruby runtime’a bağlanırsa, C++ utility’lere yakın başlatma süreleri elde edebilir ve yalnızca proje dizini içinde çalışacak şekilde sınırlandırılabilir
- İlk büyük değişim, function’ları kullanıcıya yakın edge’e taşımaktır
- Compute, veritabanına yakın değil kullanıcıya yakın yerde yapılır
- Vercel Edge Functions, V8 tabanlı olsa da birçok ilkeyi paylaşan bir örnek olarak sunulur
- next-auth, JWT login token’larına dayanarak önceden render edilmiş sayfalara erişimi kontrol edebilir
- CDN’de cache’lenmiş verilerden oluşan dinamik kişiselleştirilmiş içerik sunulabilir
- Bir başka değişim, serverless uygulamalarda process tabanlı function’ları Wasm tabanlı function’larla değiştirmektir
- Suborbital, Wasm tabanlı function çalıştırma ortamını doğrudan oluşturmayı sağlar ve Wasm function’larını workflow’lar halinde zincirleme yöntemi de sunar
- Birçok execution platform’u istek başına tek modül önerir ve bellek paylaşımı ya da birden fazla modülün hızlı çağrılabilmesi olanaklarından yeterince yararlanmıyor olarak ele alınır
- Interface Types standartlaşırsa Rack’e benzer bir middleware veri modeli ortaya çıkabilir
- Wasm, Lambda function içinde de çalıştırılabilir
- Mevcut altyapıda snapshot alınmış uygulama sürümleri kullanılabilir
- Bu birleşim ilginç olsa da sonunda ortadan kalkabilecek bir teknoloji karışımı olarak ele alınır
Bir sonraki web uygulaması modelinin yönü
- Wasm; performansı artırabilen, process düzeyi güvenliği kolaylaştırabilen, serverless function’ların build ve çalıştırma maliyetini düşürebilen bir teknoloji olarak sunulur
- Neredeyse tüm dilleri çalıştırabilir; module linking ve Interface Types ile function’lar arasındaki gecikmeyi ciddi ölçüde azaltabilir
- Sistemin kısıtları değiştiğinde daha önce imkânsız olan şeylerin mümkün hale gelmesi, Wasm’ı yeni CGI olarak görmenin temel gerekçesidir
1 yorum
Hacker News yorumları
WASM’in Java Applet, ActiveX, Silverlight, Macromedia Flash gibi eski teknolojilerden ne farkı olduğunu pek anlayamıyorum.
Tarayıcıda güvenilmeyen üçüncü taraf derlenmiş kodu çalıştırma konusunda dersimizi aldığımızı sanıyordum; ayrıca müşteri deneyimini iyileştirme bahanesiyle sunucunun hesaplama maliyetini istemciye aktaran bir yapı gibi görünüyor.
Uygulamalarında çok sayıda güvenlik açığı vardı ve sonunda tarayıcılarda fiilen kullanılamaz hale geldiler; diğer teknolojiler ise sanırım baştan böyle bir vaatte bile bulunmamıştı.
JavaScript bu vaadi gerçekten yerine getirdi ve günümüzde tarayıcılar, hangi alan adından indirilmiş olursa olsun JavaScript’i kullanıcıya güvenip güvenmediğini sormadan çalıştırıyor.
WASM, JavaScript motorunun üzerinde çalışıp benzer güvenlik garantileri sunduğundan JVM bytecode’undan temelde farklı değil; pratikteki fark ise WASM’in güvenliğini kanıtlamış olması, JVM’in ise bunu başaramamış olması.
Artık Google Chrome, milyarlarca kişi kötü niyetli WASM çalıştırsa bile telefonlarının ele geçirilemeyeceği kadar güvenli; bu motoru sunucuya taşıyıp birden çok kullanıcının betiklerini güçlü bir sandbox içinde çalıştırarak kaynakları paylaşmalarını sağlayabilirsiniz.
Alternatif sanallaştırma: kodu WASM yığınına derleyip büyük bir WASM sunucusunda çalıştırmak ya da amd64 ikilisiyle kırpılmış bir Linux çekirdeğini paketleyip VM’de çalıştırmak mümkün.
Şu anda hangi tarafın açık ara kazanan olduğunu söylemek zor; her yaklaşımın artıları ve eksileri var.
JVM’den farklı olarak WASM doğrusal bellek sağlar ve varsayılan olarak çöp toplama içermez; bu yüzden C/C++’ı Emscripten ile derlemek ya da Rust’ı hedeflemek gibi daha geniş bir dil kümesi için derleme hedefi olmaya uygundur.
WASM bir bytecode’dur ve çoğu uygulamanın ana makine JavaScript motoru ve runtime’ı ile büyük ölçüde ortak bileşenler paylaştığını düşünüyorum.
İstemci ile sunucu arasında hesaplama maliyetinin yer değiştirmesi, sektörün uzun zamandır kalın istemci ile ince istemci arasında gidip gelen akışının bir parçası; bu sarkaç gelecekte de hareket etmeye devam edecek.
Wasm bytecode’unun uyması gereken bir doğrulama spesifikasyonu var ve bu doğrulanmış alt küme sayesinde geçmiş teknolojilerde gördüğümüz güvenlik açıklarının önemli bir kısmı en baştan imkânsız hale geliyor.
Heartbleed veya Rowhammer gibi donanımın hatalı davranışına dayanan saldırılar mümkün olabilir; ancak örneğin VM’i bir sayıyı işaretçi gibi yorumlamaya kandırıp kendi Wasm belleğinin dışına başvurtmak gibi bir şey yapılamaz.
Wasm bytecode’unu makine koduna çevirmek oldukça basit olduğundan, bir VM kullanmaya kıyasla uygulaması daha küçük ve hızlı olabilir.
Belirli bir şirketin mülkiyetinde değildir; herkesin kullanabileceği, iyi yazılmış herkese açık bir spesifikasyonu vardır ve web standardı olarak benimsendiği için tarayıcı eklentisi gerektirmez.
İstemci tarafı hesaplama JavaScript’te de zaten olan bir şey; Wasm kodu JavaScript’le mümkün olmayan şekillerde verimli olabildiği için bu durum hatta daha da geçerli.
Applet’lerde bu bir ölçüde, ActiveX’te ise neredeyse hiç aracılanmıyordu; WASM’in “dış platformu” kabaca JavaScript runtime’ı iken Applet’in dış platformu execve(2)’ye daha yakındır.
WASM bunu da yapabilir ama her zaman böyle değildir; daha iyi sandboxing ve izolasyon gibi farkları da diğer yanıtlar zaten iyi biçimde ele almış.
“Amazon, Lambda ile serverless computing çağını başlattı” demek için Google App Engine 2008’de çıkmıştı ve Lambda’dan 6 yıl önceydi.
Bu tür ürünler zaten birkaç yıldır vardı ve adları da vardı; neden “serverless” adının takıldığını, bunun nereden geldiğini pek bilmiyorum.
App Engine’de de batch worker ve web worker vardı; Heroku’da da aynı şekilde.
İkisi de Docker öncesi ürünler olduğu için insanlar farklı hissediyor olabilir; ama Lambda’nın da en baştan Docker ile çıktığını sanmıyorum.
“Güvenlik gerekçesiyle dinamik Wasm kodu üretimine izin verilmediği için JIT derleme mümkün değil” ifadesi bana doğru görünmüyor
Temiz kod hot reloading gibi işleri mümkün kılmak için neredeyse temel bir özellik
Güvenlik mantığının zayıf olduğunu düşünüyorum
JS, çalışma sırasında hot reload ya da daha radikal kod üretimini güvenliği bozmadan yapabiliyor; Wasm runtime’ının tamamını dinamik olarak yeniden yükleyip belleği korursanız kod üretimini ya da hot reload’u taklit etmek de mümkün olabilir ama kullanıcı deneyimi hantal olur
Teknik olarak imkânsız olması için bir neden göremiyorum; eğer bu bir güvenlik önlemiyse çok kolay aşılabilir gibi görünüyor
WASM bytecode’u kavramsal olarak .NET IL ya da Java bytecode’u gibi JIT derleme düşünülerek tasarlanmış şeylere çok benziyor
WASM’i, güçlü bir yönü ve zamanında başarılı kılma iradesi eksik bir proje gibi gördüğüm için pek sevmiyorum
Adı “web için assembly”, yani sanal bir CPU için makine dili çağrıştırıyor; ama gerçekte derleyici backend’leri için bir ara temsil ve çöp toplama desteği gibi üst seviye özellikler de planlandığından kavramı belirsiz
Az önce bahsettiğim hot reload, hack’e yakın olmayan threading, JavaScript olmadan DOM ile doğrudan entegrasyon, düşük ek yük getiren grafik/hesaplama API’leri, düşük seviyeli ses erişimi gibi temel özellikler de hâlâ eksik
Büyük multimedya uygulamalarını büyük tavizler vermeden çalıştırmak zor
Wasm belleği yürütülebilir olarak işaretleyemez ve fiilen Harvard mimarisi gibi kod ile bellek ayrıdır
Üstelik kodun rastgele bir konumuna atlayamazsınız; atlama komutu bile yoktur
Burada JIT, çalışma sırasında yerel kodu derleyip çalıştırmak anlamına gelir; tarayıcıda ya da Wasm sandbox’ında bu büyük bir güvenlik zafiyeti olur
Bu, tasarıma ve komut kümesine gömülüdür; kolayca aşılabilecek bir şey değildir. Ayrıntılar https://webassembly.org/docs/security/ adresinde görülebilir
Wasm de JIT’i motorun üstlenmesi açısından .NET IL ya da Java bytecode’una benzer; ancak kullanıcıya runtime’ın dışına çıkıp yerel kod üretme ve oraya atlama yetkisi vermek tehlikelidir
Bu yüzden JIT’te olduğu gibi WASM kodunu ilk çalıştırırken küçük bir “ısınma takılması” görülebilir; ancak son birkaç yılda çok daha iyi hâle geldi
Ayrıca tarayıcıda WASM parçalarını dinamik olarak oluşturup örnekleyerek çalıştırmanın mümkün olduğunu biliyorum
Diğer WASM runtime’larında mümkün mü bilmiyorum; tarayıcıda da JavaScript üzerinden geçmek gerekiyor ama herhangi bir “web API”ye erişmeye çalıştığınızda zaten buna ihtiyaç var
WASM, JavaScript VM’i gibi belirli bir dile özel VM’i, JavaScript VM’inin kullanıldığı her yerde kullanılabilen genel amaçlı bir VMe dönüştürüyor
Elbette yalnızca oralarla sınırlı değil
Genel amaçlı demek, bir derleyici ya da yorumlayıcı olduğu sürece neredeyse her şeyi çalıştırabileceği anlamına gelir; buna JavaScript de dahil
Çoğunlukla JavaScript motorunun bir parçası olarak uygulandığı için sandboxing ve ilgili API erişimi gibi özelliklerin çoğunu miras alır
Bu erişimi standartlaştırma işi hâlâ sürüyor; ancak sonunda bugün yalnızca JavaScript ile mümkün olan işler WASM’de de mümkün hâle gelecek, JavaScript ile zor ya da imkânsız olan daha fazla iş de yapılabilecek
Daha hızlı ve akıcı da çalışabilir
WASM’in özü, JavaScript’in popüler olduğu ortamlardaki birçok kısıtı kaldırmasında yatıyor
JavaScript insanların sevip sevmediği konusunda keskin ayrıldığı bir dil; yani tek seçenek olmaktan çıkıp seçeneklerden biri hâline geliyor
WASM, JavaScript alternatifi, Docker alternatifi, Java alternatifi, CGI alternatifi olarak da tarif edildi; kısaca söylemek gerekirse bunların hepsi ve daha fazlası
Benzer işler yapan çok fazla araç var ve sınırları belirsiz
Sonunda her şeyi çalışır hâle getirseniz bile kişisel olarak bana kırılgan geliyor; bunu profesyonel olarak yapmayan biri için de göz korkutucu
Bugünlerde web için bir şey yapmam gerektiğinde leptos kullanıyorum; geliştirici deneyimi çok daha iyi. Henüz 1.x bile değil ama JS bundle’ını transpile etmek, obfuscate etmek, küçültmek ve paketlemek için 5 aracı birbirine bağlamaktan daha sağlam hissettiriyor
Bu yazı bana eskiden sıkça dile getirilen bir yazılım yasasını hatırlattı
Yeterince büyük ve uzun ömürlü bir uygulama, sonunda üzerinde çalıştığı tüm yazılım yığınını, işletim sistemini bile yeniden uygular; hem de bunu berbat şekilde yapar
Kaynağını pek bilmiyorum ama çoğu durumda genel olarak doğru çıkıyor
“Yeterince karmaşık herhangi bir C ya da Fortran programı, Common Lisp’in yarısını geçici çözümlerle, gayriresmî bir spesifikasyona göre, bol hatalı ve yavaş biçimde uygular”
Daha genel örüntüye Inner-Platform Effect denir
Başlıktaki önermeyi genişletirsek, WASM’in bu silsilenin gerçek varisi olabilmesi için herhangi bir hosting sağlayıcısının LAMP stack’inde PHP uygulaması yükleyip dağıtmak kadar kolay olması gerekir
Şimdilik PHP dağıtım deneyimi kadar kolay değil gibi
Hosting tarafında neyin değişmesini bekliyorsunuz, bilmiyorum
Ben bunu farklı görüyorum
Geleceğin yerel öncelikli olduğunu düşünüyorum
Uygulamaların sunucudan neredeyse hiç yardım almadan, büyük ölçüde kullanıcının tarayıcısı içinde çalıştığı bir model
Figma, Linear, Superhuman gibi uygulamalar bu modeli çok başarılı biçimde kullanıyor; Stackblitz de bir ölçüde öyle
Figma kadar karmaşık bir uygulama kullanıcının tarayıcısı içinde neredeyse tamamen çalışabiliyorsa, çoğu uygulamanın da bunu yapabileceğini düşünüyorum
Sunucu tarafı esas olarak, kullanıcı uygulamayı birden fazla konumdan kullandığında farklı örnekler arasında veriyi senkronize etme rolünü üstlenir
Electric-SQL gibi araçlar geliştiriliyor ama henüz olgun değiller; bu tür kütüphaneler olgunlaştığında bu alan büyük ölçüde büyüyecek
Serverless çoğunlukla Amazon ve Azure gibi şirketlerin para kazanması için var ve sonunda CGI gibi olacak
WASM de başarılı olabilir, ama büyük olasılıkla esas olarak kullanıcının tarayıcısı içinde
Microsoft, C#/Blazor’da WASM kullanıyor, ancak tarayıcı içindeki dotnet’in JavaScript kadar hızlanacağını sanmıyorum; bu yüzden bunun doğru yaklaşım olmadığını düşünüyorum
Saniyede 1 trilyon reklam gösterimine ölçeklenemediği için kimse bundan bahsetmiyor
Serverless fonksiyonlar, biri her yazdığında Bezos’un yatına 10 fit daha ekliyor
Çevrimdışıysanız ya da Wi-Fi’ın güvenilmez olduğu bir yerdeyseniz tasarımı yükleyemezsiniz; yakın zamanda değişmediyse, düzenleme yaptıktan sonra Wi-Fi kesikken tarayıcıyı kapatırsanız kaydedilmez
Üstelik bu hiç de yeni bir fikir değil
Biz Blazor WASM geliştiriyoruz ve performans açısından dotnet sorun değil
Temelde JVM’i ve ekosistemini yeniden yapmak mı bu?
Geçmiş dersleri dikkate alarak X’i yeniden yapmak bazen gerçekten harika bir fikir olabilir
Örneğin 2010 civarında tarayıcıda C/C++ kodu çalıştırmayı araştırmaya başladığımızda, C/C++’ı JVM’e derlemek fiilen imkânsızdı
O zamanlar Java Applet hâlâ anlamlıydı; mümkün olsaydı iyi olurdu, ama WASM de henüz yoktu, Emscripten vardı ve o da asm.js üzerinden sonunda WASM’in doğmasına yol açtı
2000’lerde programlama dilleri dersinde class loader’larla uğraşmış ve JVM assembly’sini elle yazmış biri olarak, JVM’in bu alanın zirvesi olduğundan da pek emin değilim
Büyük bir ekosistemi mümkün kıldığı doğru, ama JVM’in dış dünyayla temas eden arayüzü gerçekten hantal bir keşmekeş
20 yılı aşkın süredir JVM’le ilgili bir şeyle her karşılaştığımda içimden inlemek geldi
Rust’ın paketleme ve ekosistemini Python’la ya da daha da kötüsü C++’la karşılaştırınca, son birkaç on yılın derslerini yansıtan yeniden icatların çok iyi bir şey olabileceğini gösteriyor
İki wasm dosyasını tek dosyada birleştirmek ve bellek birleştirmesini doğru ayarlamak hâlâ çok zor
Component model bunu düzeltebilir, ama gereksiz yere şişkin çok fazla unsur var; Safari’nin benimsemesine kadar uzun zaman geçebilir
Uzun zamandır WASM’in buluttaki Lambda fonksiyon kodunun yerini alacağı bir dünyaya gideceğimizi düşünüyordum
WASM geleneksel olarak host platform üzerinde çalışan bir şey olarak görülür, ama bunun mutlaka böyle olması için bir neden yok
WASM’in sandbox niteliği nedeniyle teknik olarak işletim sisteminin dışında ya da ring0’da çalıştırılıp işletim sistemi overhead’inin büyük kısmı aşılabilir
WASM’e derlemek, kullanıcı açısından birçok dağıtım sorununu çok daha basitleştirir; barındırma ortamı için de optimizasyon alanı büyür
WASM’i daha hızlı çalıştıran özel donanımlar bile mümkün olabilir
Rastgele güvenilmeyen kaynaklardan gelen rastgele güvenilmeyen kodu otomatik çalıştırmak zorunda olmak kötü; bunun sunucu tarafı CGI ile aynı rolü doldurduğu da söylenemez