Wasm adalah CGI yang baru

• Wasm bukanlah protokol CGI, melainkan bisa dilihat sebagai model aplikasi berikutnya yang akan mengubah unit eksekusi dan cara deployment aplikasi web, seperti yang pernah dilakukan cgi-bin
• CGI, FastCGI, Rack/WSGI, dan serverless semuanya telah merancang ulang pemrosesan request dan pengelolaan server, dengan tujuan bersama untuk membuat aplikasi berkinerja tinggi lebih mudah dibuat dan dipelihara
• Modul Wasm berjalan di runtime host, dan melalui memori terisolasi serta snapshot dapat mengurangi biaya startup sambil mempertahankan status eksekusi yang bersih
• Ketiadaan thread native, tidak bisa JIT, biaya penyalinan data, serta belum matangnya Interface Types dan module linking adalah batasan utama model eksekusi server berbasis Wasm
• Jika fungsi serverless dan edge function digabungkan dengan lingkungan eksekusi Wasm, biaya cold start dan isolasi dapat diturunkan, dan modul dari berbagai bahasa dapat dikomposisikan dengan lebih ringan

---

Model aplikasi web dari CGI hingga serverless

• Inti CGI bukanlah protokol Common Gateway Interface itu sendiri, melainkan model aplikasi yang memanggil skrip atau file executable yang diletakkan di folder cgi-bin lewat URL
• Cara ini adalah model aplikasi web awal yang mengubah web dari arsip dokumen menjadi jaringan aplikasi yang dapat berinteraksi
• Karena strukturnya menjalankan proses baru untuk setiap request, menurut standar saat ini biaya startup proses dan parsing skrip menjadi bottleneck besar

Perubahan FastCGI dan web server per bahasa

• FastCGI memperkenalkan model di mana proses yang hidup lama menangani request CGI untuk mengurangi masalah performa CGI
  • Web server berkomunikasi dengan satu atau lebih proses jangka panjang tanpa menjalankan proses baru untuk setiap request
  • Aplikasi CGI yang sudah ada dibuat dengan asumsi proses berakhir setelah request, sehingga di lingkungan jangka panjang mudah terjadi kebocoran resource
• Setelah itu, web server berbasis bahasa menjadi konvensi, dan aplikasi dibuat dengan berpusat pada model request/response
  • Umumnya aplikasi ditempatkan di belakang web server yang kaya fitur dan teruji seperti Apache atau nginx, sehingga aplikasi dipisahkan dari request lambat dan detail HTTP
  • Implementasi server menggunakan berbagai strategi manajemen proses, seperti fork per request, thread OS atau bahasa, event, atau model reactor
• Antarmuka Rack dari komunitas Ruby juga memengaruhi server aplikasi Flask di Python dan spesifikasi WSGI
  • Secara sederhana, request terdiri dari metode HTTP, hashmap header, serta string byte input atau stream
  • Response terdiri dari kode status, objek header, serta string byte response atau stream

Autoscaling cloud dan kompromi serverless

• Dalam model berbasis server fisik atau server virtual, jumlah server yang berjalan harus dikelola sendiri
  • Jika traffic tinggi, server aplikasi bisa melambat
  • Jika traffic rendah, banyak komputer bisa tetap menganggur
• Autoscaling di cloud memungkinkan jumlah server aplikasi disesuaikan berdasarkan CPU, beban memori, dan waktu
  • Menambah komputer baru bisa memakan waktu 2–20 menit, tergantung aplikasi dan konfigurasinya
  • Scaling juga bergantung pada resource yang tersedia di region hosting cloud
• Komputasi serverless yang menggabungkan Amazon Lambda dan API Gateway menciptakan model yang mengelola fungsi alih-alih server
  • Menjamin satu proses, CPU terisolasi, dan memori terisolasi untuk setiap request
  • Proses dapat digunakan kembali hingga beberapa jam, tetapi akan dijeda atau dihapus jika tidak digunakan
  • AWS dapat scale up dan scale down dalam hitungan detik sesuai volume request
