Mengapa JavaScript daripada mesin virtual browser standar?

Apakah tidak masuk akal untuk mendukung serangkaian bahasa (Java, Python, Ruby, dll.) Dengan menggunakan mesin virtual standar yang dihosting di browser daripada memerlukan penggunaan bahasa khusus - sungguh, paradigma khusus - hanya untuk skrip klien?

Untuk memperjelas saran, halaman web akan berisi kode byte alih-alih bahasa tingkat tinggi seperti JavaScript.

Saya memahami kenyataan pragmatis bahwa JavaScript hanyalah apa yang harus kita kerjakan sekarang karena alasan evolusi, tapi saya lebih memikirkan jangka panjang. Berkenaan dengan kompatibilitas ke belakang, tidak ada alasan bahwa inline JavaScript tidak dapat didukung secara bersamaan untuk jangka waktu tertentu dan tentu saja JavaScript dapat menjadi salah satu bahasa yang didukung oleh mesin virtual browser.

Baiklah. Tentu saja jika kita memiliki mesin waktu, kembali dan memastikan banyak fitur Javascript dirancang berbeda akan menjadi hobi utama (itu, dan memastikan orang-orang yang merancang mesin CSS IE tidak pernah masuk ke IT). Tapi itu tidak akan terjadi, dan kita terjebak dengannya sekarang.

Saya menduga, pada waktunya, itu akan menjadi "Bahasa mesin" untuk web, dengan bahasa dan API yang dirancang lebih baik lainnya dikompilasi (dan melayani berbagai kelemahan mesin runtime).

Saya tidak berpikir, bagaimanapun, salah satu dari "bahasa yang dirancang lebih baik" ini adalah Java, Python atau Ruby. Javascript adalah, terlepas dari kemampuan untuk digunakan di tempat lain, bahasa scripting aplikasi Web. Dengan menggunakan use case tersebut, kami dapat melakukan lebih baik daripada bahasa-bahasa tersebut.

Saya pikir JavaScript adalah bahasa yang baik, tetapi saya ingin memiliki pilihan ketika mengembangkan aplikasi web sisi klien. Untuk alasan warisan, kami terjebak dengan JavaScript, tetapi ada proyek dan ide yang berusaha mengubah skenario itu:

1. Google Native Client : teknologi untuk menjalankan kode asli di browser.
2. Emscripten : LLVM bytecode compiler ke javascript. Mengizinkan bahasa LLVM dijalankan di browser.
3. Ide: .NET CLI di browser, oleh pencipta Mono: http://tirania.org/blog/archive/2010/May-03.html

Saya pikir kita akan memiliki JavaScript untuk waktu yang lama, tetapi itu akan berubah cepat atau lambat. Ada begitu banyak pengembang yang mau menggunakan bahasa lain di browser.

Menjawab pertanyaan - Tidak, itu tidak masuk akal.

Saat ini hal-hal terdekat yang kami miliki untuk VM multi-bahasa adalah JVM dan CLR. Ini bukan binatang yang benar-benar ringan, dan tidak masuk akal untuk mencoba dan menyematkan sesuatu dengan ukuran dan kompleksitas ini di peramban.

Mari kita periksa gagasan bahwa Anda dapat menulis VM baru, multilanguage yang akan lebih baik daripada solusi yang ada.

• Anda berada di belakang dalam stabilitas.
• Anda berada di belakang dalam kompleksitas (jalan, jalan, di belakang karena Anda mencoba untuk menggeneralisasi beberapa bahasa)
• Anda ketinggalan adopsi

Jadi, tidak, itu tidak masuk akal.

Ingat, untuk mendukung bahasa ini Anda harus menghapus API mereka sesuatu dengan ganas, memotong bagian mana pun yang tidak masuk akal dalam konteks skrip browser. Ada sejumlah besar keputusan desain yang harus dibuat di sini, dan peluang besar untuk kesalahan.

Dalam hal fungsionalitas, kita mungkin hanya benar - benar bekerja dengan DOM, jadi ini benar-benar masalah sintaks dan bahasa idom, pada titik itu masuk akal untuk bertanya, "Apakah ini benar-benar layak?"

