Mengapa tidak ada bahasa skrip sisi klien lainnya untuk situs web? [Tutup]

35

Mengapa hanya ada dukungan untuk JavaScript dan beberapa VBScript di browser hari ini? Saya tahu JavaScript itu baik dan semuanya, tetapi tidak memiliki opsi untuk menggunakan bahasa pemrograman lain membantu mempromosikan gaya pengembangan yang berbeda?

web-development javascript browser

— Eric Packwood
sumber

1

Lihat pertanyaan ini di Stack Overflow: stackoverflow.com/questions/2872037/…

— Corey

1

Pertanyaan Anda justru mengapa Google membuat GWT .

— jhocking

1

Saya percaya inti dari DOM API adalah memberikan dukungan untuk berbagai bahasa. Masalahnya, JS sebenarnya sangat cocok untuk tantangan. Ini menormalkan seperti bisnis dan fungsi kelas satu tidak ada yang besar dalam paradigma yang sangat didorong oleh peristiwa. Apa yang sebenarnya terjadi adalah bahwa tidak ada yang ingin membiarkan MS membuat keputusan itu dan tidak ada yang datang dengan yang lebih baik dari JS. Juga, Applet Java benar-benar lumpuh.

— Erik Reppen

33

Tidak perlu menambahkan dukungan untuk beberapa bahasa, solusinya adalah dengan melakukan standarisasi pada bytecode generik yang dapat digunakan oleh pelaksana bahasa. Tetapi saat ini tidak ada rencana untuk ini (sudah disarankan).

Bahasa juga dapat diimplementasikan di atas Javascript. Javascript cukup baik untuk memungkinkan bahasa lain diimplementasikan di atasnya. Dan sudah banyak contohnya.

— nkassis
sumber

3

+1 - Untuk menunjukkan bahwa JavaScript adalah bahasa yang kuat yang dapat digunakan sebagai abstraksi untuk bahasa lain. Ini akan menjadi proyek yang menarik untuk menulis ekstensi Firefox yang akan menjalankan sisi klien C ++ atau Java! <script type="text/cpp" src="test.cpp"></script>.

— jmort253

2

@ jmort253, lihat klien asli.

— dan_waterworth

Klien asli sangat menarik tetapi kecuali Mozilla mengadopsinya juga, tidak akan ada daya tarik. Terakhir saya periksa mereka belum siap untuk menggunakannya.

— nkassis

1

Saya menemukan Gestalt ~ beberapa tahun yang lalu: gestalt.codeplex.com itu adalah contoh yang baik untuk membangun bahasa skrip lain di atas Javascript.

— Jim Schubert

2

Contoh lain: Google Web Toolkit ? Java dikompilasi ke JavaScript

— MarkJ

21

JavaScript adalah standar de-facto dan telah ada sejak tahun 1996. Menjadi standar hanya karena tidak ada persaingan yang tidak adil, tetapi saya belum pernah mendengar banyak keluhan tentang mengapa tidak ada bahasa lain yang disertakan.

Menambahkan bahasa "standar" yang lain mempromosikan segala macam masalah kecil yang menyenangkan.

Bagaimana mereka akan bekerja dengan bahasa lain?
Apakah DOM akan dibagikan?
Apakah skrip yang ditulis dalam keduanya masih berfungsi?
Porting pustaka untuk keduanya

— Josh K.
sumber

8

Sebenarnya saya pikir JavaScript adalah bahasa yang digunakan di Mozilla's Gecko. Di IE kami memiliki JScript. Sebagian besar browser lain menggunakan sesuatu yang kurang lebih mengikuti spesifikasi ECMAScript. Semua bahasa ini adalah untuk kesederhanaan yang disebut 'JavaScript', padahal sebenarnya mereka berbeda.

— Mchl

1

Anda dapat memiliki beberapa bahasa yang menghasilkan bytecode yang sama. Lihatlah JVM - Groovy, Java, Scala, Clojure, jRuby dapat langsung dikompilasi ke bytecode JVM. Dengan cara ini, mereka akan berbagi api DOM yang sama, dan dapat dibuat interoperable. Meskipun secara eksponensial lebih sulit untuk diterapkan dengan JavaScript VM karena ditafsirkan.