• Serverless memiliki trade-off yang jelas
  • Karena biaya proses baru, saat memperluas request konkuren sebagian request mengalami cold start
  • Proses dapat dijeda setelah response, sehingga pengelolaan koneksi TCP persisten antar-request menjadi sulit
  • API database berbasis HTTP populer dalam model serverless karena dapat menahan banyak koneksi dan mudah scale up/down bersama fungsi
• Karakteristik menyediakan CPU dan memori khusus untuk setiap request bisa menjadi kelebihan maupun kekurangan, tergantung workload
  • Sebagian workload dapat mengurangi manajemen resource serta menurunkan kekhawatiran biaya dan scaling
  • Workload lain bisa lebih efisien ketika satu proses menangani banyak request atau memanfaatkan batching dan caching dengan memori bersama
  • Disajikan bersama contoh aplikasi web berbasis CMS yang dipindahkan ke serverless dan memangkas biaya 90%, serta layanan analitik event yang dipindahkan ke model berbasis server dan memangkas biaya 90%

Model eksekusi Wasm di server

• Wasm awalnya dikembangkan untuk menjalankan kode berkinerja tinggi di browser, dan juga terkait dengan upaya seperti asm.js
• WebAssembly adalah format instruksi biner untuk mesin virtual berbasis stack, dan dirancang sebagai target kompilasi portabel untuk berbagai bahasa pemrograman
  • Memungkinkan deployment aplikasi klien dan server di web
  • Dirancang agar dienkode dalam format biner yang efisien untuk ukuran dan waktu loading
  • Bertujuan menjalankan program dengan kecepatan mendekati native dengan memanfaatkan kemampuan hardware umum di berbagai platform
• Saat ini, berbagai bahasa dapat dikompilasi menjadi instruksi Wasm dan dijalankan baik di browser maupun server
• Model isolasi dan keamanan yang dibutuhkan browser juga berguna untuk aplikasi server
  • Kode yang tidak tepercaya dapat diisolasi dalam bentuk yang jauh lebih ringan daripada VM atau container Docker
• Lingkungan serverless berbasis V8 seperti Node.js, Cloudflare Workers, dan Deno memanfaatkan kemampuan eksekusi Wasm yang telah terakumulasi di browser
• Ada juga lingkungan native Wasm seperti Fastly, Shopify, dan Suborbital

Modul, host, memori, snapshot

• Karena modul Wasm adalah instruksi untuk mesin virtual, dibutuhkan runtime untuk mengeksekusinya
  • Runtime mengompilasi Wasm umum agar sesuai dengan arsitektur lokal dan menyediakan lingkungan eksekusi
  • Sebagian lingkungan menyediakan antarmuka yang mirip dengan POSIX API pada sistem Linux
  • Sebagian lingkungan hanya menyediakan fungsi tertentu dari sistem host dan membuat fungsi export dari modul dijalankan
• Program WebAssembly tersusun dalam unit modules, dan VM yang menjalankan modul disebut host
  • Modul adalah unit deployment, loading, dan kompilasi
  • Modul mengumpulkan definisi type, function, table, memory, dan global value
  • Modul dapat mendeklarasikan import dan export serta menyediakan inisialisasi dalam bentuk data segment, element segment, dan start function
• “Memories” di Wasm direpresentasikan sebagai array byte kontigu tanpa celah, yang dialokasikan oleh host pada saat instansiasi
  • Setiap modul guest memperoleh isolasi memori
  • Memori ini bertindak seperti RAM pada mesin virtual
  • Memori dapat diberikan dalam keadaan kosong atau diisi sebelumnya dengan data segment
• Berkat cara isolasi modul, modul dapat dijeda dan memorinya disimpan sebagai data segment
  • Konsepnya mirip dengan snapshot mesin virtual
  • Beberapa salinan dari modul yang dijeda dapat dimulai
