Neden web siteleri için diğer istemci tarafı komut dosyası dilleri yok? [kapalı]


35

Neden bugün tarayıcılarda sadece JavaScript ve bazı VBScript desteği var? JavaScript'in iyi olduğunu biliyorum ama başka bir programlama dili kullanma seçeneğinin olması farklı geliştirme stillerini desteklemeye yardımcı olmaz mı?


1
Şu soruya bakın Yığın Taşması: stackoverflow.com/questions/2872037/…
Corey

1
Sorunuz tam olarak Google’ın GWT’yi neden yaptığıdır .
jhocking

1
DOM API’nin bütün amacının çoklu dil desteği sağlamak olduğuna inanıyorum. İşin aslı, JS aslında mücadeleye gerçekten çok yakışmış. Kimsenin işi olmadığı gibi normalleşir ve birinci sınıf fonksiyonlar ağır bir olay güdümlü paradigmada çok büyüktür. Asıl sorun, kimsenin MS'in bu kararı vermesine izin vermek istemediği ve hiç kimsenin JS'den daha iyi bir karar veremediği. Ayrıca, Java uygulamaları gerçekten, gerçekten topal oldu.
Erik,

Yanıtlar:


33

Birden fazla dil için destek eklemek gerekmez, çözüm, dil uygulayıcıları tarafından kullanılabilecek genel bir byte kodunda standardize etmek olacaktır. Ancak şu anda bunun için hiçbir plan yoktur (önerilmiştir).

Dilleri Javascript üzerine de uygulanabilir. Javascript, diğer dillerin üzerine uygulanmasına izin verecek kadar iyidir. Ve bunun zaten pek çok örneği var.


3
+1 - JavaScript'in diğer diller için bir soyutlama olarak kullanılabilecek güçlü bir dil olduğuna dikkat çekmek için. Müşteri tarafında C ++ veya Java çalıştıracak bir Firefox eklentisi yazmak ilginç bir proje olurdu! <script type="text/cpp" src="test.cpp"></script>.
jmort253

2
@ jmort253, yerel müşteriye bir bak.
dan_waterworth

Yerli müşteri kesinlikle ilginç ama Mozilla da bunu benimsemedikçe, herhangi bir çekiş olmayacak. Son kontrol ettiğimde henüz çalışmaya hazır değillerdi.
nkassis

1
Birkaç yıl önce Gestalt'ı buldum: gestalt.codeplex.com , Javascript’in üstüne başka komut dosyası dilleri oluşturmak için iyi bir örnek.
Jim Schubert

2
Başka bir örnek: Google Web Araç Seti ? Java, JavaScript'te derlenmiştir
MarkJ

21

JavaScript'tir fiili standart ve rekabet tam adil değil çünkü orada bir standart olmak 1996 yılından bu yana olmuştur, ama ben şikayet bir sürü duymadım neden dahil başka bir dil yoktur.

Başka bir "standart" dil eklemek, her türden eğlenceli küçük sorunu teşvik eder.

  • Diğer dillerle nasıl çalışacaklar?
  • DOM paylaşılacak mı?
  • Her ikisinde de yazılmış olan komut dosyaları hala çalışabilir mi?
  • Kütüphaneleri ikisine de taşıma

8
Aslında JavaScript'in Mozilla'nın Gecko'sunda kullanılan dil olduğunu düşünüyorum. IE’de JScript’imiz var. Diğer pek çok tarayıcı ECMAScript özelliklerine az çok uyan bir şey kullanıyor. Bütün bu diller sadelik adına “JavaScript” olarak adlandırılır, aslında farklılık gösterir.
Milch

1
Aynı bytecode üreten birden fazla dile sahip olabilirsiniz. JVM'ye bakın - Groovy, Java, Scala, Clojure, jRuby doğrudan JVM bayt koduna derlenebilir. Bu şekilde aynı DOM api'yi paylaşacaklar ve birlikte çalışabilir hale getirilebilirler. Her ne kadar yorumlandığından beri JavaScript katlanarak JavaScript kullanmaya katlanmak zor.
David Sergey,

21

Yalnızca javascript'i destekledikleri için tarayıcılar arasındaki tutarsızlıkları düşünün. Şimdi daha fazla dil olsaydı nasıl olacağını düşünün.


5
Yay, zaten orada, müşteri tarafında VBScript ... çirkin, titreme.
ocodo

