#webasm

By now, you might have heard about WebAssembly. However it still seems rather new to a lot of web developers out there. So what is it? It’s really an open standard that includes an assembly language and a binary format for use in applications, such as those that run in a browser. Essentially, It allows for different languages to be run on the web, which can be very useful for enabling high-performance apps on the browser. Ever wanted to run your C++ high-performance graphics application in the browser? Now you can!

Before WebAssembly there was asm.js: a highly optimizable subset of JavaScript designed to allow other languages to be compiled into it while maintaining high performance characteristics that allowed applications to run much faster than regular JavaScript. So web applications now had a way to perform more efficiently on the browser. Compilers to JavaScript existed before asm.js, but they very terribly slow. WebAssembly, however, went one step further and completely took JavaScript out of the picture. This is now done with Wasm (WebAssembly for short) by compiling a language such as C++ into a binary file that runs in the same sandbox as regular JavaScript. A compiler capable of producing WebAssembly binaries, such as Emscripten, allows fo the compiled program to run much faster than the same program written in traditional JavaScript. This compiled program can access browser memory in a fast and secure way by using the “linear memory” model. Basically this means that the program can use the accessible memory pretty much like C++ does.

WebAssembly is useful for facilitating interactions between programs and their host environments, such as on devices which translate higher code into byte-size code. It is also useful in heavier-weight applications. For example, you can now run CAD software on the browser. WebAssembly removes some limitations by allowing for real multithreading and 64-bit support. Load-time improvements of the compiled programs can be achieved with streaming and tiered compilation, while already compiled byte code can be stored with implicit HTTP cacheing. WebAssembly can sometimes even be faster than native code, and is being utilized in things like CLI tools, game logic, and OS kernels.

Still, there are some things that WebAssembly lacks. Calls between WebAssembly and JavaScript are slow, lacking ES module integration and without a means for easy or fast data exchanges. Toolchain integration and backwards compatibility can also be largely improved on. When transpiling from other languages, garbage collection integration is not great; neither is exception support. Debugging is also a pain, as there is no equivalent of DevTools for WebAssembly.

But the advantages of using WebAssembly are still very intriguing: JavaScript that runs on the browser puts all of its code in a “sandbox” for security purposes; however, with WebAssembly, you can have the browser sandbox, while taking the code out of the browser and still keeping the performance improvements! This could better than Node’s Native Modules, although WebAssembly doesn’t have access to system resources without having to pass system functions into it.

Scott Hanselman’ın meşhur sözü artık ata sözü kıvamına geldi: JavaScript, web’in assembly dilidir. Bunu doğrulayan da çok çaba oldu. Google “Native Client” diye bir işe girişti. Mozilla, asm.js’i yaptı, kullandı. Her biri, JavaScript’in her seferinde bir metin dosyasından okunup yorumlanan ikliminden makine koduna daha yakın, byte-code seviyesine derlenmiş hâlini hedefledi. Daha hızlı, daha güçlü ve daha doğal web işçiliği için.

Şimdi geldiğimiz yer ise webasm. Herkesin kendi kendine denediği ara JavaScript formuna artık büyük oyuncuların katkı sağladığı bağımsız bir ekip devam edecek. Bu adamların her birinin elinde internet gezgini var. Ve masada olmaları önemli.

Çıkan ürün, ümit edilir ki tüm gezginlerce desteklenecek ve web uygulamaları, daha bir doğal, daha bir semiz olarak mücadelesini sürdürecek. 

Geliştiricinin hayatına etkisi ne olacak? 

Script’ler gezgine okunabilir metin dosyaları olarak değil, byte-code’a derlenmiş assembly’ler olarak gelecek. Gezgin de üzerinde çalıştığı işlemci mimarisine göre daha az eforla makine koduna dönüşüm yapıp mantığı icra edecek. Geri sararsak, geliştiricinin de uygulamalarındaki script’leri artık bir derleyiciden geçirerek sunması demek bu. TypeScript ve CoffeeScript gibi JavaScript’e derleyen soyutlayıcılarla zaten bu deneyime alışkın olan web emekçileri, tahminimce bu noktada sıkıntı çekmez. 

Gezgin tarafında da eğer webasm desteği yoksa, evrenselleşme yolunda giden asm.js’e düşerek durumu kurtarma planı varmış. Asm.js’in Chrome ve IE tarafında desteklenmesi an meselesi. 

İlginç bir yoldan geçiyoruz. Web, doğuşundaki yoğun ve güçlü soyutlama ilkesini endüstrideki akıntılardan dolayı kaybediyor ve artık, neredeyse işlemciyle birebir yazışacak yakınlığa geliyor. İşlemcilerin mimarilerinin bu kadar çeşitlendiği ve web’in de bu kadar dallandığı budaklandığı karmaşada bu iki katmanın iletişiminin yükünü yine programcılar maharetli elleriyle üstleniyor ve başarıyor.