Design: Apakah akan ada JS -> kompiler WASM?

Browser akan tetap memiliki VM JavaScript asli di samping wasm. Tidak ada alasan untuk mengkompilasi JS ke wasm karena Anda juga harus menyertakan seluruh javascript vm. Kode yang dihasilkan akan sangat besar dan lebih lambat dari JS VM yang disediakan secara asli.

Ada posting tugas MVP untuk menambahkan hal-hal seperti menambahkan akses ke GC dari kode wasm sehingga bahasa skrip dapat diimplementasikan untuk wasm.

JS → wasm hanya akan benar-benar masuk akal setelah wasm mendukung GC, dan kemungkinan besar kompilasi JIT juga, yang masih cukup lama. Ini pada dasarnya akan setara dengan mengimplementasikan mesin JS di wasm! Saya menyebutkan ini baru - @BrendanEich menuduh saya telah diambil alih oleh horse_js.

Untuk lebih jelasnya, tujuan wasm bukanlah untuk _mengganti_ JavaScript, melainkan untuk melengkapinya. Oleh karena itu, dukungan JS → wasm bukanlah tujuan saat ini, tetapi fitur yang ingin kami implementasikan akan memungkinkannya. Saya tidak yakin itu akan berguna dari sudut pandang pengembang. Anda mungkin mendapatkan beberapa pengurangan ukuran, tapi itu saja. Dari perspektif browser, mungkin menarik untuk mengimplementasikan mesin JS di wasm dari perspektif keamanan murni.

@jfbastien saya mengalahkan Anda dengan 2 detik ;)

Tapi jawabanmu lebih baik. Saya senang untuk GC dan JIT di wasm. Saya suka membuat bahasa saya sendiri dan menjalankannya di web.

Dan bagaimana dengan varian pendukung seperti asm.js atau TypeScript/ES7? Ini
rasa Javascript menjanjikan beberapa tingkat jaminan tipe.

Saya membayangkan kebutuhan untuk JIT akan lebih sedikit, tetapi GC masih sangat banyak
dibutuhkan untuk bahasa-bahasa tersebut. Akan memiliki {typed flavor JS} -> WASM make
ini lagi layak?

W: http://bguiz.com

Pada 24 Juni 2015 pukul 09:44, Tim Caswell [email protected] menulis:

@jfbastien https://github.com/jfbastien Anda mengalahkan saya dengan 2 detik: P

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment -114675456.

Ya, penerjemah asm.js -> wasm adalah prioritas tinggi, dan Luke sudah melakukannya
bekerja pada kompresor yang mungkin berfungsi sebagai titik awal yang baik.

Pada hari Rabu, 24 Jun 2015 jam 1:59 pagi, Brendan Graetz [email protected]
menulis:

Dan bagaimana dengan varian pendukung seperti asm.js atau TypeScript/ES7? Ini
rasa Javascript menjanjikan beberapa tingkat jaminan tipe.

Saya membayangkan kebutuhan untuk JIT akan lebih sedikit, tetapi GC masih sangat banyak
dibutuhkan untuk bahasa-bahasa tersebut. Akan memiliki {typed flavor JS} -> WASM make
ini lagi layak?

W: http://bguiz.com

Pada 24 Juni 2015 pukul 09:44, Tim Caswell [email protected] menulis:

@jfbastien https://github.com/jfbastien Anda mengalahkan saya dengan 2 detik: P

—
Balas email ini secara langsung atau lihat di GitHub
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/WebAssembly/design/issues/219#issuecomment -114677789.

Kami telah berbicara dengan tim TypeScript tentang kemungkinan ini dan mereka telah menunjukkan minat, tetapi sepertinya ada kemajuan saat ini untuk menambahkan objek yang diketik ke JS.

@bguiz : Mesin JS adalah mesin wasm, dan akan terus mendukung bahasa standar JS yang berkembang. Tidak ada kekhawatiran di sana (saya tidak yakin apakah Anda pikir itu akan hilang. Tidak di masa depan yang dapat saya ramalkan). OTOH seperti yang dicatat orang lain, wasm membutuhkan waktu untuk mengembangkan GC, dukungan JIT, dan fitur bahasa dinamis lainnya, untuk menjadi target kelas satu untuk JS. Bahkan ketika itu mengembangkan hal-hal ini, saya ragu bahwa mesin JS/wasm akan menjatuhkan sintaks dan bawaan JS mereka demi VM JS-in-wasm yang diunduh. Kita akan melihat!

/menjadi

Penerjemah asm.js-to-WebAssembly juga akan menjadi sesuatu yang kami rencanakan untuk ditambahkan ke Emscripten .

Adapun JS biasa, saya pikir orang lain telah menjawab pertanyaan di atas.

Inti dari JS adalah mudah untuk dikodekan dan dapat melakukan hal-hal luar biasa: dhteumeuleu atau codepen.io/ge1doot, tetapi Anda dapat melihat sumbernya dan mudah untuk diretas.

"wasm" hanyalah cara untuk menjual lebih banyak game dan aplikasi lain untuk google, apple an co. Satu-satunya "evolusi" adalah akan dapat mengontrol Anda lebih baik dengan "tidak menginstal", langsung dari server kakak ... Saya hanya terkejut mereka tidak takut makan satu sama lain ...

Mungkin dengan analisis kode atau anotasi kode untuk mengkompilasi ECMAScript ke WebAssembly. Ini kedengarannya bukan prioritas bagi tim WebAssembly tetapi kedengarannya seperti ide bagus untuk upaya independen.

Saya baru saja mulai bereksperimen dengan bahasa pemrograman mainan yang mungkin relevan: https://github.com/evanw/thinscript. Ini menggunakan sintaks gaya TypeScript dan dikompilasi ke WebAssembly. Saya pikir saya harus menyebutkannya karena itu mungkin studi kasus yang menarik. Saya juga sangat terkejut dengan betapa mudahnya WebAssembly dihasilkan. Kerja bagus semuanya!

Saya akan memperingatkan orang-orang tentang menggunakan pembungkus yang sangat tipis di atas wasm, secara umum. Sebagai salah satu contoh, membolak-balik kode thinscript, saya melihat ada pernyataan while yang diturunkan menjadi loop { if (!condition) break; } , yang akan kurang efisien daripada if (condition) loop { ...; br_if condition } pada beberapa mesin wasm.

Bagi saya, hal yang membuat wasm lebih dari sekadar JS yang dipanaskan adalah kemungkinan filosofi yang berbeda: karena wasm adalah target kompiler, kompiler dapat melakukan pengoptimalan sebelum mengirimkan kode ke klien, sehingga kami dapat menjaga VM sisi klien lebih sederhana dan lebih cepat. Namun, jika pembungkus tipis di sekitar wasm menjadi populer, ada risiko implementasi sisi klien pada akhirnya harus tumbuh lebih besar dan lebih kompleks untuk melakukan pengoptimalan yang tidak dilakukan.

Ya saya setuju. Salah satu hal yang paling saya sukai dari WebAssembly adalah kesederhanaannya. Saya berencana menambahkan pengoptimalan kompiler dan melakukan tolok ukur setelah bahasanya lebih lengkap. Saya berharap inlining menjadi salah satu kemenangan yang lebih besar, misalnya, dan saya tidak berharap WebAssembly melakukannya untuk saya. Saya juga berencana bereksperimen dengan target kode mesin dan saya akan menggunakan pengoptimalan yang sama untuk kedua target.

Kedengarannya sangat keren! Saya akan tertarik untuk melihat ke mana arahnya.

Saya membayangkan JS->WASM lebih menarik untuk server daripada klien. Sebagai ikhtisar tingkat tinggi dari arsitektur yang ada dalam pikiran saya ...

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

Dalam konsepsi ini, pemetaan yang jelas dari WASM ke LLVM IR untuk pengumpulan sampah akan sangat diinginkan. Promosi dari IEEE ganda ke bilangan bulat dapat dilakukan sebagai pass LLVM. Gagasan JIT terpisah untuk kode hangat dan panas dapat diimplementasikan dalam hal manajer lulus LLVM.

Hanya beberapa pemikiran, jangan ragu untuk menghapus ini jika itu palsu!

Kompatibilitas lintas lingkungan adalah masalah serius dalam ekosistem JS. Babel mencoba memecahkan masalah ini dengan menerjemahkan ke beberapa versi ES yang lebih diadopsi dan saya kira kita semua dapat mengatakan bahwa itu cukup berhasil.

Masih ada masalah di sini sekalipun. Misalnya, jika Anda mengubah kode ES 2016 ke ES5 untuk kompatibilitas dan kode Anda berjalan di lingkungan dengan (sebagian atau lengkap) dukungan ES 2016, Anda akan kehilangan manfaat memiliki dukungan ES 2016 di lingkungan Anda .

Jika semua orang menerjemahkan kode mereka ke ES5, lalu apa manfaat memiliki dukungan ES 2016 di lingkungan?

Sebuah proyek baru yang disebut "babel-preset-env" mencoba untuk mengatasi masalah ini dengan menargetkan lingkungan dengan versi mereka. Gagasan di baliknya adalah (1) Anda memintanya untuk menargetkan versi tertentu atau "versi X terbaru" dari browser, (2) itu menentukan penyebut umum fitur yang paling rendah dan (3) hanya mengaktifkan transpilasi yang diperlukan. Ini membantu, tetapi sayangnya tidak dapat menyelesaikan masalah.