1
+1 Ana tarayıcıların her biri ve sürümleri için ezberlemek için başka diller alt grubumuz olsaydı, kafalarımızın patlayacağını düşünüyorum. İyi cevap.
jmort253

4
Bu nitpicking olabilir, ancak ... tarayıcıların JavaScript [ECMAScript] desteği aslında başından beri genel olarak çok tutarlı olmuştur. Tutarsız olan şey, bunların DOM'yi (ve ilişkili yöntemleri) uygulamasıdır. Pratik (ve tarihsel) bir bakış açısından, ikisini ayırmak zordur - çünkü JS'nin tek gerçek kullanımı DOM'yi bir tarayıcıda manipüle etmek olmuştur - ancak sunucu tarafı JS'nin (NodeJS gibi) yükselişi ile Bu aslında biraz önemli bir ayrım haline geldi.
josh3736

tam olarak bunu bir cevap olarak yazacaktı, internet takip edilmeyen ya da desteklenmeyen standartlara sahipti. Elimizdeki karmaşa karışıklığının, olduğu gibi yarısı da çalıştığı gerçeği, bir mucizeden başka bir şey değil.
Ryathal

1
Josh haklı. Bireysel tarayıcının, JS tarafından işlerin nasıl çirkin hale geldiği ve bunlara nasıl erişilmesi gerektiği ile ilgili ne kadar çirkin hale geldiği fikrini taktığınız yer budur. MS’in tarayıcılarını dosya gezgini - jackasslarına bağlamaya yönelik kaderî kararı nedeniyle hemen hemen her şeyde en sonuncuyu geride bırakıyor.
Erik,

6

Tarayıcıların standartlaştırılması gerekir, böylece geliştirdiğiniz şey tüm tarayıcılarda her yerde çalışır.

Tekmeleyen birden fazla diliniz varsa, hepsinin de benzer şekilde performans gösterdiğinden emin olmalısınız. Bir web geliştiricisiyseniz ve bazı yerlerde desteklenebilecek veya desteklenmeyecek dil seçenekleriniz varsa, bu ek bir baş ağrısıdır.

Javascript çok esnek bir dildir, zorunludur, işlevseldir, OOP olabilir (prototipli bir modadan sonra) ve yorumlanır. Artık Chrome'daki gibi iyi motorlarla, bazı iyi şeyler yapabilme yeteneğine sahip. Ekstra diller buraya sadece bir şeyler koyardı, sadece VBScript'e, IE'ye bakardı ve içinde yazılan her şey belirli bir tarayıcı ve platforma, kabusa bağlı.


2
Buradaki önemli nokta "Chrome'daki gibi iyi motorlarla" olmak. Hafif bir vergilendirmeyi bile yapmak, IE8’in bile kırılmış bir ayağı var gibi topallamaya başlamasına neden olurken, Firefox’un son sürümleri ve Chrome sonsuza dek kullandığımdan beri (infact’i değiştirmemin sebebi) bir vuruş kaçırmadan atlamak.
Matthew Scharley

1
@Matthew Scharley: IE genellikle durgun, aslında her versiyonda daha da kötüye gidiyor. Oyunlarını geliştirmeleri gerekiyor, yoksa oyunun dışında kalacaklar. IE’nin sahip olabileceği tek neden işletim sistemi dahil olmalarından kaynaklanıyor, şimdi ilk kullanımda çok seçici bir seçici kullanmaları gerekiyor.
Orbling

"Bu OOP olabilir" ... O ise OOP! Kalıtım, OOP'yi tanımlayan şey değildir. Nesneler vardır.
KaptajnKold

@KaptajnKold: Bu, akademik çevrelerde şaşırtıcı şekilde bir tartışma konusu. JS'nin OOP yeteneğine sahip olduğunu, nesneleri olduğu için, bazıları tarafından her zaman aşırı kullanılmadıklarını kabul ediyorum. Prototip sistemi, her zamanki OOP lezzetinden farklı olarak iyi bir anlaşma olup, onu "AOP dilinin" standart tanımından daha da kaldırır. Çoğu dilde olduğu gibi, onu nasıl kullandığınıza bağlıdır - kullandığımda OOP.
Orbling

3

Bunları tarayıcılara yerleştirmek yerine, satıcılar tıkalı tarayıcı eklentileri (Java, Flash, Silverlight, vb.) Oluşturmak ister. Bu, platformlar arası tutarlılığı garanti eder.


