Dalam
artikel terakhir di WebAssembly, saya membuat pernyataan berikut:
Beberapa membandingkan WebAssembly dengan applet Java. Dalam arti tertentu, mereka benar, tetapi di sisi lain mereka sangat keliru. Entah bagaimana saya akan menulis artikel tentang perbedaan, tetapi untuk sekarang mari kita bicara tentang kesamaan. Di satu sisi, WebAssembly adalah cara yang berbeda untuk mencapai apa yang dimaksudkan JVM: itu adalah mesin virtual biasa untuk perangkat lunak lintas platform.
Banyak orang telah menyatakan minatnya pada topik ini, jadi mari kita lihat lebih dekat! Pada artikel ini, kami membandingkan WebAssembly dengan tiga teknologi: Flash, applet Java, dan
sedikit dengan PNaCL. Artikel ini juga berfokus untuk menggunakannya di
web , meskipun kami sebelumnya melihat penggunaan opsi untuk menggunakan WebAssembly offline. Tapi kita akan membicarakan perbandingan
seperti itu nanti. Akhirnya, artikel ini mirip dengan makan tapas [camilan Spanyol dari berbagai bahan - sekitar. per.], berikut adalah banyak bagian kecil. Sepertinya bagi saya ini sedikit pendek, tetapi pada saat yang sama saya mencoba untuk blog, dan jika saya terus mengembangkannya, itu akan memakan waktu lama, jadi saya minta maaf.
Saya pikir perbandingan dengan applet Flash dan Java cukup
alami ketika Anda menemukan deskripsi WebAssembly ini:
WebAssembly (Wasm for short) adalah format instruksi biner untuk mesin virtual yang ditumpuk. Wasm dikembangkan sebagai versi portabel dari kompilasi bahasa tingkat tinggi seperti C, C ++ dan Rust, yang memungkinkan Anda untuk menyebarkan aplikasi klien dan server di Internet.
Ini sedikit seperti teknologi masa lalu. Adalah logis untuk membandingkan bagaimana mereka terhubung, dan untuk menyarankan perbedaan kecil di antara mereka. Tetapi WebAssembly sangat berbeda karena beberapa alasan.
Wasm dikalahkan
Alasan pertama WebAssembly berbeda adalah karena akhirnya berhasil, sedangkan teknologi sebelumnya tidak. Maksud saya kemenangan dalam arti tertentu. Jika Anda membandingkan jumlah aplikasi Flash dan jumlah aplikasi WebAssembly, Wasm kemungkinan akan hilang. Web Penganut perakitan harus bekerja keras untuk mendistribusikan platform ini.
Ketika saya berbicara tentang kemenangan WebAssembly, maksud saya bahwa itu telah menjadi bagian dari platform web. Flash, applet Java, dan PNaCL bekerja melalui plugin. Dalam arti tertentu, mereka berada di
luar ekosistem web. Mereka tidak pernah dimasukkan dalam standar, dan ini sangat penting.
Dalam arti tertentu, penjelasan seperti itu sudah cukup. Tetapi hanya menunjukkan fakta tidak berarti menjelaskan
penyebabnya . Sisa dari artikel ini akan mencoba mencari tahu
mengapa ini terjadi: mengapa WebAssembly berhasil melakukan apa yang tidak bisa dilakukan oleh teknologi lain. Di sini,
banyak alasan saling terkait satu sama lain, tetapi saya mencoba untuk membagi mereka menjadi beberapa poin yang berbeda.
Teknologi lain tidak cocok dengan platform
Apakah kamu ingat itu?
Atau apakah itu?
Bagaimana dengan ini?
Applet yang dibangun dengan teknologi ini sebenarnya bukan
aplikasi web . Anda memiliki halaman web dengan potongan, dan applet Anda berfungsi dalam bingkai ini. Anda kehilangan semua keunggulan teknologi web lain: baik HTML, CSS, maupun kemampuan untuk berintegrasi ke web. Platform ini tidak berinteraksi dengan bagian platform lainnya di browser. Yah, secara
teknis mereka bisa , tetapi dalam praktiknya, teknologi ini telah digunakan secara berbeda.
Bagaimana web mendukung ekosistem yang tidak berintegrasi dengannya? Ini tidak akan pernah terjadi. Dan pengguna akhirnya dengan tegas menolaknya. Selain game, pengguna
membenci Flash, dan applet Java berat dan lambat. Teknologi ini tidak tertanam dalam platform web.
WebAssembly, di sisi lain, jauh lebih dekat dengan JavaScript. Bahkan, Wasm tidak mengambil bagian layar dari Anda. Dia tidak menciptakan dunianya sendiri yang kecil dan tertutup. Sekarang menggunakan JavaScript, dan
di masa depan sendiri , ia dapat berinteraksi dengan lingkungan. Dia hanya ... cocok dengan itu.
Teknologi lain yang dimiliki oleh perusahaan
Java dimiliki oleh Sun Microsystems, Flash dimiliki oleh Adobe. Mengapa ini penting?
Pengaruh perusahaan di Internet adalah topik yang kompleks.
Secara umum, web beroperasi pada model pseudo-consensus. Java dan Flash, di sisi lain, dikendalikan oleh perusahaan masing-masing. Mereka memiliki motivasi yang kuat untuk menghasilkan keuntungan, bukan untuk meningkatkan Internet. Dan ini sebagian mengarah pada situasi yang disebutkan di atas: perusahaan-perusahaan ini tidak peduli untuk berintegrasi dengan baik dengan seluruh platform. Mengapa mereka membutuhkannya? Jauh lebih baik bagi bisnis untuk memblokir platform mereka dan sepenuhnya meninggalkan sisa Internet. Motivasi benar-benar miring.
WebAssembly adalah inisiatif bersama Mozilla, Google, Apple, Microsoft dan lainnya. Ini tidak mempromosikan platform spesifik seseorang, tetapi justru mewakili kepentingan bersama berbagai pemangku kepentingan, baik perusahaan maupun individu.
WebAssembly mengikuti proses web
Afiliasi perusahaan
juga berarti bahwa teknologi ini tidak pernah mengikuti proses yang kami gunakan untuk menstandardisasi web. Proses mengadopsi standar web sudah mapan, tetapi teknologi ini terlalu besar dan bekerja sedikit berbeda. Sebaliknya, WebAssembly mengikuti prosedur standar yang diadopsi untuk teknologi web.
Asm.js pertama kali dibuat sebagai bukti bahwa kita dapat melakukan hal-hal yang mengesankan dengan web. Eksekusinya ternyata cukup berkualitas tinggi dan menunjukkan kemampuan teknologi, meskipun tidak ada yang fantastis di sana. Kartu truf utama
asm.js adalah bahwa itu hanya kode JavaScript: sepenuhnya kompatibel dengan ekosistem yang ada. "Jangan pecahkan Internet" adalah aturan yang sangat, sangat penting bagi pengembang peramban.
WebAssembly adalah versi perbaikan dari
asm.js Setelah menemukan beberapa konsensus di sekitar
asm.js semua orang berkumpul untuk membuat WebAssembly menjadi kenyataan. Karena ini bukan hanya JavaScript, ia harus melalui seluruh proses untuk implementasi di browser, dan ia melewatinya. Ini sekarang spesifikasi W3C, yang
sesuai dengan standar web, tetapi tidak bertentangan dengan mereka.
Konsekuensi: teknologi lain terlalu besar dan tidak stabil
Alasan lain Wasm berhasil: itu kecil. Wasm mengambil pendekatan teknologi web lainnya: mulai dari yang kecil dan tumbuh lebih besar atas dasar ini. Tetap kompatibel. Teknologi masa lalu juga tidak mengikuti konvensi sosial khusus ini. Sebuah runtime spesifik dimuat untuk applet Flash dan Java, jadi kompatibilitas tidak diperlukan. PNaCl dibangun di atas kode IR LLVM yang sepenuhnya tidak stabil. Mereka akan menjadikannya bagian yang stabil, tetapi jika LLVM berubah, akan ada perbedaan, yang tidak terlalu baik.
Teknologi ini juga terlalu rumit untuk berharap stabilisasi. Bisakah Anda bayangkan bahwa empat pembuat browser sepenuhnya menentukan spesifikasi JVM dan kemudian menerima semantik ini selamanya? Untuk semua ActionScript, yang dengan sendirinya merupakan versi ECMAScript yang serupa namun berbeda? Untuk semuanya LLVM-IR?
Teknologi besar menimbulkan risiko yang tidak dapat diterima terhadap situasi. Ini adalah kesepakatan semua-atau-tidak sama sekali, dan inilah taruhan “tidak ada” yang aman. WebAssembly, di sisi lain, hampir tidak melakukan apa-apa. Ini terutama matematika dan panggilan JavaScript. Artinya,
jauh lebih mudah untuk sepakat di sini.
Konsekuensi: teknologi lain membutuhkan mesin virtual yang terpisah
Dalam artikel ini saya tidak menyebutkan Dart, tetapi juga cocok di sini. Kalimatnya, "Mari kita letakkan JVM di setiap browser", masalah utama adalah bahwa browser
sudah memiliki runtime JavaScript. Bahkan satu runtime cukup sulit untuk dipertahankan, belum lagi dua. Dan bagaimana Anda mengintegrasikannya?
WebAssembly, di sisi lain, dirancang sebagai ekstensi kecil ke mesin virtual JavaScript yang ada. Meskipun Anda
dapat menerapkan mesin virtual WebAssembly Anda sendiri - ini sering dilakukan dengan WebAssembly offline, tetapi untuk browser, biaya perawatannya jauh, jauh lebih rendah.
Teknologi lain terlalu spesifik.
WebAssembly pada dasarnya adalah bahasa independen. Applet Flash dan Java terutama dirancang untuk menjalankan ActionScript dan Java. Mereka sangat melekat pada semantik relatif mereka. Bahkan PNaCl menderita sampai batas tertentu dari ini: LLVM benar-benar cocok untuk bahasa seperti-C, meskipun tidak sampai batas yang sama.
Apakah kami benar-benar ingin memilih satu bahasa untuk seluruh Internet? Kami sudah memiliki JavaScript. Pernah membayangkan bahasa ketiga? Keempat? Pendekatan independen jauh lebih baik dalam jangka panjang.
Wasm memiliki pendekatan ketat terhadap keamanan
Applet Java dan Flash adalah
mimpi buruk keamanan nyata. Sekalipun upaya dilakukan untuk melindungi mereka, pada kenyataannya masalah terus muncul.
Di sisi lain, WebAssembly kembali menerima bonus dari JavaScript VM: semua upaya untuk mengisolasi kotak pasirnya juga berlaku untuk Wasm. Di sini, beberapa fungsi assembler biasa tidak ada, yang dapat menyebabkan kerentanan, seperti penghancuran tumpukan. Wasm bekerja dengan aman dengan memori, yang sangat penting!
Selain itu, WebAssembly pada awalnya dirancang dengan gagasan
validasi : sepenuhnya diketik, dan program dapat diperiksa tanpa menjalankan kode. Spesifikasi mencakup instruksi tentang cara melakukan validasi tersebut. Ini sangat berguna!
Kesimpulan
Saya ingin mengatakan yang berikut tentang artikel ini: ini ditulis dari sudut pandang
pengembang . Tetapi pengembang itu penting karena mereka mengontrol web. Teknologi harus konsisten dengan tujuan mereka - ini sama pentingnya dengan kenyamanan bagi pengguna akhir. Dalam artikel mendatang, saya akan mencoba menganalisis masalah dari sudut pandang pengguna. Harus banyak menulis!
Untuk meringkas:
- Teknologi lain tidak diintegrasikan ke dalam platform web, dan ini terhalang oleh kepentingan komersial.
- Teknologi lain terlalu banyak dibutuhkan: banyak yang harus berkorban dalam implementasi.
- Wasm memiliki isolasi dan validasi kotak pasir yang sangat bagus, yang tidak dimiliki orang lain.