— David Sergey

21

Pikirkan ketidakkonsistenan antar browser untuk dukungan mereka terhadap javascript saja. Sekarang pikirkan bagaimana jadinya jika ada lebih banyak bahasa.

— Michael Brown
sumber

5

Yay, sudah ada di sana, sisi klien VBScript ... ya, bergidik.

— ocodo

1

+1 Saya pikir kepala kami akan meledak jika kami memiliki himpunan bagian dari bahasa lain untuk menghafal setiap browser utama dan versinya. Jawaban yang bagus.

— jmort253

4

Ini mungkin nitpicking, tetapi ... dukungan browser terhadap JavaScript [ECMAScript] sebenarnya sangat konsisten sejak awal. Apa yang tidak konsisten adalah implementasi DOM mereka (dan metode terkait). Dari sudut pandang praktis (dan historis), sulit untuk memisahkan keduanya - karena satu-satunya penggunaan nyata JS adalah untuk memanipulasi DOM dalam peramban - tetapi dengan munculnya JS sisi-server (hal-hal seperti NodeJS), ini sebenarnya menjadi perbedaan yang agak penting.

— josh3736

akan menulis ini sebagai jawaban, internet memiliki cukup standar yang tidak diikuti atau didukung. fakta bahwa kekacauan bercampur aduk yang kita miliki berfungsi dengan baik setengahnya seperti halnya keajaiban.

— Ryathal

1

Josh benar. Di sinilah Anda memasukkan ide borked-browser individu tentang bagaimana hal-hal yang seharusnya membuat dan diakses oleh JS bahwa hal-hal menjadi jelek tapi IE akhirnya setidaknya memperhatikan masalah lama API eksklusif di bagian depan itu (meskipun terus tertinggal terbaru dalam segala hal karena keputusan penting MS untuk menghubungkan browser mereka ke navigator file mereka - jackasses).

— Erik Reppen

6

Peramban harus distandarisasi, sehingga apa yang Anda kembangkan berfungsi di mana saja, di semua peramban.

Jika Anda memiliki banyak bahasa, maka Anda harus memastikan bahwa mereka semua memiliki kinerja yang sangat mirip. Jika Anda seorang pengembang web dan Anda memiliki pilihan bahasa, yang mungkin didukung atau tidak didukung di beberapa lokasi, maka itu adalah sakit kepala tambahan.

Javascript adalah bahasa yang sangat fleksibel, sangat penting, fungsional, bisa OOP (setelah mode dengan prototipe), dan ditafsirkan. Sekarang dengan mesin yang layak seperti di Chrome, itu cukup mampu melakukan beberapa hal baik. Bahasa tambahan hanya akan mengatur hal-hal di sini, lihat VBScript, hanya IE, dan segala sesuatu yang tertulis di dalamnya terikat ke browser dan platform tertentu, mimpi buruk.

— Orbling
sumber

2

Poin penting di sini adalah "dengan mesin yang layak seperti di Chrome". Melakukan sesuatu yang bahkan sedikit melelahkan menyebabkan bahkan IE8 untuk mulai pincang seperti kaki yang patah, sementara Firefox versi terbaru, dan Chrome sejak selamanya yang telah saya gunakan (ini adalah alasan saya beralih infact) melompat bersama tanpa kehilangan sedikitpun.

— Matthew Scharley

1

@Matthew Scharley: IE pada umumnya lamban, memang tampaknya semakin buruk dengan setiap versi. Mereka perlu meningkatkan permainan mereka, atau mereka akan keluar dari itu. Satu-satunya alasan IE bertahan adalah karena inklusi OS, sekarang mereka harus memasang pemilih pada penggunaan pertama, yang telah turun banyak.

— Orbling

"Itu bisa menjadi OOP" ... Itu adalah OOP! Warisan bukanlah yang mendefinisikan OOP. Objek adalah.

— KaptajnKold

@KaptajnKold: Itu adalah masalah beberapa perdebatan di kalangan akademis, secara mengejutkan. Saya setuju bahwa JS mampu OOP, karena memiliki objek, mereka tidak selalu terlalu digunakan oleh beberapa orang. Sistem prototipe sangat berbeda dengan rasa OOP biasa, yang selanjutnya menghilangkannya dari definisi standar "bahasa OOP". Seperti kebanyakan bahasa, itu tergantung bagaimana Anda menggunakannya - ketika saya menggunakannya, itu OOP.

