Design: Webasm dapat menggantikan Javascript di browser?

Saya tidak cukup akrab dengan c#, tetapi sebenarnya, saya pikir wasm tidak dapat mengambil alih javascript sepenuhnya.

Pertama, jika Anda telah mencoba, Anda akan menemukan bahwa javascript jauh lebih cepat daripada wasm di beberapa operasi tingkat rendah, seperti "+,-,*,/" dan beberapa operasi terkait matematika lainnya karena sedikit overhead saat menelepon dari JavaScript ke WebAssembly dan kembali. #1120

Kedua, bagi para web developer, mereka sudah familiar dengan javascript dan grammar-nya, tidak perlu dan sulit bagi mereka untuk membangun web apps dengan bahasa non-web development lainnya.

Akhirnya, dengan bantuan " Binary AST ", kinerja aplikasi web saat ini akan dinaikkan ke tingkat yang baru tanpa ada revisi pada aplikasi tersebut.

PS:
Tidak peduli C# atau Java, jika Anda ingin membuat bahasa pemrograman ini lebih ramah bagi pengembang, efisiensi bahasa ini akan terbatas karena beberapa fitur "mudah digunakan" seperti "tipe lemah" dan fitur lainnya, begitu pula sebaliknya.

@Becavalier Mungkin ya jika Anda mencoba memanggil fungsi wasm dari overhead konteks JS ada, tetapi runtime tidak berkomunikasi dengan Javascript sampai dan kecuali diperlukan secara eksklusif untuk .. seperti kueri/Manipulasi DOM, inline CSS, Cat kanvas _etc.._ Semua eksekusi yang terjadi di dalam konteks wasm cukup cepat. Penundaan muncul ketika jembatan JS diperkenalkan, seperti dalam kasus #1120 Anda mencoba mencetak stempel waktu kinerja dalam konteks Javascript untuk fungsi yang dijalankan dalam konteks wasm yang merupakan penundaan tambahan.

Kerangka kerja populer seperti Angular2/4 yang merupakan perombakan total mengadopsi TypeScript, Android di Kotlin atau iOS di Swift, ketika ada nama besar di balik beberapa kerangka kerja atau bahasa seluruh dunia mencoba untuk mengadopsi perubahan.

Jadi intinya adalah, ada kemungkinan JS dikesampingkan atau bahkan dihapus dari gambar dengan mengabstraksi jembatan API dan porting runtime di browser. Webassembly telah membuka pintu bagi kompiler bahasa lain untuk bersaing dengan Javascript di browser.

Kami awalnya menggunakan teknologi yang membuat kode JS kami lebih efisien untuk dijalankan pada VM seperti V8 dan lainnya, tetapi sekarang Anda dapat menulis dan mengkompilasi ke kode perakitan yang dapat melompati kode JS.

Sekarang Anda dapat mengharapkan kompiler untuk web menggantikan transpiler seperti TypeScript, CoffeeScript dll.

Pengembang Javascript, tetap semangat . Dapat mengharapkan beberapa langkah besar di tahun-tahun mendatang.

PS : Saya suka Javascript dan C-Lang

Webassembly telah membuka pintu bagi kompiler bahasa lain untuk bersaing dengan Javascript di browser.

Ya memang, itulah salah satu tujuan dari WebAssembly.

Berikut adalah kutipan dari WebAssembly FAQ :

Sementara WebAssembly akan, dari waktu ke waktu, memungkinkan banyak bahasa untuk dikompilasi ke Web, JavaScript memiliki jumlah momentum yang luar biasa dan akan tetap menjadi bahasa dinamis tunggal, istimewa (seperti dijelaskan di atas) dari Web. Selain itu, JavaScript dan WebAssembly diharapkan dapat digunakan bersama dalam beberapa konfigurasi:

• Seluruh, aplikasi C++ yang dikompilasi yang memanfaatkan JavaScript untuk merekatkan semuanya.

Ingatlah bahwa bahasa lain telah dikompilasi ke JavaScript selama bertahun-tahun , dan mereka akan terus melakukannya dengan atau tanpa WebAssembly.

Anda sudah dapat mengkompilasi C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, dll. ke JavaScript.

Anda dapat mengkompilasi .NET bytecode ke JavaScript , Anda dapat mengkompilasi OCaml bytecode ke JavaScript , dan GWT telah ada selama 11 tahun dan telah digunakan dalam proyek-proyek besar.

Proyek-proyek ini telah ada selama bertahun-tahun. Ini sebenarnya bukan hal baru.