Mengingat, satu - satunya hal yang kita bicarakan adalah skrip sisi klien, karena skrip sisi server sudah tersedia dalam bahasa apa pun yang Anda suka. Ini adalah arena pemrograman yang relatif kecil sehingga manfaat membawa banyak bahasa dipertanyakan.

Bahasa apa yang masuk akal untuk dibawa masuk? (Peringatan, materi subjektif berikut)

Membawa dalam bahasa seperti C tidak masuk akal karena itu dibuat untuk bekerja dengan logam, dan di browser tidak ada banyak logam yang benar-benar tersedia.

Membawa dalam bahasa seperti Java tidak masuk akal karena hal terbaik tentang itu adalah API.

Membawa bahasa seperti Ruby atau Lisp tidak masuk akal karena JavaScript adalah bahasa dinamis yang kuat yang sangat dekat dengan Skema.

Akhirnya, pembuat browser apa yang benar-benar ingin mendukung integrasi DOM untuk berbagai bahasa? Setiap implementasi akan memiliki bug spesifiknya sendiri. Kami sudah berjalan melewati api berurusan dengan perbedaan antara MS Javascript dan Mozilla Javascript dan sekarang kami ingin melipatgandakan rasa sakit itu lima atau enam kali lipat?

Itu tidak masuk akal.

Di Windows, Anda bisa mendaftarkan bahasa lain dengan Host Scripting dan membuatnya tersedia untuk IE. Misalnya VBScript didukung di luar kotak (meskipun tidak pernah mendapatkan banyak popularitas karena untuk sebagian besar tujuan bahkan lebih buruk daripada JavaScript).

Ekstensi Python win32 memungkinkan seseorang untuk menambahkan Python ke IE seperti ini dengan cukup mudah, tetapi itu bukan ide yang baik karena Python cukup sulit untuk di-sandbox: banyak fitur bahasa mengekspos kait implementasi yang cukup untuk memungkinkan aplikasi yang seharusnya dibatasi untuk keluar .

Ini adalah masalah secara umum bahwa semakin banyak kompleksitas yang Anda tambahkan ke aplikasi yang menghadap ke internet seperti browser, semakin besar kemungkinan masalah keamanan. Banyak bahasa baru pasti cocok dengan deskripsi itu, dan ini adalah bahasa baru yang juga masih berkembang pesat.

JavaScript adalah bahasa yang jelek, tetapi melalui penggunaan yang cermat dari subset fitur yang selektif, dan dukungan dari pustaka objek yang sesuai, secara umum dapat dibuat cukup lumayan. Tampaknya tambahan, penambahan praktis ke JavaScript adalah satu-satunya cara skrip web untuk melanjutkan.

Saya pasti akan menyambut VM standar bahasa independen di browser (saya lebih suka kode dalam bahasa yang diketik secara statis).

(Secara teknis) Ini cukup bisa dilakukan secara bertahap: pertama browser utama mendukungnya dan server memiliki kemungkinan untuk mengirim bytecode jika permintaan saat ini dari browser yang kompatibel atau menerjemahkan kode ke JavaScript dan mengirim JavaScript teks biasa.

Sudah ada beberapa bahasa eksperimental yang mengkompilasi ke JavaScript, tetapi memiliki VM yang ditentukan akan (mungkin) memungkinkan untuk kinerja yang lebih baik.

Saya akui bahwa bagian "standar" akan sangat sulit. Juga akan ada konflik antara fitur bahasa (mis. Pengetikan statis vs dinamis) tentang perpustakaan (dengan asumsi hal baru akan menggunakan perpustakaan yang sama). Karena itu saya tidak berpikir itu akan terjadi (segera).

Jika Anda merasa tangan Anda kotor, maka Anda telah dicuci otak, atau masih merasakan dampak setelah "tahun DHTML". JavaScript sangat kuat, dan sangat cocok untuk tujuannya, yaitu untuk skrip interaktivitas sisi klien. Inilah sebabnya mengapa JavaScript 2.0 mendapat rap yang buruk. Maksud saya, mengapa paket, antarmuka, kelas, dan sejenisnya, ketika itu jelas merupakan aspek dari bahasa sisi server. JavaScript baik-baik saja sebagai bahasa berbasis prototipe, tanpa berorientasi objek penuh.