Kami masih memiliki risiko vendor besar tidak berperilaku dan menyebabkan masalah yang sama yang disebabkan Microsoft dengan Internet Explorer selama bertahun-tahun. Seluruh ekosistem berada di tangan beberapa vendor, yang memutuskan apa yang akan diterapkan dan kapan harus diterapkan. Ini tidak gratis atau terbuka.

Satu-satunya solusi adalah target kompilasi baru untuk JavaScript yang berkinerja dan membutuhkan perawatan yang jauh lebih sedikit (semoga tidak ada) daripada mesin JS. Ketika lingkungan (browser, Node.js, dll.) mulai mendukung target tersebut, mengimplementasikan fitur ES baru harus menjadi tanggung jawab kompiler dan bukan vendor mesin.

JS -> WASM akan menarik untuk melindungi kekayaan intelektual dengan kebingungan kode ketika datang ke instalasi di tempat, katakanlah aplikasi Electron di server pelanggan. Sulit dipercaya tetapi benar, ada banyak institusi kecil di Jerman dengan koneksi internet yang sangat sedikit atau tanpa koneksi internet, yang memerlukan instalasi di tempat, tetapi memberikan seluruh kode Anda dalam teks biasa kepada mereka dapat menakutkan bagi perusahaan perangkat lunak.

@Simran-B Wasm memiliki prinsip desain untuk mendukung format teks yang sudah dikenal. Khususnya ia memiliki desain aliran kontrol terstruktur untuk analisis cepat, dan dioptimalkan untuk definisi sekali pakai yang digunakan dalam urutan tumpukan sehingga dioptimalkan untuk ekspresi yang dapat dibaca. Jadi ini bukan target 'kebingungan kode', tetapi pengembang dapat memancarkan 'kebingungan kode' mereka sendiri di atas ini tetapi harus memahami bahwa ini diharapkan memiliki biaya dalam hal penurunan efisiensi penyandian dan penurunan kinerja.

Hai semua, saya baru saja menemukan WebAssembly, tetapi memikirkan tentang JS -> kompiler wasm, saya membayangkan sesuatu seperti kompilasi Ahead-of-Time Angular2, hanya lebih dioptimalkan (saya berpikir kode mesin daripada javascript) ... Akankah ini pernah mungkin? Apakah itu layak?

EDIT
Saya juga berpikir, apakah akan ada kemungkinan bagi browser untuk mengirim bendera ke klien yang mendukung wasm, dan kemudian kami dapat menyajikan aplikasi yang telah dikompilasi alih-alih file javascript?

Richard

@Richard87 Anda dapat menganggap webassembly sebagai set instruksi independen platform dengan konvensi penyandian dan panggilan khusus sendiri. Tidak ada yang mengatakan Anda tidak dapat menggambarkan subset dari javascript yang akan sangat mudah diubah untuk bekerja di dunia webassembly dari hal-hal itu, tetapi menegakkan itu mungkin akan sulit. Set fitur dan area permukaan implementasi selamanya berkembang di javascript, dan mengadaptasi pustaka dan kerangka kerja yang ada untuk bekerja di subset itu kemungkinan akan sulit, terutama mengingat kurangnya pengumpulan sampah saat ini di webassembly, dan Anda pada dasarnya akan kehilangan manfaat dari javascript yang ada kode.

Dengan penambahan primitif pengumpulan sampah di webassembly, subset javascript yang layak untuk ditranskripsikan tanpa menulis mesin virtual besar akan melebar, tetapi menurut saya masih tidak akan optimal dibandingkan dengan hanya memindahkan dari yang lebih cocok bahasa, karena overhead Anda dalam javascript hanya akan sedikit lebih kecil, overhead penting dalam aplikasi web (jaringan!) akan melebar, dan manfaat yang ingin Anda petik dari menggunakan javascript di tempat pertama masih akan di luar jangkauan, selain mengatakan bahwa ia menggunakan sesuatu yang menyerupai "javascript" (ini sebenarnya adalah perahu yang mirip dengan Unity dengan UnityScript, kecuali mereka menyesuaikannya agak untuk berintegrasi lebih baik dengan subsistem mereka dan konvensi pemanggilan secara umum, selain keinginan lainnya).

Saya pikir sangat penting bagi sebagian dari kita yang melihat Browser dan Webgl menjadi lebih cepat untuk bermain game. Saya bermaksud untuk menghadirkan game berkualitas komersial di webgl tetapi teknologi saat ini menghasilkan begitu banyak sampah yang dilewatkan oleh frame.
Game browser menggunakan mesin game JS hampir gagal dan Unity lepas landas. Saya pikir C++ => Wasm adalah keuntungan yang tidak semestinya untuk pembuat kerangka kerja seperti Unity besar ini yang dapat mengkompilasi silang kode mereka ke WASM.
Tapi bagaimana dengan orang yang menulis JS dengan tangan menggunakan Three JS atau Babylon.. Tidak memiliki JS/Asm.js => Wasm toolchain berarti aplikasi besar di Js akan mati dan orang akan menggunakan C++ dan backend pembuatan kode untuk menghasilkan Wasm. Lebih tepatnya dalam game dan semacamnya.
Tidak memiliki JS => Wasm backend tidak adil bagi Pengembang JS. Juga EMCC mengalokasikan tumpukan besar ketika dijalankan dan kecepatan terbukti karena itu, tetapi Pengembang Js yang menulis Kode js yang baik masih tidak dapat mencapai kinerja yang begitu banyak karena kerumitan penulisan kode tersebut. Seharusnya ada beberapa mekanisme untuk menggunakan kembali sebagian besar barang dan kemampuan untuk memanggil gc lebih awal atau sesuka hati. Lompatan bingkai saat GC berjalan menyebabkan Webgl melewatkan bingkai adalah masalah besar dan perlu diselesaikan. Seharusnya ada beberapa mekanisme untuk menyetel kode JS lebih baik daripada generator Kode. seperti Majelis yang ditulis tangan masih menghasilkan kode yang jauh lebih kecil dan sangat selaras. Itu harus dimungkinkan dalam perakitan web.

@metacritical C++ dapat dikompilasi ke WASM karena banyak orang melakukan banyak pekerjaan dalam prosesnya. Hal yang sama dapat terjadi untuk JavaScript, tetapi sejauh yang saya tahu, tidak ada yang mencoba ini saat ini. Ada sedikit alasan untuk melakukannya: kinerja tidak akan berubah.

Masalah mesin Anda adalah pengumpulan sampah. Masalah ini tidak akan hilang jika Anda membangun algoritme pengumpulan sampah yang menggunakan memori linier dan kode WASM... akhirnya Anda harus menghentikan program untuk melihat objek mana yang masih hidup dan menghapus yang tidak. Solusinya adalah tidak membuat objek sampah, mencegah kebutuhan GC untuk terus berjalan. Anda tidak perlu WASM untuk mencapai ini, Anda perlu mengerjakan ulang mesin Anda.

Javascript ultra murni yang menggunakan kembali Array dan menghasilkan sampah rendah sangat sulit untuk ditulis. Juga saya pikir Plain Js tidak dapat dikompilasi ke WASM. Asm.js atau TypeScript akan lebih mudah dikompilasi ke WASM karena ketersediaan anotasi atau tipe di dalamnya masing-masing.

@metacritical Sulit, tapi bukan tidak mungkin. Bahkan di mesin C++, sebagian besar kode ada di sekitar manajemen seumur hidup objek. Meskipun tidak konvensional, tidak ada alasan Anda tidak dapat melakukan hal yang sama di JavaScript.

JS biasa _dapat_ dikompilasi ke WASM tetapi kompiler harus menambahkan banyak kode pembantu untuk mengaktifkan fitur JavaScript tingkat tinggi seperti pengumpulan sampah, refleksi, properti, dan sebagainya. Pada dasarnya, semua hal yang Anda dapatkan secara gratis dengan mesin JS bawaan browser. TypeScript tidak banyak membantu.

Sebagai perbandingan, ASM.JS akan mudah dikonversi ke WASM. Bagian ketat dari fitur JS yang diizinkan oleh ASM.JS juga 100% dicakup oleh WASM. Jika ada sejumlah besar kode yang ditulis dalam ASM.JS, ini akan menjadi upaya yang bermanfaat, tetapi sejauh yang saya tahu semua file ASM.JS utama dihasilkan dari kode sumber C++, yang sudah dapat langsung menargetkan WASM.

Sebagai perbandingan, ASM.JS akan mudah dikonversi ke WASM.

Benar, dan sebenarnya cara utama kami mengkompilasi C++ ke wasm hari ini adalah dengan mengompilasinya ke asm.js terlebih dahulu, lalu mengkompilasi asm.js itu ke wasm menggunakan asm2wasm Binaryen .

@kripken Melihat spesifikasi asm.js sepertinya mudah untuk menulis asm.js tulisan tangan, yang berarti semua tidak hilang untuk programmer js, kita masih bisa mendapatkan binari WASM menggunakan yang di atas.

Bukankah evolusi JS yaitu bahasa yang diketik dengan ketat, dapat menjadikannya kandidat yang baik untuk JS -> WASM?
Saya pikir TC39 memiliki proposal untuk objek yang diketik. Mungkin lebih banyak fitur lain yang memungkinkan.