• Wizer menginstansiasi modul Wasm, menjalankan fungsi inisialisasi, lalu merekam status instance untuk menulis ulang biner Wasm
  • Menginisialisasi langsung status global value
  • Merekam area memori yang bukan nol
  • Menghapus data segment yang ada dan menggantinya dengan data segment untuk area memori yang direkam
• Cara ini menyediakan eksekusi yang bersih seperti proses baru sambil menghindari biaya startup proses baru
  • Mendekati CGI tanpa kekurangan CGI
  • Dalam istilah modern, mendekati serverless tanpa cold start

Batasan dan keunggulan Wasm

• Wasm dalam konfigurasi native tidak memiliki thread
  • Operasi blocking harus dipindahkan ke metode host
  • Host dapat menyediakan wrapper untuk membaca/menulis file atau antarmuka jaringan, menjeda modul, atau menyediakan callback handler
  • Model reactor atau model blocking dapat dibuat, tetapi hingga thread proposal diterapkan, desain lingkungan eksekusi memegang peran besar
• Karena alasan keamanan, pembuatan kode Wasm dinamis tidak diizinkan, sehingga kompilasi JIT tidak dapat dilakukan
  • Di runtime, kode itu sendiri tidak dapat diperlakukan sebagai alamat
  • Lingkungan eksekusi seperti V8 dan CRuby yang bergantung pada JIT untuk performa tidak dapat berjalan di Wasm VM atau harus mengorbankan JIT
  • Pendekatan “pre-jit” yang menghasilkan runtime teroptimasi untuk skrip pada tahap build pernah diusulkan, tetapi belum banyak digunakan
• Antarmuka dasar antara modul Wasm dan host adalah memori, sehingga perpindahan data mungkin memerlukan penyalinan
  • Berbagi potongan memori dimungkinkan, tetapi apakah bisa atau disarankan bergantung pada model memori runtime
  • Di sebagian besar runtime, komunikasi zero-copy antara modul dan operasi I/O dianggap sulit
  • Memindahkan data streaming masuk dan keluar modul Wasm bisa lebih lambat dibanding menanganinya di host
• Wasm VM memberikan kontrol tinggi dalam hal pembatasan penggunaan
  • Sebagian runtime dapat menegakkan batas CPU dengan menghitung jumlah instruksi CPU, seperti konsep fuel Wasmtime
  • VM dapat membatasi memori dan wall clock time
• Interface Types dan module linking dapat mengurangi ukuran modul serta meningkatkan kecepatan I/O dan usability
  • Interface Types sudah dapat digunakan, tetapi belum menjadi standar yang diratifikasi
  • Module linking memiliki prototipe yang berjalan, tetapi belum ada pendekatan standar
  • Wizer saat ini bisa berbenturan dengan module linking, dan ada pendekatan kustom untuk menyelesaikannya, tetapi belum ada pemenang yang jelas
  • Interface Types mengarah pada memungkinkan objek netral bahasa melewati batas memori Wasm tanpa encoding/decoding yang mahal
  • Cara yang umum saat ini adalah menyalin JSON masuk dan keluar memori
• Secara default, modul Wasm hanya dapat mengakses hal yang diberikan kepadanya, sehingga model keamanannya kecil dan jelas
  • Menjalankan kode Wasm yang tidak tepercaya umumnya cukup aman
  • Permukaan serangan VM lebih kecil daripada Docker atau model isolasi lain
  • Karena menjalankan instruksi yang diterjemahkan pada hardware host, timing attack mungkin terjadi, tetapi ada mitigasinya
  • Wasm juga dapat dikompilasi menjadi biner native, tetapi permukaan serangannya menjadi lebih besar

Edge function dan eksekusi fungsi berbasis Wasm