Tabi bu, çapraz platform tutarlılığını, kontrolü garanti ettiği kadar güvence altına almakla ilgili değil. İçinde olduğu gibi eklentiyi kontrol ediyor ve kimseye cevap vermek zorunda değilsin.
jhocking

Hızlı bir şekilde javascript çalıştıran ile mücadele etmekle karşılaştırıldığında, "clunky" eklentileri çok daha iyi. Tarayıcı eklentisi indirme işleminin tamamında olumsuz hissetmiştim, ancak kesinlikle "uygulamalı olmayan bir şekilde javascript" den daha açık.
Milind R

2

Bunun nedenlerinden biri, farklı tarayıcı satıcılarının standart bir Javascript uygulaması üzerinde hemfikir olmalarının neredeyse imkansız olmasıdır ve Javascript en azından bir web dili perspektifinden sonsuza kadar olmuştur. Bu yüzden çoğu insan, ekosisteme başka bir müşteri tarafı dili eklemenin ve tüm satıcıları desteklemesinin pratik olarak imkansız olduğunu ve potansiyel olarak bunu gerçekleştirebilecek insanların çoğunun zaten daha iyi olduğunu düşündüğüm Javascript standardizasyon konularında olduğunu düşünüyor. zamanlarının kullanımı.


Hemen hemen ne söyleyecektim. İstemci tarafı ve sunucu tarafı dilleri arasındaki önemli (bu tartışmada) fark, tarayıcıların istemci tarafı dilini uygulamak zorunda olmalarıdır.
atıyor

2

Burada, birden fazla dili desteklemenin, web tarayıcılarının üreticileri için tüm dillerle uyumlu olmalarını sağlama konusunda çok çılgınca olacağını iddia eden birkaç yanıt var. Bana göre bu yanlış görünüyor.

Java, örneğin son derece iyi tanımlanmış bir standarttır. Temel olarak yapmanız gereken tek şey, DOM tarayıcıyı bir Java API olarak göstermek ve web tarayıcınızın içinde Java Sanal Makinesi'ni (JVM) çalıştırmak. Komut dosyası kodunun, derlenmiş ve imzalanmış JAR dosyaları biçiminde veya JavaScript kaynak kodu biçiminde gönderilmesi gerektiğini belirleyebilirsiniz. Tarayıcı JavaScript ile karşılaşırsa, özel bir tercüman aracılığıyla (bugün olduğu gibi) veya JVM'nin üstündeki Rhino aracılığıyla çalıştırabilir . Jar dosyalarına rastlarsa, yeni bir sınıf yükleyici ve güvenlik sanal alanı oluşturur, java bayt kodunu belleğe yükler ve yürütür. Bu, mevcut web sayfalarıyla tamamen geriye dönük olarak uyumlu olacak ve tarayıcının, tek bir vuruşla JVM'de çalışan düzinelerce dili desteklemesini sağlayacaktır.

Diğer Avantajlar:

  1. JVM, on yıllık bir performans iyileştirmesinden faydalanmıştır. Şimdi çok hızlı, kararlı ve olgun. Bahse girerim, yorumlanmış javascript üzerinde büyük bir performans artışı göreceksin.
  2. İstemci tarafı uygulamalar büyüdükçe ve daha karmaşık hale geldikçe, Java ve Scala gibi yapılandırılmış, yazılan dillerin yararları artar.
  3. Gerçek çoklu iş parçacığına ve çok çekirdekli bilgi işlem için en iyi duruma getirilmiş bir koleksiyon kitaplığı olan Scala'ya erişebilirsiniz.
  4. Tarayıcının içindeki binlerce açık kaynaklı java kütüphanesinden herhangi birini kullanabilirsiniz.
  5. OpenGL gibi kütüphaneler sayesinde, tarayıcı gelişmiş grafiklere ve grafik kartı hesaplama yeteneklerine erişim sağlayabilir.
  6. İstemci ve sunucu tarafında çalışan java'nız varsa, aşırı sıkıştırılmış, ikili nesne grafiği serileştirme = web sayfalarını daha hızlı yükleyip gerçekleştirerek istemci-sunucu iletişiminden daha fazla yararlanabilirsiniz.