@aruns07 Semakin sedikit fitur JavaScript yang Anda izinkan untuk digunakan orang, semakin mudah untuk mengompilasi ke WASM, dan semakin besar kemungkinan orang tidak mau hidup dengan batasan Anda karena ketidakcocokan dengan perpustakaan favorit mereka.

@Kardax @aruns07 Orang menyukai kenyamanan Bahasa Dinamis. Kami membutuhkan tipe yang kuat kadang-kadang tidak setiap saat.

jfbastien mengomentari pada 24 Jun 2015
JS → wasm hanya akan benar-benar masuk akal setelah wasm mendukung GC, dan kemungkinan besar kompilasi JIT juga, yang masih cukup lama. Ini pada dasarnya akan setara dengan mengimplementasikan mesin JS di wasm!

Menurut tautan berikut:
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
Konsensus WebAssembly dan akhir Pratinjau Browser

Sekarang, 2 tahun setelah balasan pertama Anda, WebAssembly sekarang didukung oleh browser web utama saat ini.
Jadi itu tidak setara dengan mengimplementasikan mesin JS di wasm.
Kelebihan js -> wasm tidak hanya support GC, tetapi juga ukuran kode yang lebih kecil, dan eksekusi yang lebih cepat, khususnya di bidang pengembangan aplikasi Hybrid seperti Ionic2 yang biasanya menghasilkan file JS sekitar 10MB yang menyebabkan waktu buka aplikasi melebihi 5 detik (setiap 2MB parse JS = 1 detik)

@jfbastien Jadi tolong posting jawaban terbaru Anda tentang JS -> wasm transpiler ?

Sebagai bagian dari tesis master saya, saya mencoba menulis Transpiler dari subset JavaScript ke WebAssembly. Pada awalnya, ini akan terbatas pada TypeScript, tetapi varian yang diketik lainnya seperti Flow mungkin akan didukung di masa mendatang.

Namun, tujuannya bukan untuk mengimplementasikan bahasa JavaScript penuh karena, dalam hal ini, saya akan menghadapi masalah yang sama dengan yang dihadapi implementasi JIT hari ini, dan oleh karena itu, tidak ada percepatan yang dapat diharapkan (lebih pasti, implementasi saya akan 100 kali lebih lambat! ). Ini akan menjadi subset seperti yang didefinisikan oleh SoundScript

Tujuan saya lebih untuk memungkinkan bagian-bagian tertentu dari suatu aplikasi dikompilasi ke WebAssembly tanpa perlu pengembang meninggalkan lingkungan pengembangan yang sudah dikenalnya atau menggunakan bahasa pemrograman lain. Oleh karena itu, ini akan lebih ditujukan untuk mempercepat kinerja bagian penting dari suatu aplikasi dan bukan sebagai transpiler tujuan umum yang menerima aplikasi JavaScript yang ada.

Saya cukup penasaran seperti apa temuan saya karena saya melihat pro dan kontra dari pendekatan semacam itu. Beri tahu saya jika Anda memiliki masukan.

@Mohsen7s jawaban saya tetap akurat: versi MVP WebAssembly tidak mendukung kemampuan GC dan JIT yang memungkinkan untuk mengimplementasikan mesin virtual JavaScript cepat. Penerjemah sepenuhnya mungkin, dengan trik pintar itu bisa sangat bagus, tetapi tidak sebanyak yang dilakukan implementasi asli.

Ini melekat pada pendekatan "Produk yang Layak Minimal" kami: kirimkan sesuatu yang berfungsi untuk beberapa kasus penggunaan terlebih dahulu, lalu tambahkan fitur untuk memenuhi kasus penggunaan lainnya. Silakan lihat utas berikut untuk diskusi serupa tentang MVP dan "fitur masa depan" yang hilang: https://github.com/WebAssembly/design/issues/992#issuecomment -281735235

Mengesampingkan diskusi teknis tentang apa yang dapat dan tidak dapat diterapkan saat ini, saya kagum bahwa JS -> WASM bukanlah tujuan nomor 1 baik secara filosofis maupun dari perspektif pemasaran - saya gagal melihat bagaimana Anda akan mendapatkan dukungan pengembang sampai hal ini terjadi. Jika semua pengembang front/back-end/full-stack di luar sana dengan keterampilan JS yang mampu bekerja di vertikal pasar mana pun ingin menghabiskan waktu mereka untuk mempelajari C++ yang digunakan dalam subset industri yang jauh lebih kecil, maka mereka pasti sudah melakukannya jadi - saya tahu, saya berbicara sebagai satu. Mau tidak mau saya merasa bahwa seluruh diskusi ini adalah sedikit ruang gema dan bahwa mereka yang membela kurangnya kompiler akan menemukan waktu mereka akan lebih baik dihabiskan untuk berbicara dengan orang-orang di wajah batu bara menanyakan apa yang sebenarnya mereka inginkan.

@BossLevel

Mengesampingkan diskusi teknis tentang apa yang dapat dan tidak dapat diterapkan saat ini, saya kagum bahwa JS -> WASM bukanlah tujuan nomor 1 baik secara filosofis maupun dari perspektif pemasaran - saya gagal melihat bagaimana Anda akan mendapatkan dukungan pengembang sampai hal ini terjadi. Jika semua pengembang front/back-end/full-stack di luar sana dengan keterampilan JS yang mampu bekerja di vertikal pasar mana pun ingin menghabiskan waktu mereka untuk mempelajari C++ yang digunakan dalam subset industri yang jauh lebih kecil, maka mereka pasti sudah melakukannya jadi - saya tahu, saya berbicara sebagai satu.

Browser sudah dapat menjalankan JavaScript secara efisien. Browser tidak dapat menjalankan kasus penggunaan yang dimaksudkan secara efisien. Selain itu, WebAssembly memiliki aspirasi non-Web.

Diskusi ini, serta https://github.com/WebAssembly/design/issues/992#issuecomment -281735235, menggambarkan berbagai tujuan yang dimiliki orang yang berbeda. Tidak ada yang salah! MVP hanya perlu memprioritaskan siapa yang dilayani terlebih dahulu.

Mau tidak mau saya merasa bahwa seluruh diskusi ini adalah sedikit ruang gema dan bahwa mereka yang membela kurangnya kompiler akan menemukan waktu mereka akan lebih baik dihabiskan untuk berbicara dengan orang-orang di wajah batu bara menanyakan apa yang sebenarnya mereka inginkan.

Itulah inti dari pembentukan Grup Komunitas W3C. Kami pikir itu berhasil, seperti yang kami dengar dari banyak pengembang yang tertarik. Beberapa tidak tertarik dengan MVP, tetapi tertarik dengan fitur masa depan .

@jfbastien

Browser sudah dapat menjalankan JavaScript secara efisien.

Ha, saya sudah mencoba menulis game HTML5 multipemain masif yang mampu berjalan pada FPS yang layak di ponsel rata-rata sejak 2008 dan saya masih belum sampai di sana! Dan mengingat bahwa ketika saya pergi mengontrak untuk membayar tagihan, saya dihargai dengan sangat baik, saya cukup yakin bahwa kurangnya kemajuan saya bukan karena kualitas kode saya.

Itulah inti dari pembentukan Grup Komunitas W3C

Ha lagi - berapa banyak pengembang dunia nyata yang Anda kenal yang bergabung dengan Grup Komunitas? Pengembang yang melakukannya biasanya adalah penginjil dll yang berpengetahuan ya, tetapi telah merasakan lebih sedikit rasa sakit dari pengembang kehidupan nyata.

Dan saya minta maaf, saya benar-benar tidak ingin meremehkan siapa pun di halaman ini/terlibat/di W3C. Seperti yang Anda katakan, ini adalah diskusi, dan ini adalah sudut pandang saya dari garis depan.

Permintaan maaf karena kembali ke sini seperti anjing yang mengkhawatirkan tulang, tetapi sementara pergi, saya memikirkan cara yang lebih baik untuk menyampaikan maksud saya. Dalam buletin/acara komunitas Anda berikutnya atau cara apa pun yang Anda miliki untuk mengumpulkan umpan balik, ajukan pertanyaan ini kepada pengembang web (pelanggan Anda):

Untuk membawa kinerja berbasis browser ke tingkat berikutnya, Anda perlu mempelajari bahasa lain; apakah ini bisa diterima?

Karena pada dasarnya itulah pertanyaan yang sudah (menurut saya, sangat buruk) telah dijawab oleh beberapa orang di halaman ini.

Dan akhirnya (saya berjanji ;-) ) @jfbastien , jika:

Selain itu, WebAssembly memiliki aspirasi non-Web.

mengapa disebut "WebAssembly"?

@BossLevel Saya pikir saya melihat dari mana Anda berasal. Saya tidak dapat berbicara mewakili orang-orang yang melakukan penginjilan, tetapi pemahaman saya adalah bahwa penginjil yang berbeda telah berhubungan dengan pengembang "asli" tradisional yang tertarik dengan WebAssembly. Dari sudut pandang Anda, itu mungkin tidak terlihat, tetapi setidaknya saya dapat menunjukkan minat Unity sebagai tanda pengembang "serius". Orang-orang ini juga memposting ke github, dengan nama mereka sendiri, tetapi afiliasi tidak selalu terlihat. Bukan tempat saya untuk berbicara mewakili mereka.