Jika ada kekurangan mulus untuk aplikasi Anda karena sisi server dan sisi klien tidak berkomunikasi dengan baik, maka Anda mungkin ingin mempertimbangkan kembali bagaimana Anda merancang aplikasi Anda. Saya telah bekerja dengan situs Web yang sangat kuat dan aplikasi Web, dan saya tidak pernah berkata, "Hmm, saya benar-benar berharap JavaScript dapat melakukannya (xyz)." Jika itu bisa dilakukan, maka itu bukan JavaScript - itu akan menjadi ActionScript atau AIR atau Silverlight. Saya tidak membutuhkan itu, dan begitu pula kebanyakan pengembang. Itu adalah teknologi yang bagus, tetapi mereka mencoba memecahkan masalah dengan teknologi, bukan ... yah, solusi.

Saya tidak berpikir bahwa web VM standar adalah yang tak terbayangkan. Ada beberapa cara Anda dapat memperkenalkan standar VM web baru dengan anggun dan dengan dukungan legacy penuh, selama Anda memastikan bahwa setiap format VM bytecode yang Anda gunakan dapat dengan cepat didekompilasi menjadi javascript, dan bahwa output yang dihasilkan akan cukup efisien ( Saya bahkan akan melangkah lebih jauh dengan menebak bahwa decompiler yang pintar mungkin akan menghasilkan javascript yang lebih baik daripada javascript apa pun yang bisa dihasilkan oleh manusia).

Dengan properti ini, semua format VM web dapat dengan mudah didekompilasi baik pada server (cepat), pada klien (lambat, tetapi mungkin dalam kasus di mana Anda memiliki kontrol terbatas pada server), atau dapat dibuat sebelumnya dan dimuat secara dinamis oleh baik klien atau server (tercepat) untuk browser yang tidak mendukung standar baru.

Browser yang secara native mendukung standar baru akan mendapat manfaat dari peningkatan kecepatan runtime untuk aplikasi berbasis web vm. Selain itu, jika browser mendasarkan mesin javascript lawas mereka pada standar web vm (yaitu mem-parsing javascript ke dalam standar web vm dan kemudian menjalankannya), maka mereka tidak perlu mengelola dua runtime, tetapi itu tergantung pada vendor browser .

Walaupun Javascript adalah satu-satunya bahasa skrip yang didukung dengan baik, Anda dapat langsung mengontrol halaman, Flash memiliki beberapa fitur yang sangat bagus untuk program yang lebih besar. Akhir-akhir ini memiliki JIT dan juga dapat menghasilkan bytecode on the fly (lihat evaluasi ekspresi runtime untuk contoh di mana mereka menggunakan flash untuk mengkompilasi ekspresi matematika input-pengguna semua jalan ke biner asli). Bahasa Haxe memberi Anda mengetik statis dengan inferensi dan dengan kemampuan menghasilkan bytecode Anda bisa menerapkan hampir semua sistem runtime pilihan Anda.

Pembaruan cepat untuk pertanyaan lama ini.

Setiap orang yang menegaskan bahwa "halaman web akan berisi kode byte alih-alih bahasa tingkat tinggi seperti JavaScript" "tidak akan terjadi".

Juni 2015 yang W3C mengumumkan WebAssembly yang

format portabel, ukuran-dan-waktu-efisien baru yang cocok untuk kompilasi ke web.

Ini masih eksperimental, tetapi sudah ada beberapa implementasi prototipe di Firefox nightly dan Chrome Canary dan sudah ada beberapa demonstrasi yang berfungsi .

Saat ini, WebAssembly sebagian besar dirancang untuk diproduksi dari C / C ++

karena WebAssembly berevolusi, ia akan mendukung lebih banyak bahasa daripada C / C ++, dan kami berharap bahwa kompiler lain akan mendukungnya juga .

Saya membiarkan Anda melihat lebih dekat pada halaman resmi proyek, ini benar-benar menarik!

pertanyaan ini muncul kembali secara teratur. sikap saya tentang ini adalah:

A) tidak akan terjadi dan B) sudah ada di sini.

maaf, apa? coba saya jelaskan:

iklan A

VM bukan hanya semacam perangkat magis universal. kebanyakan VM dioptimalkan untuk bahasa tertentu dan fitur bahasa tertentu. ambil JRE / Java (atau LLVM): dioptimalkan untuk pengetikan statis, dan pasti ada masalah dan kelemahan ketika menerapkan pengetikan dinamis atau hal lain yang tidak didukung java sejak awal.