— Orbling

3

Alih-alih membangun ini menjadi browser, vendor lebih suka membangun plug-in browser yang kikuk - Java, Flash, Silverlight, dll. Ini menjamin konsistensi lintas platform.

— Kirk Broadhurst
sumber

Yah ini bukan tentang menjamin konsistensi lintas-platform, tetapi juga menjamin kontrol. Seperti Anda mengontrol plugin dan Anda tidak perlu menjawab kepada orang lain.

— jhocking

Dibandingkan dengan berjuang dengan menjalankan javascript kotor dengan cepat, plug-in "kikuk" jauh lebih baik. Dulu saya merasa negatif tentang keseluruhan unduhan browser-plugin, tapi itu jelas lebih terbuka daripada "javascript yang diimplementasikan secara universal".

— Milind R

2

Salah satu alasannya adalah bahwa hampir tidak mungkin bagi vendor browser yang berbeda untuk menyepakati implementasi Javascript standar dan Javascript telah ada selamanya, setidaknya dari perspektif bahasa web. Jadi sebagian besar orang dengan tepat berpikir bahwa memasukkan bahasa sisi klien lain ke dalam ekosistem dan meminta semua vendor untuk mendukungnya secara praktis tidak mungkin dan sebagian besar orang yang berpotensi mewujudkannya sudah terlibat dalam masalah standardisasi Javascript yang menurut saya jauh lebih baik. gunakan waktu mereka.

— davidk01
sumber

Cukup banyak apa yang akan saya katakan. Perbedaan penting (dalam diskusi ini) antara bahasa sisi-klien dan sisi-server adalah bahwa browser harus mengimplementasikan bahasa sisi-klien.

— jhocking

2

Ada beberapa tanggapan di sini yang mengklaim bahwa mendukung banyak bahasa akan membuatnya sangat menjijikkan bagi pembangun peramban web untuk memastikan mereka patuh dengan semua bahasa. Bagi saya ini sepertinya tidak benar.

Java, misalnya adalah standar yang didefinisikan dengan sangat baik. Pada dasarnya, semua yang perlu Anda lakukan adalah mengekspos DOM browser sebagai Java API, dan menjalankan Java Virtual Machine (JVM) di dalam browser web Anda. Anda dapat menentukan bahwa kode skrip harus dikirimkan dalam bentuk file JAR yang dikompilasi dan ditandatangani, atau sebagai kode sumber JavaScript. Jika peramban menjumpai JavaScript, ia dapat menjalankannya melalui penerjemah khusus (seperti halnya saat ini), atau melalui Badak di atas JVM. Jika menemukan file jar, itu menciptakan loader kelas baru dan sandbox keamanan, memuat bytecode java ke dalam memori dan menjalankannya. Ini akan sepenuhnya kompatibel dengan halaman web yang ada, dan akan memungkinkan browser, dengan satu pukulan, untuk mendukung puluhan bahasa yang berjalan di JVM.

Keuntungan lain:

JVM telah mendapat manfaat dari satu dekade peningkatan kinerja. Sekarang sangat cepat, stabil dan dewasa. Saya yakin Anda akan melihat peningkatan kinerja yang besar dibandingkan javascript yang diinterpretasikan.
Saat aplikasi sisi klien menjadi lebih besar dan lebih kompleks, manfaat dari bahasa terstruktur dan diketik seperti Java dan Scala meningkat.
Anda akan memiliki akses ke multi-threading sejati, dan melalui Scala, perpustakaan koleksi yang dioptimalkan untuk komputasi multi-inti.
Anda bisa menggunakan salah satu dari ribuan pustaka java open source di dalam browser.
Melalui perpustakaan seperti openGL, browser dapat menyediakan akses ke grafik canggih dan kemampuan komputasi kartu grafis.
Jika Anda menjalankan java di sisi klien dan server, Anda dapat memanfaatkan komunikasi klien-server lebih lanjut melalui serialisasi objek-grafik biner yang sangat terkompresi = memuat lebih cepat dan melakukan halaman web.