Ha, saya sudah mencoba menulis game HTML5 multipemain masif yang mampu berjalan pada FPS yang layak di ponsel rata-rata sejak 2008 dan saya masih belum sampai di sana! Dan mengingat bahwa ketika saya pergi mengontrak untuk membayar tagihan, saya dihargai dengan sangat baik, saya cukup yakin bahwa kurangnya kemajuan saya bukan karena kualitas kode saya.

Saya tidak bermaksud menyiratkan bahwa menulis JavaScript cepat itu mudah. Yang ingin saya katakan adalah: WebAssembly tidak membuat pengoptimalan JavaScript menjadi lebih mudah. Sebaliknya, ini memungkinkan browser untuk menggunakan format yang lebih cocok untuk menghasilkan kinerja yang andal. Ini juga memungkinkan TC39 untuk fokus pada peningkatan JavaScript itu sendiri, bukan hanya JavaScript sebagai target kompilasi.

Ha lagi - berapa banyak pengembang dunia nyata yang Anda kenal yang bergabung dengan Grup Komunitas? Pengembang yang melakukannya biasanya adalah penginjil dll yang berpengetahuan ya, tetapi telah merasakan lebih sedikit rasa sakit dari pengembang kehidupan nyata.

Dan saya minta maaf, saya benar-benar tidak ingin meremehkan siapa pun di halaman ini/terlibat/di W3C. Seperti yang Anda katakan, ini adalah diskusi, dan ini adalah sudut pandang saya dari garis depan.

Sudut pandang Anda memang valid, dan saya pikir jelas bahwa dari posisi Anda, saya mengatakan sesuatu yang sulit dipercaya. Kita harus mengomunikasikannya dengan lebih baik (atau hei, mungkin saya salah :wink :).

Untuk membawa kinerja berbasis browser ke tingkat berikutnya, Anda perlu mempelajari bahasa lain; apakah ini bisa diterima?

Karena pada dasarnya itulah pertanyaan yang sudah (menurut saya, sangat buruk) telah dijawab oleh beberapa orang di halaman ini.

Saya melihat kekhawatiran Anda, tapi saya harap itu bukan salah satu yang akan menjadi kenyataan. Sekali lagi, saya mungkin salah. Cara saya melihatnya, WebAssembly membawa pengembang baru ke platform ini, pengembang yang memiliki pengalaman buruk dengan Web di masa lalu atau mendengar cerita horor. Pada gilirannya, ini membantu pengembang JavaScript yang ingin menggunakan kode "tradisional" (apa yang disebut "warisan") menggunakan kode itu: kami ingin WebAssembly mudah digunakan dari JavaScript. Untuk mencapai ini perlu semudah menggunakan npm (yang... tidak selalu mudah!).

Saya agak yakin ini akan terjadi karena umpan balik yang kami lihat di Twitter, Hacker News, Reddit, dan berbagai konferensi. Sekali lagi, mungkin saya salah dan saya mendengarkan ruang gema. Setidaknya, saya telah melakukan diskusi yang sangat menjanjikan di konferensi dengan orang-orang dengan latar belakang C++ serta JavaScript.

Pada saat yang sama, TC39 benar-benar mencoba meningkatkan JavaScript. Saya percaya dalam beberapa tahun terakhir, terutama dengan ES6.

Tapi poin Anda tetap: mungkin pengembang ingin menjadi berpengalaman dalam JavaScript serta lebih banyak bahasa "WebAssembly-friendly" seperti C++ atau Rust. Saya tidak tahu ke mana arahnya.

mengapa disebut "WebAssembly"?

Ha! Itu pertanyaan yang luar biasa. Saya memiliki ceramah berjudul "WebAssembly: bukan Web atau Majelis". Saya harus memberikannya secara terbuka sehingga saya dapat mengungkapkan perasaan saya tentang nama itu :grin:

Jadi saya akan membuat Anda tergantung pada yang satu itu.

Saya membaca dua keinginan di sini:

1. Representasi biner dari JavaScript standar untuk waktu muat yang cepat.
2. Sesuatu untuk menjembatani kesenjangan kinerja antara C++ yang dikompilasi secara native dan JavaScript standar.

Butir 2 adalah subjek penelitian yang sedang berlangsung dan investasi besar-besaran oleh banyak perusahaan. Jika Anda melihat pengukuran kinerja mesin JavaScript selama 15 tahun terakhir, ini juga berhasil... kesenjangannya semakin kecil.

Butir 1 tidak sedang dikerjakan oleh siapa pun, sejauh yang saya tahu. Ini sangat rumit, dan semakin sulit karena JavaScript terus berkembang dengan cepat. WebAssembly sangat ketat dan relatif tidak rumit, dan masih membutuhkan waktu bertahun-tahun untuk berkembang.

@jfbastien - terima kasih banyak atas tanggapan Anda yang dipertimbangkan dan perhatian :)

Jadi beberapa poin ilustrasi, tanpa urutan tertentu:

1) Contoh bagus yang saya lihat dari seluruh diskusi ini dan pandangan saya tentang arah yang harus Anda tuju, terletak pada NodeJS - JS API/front-end ke back-end C++ - Anda mendapatkan kemudahan penggunaan/keakraban dll di satu sisi dan kecepatan di sisi lain.
2) Berpegang teguh pada Node, pada tahun 2008 ketika saya memulai pengembaraan pribadi saya ;-) Saya awalnya melihat PHP dan Java untuk back-end (saya kembali ke pengembangan setelah satu dekade di sisi gelap manajemen TI dan penjualan ;-) !) tetapi dengan cepat mengabaikannya karena alasan sederhana bahwa saya hanya ingin belajar satu bahasa, dan mempelajarinya dengan baik! Sebuah kisah pribadi yang saya tahu, tapi saya ragu saya satu-satunya pengembang yang merasa seperti ini, terutama mereka yang bekerja untuk diri mereka sendiri, bukan pada uang receh perusahaan sementara mereka belajar bahasa.
3) Saya sengaja tidak mencari nomornya di Google sebelum membuat poin saya berikutnya (memang saya tidak yakin apakah saya bisa) tetapi saya berani bertaruh bahwa penerimaan ASM rendah. Saya tahu saya sangat bersemangat ketika melihat demo awal tetapi setelah mengetahui bahwa tidak ada kompiler, saya segera mengabaikannya. Untuk meminta pengembang web yang merupakan bagian dari komunitas pengembang terbesar di planet (JS) dengan beragam API, perpustakaan, sumber daya, tutorial, kerangka kerja dll yang tersedia online untuk menjauh dari itu, menurut saya terlalu banyak bertanya, dan dengan tidak memberi mereka sarana untuk berpotensi membuat langkah pertama itu (yaitu kompiler) kehilangan trik yang jelas di pihak Anda. Saya bahkan berani bertaruh bahwa pengembangan dalam bahasa Shading (GLSL) telah melihat lebih banyak pertumbuhan daripada ASM sekarang karena Anda dapat a) menulisnya langsung ke kerangka kerja yang sangat baik seperti Pixi.js dan Three.js dan b) bermain dengannya langsung di situs seperti ShaderToy .
4) Industri game/permainan pada umumnya. Saya dapat berbicara dari pengalaman di sini sebagai a) Saya telah menulis (belum dirilis!) game selama 9 tahun terakhir dan b) Saya menjabat di dewan TIGA (asosiasi perdagangan untuk pengembang game Inggris) selama 2 tahun. Percayalah, saya pikir jumlah pengembang game yang ingin bermigrasi ke web mungkin dapat dihitung dengan satu tangan - pengembang game sudah berada di industri yang mereka sukai dan bahkan mengambil bayaran/bekerja berjam-jam meskipun begitu, jadi ini tidak boleh menjadi target audiens WA. Ya, majikan mereka selalu mencari media baru untuk mem-porting game mereka, tetapi jangan menipu diri sendiri, tidak termasuk seluler (di mana kode asli sayangnya menang telak dan itulah yang saya ingin WASM perbaiki), web masih sangat banyak hubungan yang buruk dengan PC/konsol baik dari segi kinerja maupun monetisasi.
5) Sebaliknya, sementara adegan coder/indie kamar tidur tidak mencapai puncaknya seperti beberapa tahun yang lalu, ada sejumlah besar pengembang web yang suka membuat game web di waktu luang mereka. Dan sementara saya tidak ingin membelok secara terang-terangan ke dalam politik dan saya sama sekali tidak menjatuhkan orang-orang Unity (saya sudah berurusan dengan beberapa dari mereka dan ini adalah produk yang hebat), secara pribadi saya pikir Anda harus menjaga kepentingan dari banyak orang kecil, bukan satu orang besar (ini masuk akal secara filosofis dan komersial).

Saya akan sangat menantikan untuk melihat pembicaraan Anda @jfbastien :)

@RyanLamansky - Saya pikir Anda membuat perbedaan yang masuk akal. Dengan hormat:

Butir 1 tidak sedang dikerjakan oleh siapa pun, sejauh yang saya tahu. Ini sangat rumit, dan semakin sulit karena JavaScript terus berkembang dengan cepat.