• Jika lingkungan eksekusi dan alat pengembangan Wasm digunakan secara luas, bahasa skrip juga dapat terdorong untuk menyediakan pendekatan preboot seperti runtime Wasm dan Wizer
• Secara teori, aplikasi dapat dilanjutkan dari salinan tersnapshot untuk setiap request dan berjalan lebih cepat daripada model lain saat ini
• CLI lokal juga dapat ditulis dengan Ruby lalu didistribusikan sebagai modul Wasm tersnapshot dan dihubungkan ke runtime Wasm Ruby, sehingga memperoleh waktu startup mendekati utilitas C++ dan dapat dibatasi agar hanya bekerja di dalam direktori proyek
• Perubahan besar pertama adalah memindahkan fungsi ke edge yang dekat dengan pengguna
  • Komputasi dilakukan di dekat pengguna, bukan di dekat database
  • Vercel Edge Functions berbasis V8, tetapi disajikan sebagai contoh yang berbagi banyak prinsip
  • next-auth dapat mengontrol akses ke halaman pra-render berdasarkan token login JWT
  • Konten personalisasi dinamis yang tersusun dari data yang di-cache di CDN dapat disajikan
• Perubahan lain adalah mengganti fungsi berbasis proses dalam aplikasi serverless dengan fungsi berbasis Wasm
  • Suborbital memungkinkan pembuatan langsung lingkungan eksekusi fungsi berbasis Wasm, dan juga menyediakan cara merangkai fungsi Wasm menjadi workflow
  • Banyak platform eksekusi merekomendasikan satu modul per request dan dianggap belum cukup memanfaatkan kemungkinan berbagi memori atau pemanggilan cepat banyak modul
  • Jika Interface Types distandardisasi, model data middleware yang mirip Rack dapat muncul
• Wasm juga dapat berjalan di dalam fungsi Lambda
  • Versi aplikasi yang tersnapshot dapat digunakan pada infrastruktur yang ada
  • Kombinasi ini menarik, tetapi diperlakukan sebagai campuran teknologi yang pada akhirnya bisa menghilang

Arah model aplikasi web berikutnya

• Wasm disajikan sebagai teknologi yang dapat meningkatkan performa, mempermudah keamanan tingkat proses, serta menurunkan biaya build dan eksekusi fungsi serverless
• Hampir semua bahasa dapat dijalankan, dan module linking serta Interface Types dapat menurunkan latensi antar-fungsi secara signifikan
• Dasar utama untuk melihat Wasm sebagai CGI yang baru adalah bahwa ketika batasan sistem berubah, hal-hal yang sebelumnya mustahil menjadi mungkin

[GN⁺]

Komentar Hacker News