JavaScript sudah bersaing dengan bahasa lain. WebAssembly hanya membuat bahasa lain lebih efisien, itu saja.

Kami awalnya menggunakan teknologi yang membuat kode JS kami lebih efisien untuk dijalankan pada VM seperti V8 dan lainnya, tetapi sekarang Anda dapat menulis dan mengkompilasi ke kode perakitan yang dapat melompati kode JS.

Ya, karena VM JavaScript tidak pernah dapat mencapai kinerja asli, karena overhead mesin JIT (dan sifat dinamis bawaan dari JavaScript), jadi jika Anda menginginkan kinerja lebih, Anda memerlukan kontrol tingkat rendah yang ketat dari eksekusi kode. WebAssembly memberi Anda kendali itu.

Jadi intinya adalah, ada kemungkinan JS dikesampingkan atau bahkan dihapus dari gambar dengan mengabstraksi jembatan API dan porting runtime di browser.

Tidak, orang akan terus menggunakan JavaScript.

Selama bertahun-tahun di desktop ada banyak bahasa untuk dipilih: Python, Perl, Ruby, PHP, Haskell, JavaScript (Node.js), OCaml, C++, Java, dll.

Orang menggunakan banyak bahasa, termasuk JavaScript. JavaScript tidak akan kemana-mana.

Bahkan di dunia hipotetis ( sangat tidak mungkin) di mana JavaScript bukan bahasa kelas satu, orang masih dapat mengkompilasi JavaScript ke WebAssembly.

Sekarang Anda dapat mengharapkan kompiler untuk web menggantikan transpiler seperti TypeScript, CoffeeScript dll.

Itu tidak mungkin, masih ada alasan bagus bagi orang untuk menggunakan TypeScript dan JavaScript.

Tentu saja akan ada alternatif untuk TypeScript, dan beberapa orang akan menggunakan alternatif tersebut, tetapi TypeScript tidak mungkin hilang.

Saya mengatakan itu karena sudah ada alternatif yang baik untuk TypeScript selama bertahun-tahun (seperti Haxe ) tetapi mereka tidak pernah menggantikan TypeScript.

Pada 4 September 2017 pukul 03:42, Pauan [email protected] menulis:
>

JavaScript sudah bersaing dengan bahasa lain. WebAssembly hanya membuat
bahasa lain lebih efisien, itu saja.

Yang terakhir ini tidak sepenuhnya benar. Tujuan lain dari Wasm adalah untuk mengaktifkan fitur
yang tidak didukung oleh JavaScript, dan kemungkinan tidak akan pernah didukung. Untuk
contoh, konkurensi, panggilan ekor, atau pengecualian yang dapat dilanjutkan semuanya ada di
peta jalan.

@rossberg-chromium Memang Anda benar, saya lupa detail itu. Terima kasih telah mengklarifikasi.

@Pauan Terima kasih atas detailnya. Meskipun beberapa poin Anda valid dan masuk akal, saya tidak setuju dengan semuanya.

C# di sisi klien terlihat menjanjikan dan contoh pembunuh untuk menghindari Javascript sepenuhnya pada tahap pengembangan. yaitu.. Saya dapat menggunakan C# untuk menulis aplikasi web yang berfungsi penuh tanpa saya menulis kode Javascript. Kerangka kerja berbasis sikap semacam ini memiliki kemungkinan peluang untuk mematikan warisan Javascript setidaknya sampai batas tertentu.

Anda sudah dapat mengkompilasi C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, dll. ke JavaScript.

Ya Javascript ada di gambar. Tetapi sekarang dengan WASM/Webasm motif kompilasi saya ke Javascript berubah. Seseorang dapat langsung mengkompilasi ke wasm dan menulis lapisan topeng API atau jembatan dalam Javascript kapan pun diperlukan, sehingga basis pengembang tidak perlu mengetahui Javascript untuk mengembangkan aplikasi web dengan Webapp maksud saya Webapp murni bukan ASP.net, kerangka kerja agak JSP.

Ingatlah bahwa bahasa lain telah dikompilasi ke JavaScript selama bertahun-tahun, dan mereka akan terus melakukannya dengan atau tanpa WebAssembly.

Anda sudah dapat mengkompilasi C#, F#, C++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, dll. ke JavaScript.

Sementara banyak bahasa sudah dapat dikompilasi ke JavaScript, apakah kompilasi ke Webasm menghindari beban yang signifikan dan hukuman kinerja runtime untuk melakukannya? Dan masalah kinerja jika Anda mengkompilasi bahasa C VM penuh ke Webasm untuk melakukannya seperti itu?