Pada tingkat yang sepenuhnya pribadi, sebagai seseorang yang telah menulis JS 8 jam sehari sejak 2008, saya sangat ingin melihat evolusi JS berhenti sejenak dan biarkan orang lain menyusul! Saya selalu bekerja pada prinsip mengembangkan untuk penyebut umum terendah yaitu jika tidak memiliki dukungan 100% itu tidak terjadi (IE6/7/8/9 selain ;-)). Jadi kami menemukan diri kami dalam posisi menggelikan untuk berfokus pada pola ES6 yang trendi dan kasus penggunaan yang seharusnya ketika kami bahkan belum mendapatkan dukungan browser 100% untuk ES5 di desktop dan seluler. Bahasanya jelas berfungsi apa adanya (meskipun diakui kelemahannya) seperti yang ditunjukkan oleh pangsa pasarnya, jadi bagaimana kalau kita, sebagai komunitas pengembang, menghabiskan beberapa tahun ke depan untuk belajar menulis kode yang efisien dan optimal dengan apa yang kita miliki daripada sekali lagi menemukan kembali roda dengan kode hipster baru (maaf saya masuk ke wilayah kata-kata kasar ;-))?

Saya pikir mungkin sudah waktunya saya mendapatkan mantel saya ;-)

@RyanLamansky Saya menemukan kesan bahwa WebAssembly hanya akan menjadi target baru untuk proses pembuatan bundel Anda, dan tiba-tiba semuanya akan lebih cepat. Jelas bukan itu masalahnya. WebAssembly memiliki kasus penggunaan target yang sangat spesifik, dan kemungkinan tidak akan memiliki banyak hal untuk ditawarkan kepada pengembang web biasa dengan basis kode JS besar yang penuh dengan logika bisnis.

Tetapi seperti yang Anda perhatikan, ada beberapa celah dalam siklus hidup pengembangan berbasis JS untuk aplikasi web berorientasi bisnis yang lebih umum:
1) Bundel JS besar memiliki overhead parsing yang signifikan dan biasanya memberikan kebingungan yang tidak memadai.
2) Kode JS standar tidak memiliki anotasi tipe (dan mungkin petunjuk lain) yang diperlukan untuk membuat pengoptimalan kode JIT/Native.

Ini menyarankan solusi yang mungkin adalah versi JS yang diketik dan diberi anotasi dengan benar yang memberi pengembang jalur pengoptimalan yang lebih deterministik dan transparan, dan versi biner yang telah diurai sebelumnya dari versi bahasa tersebut.

Komentar dan dokumen mengatakan WASM berjalan selain JS dan menggunakan mesin browser JS yang sama (dioptimalkan). https://developer.mozilla.org/en-US/docs/WebAssembly

Saya tidak mengerti pertanyaan ini benar-benar.

Maaf mengajukan pertanyaan bodoh dan membuat komentar bodoh: Apakah pertanyaan dan komentar tim Webassembly berarti bahwa Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code? Saya hanya melihat pemikiran subjektif. Bisakah seseorang menjelaskan ini? Jika Webasembly lebih cepat daripada Javascript, mengapa tidak menyediakan transpiler? Jika Javascript tidak memungkinkan, mengapa tidak kode ES7/TS? Mengapa ada begitu banyak kerahasiaan di sekitar ini?

@ganeshkbhat Rilis awal WASM tidak lebih dari pengkodean biner kompak asm.js, yang merupakan subset JavaScript yang sangat ketat. Itu tidak berjalan lebih cepat dari asm.js kecuali bilangan bulat 64-bit digunakan, karena ini harus ditiru di asm.js.

Ada proposal untuk menambahkan fitur ke WASM yang akan membawanya lebih dekat ke JavaScript dalam kemampuan (pengumpulan sampah, integrasi DOM, utas), tetapi tidak ada rencana untuk menambahkan set fitur JavaScript lengkap. Jadi, kemungkinan transpiler JS->WASM tidak akan pernah ada. Sebagai gantinya, aplikasi dan perpustakaan baru akan dibuat yang dirancang untuk bekerja dalam batasan WASM. Hari ini, itulah C dan C++, di mana batasan bahasa selaras dengan WASM dan asm.js.

Tidak ada rahasia atau keajaiban apapun. Wasm "lebih cepat dari JavaScript" karena merupakan bahasa yang jauh lebih sederhana yang lebih dekat dengan perangkat keras. JavaScript adalah bahasa yang rumit yang harus melakukan banyak hal mahal selama eksekusi. Itu tidak akan secara ajaib menjadi lebih cepat dengan mengompilasinya ke kode asli melalui Wasm alih-alih secara langsung.

@ganeshkbhat saat ini, tidak mungkin untuk mengalokasikan objek di dalam asm.js / webassembly. Di asm.js dan webassembly, semua operasi JavaScript akan menggunakan satu typedarray besar untuk menyimpan dan memuat nilai di sana. Membuat objek JavaScript (mis. var obj = {a: 1, b: 'test'} ) dan larik (mis. var a = []; ) tidak dimungkinkan di dalam webassembly karena belum ada dukungan objek. Ini adalah keputusan desain Produk yang Layak Minimal yang dibuat untuk mendapatkan dukungan perakitan web di semua browser utama sesegera mungkin.

Dalam versi mendatang, dukungan GC direncanakan untuk perakitan web. Kami ( pengembang LeaningTech.com ) sedang mengerjakan proposal untuk dukungan objek di webassembly, tetapi itu akan memakan waktu untuk mendarat sebagai spesifikasi dan implementasi di semua browser utama. Sampai saat itu, tidak mungkin untuk mentranspile JavaScript (dan CoffeeScript, TypeScript, dll.) ke webassembly. Saat proposal diterima, seharusnya dimungkinkan untuk mentranspile subset JavaScript yang lebih besar , tetapi tidak akan mendukung semua fitur yang saat ini tersedia.

Tentu. Nantikan dukungan yang lebih baik untuk JS di sini. Saya pasti merasa itu bisa didukung. Menulis transpiler adalah hal yang mungkin diperlukan untuk mengetik bahasa pendukung.

Dari apa yang saya baca tentang webassembly, ini menargetkan terutama browser web dan di area itu kedengarannya tidak terlalu menarik untuk memiliki js -> kompiler webassembly. Tapi saya bisa membayangkan menjalankan webassembly di lingkungan non browser. Ini tidak sepenuhnya benar karena in juga dapat berjalan di nodejs, tetapi saya melihat potensi sebenarnya di lingkungan nodejs dalam sesuatu seperti vertx - polyglot memungkinkan menjalankan modul yang ditulis dalam bahasa apa pun, yang dapat dikompilasi ke webassembly. Saya dapat membayangkan, bahwa akan sangat sulit untuk menyelesaikan sesuatu seperti ini. Ini akan membutuhkan banyak fitur seperti GC, bahkan mungkin beberapa jenis VM untuk diimplementasikan, tetapi tidak ada yang tidak mungkin. Ingatlah bahwa banyak orang juga skeptis tentang asm.js dan melihatnya hari ini.

Untuk semua itu, yang bersemangat (seperti saya) tentang kompilasi js -> webassembly, mungkin ada cara tidak langsung dan sangat bergelombang melalui js -> c -> webassembly menggunakan proyek ts2c transpiler di masa depan.

@mauron85 Lingkungan runtime non-browser dan non-JavaScript jelas merupakan pertimbangan desain, hanya saja hanya JS API yang ada saat ini.

Untuk bagian saya, saya telah bereksperimen dengan sistem .NET JIT dan tidak melihat hambatan nyata selain waktu, dan saya yakin ada orang lain yang ingin mengintegrasikan WASM ke platform favorit mereka juga. Saya yakin beberapa tahun dari sekarang akan ada runtime non-JavaScript berkualitas tinggi untuk WebAssembly, satu-satunya pertanyaan terbuka adalah sejauh mana mereka akan secara resmi didukung oleh tim WebAssembly.

IMO satu manfaat dari kemampuan kompilasi JavaScript -> WebAssembly adalah bahwa pengembang/pengelola perpustakaan dan alat Javascript mungkin dapat merilis API mereka dalam dua format:

1. di JS (seperti sekarang) yang dapat digunakan pengguna untuk browser & node
2. WASM sebagai perpustakaan yang dikompilasi yang mungkin lebih efisien.

Dan ini tanpa harus menulis ulang kode JS mereka yang ada di C/C++, jika mereka ingin melepaskan manfaat kinerja WASM di perpustakaan JS mereka.
Jadi pengembang perpustakaan akan tetap dapat mengembangkan dan memelihara di Javascript dan menghasilkan dua output untuk dua target yang berbeda baik di JS & WASM.

Dan menggunakan perpustakaan versi WASM yang dikompilasi pasti akan lebih efisien bagi pengguna karena yang perlu mereka lakukan hanyalah menggunakan API yang terbuka dari perpustakaan dan mereka jelas tidak akan peduli apakah itu ditulis dalam WASM atau tidak. Tapi performanya pasti akan ditingkatkan.

WASM sebagai perpustakaan yang dikompilasi yang mungkin lebih efisien

Mengapa? Mengapa gumpalan javascript mengubah perakitan web (skenario kasus terburuk, termasuk banyak runtime untuk mesin javascript dalam biner itu; skenario kasus terbaik, termasuk lapisan yang dibangun di atas GC wasm bawaan masa depan, yang menimbulkan overhead sendiri ) berjalan lebih cepat daripada javascript yang dilemparkan ke jit yang didedikasikan untuk... menjalankan javascript?