• Saya tidak begitu paham apa bedanya WASM dengan teknologi lama seperti Java Applet, ActiveX, Silverlight, dan Macromedia Flash
  Saya kira kita sudah belajar dari menjalankan kode kompilasi pihak ketiga yang tidak tepercaya di browser, dan ini terlihat seperti struktur yang memindahkan biaya komputasi server ke klien atas nama peningkatan pengalaman pelanggan

  • Java dan Flash gagal memenuhi janji sebagai “sandbox yang tak bisa ditembus yang dapat menjalankan apa pun dengan aman”
    Implementasinya penuh kerentanan dan pada akhirnya secara praktis tidak bisa lagi dipakai di browser; teknologi lain sepertinya bahkan sejak awal tidak membuat janji seperti itu
    JavaScript benar-benar memenuhi janji itu, dan browser masa kini menjalankan JavaScript yang diunduh dari domain mana pun tanpa bertanya kepada pengguna apakah mereka memercayainya
    WASM berjalan di atas engine JavaScript dan memberikan jaminan keamanan serupa, jadi secara mendasar tidak berbeda dari bytecode JVM; perbedaan praktisnya adalah WASM telah membuktikan keamanannya, sedangkan JVM tidak
    Kini Google Chrome cukup aman sehingga sekalipun miliaran orang menjalankan WASM berbahaya, ponsel mereka tidak akan diretas; engine ini bisa dibawa ke server untuk menjalankan skrip dari banyak pengguna di dalam sandbox yang kuat sambil berbagi sumber daya
    Alternatifnya adalah virtualisasi: kode bisa dikompilasi menjadi bongkahan WASM dan dijalankan di server WASM besar, atau binary amd64 bisa dibundel dengan kernel Linux yang dipangkas dan dijalankan di VM
    Saat ini sulit mengatakan mana yang jelas menjadi pemenang, dan tiap pendekatan punya kelebihan serta kekurangan
  • Berbeda dari ActiveX, Silverlight, dan Flash, WASM adalah standar terbuka yang dibuat oleh banyak pelaku industri dan memiliki beberapa implementasi, dan itu saja sudah membuatnya jauh lebih baik daripada alternatif-alternatifnya
    Berbeda dari JVM, WASM menyediakan memori linear dan secara default tidak memiliki garbage collection, sehingga lebih cocok menjadi target kompilasi untuk jajaran bahasa yang lebih luas, seperti mengompilasi C/C++ dengan Emscripten atau menargetkan Rust
    WASM adalah bytecode, dan menurut saya sebagian besar implementasi berbagi banyak hal dengan engine dan runtime JavaScript host
    Perpindahan biaya komputasi antara klien dan server adalah bagian dari tren industri yang sejak lama berayun antara thick client dan thin client, dan pendulum ini akan terus bergerak
  • Wasm punya keunggulan besar dibanding teknologi lama
    Ada spesifikasi validasi yang harus dipatuhi bytecode Wasm, dan subset yang tervalidasi ini membuat banyak kerentanan keamanan yang terlihat pada teknologi masa lalu menjadi mustahil sejak awal
    Serangan seperti Heartbleed atau Rowhammer yang mengandalkan malfungsi hardware mungkin saja bisa terjadi, tetapi misalnya menipu VM agar menafsirkan angka sebagai pointer lalu mengacu ke luar memori Wasm miliknya sendiri tidak bisa dilakukan
    Bytecode Wasm relatif sangat sederhana untuk diubah menjadi machine code, sehingga implementasinya bisa lebih kecil dan lebih cepat daripada memakai VM
    Tidak dimiliki perusahaan tertentu, memiliki spesifikasi publik yang ditulis dengan baik dan bisa digunakan siapa saja, serta diadopsi sebagai standar web sehingga tidak membutuhkan ekstensi browser
    Komputasi klien sudah terjadi di JavaScript, dan kode Wasm bisa efisien dengan cara yang tidak mungkin dilakukan JavaScript, jadi justru makin demikian
  • Java Applet dan ActiveX memiliki akses yang kurang dimediasi ke sistem operasi di bawahnya
    Applet dimediasi sampai batas tertentu, ActiveX hampir tidak sama sekali, dan “platform luar” WASM kira-kira adalah runtime JavaScript, sedangkan platform luar Applet lebih dekat ke execve(2)
  • Artikel ini membahas WASM di server, jadi berbeda dari pembicaraan tentang memindahkan biaya komputasi server ke klien
    WASM bisa saja digunakan untuk itu, tetapi tidak selalu, dan perbedaan seperti sandboxing serta isolasi yang lebih baik juga sudah dibahas dengan baik oleh jawaban lain

• Mengatakan “Amazon membuka era komputasi serverless dengan Lambda” kurang tepat, karena Google App Engine hadir pada 2008, enam tahun lebih awal daripada Lambda

  • Ada juga Heroku dan generasi PaaS pada masa itu
    Produk-produk seperti itu sudah ada dan punya nama beberapa tahun sebelumnya, jadi saya tidak begitu tahu mengapa muncul nama “serverless” atau dari mana asalnya
    App Engine juga punya batch worker dan web worker, begitu pula Heroku
    Keduanya adalah produk sebelum Docker, jadi mungkin orang merasakannya berbeda, tetapi sepertinya Lambda juga tidak diluncurkan dengan Docker sejak awal