jadi, "VM multiguna umum" yang mendukung banyak fitur bahasa (pengoptimalan panggilan ekor, pengetikan statis & dinamis, foo bar boo, ...) akan kolosal, sulit diimplementasikan, dan mungkin lebih sulit dioptimalkan untuk mendapatkan kinerja yang baik dari Itu. tapi saya bukan perancang bahasa atau vm guru, mungkin saya salah: sebenarnya cukup mudah, hanya belum ada yang tahu? hrm, hrm.

iklan B

sudah ada di sini: mungkin tidak ada bytecode compiler / vm, tetapi Anda tidak benar-benar membutuhkannya. afaik javascript sudah selesai, jadi seharusnya bisa:

1. buat penerjemah dari bahasa X ke javascript (mis. naskah kopi)
2. buat juru bahasa dalam javascript yang mengartikan bahasa X (misalnya brainfuck ). ya, kinerja akan sangat buruk, tapi hei, tidak bisa memiliki segalanya.

iklan C

apa? tidak ada titik C di tempat pertama !? karena belum ada ... belum. google NACL. kalau ada yang bisa melakukannya, itu google. segera setelah google membuatnya berfungsi, masalah Anda terpecahkan. hanya, uh, itu mungkin tidak pernah berhasil, saya tidak tahu. terakhir kali saya membaca tentang itu ada beberapa masalah keamanan yang tidak terpecahkan dari jenis yang benar - benar rumit.

Selain itu:

• javascript sudah ada sejak ~ 1995 = 15 tahun. tetap saja, implementasi browser berbeda hari ini (walaupun setidaknya itu tidak bisa ditolerir lagi). jadi, jika Anda memulai sesuatu yang baru, Anda mungkin memiliki versi browser lintas yang berfungsi sekitar tahun 2035. setidaknya subset yang berfungsi. yang hanya berbeda secara halus. dan membutuhkan lib dan layer kompatibilitas. tidak ada gunanya untuk tidak memperbaiki keadaan.

• juga, bagaimana dengan kode sumber yang dapat dibaca? saya tahu banyak perusahaan lebih memilih untuk tidak menyajikan kode mereka sebagai "open source". secara pribadi, saya cukup senang saya bisa membaca sumbernya jika saya mencurigai ada sesuatu yang mencurigakan atau ingin belajar darinya. hore untuk kode sumber!

Memang. Silverlight secara efektif hanya itu - sisi klien .Net berbasis VM.

Ada beberapa kesalahan dalam alasan Anda.

1. Mesin virtual standar di browser standar tidak akan pernah menjadi standar. Kami memiliki 4 browser, dan IE memiliki minat yang bertentangan terkait dengan 'standar'. Tiga lainnya berkembang cepat tetapi tingkat adopsi teknologi baru lambat. Bagaimana dengan browser di ponsel, perangkat kecil, ...

2. Integrasi JS di browser yang berbeda dan riwayat masa lalunya membuat Anda meremehkan kekuatan JS. Anda menjanjikan standar, tetapi menolak JS karena standar tidak berhasil di tahun-tahun awal.

3. Seperti yang diceritakan oleh orang lain, JS tidak sama dengan AIR / .NET / ... dan sejenisnya. JS dalam inkarnasinya saat ini sangat sesuai dengan tujuannya.

Dalam jangka panjang, Perl dan Ruby bisa menggantikan javascript. Namun adopsi bahasa-bahasa itu lambat dan diketahui bahwa mereka tidak akan pernah mengambil alih JS.

Bagaimana Anda mendefinisikan yang terbaik? Terbaik untuk peramban, atau terbaik untuk pengembang? (Plus ECMAScript berbeda dari Javascript, tapi itu teknis.)

Saya menemukan bahwa JavaScript dapat menjadi kuat dan elegan pada saat bersamaan. Sayangnya sebagian besar pengembang yang saya temui memperlakukannya seperti kejahatan yang diperlukan alih-alih bahasa pemrograman yang sebenarnya.

Beberapa fitur yang saya nikmati adalah:

• memperlakukan fungsi sebagai warga negara kelas satu
• bisa menambah dan menghapus fungsi ke objek apa saja kapan saja (tidak banyak berguna tetapi pikiran bertiup ketika itu)
• itu adalah bahasa yang dinamis.

Sangat menyenangkan untuk berurusan dan didirikan. Nikmati saat ini ada karena sementara itu mungkin bukan yang "terbaik" untuk scripting klien itu tentu menyenangkan.

Saya setuju itu membuat frustasi ketika membuat halaman dinamis karena ketidakcocokan browser, tetapi itu dapat dikurangi dengan perpustakaan UI. Itu seharusnya tidak ditahan melawan JavaScript sendiri daripada Swing harus dilakukan terhadap Java.

JavaScript adalah mesin virtual standar peramban. Sebagai contoh, OCaml dan Haskell sekarang memiliki kompiler yang dapat menghasilkan JavaScript. Batasannya bukan JavaScript bahasa, batasannya adalah objek browser yang dapat diakses melalui JavaScript, dan model kontrol akses yang digunakan untuk memastikan Anda dapat menjalankan JavaScript dengan aman tanpa membahayakan mesin Anda. Kontrol akses saat ini sangat buruk, sehingga JavaScript hanya diperbolehkan akses sangat terbatas ke objek browser untuk alasan keamanan. Proyek Harmony sedang mencari cara untuk memperbaikinya.

Itu ide yang keren. Mengapa tidak melangkah lebih jauh?

• Tulis parser HTML dan mesin tata letak (semua bit rumit di browser, sebenarnya) dalam bahasa VM yang sama
• Publikasikan mesin ke web
• Sajikan halaman dengan deklarasi mesin tata letak mana yang digunakan, dan URL-nya

Kemudian kita dapat menambahkan fitur ke browser tanpa harus mendorong browser baru ke setiap klien - bit baru yang relevan akan dimuat secara dinamis dari web. Kami juga dapat mempublikasikan versi HTML baru tanpa semua kerumitan konyol menjaga kompatibilitas ke belakang dengan semua yang pernah bekerja di browser - kompatibilitas adalah tanggung jawab penulis halaman. Kami juga bisa bereksperimen dengan bahasa markup selain HTML. Dan, tentu saja, kita dapat menulis kompiler JIT yang bagus ke dalam mesin, sehingga Anda dapat membuat skrip laman web Anda dalam bahasa apa pun yang Anda inginkan.

Saya akan menyambut bahasa apa pun selain javascript sebagai bahasa scripting mungkin.

Apa yang akan keren adalah menggunakan bahasa lain kemudian Javascript. Java mungkin tidak cocok di antara tag tetapi bahasa seperti Haskell, Clojure, Scala, Ruby, Groovy akan bermanfaat.

Saya datang lintas Rubyscript beberapa waktu lalu ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby dan http://code.google.com/p/ruby- in-browser /
Masih eksperimental dan sedang berlangsung, tetapi terlihat menjanjikan.
Untuk .Net, saya baru saja menemukan: http://www.silverlight.net/learn/dynamic-languages/ Baru saja menemukan situsnya, tetapi terlihat menarik juga. Bekerja bahkan dari Apple Mac saya .

Tidak tahu seberapa bagus kerja di atas dalam memberikan alternatif untuk Javascript, tetapi terlihat cukup keren pada pandangan pertama. Secara potensial, ini akan memungkinkan seseorang untuk menggunakan Java atau .Net framework apa pun dari browser - di dalam kotak pasir browser.

Adapun keamanan, jika bahasa berjalan di dalam JVM (atau mesin .Net dalam hal ini), VM akan menjaga keamanan sehingga kita tidak perlu khawatir tentang itu - setidaknya tidak lebih maka kita harus untuk apa pun yang berjalan di dalam browser.

Mungkin, tetapi untuk melakukannya kita perlu mendapatkan browser utama untuk mendukung mereka. Dukungan IE akan menjadi yang paling sulit didapat. JavaScript digunakan karena itu adalah satu-satunya hal yang dapat Anda andalkan tersedia.