Oke, maksud Anda itu akan lebih lambat dengan lebih banyak overhead?

Mungkin ada yang belum saya pahami dengan baik. Bagaimana C/C++/Rust -> WebAssembly dikompilasi benar-benar efisien dan bahkan jika ada dukungan JS -> WASM di masa depan yang akan menyebabkan overhead? Apakah itu hanya karena JS adalah bahasa yang dinamis dan C, C++, & Rust tidak? Atau karena JS pada dasarnya bukan bahasa yang dikompilasi sepenuhnya tetapi bahasa-bahasa lain ini?

Saya kira tidak mungkin kompilasi JS ke WASM akan meningkatkan kinerja yang berkelanjutan; namun, ini dapat meningkatkan ukuran kode dan waktu penguraian karena pengkodean biner, yang masih berguna.

Saya pikir kita bisa mendefinisikan pengkodean biner untuk JS, dan mengabaikan memori linier dll untuk saat ini. Ini sederhana dan polyfillable.

@kabirbaidhya Masalah utama dengan JS -> WASM sekarang adalah Anda tidak dapat membangun pengumpul sampah yang efisien di dalamnya karena tidak ada cara untuk menganalisis tumpukan untuk melihat objek mana yang hidup. Ini berarti Anda harus menempatkan salinan semua referensi objek dalam memori linier (heap) dan tetap menyinkronkannya, menurunkan kinerja secara serius. Ini juga tidak memiliki multi-threading memori bersama, sehingga pengumpulan sampah latar belakang tidak mungkin dilakukan. Versi WASM mendatang akan dapat memanfaatkan mesin pengumpul sampah browser host, menghilangkan masalah ini.

Hambatan utama lainnya untuk JS -> WASM adalah kenyataan bahwa hampir semua objek sepenuhnya dinamis. WASM secara intrinsik mengharapkan semuanya menjadi statis murni, sehingga lapisan pemetaan yang kompleks, emulasi, dan pembuatan kode dinamis akan diperlukan untuk mendekati kinerja JS standar. Untungnya, TypeScript membantu dalam hal ini, jadi subset ketat dari TypeScript mungkin dapat menargetkan WASM sampai tingkat tertentu. Saya tahu setidaknya ada satu orang yang mencoba membangun ini.

C/C++ bekerja dengan baik dengan rilis pertama WASM karena fakta bahwa keterbatasan WASM sangat selaras dengan keterbatasan perangkat keras asli, yang dirancang untuk ditargetkan oleh C/C++.

FWIW ada slidedeck yang bagus tentang bagaimana V8 menangani aritmatika JavaScript: https://docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl; dr ini hanya _one_ contoh di mana kenyataannya jauh lebih sulit daripada yang terlihat dan dalam praktiknya tidak terlalu berarti karena VM asli dapat (dan kemungkinan akan) melakukan pekerjaan yang lebih baik dan lebih cepat karena itu benar-benar asli dan memiliki akses ke sumber daya dan API tidak akan pernah - dan (mungkin) yang paling penting, iterasi bertahun-tahun.

Itu tidak berarti _subset_ dari JS/TypeScript tidak dapat berkembang biak dengan sukses, seperti ThinScript , TurboScript , dll.

Saya masih berpikir ini adalah pertanyaan yang bagus untuk ditanyakan, dan terus bertanya. Sangat penting bagi kita semua untuk memahami kasus penggunaan dan masa depan WebAssembly--serta non-sasaran.

Pada 6 April 2017 pukul 00:36, Ryan Lamansky [email protected] menulis:

Hambatan utama lainnya untuk JS -> WASM adalah kenyataan bahwa hampir semua objek
sepenuhnya dinamis. WASM secara intrinsik mengharapkan semuanya murni
lapisan pemetaan statis, begitu kompleks, emulasi, dan pembuatan kode dinamis
akan diperlukan untuk mendekati kinerja JS standar. Untung,
TypeScript membantu dengan ini, jadi subset ketat dari TypeScript mungkin dapat
menargetkan WASM sampai tingkat tertentu. Saya tahu setidaknya ada satu orang yang mencoba
membangun ini.

Sayangnya, saya ragu bahwa TypeScript membantu dalam hal ini. untuk mencakup
Warisan JS, sistem tipenya sangat dalam dan pada dasarnya tidak sehat sehingga
tidak ada subset "ketat" yang menarik. Misalnya, subset seperti itu akan
perlu mengecualikan gagasan TS tentang subtipe, yang akan membuatnya cantik
banyak tidak berguna dalam domainnya.

Ada makalah penelitian yang bagus, seperti misalnya di SafeTypeScript, tetapi tidak
hanya saja mereka lebih terbatas, mereka juga membutuhkan sejumlah besar
pembukuan dan pemeriksaan runtime tambahan yang mahal, mengalahkan tujuan dari
diskusi (dan secara efektif menjadi bahasa yang berbeda dari JS/TS).

Mungkin saya tidak mendapatkan sesuatu, tetapi salah satu ide WebAssembly adalah memuat AST secara langsung untuk menghindari waktu parse js, bukan?

Jadi, jika kita memiliki alat yang mengkompilasi js ke format ast ini dan meneruskannya ke browser, bukankah itu akan bermanfaat dari menghindari waktu untuk mengurai?

@agnivade , ini adalah AST untuk bahasa tingkat rendah yang sama sekali berbeda.

Jika Anda mengkompilasi JS ke Wasm offline, maka ya, Anda tidak perlu mengurai di sisi klien (cukup dekode). Pada saat yang sama, karena JS sangat rumit, ukuran kode akan meningkat secara drastis, mungkin dengan faktor 5 atau lebih, yang merupakan biaya yang jauh lebih tinggi. (Dan itu bahkan tidak memperhitungkan bahwa Anda mungkin juga perlu memasukkan seluruh implementasi sistem runtime JS VM di Wasm, yang dengan mudah adalah megabyte kode.)

Selain itu, tanpa representasi sumber, Anda tidak dapat menerapkan sebagian besar pengoptimalan dinamis yang sangat penting untuk mendapatkan JS dengan cepat. Pengoptimalan ini bergantung pada kompilasi ulang kode sumber asli dan mengkhususkannya berdasarkan informasi profil. AST Wasm yang sudah dikompilasi tidak mengaktifkannya, Anda memerlukan AST dari program sumber aslinya.

@rossberg-chromium - Terima kasih banyak. Itu membersihkan banyak! Satu keraguan meskipun -

Dan itu bahkan tidak memperhitungkan bahwa Anda mungkin juga perlu memasukkan seluruh implementasi sistem runtime JS VM di Wasm, yang dengan mudah adalah megabyte kode

Mengapa Anda membutuhkan sistem runtime VM? Bukankah browser itu sendiri adalah runtime VM? Saya hanya ingin kode dalam format AST sehingga browser dapat dengan mudah mulai menjalankannya. Saya mendapatkan bahwa ukuran bersih akan meningkat karena bahasa itu sendiri rumit, dan kami tidak dapat menerapkan pengoptimalan dinamis. Tetapi mengapa kita perlu menggabungkan runtime VM itu sendiri, ketika kita memiliki browser untuk itu?

@agnivade , tanpa

Yang saya maksud dengan "runtime" bukanlah hal-hal browser seperti DOM, tetapi dukungan bahasa JS, yaitu, hal-hal seperti pengumpul sampah, representasi objek, primitif dan pustaka dasar, dll. Itu cukup besar untuk JavaScript, dan Anda akan perlu implementasi ulang semua itu di dalam Wasm.

Dan tentu saja, Anda juga memerlukan lapisan antarmuka ke DOM.

Ok saya pikir saya mengerti hal-hal sedikit lebih baik sekarang. Saya berpikir bahwa

pengumpul sampah, representasi objek, primitif dan perpustakaan dasar, dll.

dapat digunakan dari browser itu sendiri. Dan saya bisa membiarkan browser memuat AST dan melakukan tugasnya seperti biasa. Tetapi sekarang saya menyadari bahwa semuanya perlu dikemas di dalam WASM itu sendiri.

Bytecode bahasa scripting universal-ish akan menarik! Target kompilasi yang dirancang untuk mengangkut dan menjalankan program secara efisien yang ditulis dalam bahasa yang diketik secara dinamis, bahasa yang dikumpulkan sampah, dengan semua kasus tepi aneh dari yang populer (javascript, ruby, python, lua) tercakup dalam (beberapa kasus) opcode dan struktur khusus dll

@distransient , jadi Anda ingin kegilaan kombinatorial dari semua bahasa skrip? Saya optimis bahwa umat manusia dapat mengumpulkan sumber daya teknik untuk menentukan dan mengimplementasikannya secara efisien pada tahun 2050. :)

Mereka yang tertarik untuk mengkompilasi TypeScript ke WebAssembly menggunakan LLVM. lihat proyek jangkauan ini. https://github.com/MichaReiser/speedy.js
Sepertinya diskusi ini tidak akan pernah berakhir ...

@rossberg-chromium Saya mengatakan itu akan "menarik", tidak mudah atau cantik

Sebuah bytecode bahasa scripting universal akan menarik...