• Pernyataan bahwa “karena alasan keamanan, pembuatan kode Wasm dinamis tidak diizinkan sehingga kompilasi JIT tidak mungkin” tampaknya tidak tepat
  Untuk mengizinkan hal seperti hot reloading kode yang bersih, itu pada dasarnya mendekati fitur fundamental
  Menurut saya logika keamanannya rapuh
  JS bisa melakukan hot reload saat berjalan atau pembuatan kode yang lebih ekstrem tanpa merusak keamanan, dan jika seluruh runtime Wasm dimuat ulang secara dinamis sambil mempertahankan memori, pembuatan kode atau hot reload juga bisa ditiru, tetapi pengalaman penggunanya akan terasa kaku
  Saya tidak melihat alasan mengapa secara teknis itu harus mustahil, dan jika ini langkah keamanan, tampaknya terlalu mudah diakali
  Bytecode WASM secara konseptual sangat mirip dengan .NET IL atau bytecode Java, yang memang dirancang dengan kompilasi JIT dalam pikiran
  Saya kurang menyukai WASM karena terasa seperti proyek yang kurang memiliki arah kuat dan kemauan untuk membuatnya berhasil tepat waktu
  Namanya mengisyaratkan “assembly untuk web”, yaitu bahasa mesin untuk CPU virtual, tetapi kenyataannya lebih merupakan representasi perantara untuk backend compiler, dan konsepnya tidak jelas karena fitur tingkat tinggi seperti dukungan garbage collection juga direncanakan
  Fitur dasar seperti hot reload yang disebutkan tadi, threading yang tidak terasa seperti peretasan, integrasi langsung dengan DOM tanpa JavaScript, API grafis/komputasi ber-overhead rendah, dan akses audio tingkat rendah juga masih kurang
  Sulit menjalankan aplikasi multimedia besar tanpa kompromi besar

  • Kalimat itu benar
    Wasm tidak dapat menandai memori sebagai dapat dieksekusi dan pada praktiknya kode dan memori terpisah seperti arsitektur Harvard
    Selain itu, ia juga tidak bisa melompat ke posisi kode sembarang, dan bahkan tidak memiliki instruksi jump
    JIT di sini berarti mengompilasi dan menjalankan kode native saat runtime, dan di browser atau sandbox Wasm itu menjadi kelemahan keamanan besar
    Ini tertanam dalam desain dan set instruksinya, jadi bukan sesuatu yang mudah diakali; detailnya bisa dilihat di https://webassembly.org/docs/security/
    Wasm memang mirip dengan .NET IL atau bytecode Java dalam arti engine yang menangani JIT, tetapi berbahaya memberikan pengguna hak untuk keluar dari runtime, membuat kode native, lalu melompat ke sana
  • Browser jelas menggunakan suatu bentuk JIT untuk WASM
    Karena itu, seperti JIT, saat pertama kali menjalankan kode WASM bisa terlihat sedikit “tersendat saat pemanasan”, meski dalam beberapa tahun terakhir ini jauh membaik
    Selain itu, setahu saya di browser kita bisa membuat, menginstansiasi, dan menjalankan bongkahan WASM secara dinamis
    Saya tidak tahu apakah ini juga mungkin di runtime WASM lain, dan di browser pun harus lewat JavaScript, tetapi untuk mengakses “web API” apa pun, pada akhirnya itu memang diperlukan