Sebagian besar devs yang saya ajak bicara tentang ECMAScript et. Al. akhirnya mengakui bahwa masalahnya bukan bahasa scripting, itu adalah DOM HTML konyol yang ia tampilkan. Penggabungan DOM dan bahasa scripting adalah sumber umum dari rasa sakit dan frustrasi mengenai ECMAScript. Juga, jangan lupa, IIS dapat menggunakan JScript untuk skrip sisi server, dan hal-hal seperti Rhino memungkinkan Anda untuk membangun aplikasi yang berdiri sendiri di ECMAScript. Cobalah bekerja di salah satu lingkungan ini dengan ECMAScript untuk sementara waktu, dan lihat apakah pendapat Anda berubah.

Keputusasaan semacam ini telah terjadi selama beberapa waktu. Saya sarankan Anda mengedit ini untuk memasukkan, atau memposting ulang dengan, masalah spesifik. Anda mungkin akan terkejut dengan beberapa bantuan yang Anda dapatkan.

Situs lama, tetapi masih tempat yang bagus untuk memulai: Situs Douglas Crockford .

Yah, kita sudah punya VBScript, bukan? Tunggu, hanya IE yang mendukungnya!
Sama untuk ide bagus Anda tentang VM. Bagaimana jika saya skrip halaman saya menggunakan Lua, dan browser Anda tidak memiliki parser untuk mengubahnya menjadi bytecode? Tentu saja, kita dapat membayangkan tag skrip menerima file bytecode, yang bahkan akan sangat efisien.
Tetapi pengalaman menunjukkan sulit untuk membawa sesuatu yang baru ke Web: akan butuh bertahun-tahun untuk mengadopsi perubahan baru yang radikal seperti ini. Berapa banyak browser yang mendukung SVG atau CSS3?

Selain itu, saya tidak melihat apa yang Anda temukan "kotor" di JS. Ini bisa jelek jika dikodekan oleh amatir, menyebarkan praktik buruk yang disalin di tempat lain, tetapi master menunjukkan itu bisa menjadi bahasa yang elegan juga. Sedikit seperti Perl: sering terlihat seperti bahasa yang dikaburkan, tetapi dapat dibuat dapat dibaca dengan sempurna.

Lihat ini http://www.visitmix.com/Labs/Gestalt/ - memungkinkan Anda menggunakan python atau ruby, selama pengguna telah menginstal silverlight.

Ini pertanyaan yang sangat bagus.

Ini bukan masalah hanya di JS, karena kurangnya IDE gratis yang bagus untuk mengembangkan program yang lebih besar di JS. Saya hanya tahu satu yang gratis: Eclipse. Yang bagus lainnya adalah Microsoft's Visual Studio, tetapi tidak gratis.

Mengapa itu gratis? Jika vendor peramban web ingin mengganti aplikasi desktop dengan aplikasi online (dan mereka menginginkannya) maka mereka harus memberi kami, programmer, alat dev yang baik. Anda tidak dapat membuat 50.000 baris JavaScript menggunakan editor teks sederhana, JSLint, dan debugger Google Chrome bawaan. Kecuali Anda seorang makohist.

Ketika Borland membuat IDE untuk Turbo Pascal 4.0 pada 1987, itu adalah revolusi dalam pemrograman. 24 tahun telah berlalu. Yang memalukan, di tahun 2011 banyak programmer masih tidak menggunakan pelengkapan kode, pemeriksaan sintaksis dan debuggers yang tepat. Mungkin karena ada beberapa IDE yang bagus.

Adalah kepentingan vendor browser web untuk membuat alat (GRATIS) yang tepat untuk programmer jika mereka ingin kita membangun aplikasi yang dapat digunakan untuk melawan Windows, Linux, MacOS, iOS, Symbian, dll.

Secara realistis, Javascript adalah satu-satunya bahasa yang akan digunakan browser mana pun untuk waktu yang lama, jadi walaupun akan sangat menyenangkan untuk menggunakan bahasa lain, saya tidak bisa melihatnya terjadi.

"VM standar" yang Anda bicarakan ini akan sangat besar dan perlu diadopsi oleh semua browser utama, dan sebagian besar situs akan terus menggunakan Javascript karena itu lebih cocok untuk situs web daripada banyak browser lainnya.