Sementara WASM secara bertahap berkembang untuk akhirnya mendukung hal-hal seperti Python, kami dapat memiliki dukungan kelas satu untuk mengembangkan bahasa skrip untuk Web lebih cepat daripada yang dapat disediakan oleh WASM, jika kami mendekati masalah dari ujung yang berlawanan pada saat yang sama.

Seharusnya relatif sederhana bagi mesin JavaScript untuk mengekspos kemampuan mereka untuk mengeksekusi AST JavaScript, dan AST yang mereka terima dapat distandarisasi (bahkan jika mereka segera dikonversi ke format perantara non-standar secara internal).

Kita cukup menggabungkan format AST (seperti estree ) dan format serialisasi (seperti JSON) untuk membuat format file baru dengan ekstensi baru. Jika browser mendukung format dalam tag skrip dan sebagainya, maka bahasa seperti TypeScript dan CoffeeScript hanya akan dikompilasi untuk mengurai pohon, dan browser akan mengambilnya dari sana. Bahasa yang ditranspilasikan tidak perlu melakukan pembuatan kode, dan peta sumber juga tidak lagi diperlukan, karena informasi leksikal akan didasarkan pada sumber yang sebenarnya.

Setelah dukungan dasar dibuat, standar dapat berkembang secara bertahap untuk memenuhi WASM di tengah, dengan hanya menambahkan tipe node baru. Ada hal-hal sederhana untuk memulai, seperti node add dan concat eksplisit, atau mungkin menambahkan tipe data baru, seperti DEC64.

Saat WASM membangun untuk mendukung bahasa skrip, dengan menambahkan hal-hal seperti GC, eksekusi AST akan bergerak ke bawah, memperluas semantik JavaScript untuk menyertakan fitur dari bahasa tingkat tinggi lainnya, sehingga kumpulan bahasa skrip yang lebih luas dapat dikompilasi menjadi semacam JavaScript abstrak .

Pada 25 Mei 2017 pukul 02:57, Carl Smith [email protected] menulis:
>

Ada beberapa masalah yang perlu ditangani, tetapi itu akan menjadi
relatif sederhana untuk mesin JavaScript untuk mengekspos dukungan internal mereka
untuk menjalankan AST JavaScript, dan AST yang mereka terima harus
standar (bahkan jika AST segera diubah menjadi non-standar,
format menengah secara internal).

Hanya untuk definisi "relatif sederhana" yang jauh lebih luas daripada yang mungkin Anda ketahui
ada dalam pikiran... ;)

Dibandingkan dengan WASM, itu sederhana.

@bguiz Misalnya:

• Anda tidak dapat menerjemahkan JS secara native ke ASM, karena memiliki arsitektur yang berbeda.
• Anda tidak dapat memanipulasi DOM dari ASM, karena Anda tidak memiliki akses ke sumber dayanya di tingkat dasar CPU.

Mesin Google V8 sudah mengkompilasi JavaScript langsung ke kode mesin asli, dengan mengkompilasi seluruh tugas runtime, sebelum menjalankannya.

Jadi sama sekali tidak perlu memiliki saluran WASM alternatif dari sisi klien.

Di sisi lain, WASM disajikan dengan demo Mandelbrot, kemudian menampilkan demo Unity "Tank" di tempat pertama, tetapi saya sangat ragu bahwa menggambar piksel dengan ASM->CPU (bahkan dengan presisi ganda SSE) bisa lebih cepat daripada WebGL->GPU, karena seperti yang dikatakan komunitas ini, GPU tidak ada dalam cakupannya. Terus?

@ivanherczeg Wah ! Di mana komunitas ini mengatakan GPU tidak dalam spesifikasi?

@SephReed

Kami sudah memiliki ketegangan karena perbedaan bikeshed antara lengan dan x86. Saya pikir menambahkan satu set target perangkat keras akan menciptakan lebih banyak ketegangan: lebih banyak operasi harus lambat karena biaya emulasi untuk mendapatkan semantik yang seragam pada semua target, atau lebih banyak operasi harus memiliki perilaku tidak terdefinisi untuk memungkinkan semua orang berjalan cepat. Saya pikir itu membuatnya tidak menguntungkan untuk mempertimbangkan GPU saat ini (atau selamanya).

-Fil

https://github.com/WebAssembly/design/issues/273#issuecomment -123094583

C# runtime di-porting ke wasm dan merupakan prototipe yang berfungsi penuh menggantikan JS sepenuhnya. Jadi ini berarti di masa depan Anda dapat mengharapkan runtime muncul untuk menggantikan JS di browser dan menulis aplikasi web sisi klien di Java, C# atau bahkan C++ dengan pernyataan yang mengatakan "Kode akan berjalan lebih cepat di dekat asli" , "Kode yang dikompilasi lebih cepat daripada VM" atau apa pun tanpa bantuan JavaScript.

Silakan tonton video ini dari apa yang saya coba katakan.

WebASM diperkenalkan untuk melengkapi JS agar tidak mengambil alih sepenuhnya, menggantikan bahasa kelas satu.

Dalam waktu dekat, Anda dapat mengharapkan halaman web dikirim dari server yang dikompilasi secara asli

https://github.com/ballercat/walt

@Steakeye Sangat bagus :) Saya akan bermain - terima kasih banyak untuk menyoroti :)

anda dapat mengkompilasi JS ke WebAssembly menggunakan NectarJS . Demo: http://nectar-lang.com/ pilih dari dropdown WebAssembly

Menariknya, demo NectarJS menggunakan emscripten, Anda bisa melihatnya di output asm.js. Tampaknya secara statis mengkompilasi JS menjadi sesuatu - kemungkinan C atau LLVM IR - dan kemudian menjalankannya melalui emscripten.

Output wasm juga menggunakan emscripten (dapat dilihat dari memeriksa biner), tetapi tampaknya menggunakan versi lama karena memancarkan 0xd binari wasm, yang tidak berjalan di VM modern. Itu juga hanya mengirimi Anda wasm, bukan JS, jadi bagaimanapun juga itu tidak dapat dijalankan. Bagaimanapun, sangat mungkin itu hanya melakukan hal yang sama seperti untuk asm.js, hanya menjalankan emscripten dengan flag for wasm output dinyalakan.

Demo memiliki batas 300 byte pada input, jadi sulit untuk memberi makan program dunia nyata untuk merasakan seberapa kuat analisis mereka, yang merupakan pertanyaan sebenarnya dengan pendekatan statis seperti ini. Secara umum, penelitian akademis tentang topik ini menunjukkan skeptisisme.

Demo terkompilasi mereka untuk Windows hanya crash untuk saya

Saya setuju dengan skeptisisme @kripken di sini. Saya percaya JS sewenang-wenang tidak dapat dikonversi secara wajar ke WebAssembly. Alat apa pun yang mengklaim untuk mencapai ini mungkin bekerja pada beberapa subset bahasa JS yang dapat dilacak, atau melepaskan kinerja eksekusi.

JS adalah bahasa yang sangat dinamis. Operasi run-time yang tidak dapat diprediksi dapat secara signifikan dan global mengubah semantik kode. Ini berarti bahwa kompiler Ahead-Of-Time (atau offline) hanya dapat mengasumsikan yang lebih buruk dan menghasilkan kode generik yang sangat tidak efisien yang dapat menangani semua kemungkinan kasus. Sebagai contoh ambil kode JS berikut:

var a = {prop1: 1};
func(a);

dapat dikonversi (dalam pseudo-wasm) menjadi ini

i32.const 42
call $CreateJSValFromStrTable ;; Returns prop1
i32.const 1
call $CreateJSValFromInt
call $CreateJSObj1 ;; Consume a JS string and a JS value to make an object
call $_func

Sekarang, ini jauh dari apa yang dapat kita anggap "kompilasi" dan ini lebih mirip dengan membuka gulungan juru bahasa. Tentu saja juga dimungkinkan untuk menjalankan juru bahasa JS yang dikompilasi ke Wasm, tetapi itu tidak akan menjadi kemenangan kinerja.

Mesin JS seperti V8 dan Spidermonkey dapat menjalankan kode JS secepat yang mereka lakukan dengan mengkompilasinya Just-In-Time. Dengan melakukan kompilasi JIT, mereka dapat mengamati apa semantik yang sebenarnya dimaksudkan untuk bagian JS tertentu dan menghasilkan kode cepat untuk kasus tertentu itu, sambil tentu saja berhati-hati untuk mendeteksi perubahan apa pun di lingkungan yang dapat membatalkan asumsi saat ini.

Sepakat. Namun saya tidak keberatan menggunakan subset JavaScript. Atau mungkin varian yang diketik, yang mungkin akan mengurangi dinamisme dan memungkinkan pembuatan kode yang lebih efisien.

Apakah ada berita di depan "mode kuat" BTW?

@Simran-B, kami telah lama meninggalkan mode kuat, karena alasan yang dirangkum di sini . Kesimpulannya adalah hampir tidak mungkin untuk mengencangkan semantik JavaScript tanpa kehilangan interop dengan kode yang ada.

Untuk alasan yang sama, saya juga tidak memiliki banyak harapan untuk ide merancang dialek JavaScript atau TypeScript yang "dapat dikompilasi secara statis" -- ini akan menjadi bahasa berbeda yang tidak dapat menjalankan kode yang ada, jadi tidak banyak gunanya.