• WASM mengubah VM yang khusus untuk bahasa tertentu, seperti JavaScript VM, menjadi VM serbaguna yang bisa digunakan di mana pun JavaScript VM digunakan
  Tentu saja tidak terbatas hanya di sana
  Serbaguna berarti hampir apa pun bisa dijalankan selama ada compiler atau interpreter, termasuk JavaScript
  Karena umumnya diimplementasikan sebagai bagian dari engine JavaScript, ia mewarisi banyak karakteristik seperti sandboxing dan akses ke API terkait
  Standarisasi akses tersebut masih berjalan, tetapi pada akhirnya hal-hal yang saat ini hanya mungkin dengan JavaScript akan menjadi mungkin juga di WASM, dan lebih banyak hal yang sulit atau mustahil dengan JavaScript juga akan menjadi mungkin
  Bisa juga berjalan lebih cepat dan lebih mulus
  Inti WASM adalah menghapus banyak keterbatasan yang ada di lingkungan tempat JavaScript populer
  JavaScript adalah bahasa yang sangat memecah selera, jadi ia berubah dari satu-satunya pilihan menjadi salah satu dari beberapa pilihan
  WASM pernah digambarkan sebagai pengganti JavaScript, pengganti Docker, pengganti Java, dan pengganti CGI; singkatnya, ia semua itu dan lebih dari itu

  • Saya sendiri tidak punya keluhan terhadap JavaScript, tetapi menurut saya ekosistem untuk mendistribusikan JS di web-lah masalahnya
    Terlalu banyak alat yang melakukan hal serupa dan batasnya tidak jelas
    Pada akhirnya, meski semuanya bisa dibuat berjalan, secara pribadi rasanya rapuh, dan menakutkan bagi orang yang tidak menekuninya secara profesional
    Belakangan ketika harus membuat sesuatu untuk web saya memakai leptos; pengalaman developernya jauh lebih baik, dan meski belum 1.x, rasanya lebih stabil daripada merangkai lima alat untuk mentranspilasi, mengobfuskasi, mengecilkan, dan memaketkan bundle JS

• Membaca tulisan ini mengingatkan saya pada hukum perangkat lunak yang dulu sering disebut-sebut
  Aplikasi yang cukup besar dan bertahan cukup lama pada akhirnya akan mengimplementasikan ulang seluruh software stack tempat ia berjalan, bahkan sampai sistem operasinya, dan mengimplementasikannya dengan buruk
  Saya tidak tahu sumbernya, tetapi sering kali cukup benar

  • Versi yang jenaka dikenal sebagai hukum ke-10 Greenspun
    “Program C atau Fortran yang cukup kompleks akan mengimplementasikan separuh Common Lisp secara ad hoc, berdasarkan spesifikasi informal, penuh bug, dan lambat”
    Pola yang lebih umum disebut Inner-Platform Effect

• Jika premis judulnya diperluas, agar WASM menjadi penerus sejati dari garis keturunan itu, ia harus semudah mengunggah dan mendistribusikan aplikasi PHP di stack LAMP milik penyedia hosting sembarang
  Untuk saat ini, tampaknya belum semudah pengalaman deployment PHP

  • WASM berjalan di browser
    Saya tidak tahu apa yang Anda harapkan harus berubah di sisi hosting

• Saya melihatnya berbeda
  Menurut saya masa depan adalah local-first
  Artinya aplikasi sebagian besar berjalan di dalam browser pengguna, dengan sangat sedikit bantuan dari server
  Aplikasi seperti Figma, Linear, dan Superhuman memakai model ini dengan sangat sukses, dan Stackblitz juga sampai batas tertentu
  Kalau aplikasi yang cukup kompleks seperti Figma bisa berjalan hampir sepenuhnya di dalam browser pengguna, saya rasa sebagian besar aplikasi juga bisa
  Sisi server terutama berperan menyinkronkan data antarinstans yang berbeda saat pengguna memakai aplikasi dari beberapa lokasi
  Alat seperti Electric-SQL sedang dibuat, tetapi belum matang; begitu pustaka-pustaka seperti ini matang, area ini akan tumbuh besar
  Serverless pada umumnya ada agar perusahaan seperti Amazon dan Azure bisa menghasilkan uang, dan pada akhirnya akan menjadi seperti CGI
  WASM juga bisa sukses, tetapi kemungkinan besar terutama di dalam browser pengguna
  Microsoft memakai WASM untuk C#/Blazor, tetapi saya tidak yakin dotnet di dalam browser akan secepat JavaScript, jadi menurut saya itu bukan pendekatan yang tepat

  • CGI memberi kekuatan kepada pengguna dan situs kecil
    Hanya saja tidak ada yang membicarakannya karena tidak bisa diskalakan sampai 1 triliun impresi iklan per detik
    Setiap kali seseorang menulis satu serverless function, itu menambah 10 kaki pada yacht Bezos
  • Agak sulit menyebut Figma sebagai local-first
    Kalau sedang offline atau berada di tempat dengan Wi-Fi yang tidak stabil, desain tidak bisa dimuat; dan kalau belum berubah baru-baru ini, setelah mengedit lalu Wi-Fi terputus dan browser ditutup, perubahan tidak tersimpan
  • Jadi maksudnya masa depan adalah kembali ke cara menjalankan aplikasi sebelum era web
  • Saya mendukung perkembangan aplikasi sisi klien, tetapi tidak melihatnya harus selalu berjalan di dalam browser atau sandbox, atau harus dibeli lewat app store
    Dan ini juga sama sekali bukan ide baru
  • dotnet di dalam browser mungkin tidak secepat JavaScript, tetapi keduanya akan cukup cepat
    Kami sedang mengembangkan Blazor WASM, dan dari sisi performa dotnet bukan masalah