Anda harus mem-sandbox setiap bahasa pemrograman dalam VM ini dan mengurangi jumlah akses setiap bahasa ke sistem, yang membutuhkan banyak perubahan dalam bahasa dan menghapus atau mengimplementasikan kembali banyak fitur. Padahal Javascript sudah memikirkan hal ini, dan sudah lama melakukannya.

Mungkin Anda mencari Klien Asli Google.

Dalam arti, memiliki bahasa yang lebih ekspresif seperti Javascript di browser daripada sesuatu yang lebih umum seperti bytecode Java berarti web yang lebih terbuka.

Saya pikir ini bukan masalah yang mudah . Kita dapat mengatakan bahwa kita terjebak dengan JS, tetapi apakah itu benar-benar buruk dengan jQuery, Prototype, scriptaculous, MooTools, dan semua perpustakaan yang fantastis?

Ingat, JS ringan , apalagi dengan V8, TraceMonkey, SquirrelFish - mesin Javascript baru yang digunakan di browser modern.

Itu juga terbukti - ya, kami tahu ada masalah, tapi kami punya banyak masalah, seperti masalah keamanan awal. Gambar memungkinkan browser Anda untuk menjalankan kode Ruby, atau apa pun. Kotak pasir keamanan harus dilakukan untuk awal. Dan tahukah Anda? Orang-orang Python sudah gagal dua kali.

Saya pikir Javascript akan direvisi dan ditingkatkan seiring waktu, seperti halnya HTML dan CSS. Prosesnya mungkin panjang, tetapi tidak semuanya mungkin di dunia ini.

Saya tidak berpikir Anda "memahami masalah pragmatis bahwa JavaScript hanyalah apa yang harus kita kerjakan sekarang". Sebenarnya itu adalah bahasa yang sangat kuat. Anda memiliki applet Java di browser selama bertahun-tahun, dan di mana sekarang?

Bagaimanapun, Anda tidak perlu "menjadi kotor" untuk bekerja pada klien. Misalnya, coba GWT.

... maksudmu...

Java dan Java applet Flash dan Adobe AIR dll.

Secara umum, kerangka kerja RIA apa pun dapat memenuhi kebutuhan Anda; tetapi untuk setiap orang ada harga yang harus dibayar untuk menggunakannya (mis. runtime tersedia di browser atau / dan propietary atau / dan lebih sedikit pilihan daripada desktop murni) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

Untuk mengembangkan Web dengan bahasa non-web, Anda telah GWT: mengembangkan Java, kompilasi ke Javascript

Karena mereka semua sudah memiliki VM dengan interpreter bytecode, dan bytecode juga berbeda. {Chakra (IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera (Carakan).

Maaf, saya pikir Chrome (V8) mengkompilasi ke kode mesin IA32.

baik, mengingat semua browser sudah menggunakan VM, saya tidak berpikir akan sulit untuk membuat bahasa VM untuk web.
Saya pikir ini akan sangat membantu karena beberapa alasan:
1. karena server mengkompilasi kode, jumlah data yang dikirim lebih kecil dan klien tidak memiliki waktu untuk menyusun kode.
2. karena server dapat mengkompilasi kode dalam persiapan dan menyimpannya, tidak seperti klien yang mencoba untuk menilai sedikit waktu dengan cepat menyusun JS, ia dapat membuat optimasi kode yang lebih baik.
3. mengkompilasi suatu bahasa ke kode byte adalah cara yang lebih mudah daripada mentransformasikannya ke JS.

sebagai catatan akhir (seperti yang telah dikatakan seseorang dalam komentar lain), HTML dan CSS dikompilasi ke bahasa yang lebih sederhana, tidak yakin apakah itu dianggap sebagai kode byte, tetapi Anda juga dapat mengirim html dan css yang dikompilasi dari server ke klien yang akan kurangi waktu parse dan fetch

IMO, JavaScript, bahasa, bukan masalah. JavaScript sebenarnya adalah bahasa yang cukup ekspresif dan kuat. Saya pikir itu mendapat rep yang buruk karena tidak punya fitur OO klasik, tetapi bagi saya semakin saya pergi dengan alur prototypal, semakin saya menyukainya.

Masalahnya seperti yang saya lihat adalah implementasi yang rapuh dan tidak konsisten di banyak browser yang kami terpaksa dukung di web. Pustaka JavaScript seperti jQuery sangat membantu mengurangi perasaan kotor itu.