Jika menggunakan bahasa lain menghasilkan masalah kinerja yang tidak dapat dihindari, atau banyak tempat yang melanggar spesifikasi bahasa itu (untuk alasan kinerja), itu adalah pengganti sebagian untuk JavaScript yang terbaik dan umumnya saya telah melihat mereka lebih banyak digunakan untuk mem-porting kode lama daripada kode baru ke "ganti JavaScript" (kecuali CoffeeScript, TypeScript, dll. yang dirancang untuk dikompilasi ke JS dengan baik).

Apakah masalah-masalah tersebut dapat diselesaikan? misalnya dengan Ruby baru -> kompiler Webasm, dan dapatkan kinerja yang sebanding dengan JavaScript browser saat ini?

Untuk menggunakan JavaScript dan Ruby (dengan Opal) sebagai contoh (sebagai sesuatu yang saya coba dan pada dasarnya ditinggalkan sebelumnya):

Dalam JavaScript dengan operator + , memungkinkan angka dikonversi menjadi string, mis

5 + " example" === "5 example"

Ruby memiliki pengetikan yang jauh lebih kuat, dan itu tidak diperbolehkan:

5 + " example"
#TypeError: String can't be coerced into Integer

Jadi Opal harus membuat plus sendiri, dan metode yang cukup rumit untuk banyak tipe inti

function $rb_plus(lhs, rhs) {
  return (typeof(lhs) === 'number' && typeof(rhs) === 'number') ? lhs + rhs : lhs['$+'](rhs);
}
String.prototype['$+'] = function (r){var t=this,n=arguments.length;return 1!==n&&e.ac(n,1,this,"+"),r=ke.get("Opal").$coerce_to(r,ke.get("String"),"to_str"),t+r.$to_s()}

Demikian juga untuk banyak operasi dasar.