1
JVM kodunu zaten çalıştırabilirsiniz. Buna bir java uygulaması denir
Raynos,

1

JavaScript’in Web’de standart dil olarak daha fazla yer kazanacağına inanıyorum. Sunucu tarafı JavaScript’inde bir artış görüyoruz. İşte bu güçlü dilin sunucudaki uygulamalarından bazı örnekler:

  • POW Web Sunucusu SJS - Firefox Uzantısı veya XULRunner Uygulaması olarak çalışan POW Web Sunucusu için Sunucu tarafı JavaScript. SJS, Apache'deki PHP'ninkine benzer bir rol oynamaktadır, çünkü veritabanlarına bağlanabilir ve müşteri tarafı içeriği oluşturabilir.

  • NodeJS - Olay tabanlı bir model kullanan sunucu tarafı JavaScript. Google'ın V8 JavaScript Motoru kullanılarak inşa edilmiştir . NodeJS, ölçeklenebilir ağ programları oluşturmak için bir araç olarak ilan edilir. Bir "Merhaba Dünya" Web sunucusu sadece 6 kısa satırda yazılabilir!

  • Jaxer - Tüm script bloklarını runat="server"server-tarafı JavaScript olarak yorumlayan bir JavaScript sunucusu . Tüm Web uygulamaları JavaScript ile yazılabilir.

  • Rhino - Java için JavaScript - Mozilla, Java ile çalışan bu sunucu tarafı JavaScript uygulamasını oluşturdu. Temel olarak Querces PHP for Java , Jython, JRuby ve JVM'de çalışan diğer dillerin soyutlamaları ile benzer bir kavramdır . Rhino tipik olarak JavaScript'i Java'ya gömmek için son kullanıcılara komut dosyası araçları sağlamak için kullanılır, ancak iş tarafı mantığını başka bir dilde yeniden yazmak zorunda kalmadan istemci tarafı kodu sunucuya taşımak için de kullanılabilir!

  • JQuery Claypool - Sunucudaki JQuery'nin gücünü kullanan sunucu tarafı JavaScript çerçevesi. Çok havalı! Bir tarayıcının EnvJs Sunucu tarafı JavaScript uygulaması kullanılarak geliştirilmiştir.

  • EnvJs - Rhino'nun üzerine kurulu başsız bir tarayıcı.

Bu uygulamaların ve çerçevelerin birçoğunun gösterdiği şey, JavaScript’in web geliştirmede o kadar güçlü bir güç haline geldiği, topluluk liderlerinin zaten JavaScript’i sunucuya taşımaya başladıkları. JavaScript oldukça güçlü bir işlevsel programlama dilidir ve zaman geçtikçe evrimleştiğini göreceğimizi hissediyorum.

Özetle, bu tek tarayıcı dilini sunucuya taşıyabildiğimiz ve bu açığı daha birleşik bir şekilde köprüleyebildiğimizde diğer dilleri tarayıcıya taşımak gibi bir çelişki gibi görünüyor.


JavaScript'in tarayıcıyla sınırlı olmadığını vurgulamak için +1
Gary Rowe

1

Haskel, Lisp ve Python (Muhtemelen diğerleri) de dahil olmak üzere diğer dilleri javascriptte derleyecek araç örnekleri vardır. Yani, bu dillerden birinde çalışmak istiyorsanız, bunu yapabilirsiniz.

Ve üniversite profesörlerinden birinin Javascript'te bir program uygulaması yazdığını düşünüyorum. Yani düzeni seviyorsanız, bunu da yapabilirsiniz.


0

İnsanlar yerleşik çeşitliliğin olmaması konusunda iki şekilde çalıştılar: flash veya java uygulamaları gibi eklentileri kullanmak ve jquascript'i jquery veya google web araç seti gibi kendi "makine kodları" olarak kullanmak için javascript kullanan türler oluşturmak. Yeterince popüler olan yeni bir gelişme tarzı olsaydı, insanlar onu kullanmanın bir yolunu bulurlardı.

Javascript'te bir .net çalışma zamanı yaparsanız ve popüler hale gelirse, bazı çevreler adınızı internette sonsuza dek küfredeceklerini unutmayın.


Web formlarını ve IE'yi suçlayın. Web kullanıcı arayüzü geliştiricilerine daha az ateşli silahla vurup daha az işeyeceksin. Marka birliği için iyi değil.
Erik,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.