— Patrick Arnesen
sumber

1

Anda sudah dapat menjalankan kode JVM. Ini disebut applet java

— Raynos

1

Saya percaya JavaScript akan mendapatkan lebih banyak dasar sebagai bahasa standar untuk Web. Kami melihat peningkatan JavaScript di sisi server. Berikut adalah beberapa contoh implementasi bahasa yang kuat ini di server:

POW Web Server SJS - JavaScript sisi server untuk POW Web Server, yang berjalan sebagai Ekstensi Firefox atau sebagai Aplikasi XULRunner. SJS memainkan peran yang mirip dengan PHP di Apache karena dapat terhubung ke database dan menghasilkan konten sisi klien.
NodeJS - JavaScript sisi server yang menggunakan model berbasis peristiwa. Itu dibangun menggunakan Google JavaScript V8 Engine . NodeJS diiklankan sebagai alat untuk membangun program jaringan yang dapat diskalakan. Server Web "Hello World" hanya dapat ditulis dalam 6 baris pendek!
Jaxer - Server JavaScript yang menginterpretasikan semua blok skrip dengan runat="server"JavaScript sisi-server. Seluruh aplikasi Web dapat ditulis dalam JavaScript.
Badak - JavaScript untuk Java - Mozilla menciptakan implementasi JavaScript sisi-server yang berjalan di Jawa. Ini pada dasarnya konsep yang mirip dengan PHP Querces untuk Java , Jython, JRuby, dan banyak abstraksi lain dari bahasa lain yang berjalan di JVM. Badak biasanya digunakan untuk menanamkan JavaScript ke Jawa untuk menyediakan alat skrip untuk pengguna akhir, tetapi juga dapat digunakan untuk memindahkan kode sisi klien ke server tanpa harus menulis ulang logika bisnis dalam bahasa lain!
JQuery Claypool - Kerangka kerja JavaScript sisi-server menggunakan kekuatan JQuery di server. Sangat keren! Ini dikembangkan menggunakan implementasi JavaScript sisi server EnvJs browser.
EnvJs - Browser tanpa kepala yang dibangun di atas Badak.

Apa yang ditunjukkan oleh banyak implementasi dan kerangka kerja ini adalah bahwa JavaScript menjadi kekuatan yang sangat kuat dalam pengembangan Web sehingga para pemimpin komunitas sudah mulai memindahkan JavaScript ke server. JavaScript adalah bahasa pemrograman fungsional yang sangat kuat, dan seiring berjalannya waktu saya merasa kita akan melihatnya berkembang.

Singkatnya, sepertinya ada kontradiksi untuk mem-porting bahasa-bahasa lain ke browser ketika sebaliknya kita bisa mem-porting bahasa browser tunggal ini ke server dan menjembatani celah itu dengan cara yang lebih terpadu.

— jmort253
sumber

+1 untuk menunjukkan bahwa JavaScript tidak terbatas pada browser

— Gary Rowe

1

Ada beberapa contoh alat yang akan mengkompilasi bahasa lain ke javascript, termasuk Haskel, Lisp dan Python (Mungkin yang lain). Jadi, jika Anda ingin bekerja dalam salah satu bahasa itu, Anda bisa melakukannya.

Dan saya pikir salah satu profesor saya dari universitas menulis implementasi skema dalam Javascript. Jadi, jika Anda suka skema, Anda bisa melakukannya juga.

— Zachary K
sumber

0

Orang-orang telah bekerja di sekitar kurangnya variasi bawaan dalam dua cara: menggunakan plugin seperti flash atau applet java, dan membangun lapisan yang menggunakan javascript sebagai "kode mesin" mereka, seperti jquery atau google web toolkit. Jika ada gaya pengembangan baru yang cukup populer, orang akan menemukan cara untuk mendapatkannya.

Perlu diketahui jika Anda membuat runtime .net di javascript, dan itu menjadi populer, lingkaran tertentu akan mengutuk nama Anda di internet selamanya.

— Karl Bielefeldt
sumber

Salahkan format web dan IE. Anda akan kencing web devs kurang dengan menusuk mereka dengan hot pokers. Tidak bagus untuk asosiasi merek.

— Erik Reppen