• Pada dasarnya ini membuat ulang JVM dan ekosistemnya?

  • Sampai batas tertentu benar, tetapi WASM dirancang dengan batasan berbeda yang lebih cocok ketika Anda ingin memasukkan runtime ke mana saja
    Terkadang membuat ulang X dengan pelajaran dari masa lalu memang bisa menjadi ide yang sangat bagus
  • Dalam beberapa hal benar, tetapi WASM mendukung jauh lebih banyak bahasa
    Misalnya, sekitar 2010 ketika saya mulai mencari cara menjalankan kode C/C++ di browser, mengompilasi C/C++ ke JVM pada praktiknya mustahil
    Saat itu Java Applet masih masuk akal, jadi kalau itu bisa dilakukan tentu bagus, tetapi WASM juga belum ada, sementara Emscripten sudah ada; dari situlah lewat asm.js pada akhirnya lahir WASM
  • JVM memang hebat, tetapi bukan berarti ia jawaban final untuk genre ini
    Sebagai orang yang pernah mengutak-atik class loader dan menulis assembly JVM langsung di kelas bahasa pemrograman tahun 2000-an, saya juga tidak yakin JVM adalah puncak di bidang ini
    Memang benar JVM memungkinkan ekosistem besar, tetapi antarmuka JVM dengan dunia luar benar-benar berantakan dan kaku
    Selama lebih dari 20 tahun, setiap kali berhadapan dengan sesuatu terkait JVM, saya selalu mengeluh
    Jika membandingkan packaging dan ekosistem Rust dengan Python, atau yang lebih mengerikan lagi C++, itu menunjukkan bahwa reinvention yang mengambil pelajaran dari beberapa dekade terakhir bisa menjadi hal yang sangat baik
  • Namun WASM punya masalah class loader/linker yang besar
    Menggabungkan dua file wasm menjadi satu dan menyelaraskan penggabungan memorinya dengan benar masih sangat sulit
    Component Model mungkin bisa memperbaikinya, tetapi terlalu banyak elemen yang membengkak tanpa perlu, sehingga adopsi Safari bisa memakan waktu lama
  • Benar, dan .Net CLR dan sejenisnya juga begitu

• Sudah lama saya berpikir WASM akan menuju dunia di mana ia menggantikan kode fungsi Lambda di cloud
  WASM secara tradisional dianggap berjalan di atas platform host, tetapi tidak ada alasan harus selalu begitu
  Karena sifat sandbox WASM, secara teknis ia juga bisa dijalankan di luar sistem operasi atau di ring0 untuk melewati banyak overhead sistem operasi
  Dengan mengompilasi ke WASM, berbagai masalah deployment menjadi jauh lebih sederhana bagi pengguna, dan lingkungan hosting punya lebih banyak ruang untuk optimasi
  Bahkan hardware khusus untuk menjalankan WASM lebih cepat bisa saja memungkinkan

• Buruk kalau harus mengeksekusi otomatis kode arbitrer yang tidak tepercaya dari sumber arbitrer yang tidak tepercaya, dan itu juga tidak bisa dianggap mengisi peran yang sama seperti CGI sisi server