# Ruby: if a || b
if ((($a = ((($b = a) !== false && $b !== nil && $b != null) ? $b : b)) !== nil && $a != null && (!$a.$$is_boolean || $a == true))) {

Mungkin secara teori JIT dapat mengoptimalkannya sepenuhnya, tetapi jangan berpikir mereka sudah dekat (bukan tolok ukur mikro, tetapi untuk seluruh aplikasi/halaman prototipe yang saya lakukan, versi Ruby secara signifikan lebih lambat) dan konversi seperti itu tampaknya hanya membuat pengoptimal hidup lebih keras?

Dan bahkan kemudian, beberapa hal salah atau tidak didukung (walaupun Webasm memiliki bilangan bulat asli, jadi semoga itu awal yang baik jika dikompilasi ke Webasm daripada JS):

1 / 2 == 0.5 # Should be 0, Ruby has integer division

str = "Hello"
str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.
puts str # "Hello World"

@nirus

Saya dapat menggunakan C# untuk menulis aplikasi web yang berfungsi penuh tanpa saya menulis kode Javascript apa pun.

Ya, dan saya setuju itu sangat keren (saya sedang mengerjakan bahasa yang saya rencanakan untuk dikompilasi ke WebAssembly), tetapi maksud saya adalah Anda sudah dapat melakukannya, bahkan tanpa WebAssembly.

Seseorang dapat langsung mengkompilasi ke wasm dan menulis lapisan topeng API atau jembatan dalam Javascript kapan pun diperlukan, sehingga basis pengembang tidak perlu mengetahui Javascript untuk mengembangkan aplikasi web dengan Webapp maksud saya Webapp murni bukan ASP.net, kerangka kerja agak JSP.

Memang, dan itu sudah mungkin selama bertahun-tahun sekarang. Anda tidak perlu menunggu WebAssembly, Anda bisa mulai sekarang : asm.js telah ada selama beberapa tahun.

@wnewbery

Sementara banyak bahasa sudah dapat dikompilasi ke JavaScript, apakah kompilasi ke Webasm menghindari beban yang signifikan dan hukuman kinerja runtime untuk melakukannya? Dan masalah kinerja jika Anda mengkompilasi bahasa C VM penuh ke Webasm untuk melakukannya seperti itu?

Ini mungkin membantu mengurai waktu, tetapi tidak mungkin membantu kinerja runtime.

Biarkan saya menjernihkan sesuatu: asm.js telah ada selama beberapa tahun. Ini memungkinkan Anda untuk mengkompilasi program ke JavaScript, dan program itu akan berjalan pada kecepatan yang hampir asli. Dengan kata lain, Anda dapat menjalankan program dengan kecepatan yang sama dengan yang dijalankan di desktop.

Jadi sudah dimungkinkan untuk mengambil bahasa, mengkompilasi VM, runtime, dan pengumpul sampah ke asm.js, dan Anda kemudian dapat menjalankan bahasa apa pun yang Anda inginkan di browser, dengan kecepatan yang hampir sama seperti di desktop. Ini sudah mungkin untuk beberapa waktu sekarang.

Namun, mengompilasi VM, runtime, dan pengumpul sampah berarti ukuran file akan cukup besar (banyak megabita).

Dan sulit untuk berkomunikasi dengan JS API (seperti DOM).

Tetapi beberapa orang telah melakukannya, dan menciptakan hal-hal seperti PyPy.js yang mengkompilasi penerjemah PyPy ke dalam asm.js.

Ini berjalan lebih cepat daripada CPython (ya, sungguh! Penerjemah PyPy yang telah dikompilasi ke JavaScript dan berjalan di browser berjalan lebih cepat daripada CPython asli di desktop!)

Tetapi ukuran filenya cukup buruk (5 megabyte gzip, 15 megabyte mentah).

Jadi Anda bisa mengkompilasi VM + pengumpul sampah + runtime Ruby ke asm.js, dan itu akan sangat cepat, tetapi akan memiliki masalah itu. Jadi, sebaliknya orang membuat hal-hal seperti Opal.

WebAssembly adalah evolusi berikutnya dari asm.js. Saat ini, apa pun yang dapat Anda lakukan dengan WebAssembly, Anda juga dapat melakukannya dengan asm.js.

Jadi ya, dimungkinkan untuk mengkompilasi bahasa Anda + VM + runtime + pengumpul sampah ke WebAssembly, dan itu akan berjalan dengan kecepatan hampir asli.

Tapi tentu saja memiliki kelemahan yang sama seperti asm.js: ukuran file yang sangat besar, dan sulit untuk berkomunikasi dengan JS API.

Ada tujuh perbedaan antara WebAssembly dan asm.js:

1. WebAssembly sedikit lebih cepat (5%) daripada asm.js pada umumnya.

2. WebAssembly secara signifikan (~400%) lebih cepat daripada asm.js jika Anda menggunakan bilangan bulat 64-bit.

3. WebAssembly dapat diuraikan lebih cepat. Ini tidak meningkatkan kecepatan runtime program Anda, tetapi ini berarti bahwa waktu buka awal lebih cepat dengan WebAssembly.

4. Ukuran file WebAssembly lebih kecil dari ukuran file asm.js (sekitar 10-20% lebih kecil).

5. WebAssembly mungkin di masa depan mendapatkan fitur luar biasa yang tidak dimiliki asm.js (utas, konkurensi, pengecualian tanpa biaya, dll.).

6. WebAssembly mungkin di masa mendatang mendapatkan akses ke pengumpul sampah JavaScript (yang berarti Anda tidak perlu lagi mengompilasi pengumpul sampah bahasa Anda ke WebAssembly, yang berarti ukuran file lebih kecil).

7. WebAssembly di masa depan akan mendapatkan kemampuan untuk dengan mudah menggunakan JS API (seperti DOM).

Tetapi bahkan di masa depan masih perlu untuk mengkompilasi VM + runtime bahasa Anda ke WebAssembly, jadi ukuran file masih akan menjadi masalah.

Jika mengkompilasi VM + runtime + pengumpul sampah bahasa Anda ke dalam asm.js tidak dapat Anda terima, itu mungkin masih tidak dapat diterima bahkan dengan WebAssembly.

Dan jika kompilasi bahasa Anda VM + runtime + pengumpul sampah dapat diterima untuk Anda, Anda sudah bisa melakukan itu sekarang dengan asm.js (dan kemudian dengan mudah transisi ke WebAssembly kemudian).

Apakah masalah-masalah tersebut dapat diselesaikan? misalnya dengan Ruby baru -> kompiler Webasm, dan dapatkan kinerja yang sebanding dengan JavaScript browser saat ini?

Tujuan WebAssembly adalah menjalankan program dengan kecepatan asli. Dengan kata lain, menjalankannya dengan kecepatan yang sama dengan yang dijalankan di desktop.

Jadi, jika Anda mengompilasi Ruby ke WebAssembly, ia akan berjalan pada kecepatan yang sama dengan kecepatan Ruby di desktop.

Ruby adalah bahasa yang cukup lambat. Bahasa yang lambat dan program yang lambat akan tetap lambat, bahkan ketika dikompilasi dengan WebAssembly.

1 / 2 == 0.5 # Should be 0, Ruby has integer division

Itu adalah bug di Opal yang dapat diperbaiki hanya dengan mengubah definisi fungsi $rb_divide .

str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.

Itu bisa diperbaiki dengan meminta Opal mengkompilasi string ke dalam array JavaScript (yang bisa berubah).

@Pauan

WebAssembly mungkin di masa depan mendapatkan fitur luar biasa yang tidak dimiliki asm.js (utas, konkurensi, pengecualian biaya nol, dll.).

Utas adalah fitur yang sangat penting untuk banyak bahasa, pustaka, kerangka kerja. Tanpa utas, banyak aplikasi yang dibuat oleh c++, c#, java yang mengandalkan multithread tidak bisa begitu saja berubah menjadi webapp karena dapat menyebabkan perilaku aneh (Belum lagi hal baik lainnya seperti SIMD mendukung _di masa depan(?)_). Singkatnya, saya pikir asm.js tidak cukup baik, baik kinerja maupun kemampuan port, jika sebagus itu, harus ada lebih banyak perpustakaan "porting" ke asm.js sejak lama.

seperti yang dikatakan semua orang bahwa javascript tidak akan hilang begitu saja karena sangat populer dan untuk dukungan warisan, sebagian besar browser akan tetap mendukung menjalankan javascript secara asli, tetapi saya pikir di masa depan siapa pun yang membuat situs web baru dengan javascript akan mengompilasinya menjadi wasm untuk semua peningkatan kinerja itu

@unmellow , untuk

ya maaf saya lupa maksud saya itu akan diurai lebih cepat
edit: sesuatu yang mungkin terjadi adalah browser tidak memperbarui mesin javascript mereka untuk mendukung
versi javascript yang lebih baru dapat dikompilasi oleh orang-orang tanpa kehilangan kinerja

Saya tidak benar-benar nyaman dengan menendang tiket berusia satu tahun, tetapi, demi diskusi dan hanya sedikit kata-kata kasar.

Saya dapat melihat banyak orang skeptis dengan gagasan mengganti Javascript dengan WASM, tetapi satu hal adalah bahwa WASM bukan hanya tentang kinerja. Apa yang kebanyakan orang lupakan adalah bahwa Javascript bukanlah bahasa yang mereka inginkan (atau inginkan). Maksud saya, setidaknya, Javascript barebone bukanlah yang diinginkan orang. Semakin banyak orang menggunakan transpiler, yang pada dasarnya adalah kompiler untuk bahasa pihak ke-3. Ini hanya karena orang-orang menyerah mengandalkan standar dan dialihkan ke solusi userland(?).

Tetapi transpilasi, pada dasarnya, jauh lebih sulit daripada kompilasi. Masalah matematika pemetaan satu bahasa ke bahasa lain tidak selalu terbatas pada lingkup lokal. Beberapa informasi kontekstual harus dibawa ke sisi lain, dan melakukannya dengan benar adalah masalah yang sulit. Itu sebabnya transpiler non-Javascript tidak diadopsi secara luas (atau mengapa mereka tidak boleh diandalkan).

Juga, ada masalah dengan upaya duplikat. Transpiler adalah compiler, dan bundler adalah linker. Kita semua telah memiliki alat itu selama berabad-abad. Modul, penggoyangan pohon, pemecahan kode, pemuatan dinamis/malas, manajemen aset, dll. Tidak ada yang benar-benar baru, tetapi orang memerlukan alat baru untuk memiliki fitur ini hanya untuk web, yang tidak ramah untuk solusi non-web.

Ini tidak seperti WASM akan mengubah segalanya dalam satu hari. Javascript memiliki ekosistem yang dibangun dengan baik saat ini, sementara bahasa lain tidak. Saya akan membutuhkan waktu sebelum Javascript benar-benar pergi ke suatu tempat, tetapi itu jelas akan terjadi dalam jangka panjang.

Javascript sedang menuju, apa yang saya anggap sebagai, arah yang buruk jadi saya menyambut pengganti WASM. Saya pikir sementara ada peningkatan yang signifikan, banyak komunitas dan arahan telah disesatkan selama beberapa tahun terakhir. Saya lebih dari menyambut bahasa yang tepat untuk .. tidak harus menggantikannya, tetapi untuk menjadi pesaing langsung jadi saya tidak perlu menulis rasa JS baru yang menjengkelkan ini dan "kerangka" yang telah muncul.

@spencerudnick Tidak pernah menulis perakitan untuk peningkatan kinerja yang tidak bisa Anda dapatkan dari C?