@Simran-B : "Saya tidak keberatan menggunakan subset JavaScript. Atau mungkin varian yang diketik"

Ada beberapa pekerjaan yang sangat menarik di ruang itu, seperti AssemblyScript yang merupakan subset ketat dari TypeScript yang dikompilasi ke WebAssembly, https://github.com/AssemblyScript/assemblyscript

@rossberg : "Saya juga tidak punya banyak harapan untuk ide mendesain dialek JavaScript atau TypeScript yang "dapat dikompilasi secara statis" -- itu akan menjadi bahasa yang berbeda yang tidak dapat menjalankan kode yang ada, jadi tidak banyak gunanya."

Saya pikir potensi besar dengan hal-hal seperti AssemblyScript bukan tentang menjalankan kode yang ada (saya setuju dengan Anda di sana, itu tidak akan layak secara umum), tetapi memiliki bahasa yang ramah dan akrab adalah masalah besar.

Saat ini jika Anda adalah seorang pengembang TypeScript dan Anda ingin menulis WebAssembly maka Anda perlu menggunakan C++ atau Rust. Keduanya adalah bahasa yang baik tetapi juga memiliki kelemahan. Untuk seseorang dengan latar belakang itu, sesuatu seperti AssemblyScript bisa menjadi jalur tercepat menuju produktivitas.

Jika AssemblyScript dapat dikompilasi ke JavaScript dan Assembly, itu akan sangat ideal. Menantikan pembaruan ini.

Juga, di masa depan, kecuali seseorang melakukannya terlebih dahulu, saya mungkin akan mencoba menulis TypeScript -> konverter Assembly Script yang menelusuri file, mengajukan pertanyaan yang perlu diajukan, dan kemudian membuat konversi. Semoga berhasil!

@SephReed Ya itu dapat dikompilasi ke JavaScript, karena ada kompiler WebAssembly -> asm.js , yang harus bekerja dengan semua kode WebAssembly.

Lihat juga "Dapatkah WebAssembly menjadi polyfill?"

Jika Anda bermaksud "apakah mungkin AssemblyScript untuk mengkompilasi ke kode JavaScript idiomatik ?", maka saya harus bertanya, mengapa Anda ingin melakukan itu ketika WebAssembly / asm.js jauh lebih cepat daripada kode JavaScript idiomatik?

Meskipun saya kira Anda harus dapat menjalankan kode AssemblyScript melalui kompiler TypeScript. Namun Anda perlu mengingat hal-hal tertentu .

Lihat juga bagian dokumentasi AssemblyScript ini.

Tuan-tuan, mohon pertimbangkan WALT , bahasa WebAssembly seperti JavaScript.

UPD. Maaf necroposting

Saya melihat banyak orang menganggap kompiler "JS -> WASM" ini sebagai ide yang bagus.

Bagi mereka yang tidak merasa berguna, seperti:

Saya tidak yakin itu akan berguna dari sudut pandang pengembang. Anda mungkin mendapatkan beberapa pengurangan ukuran, tapi itu saja. Dari perspektif browser, mungkin menarik untuk mengimplementasikan mesin JS di wasm dari perspektif keamanan murni.

Tolong, inilah contoh konkret saya tentang mengapa itu penting, dan mengapa itu berguna, dan bukan hanya Anda "mendapatkan pengurangan ukuran, tetapi hanya itu". Salah satu fitur yang disertakan dengan WebAssembly adalah:

<=XXX « LINGKUNGAN SANDBOXeD » XXX=>

WebAssembly bukan hanya tentang kinerja. Anda mungkin melihat artikel bagus tentang plugin dari tim Figma .

Membuat sistem plugin cukup menantang. Anda memerlukan beberapa cara yang baik untuk menjalankan kode khusus. Anda membutuhkan lingkungan yang terpisah, yang aman.

WebAssembly memberi Anda itu, - lingkungan murni tanpa kekacauan seperti beberapa variabel global. AssemblyScript membuatnya nyaman, - Anda memiliki lingkungan TypeScript yang hampir sama, seperti lingkungan aplikasi utama Anda, yang cukup keren.

Tapi inilah masalahnya, "hampir sama":

Bisakah saya menggunakan paket JS dari NPM dalam lingkungan aman saya?

Tidak.

Nah, proyek WALT ini adalah semacam alternatif AssemblyScript. Hampir tidak seperti JS, - diketik js. Ini lebih seperti TS. Anda tidak dapat mengkompilasi/mengubah pustaka js yang ada dengan itu.

Bisakah saya menggunakan paket TS dari NPM dalam lingkungan aman saya?

Tidak.

AssemblyScript juga bahasa seperti TS. Itu dapat mengkompilasi sesuatu yang ditulis dalam TS jika sepenuhnya ditutupi dengan tipe. Tidak ada pengecualian. Tidak ada any . Tetapi seringkali orang memiliki konfigurasi yang tidak cukup ketat atau mereka memiliki beberapa @ts-ignore , atau bahkan lebih sering, - mereka menulis paket dalam js dan menyediakan tipe terpisah dalam file .d.ts - dalam semua kasus ini Anda tidak akan dapat mengkompilasi paket seperti itu ke WASM.

@JerryGreen poin bagus, tetapi di sisi kinerja, saya sebenarnya percaya itu adalah kesalahpahaman besar bahwa tidak ada manfaat kinerja yang signifikan selain menghemat beberapa byte. Orang-orang, termasuk benchmark, sangat terobsesi dengan kinerja runtime. Lihat seberapa cepat ia menjalankan game 3D?

Namun peluang dunia nyata sebenarnya ada dalam kinerja startup , yang menguntungkan hampir semua situs web. Hanya sedikit yang berbicara tentang bagaimana WebAssembly secara substansial lebih cepat dalam waktu startup (per byte), jauh melampaui manfaat runtime. Inilah sebabnya mengapa misalnya gzip pada konten tekstual, seperti JavaScript, memiliki sedikit dampak dunia nyata pada PLT -- ukuran kode yang

Ironisnya, industri terobsesi dengan PLT (Page Load Times), dan berbagai penanda visual yang lengkap, namun tidak ada yang melihat korelasi antara WebAssembly dan vektor-vektor ini? JavaScript bertanggung jawab atas lebih dari 30% waktu yang dihabiskan sebelum peristiwa penting ini, di sebagian besar situs web. Faktanya, ukuran halaman dan bandwidth memiliki dampak yang jauh lebih kecil pada PLT dibandingkan dengan faktor kinerja linier, yaitu waktu startup JavaScript dan latensi.

Dengan demikian, tidak jelas bagi saya kelayakan JS -> WebAssembly.

Pendekatan @JerryGreen Figma adalah kasus yang sangat spesifik dan saya kira untuk sebagian besar proyek, iframe atau ranah cukup untuk isolasi javascript pihak ketiga. Untuk kasus khusus di mana isolasi harus lebih terkontrol dan kinerja, ukuran dan waktu buka tidak begitu penting, Anda selalu dapat mengkompilasi QuickJS atau JavaScriptCore ke WebAssembly.

Anda juga dapat menggunakan Pekerja Web , dan menjalankan kode sebelum kode tidak tepercaya Anda yang menghapus API apa pun yang Anda tidak ingin akses kode tidak tepercaya tersebut. Tidak perlu WASM dalam hal ini @JerryGreen!

Framerate Turun dalam Tiga js dalam hal yang nyata, saya tidak yakin apakah wasm dapat membantu tetapi tampaknya begitu setidaknya di permukaan.

Tidak ada alasan untuk mengkompilasi JS ke wasm karena Anda juga harus menyertakan seluruh javascript vm. Kode yang dihasilkan akan sangat besar dan lebih lambat dari JS VM yang disediakan secara asli.

Tidak bisakah kita melakukan semua monomorfisasi dll yang dilakukan oleh JS VM melalui Profile-Guided Optimization ? Kami akan melakukan hal yang sama seperti yang dilakukan VM JS saat runtime, tetapi sebelumnya.

Pembuatan PGO terdiri dari dua lintasan: lintasan pertama untuk membangun binari berinstrumen, lalu lintasan kedua untuk membangun kembali binari yang dioptimalkan menggunakan informasi profil yang diperoleh dari menjalankan binari berinstrumen.

Jalankan pertama akan memberi kami semua jenis info (fungsi mana yang dipanggil dengan argumen yang diketik, dll), kemudian kami membangun biner yang dioptimalkan dengan semua varian fungsi yang dipanggil (+ yang umum dengan argumen dinamis untuk kode yang tidak diprofilkan) . Kami tidak membutuhkan seluruh JS VM.

PGO membutuhkan cakupan tes yang bagus untuk program Anda. Itu tidak selalu mungkin. Tetapi Anda dapat melacak beberapa jenis informasi selama eksekusi di v8. Lihat dokumen ini: https://docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading =h.xgjl2srtytjt

Kami telah berbicara dengan tim TypeScript tentang kemungkinan ini dan mereka telah menunjukkan minat, tetapi sepertinya ada kemajuan saat ini untuk menambahkan objek yang diketik ke JS.

Tidak perlu tipe

Bisakah QuickJS benar-benar dikompilasi ke WASM?

Ya, Figma menggunakan QuickJS untuk sistem plugin mereka misalnya

Dan itu digunakan di http://numcalc.com/ juga.