Standart tarayıcı sanal makinesi yerine neden JavaScript?


167

Tarayıcıda barındırılan standartlaştırılmış bir sanal makine aracılığıyla bir dizi dili (Java, Python, Ruby, vb.) Desteklemek, özel bir dilin (gerçekten, özel bir paradigma) kullanılması yerine mantıklı olmaz mı? yalnızca istemci komut dosyaları için mi?

Öneriyi açıklığa kavuşturmak için bir web sayfasında JavaScript gibi daha üst düzey bir dil yerine bayt kodu bulunur.

JavaScript'in evrimsel nedenlerden dolayı şu anda birlikte çalışmak zorunda olduğumuz pragmatik gerçekliği anlıyorum, ancak uzun vadeyi daha fazla düşünüyorum. Geriye dönük uyumlulukla ilgili olarak, satır içi JavaScript'in bir süre aynı anda desteklenememesi için hiçbir neden yoktur ve elbette JavaScript, tarayıcı sanal makinesi tarafından desteklenen dillerden biri olabilir.


17
Bunun neden oylandığını bilmiyorum. Bunun iyi bir soru olduğunu düşündüm!

11
Çünkü bu bir sorudan çok bir şikayet.
Dustman

6
Javascript'in gerçek bir dil olmadığı veya diğer diller kadar iyi olmadığı fikri nedeniyle. Bunların hiçbiri ilk günlerden beri doğru değildir, ancak 'kirli' algı halen devam etmektedir.
Adam Davis

43
Vay be, SO topluluğunun bu kadar tamamen başarısız olduğunu hiç görmedim. Burada önerilen fikre hitap eden tek cevap, aşağıya inen, aşağıya inen, cevapları gereksiz yere "JS'yi savunan" tüm sevgiyi alıyor. Bu soru JS'ye saldırmıyor, sadece seçimi savunuyor. Basitçe şöyle diyor: "JS hakkında ne düşünürseniz düşünün, dilerseniz başka dilleri de kullanmak iyi olmaz mıydı?". Neyin var?
Jordi

4
Bu, StackOverflow ile ilgili çok önemli bir sorundur ve birkaç cevap verildikten sonra gelecekteki düzenlemelere izin verir. Sorulan orijinal soru en iyi cevaplarla daha alakalı, geri kalanı ise düzenlemelerden sonra sorunun "yeni ruhunu" ele almaktadır.

Yanıtlar:


28

İyi evet. Kesinlikle bir zaman makinemiz olsaydı, geri dönüp Javascript özelliklerinin birçoğunun farklı şekilde tasarlanmasını sağlamak büyük bir eğlencedir (IE'nin CSS motorunu tasarlayan insanların hiçbir zaman BT'ye girmemesini sağlamak). Ama bu olmayacak ve şimdi onunla sıkışıp kaldık.

Zamanla, web için "Makine dili" olacağından şüpheleniyorum, diğer daha iyi tasarlanmış diller ve API'ler de derleniyor (ve farklı çalışma zamanı motor foibleslerini karşılayacak).

Ancak, bu "daha iyi tasarlanmış dillerden" herhangi birinin Java, Python veya Ruby olacağını sanmıyorum. Javascript, başka bir yerde kullanılabilmesine rağmen, bir Web uygulaması komut dosyası dilidir. Bu kullanım durumu göz önüne alındığında, bu dillerden daha iyisini yapabiliriz.


54
IE CSS ekibi için -1. IE6 piyasaya sürüldüğünde kötü değildi, ana rakibi şimdiye kadar yazılmış en ürkütücü yazılım parçasıydı. İnsan saldırıları, bazen eğlenceli olsa da, dünyayı daha iyi bir yer yapmaz.
erikkallen

5
JavaScript değerlendirmenize "... bir Web uygulaması komut dosyası dili ..." gibi daha az katılmıyorum. Bundan çok daha fazla uygulanabilirliğe sahip harika, esnek bir dil.
TJ Crowder

2
@TJ Crowder: ITYM "[...] Daha fazla katılmıyorum."?
Christoffer Hammarström

2
@Jaroslaw Szpilewski Utanmaz JS zealotizm? Başka bir gönderi düşünerek bu konuda yanlış mı yaptınız? Ayrıca, @erikkallen için, IE CSS ekibi yorumu yaygın olarak "şaka" olarak bilinen şeydi.
Adam Wright

2
Bu cevaptaki bazı "basiret": artık CoffeeScript var.
andref

19

JavaScript'in iyi bir dil olduğunu düşünüyorum, ancak istemci tarafı web uygulamaları geliştirirken bir seçim yapmak isterim. Eski nedenlerden dolayı JavaScript ile sıkışıp kaldık, ancak bu senaryoyu değiştirmek isteyen projeler ve fikirler var:

  1. Google Yerel İstemci : tarayıcıda yerel kod çalıştırmak için kullanılan teknoloji.
  2. Emscripten : Javascript için LLVM bayt kodu derleyicisi. LLVM dillerinin tarayıcıda çalışmasına izin verir.
  3. Fikir: Mono'nun yaratıcısı tarafından tarayıcıda .NET CLI: http://tirania.org/blog/archive/2010/May-03.html

Uzun zamandır JavaScript'imiz olacağını düşünüyorum, ancak bu er ya da geç değişecek. Tarayıcıda başka dilleri kullanmak isteyen pek çok geliştirici var.


LLVM tüm bunlara bir cevap olabilir. LLVM'ye derleme desteği ile çok sayıda dil (Python, Ruby, hatta Java) zaten var ve LLVM Javascript'e derleyebilir, bu yüzden en azından tarayıcılarda otomatik olarak LLVM desteğini JS'ye derleyerek alabiliriz. Elbette LLVM, tüm programlama paradigmaları ve belirli diller için optimize edilemez, bu nedenle performans% 100 yerli ile aynı olmayacaktır, ancak Javascript'in JIT'leri / Tercümanları, son gelişmeleri hesaba katarak bile, her zaman yerel olarak göreceli olarak yavaş olmuştur. .
facuq

18

Soruyu cevaplamak - Hayır, mantıklı değil.

Şu anda çok dilli bir VM'ye en yakın şey JVM ve CLR'dir. Bunlar tam olarak hafif canavarlar değildir ve bu boyutta ve karmaşıklıkta bir şeyi bir tarayıcıya yerleştirmek mantıklı olmaz.

Mevcut çözümden daha iyi olacak yeni, çok dilli bir VM yazabileceğiniz fikrini inceleyelim.

  • İstikrardasınız.
  • Karmaşıklık içindesiniz (yol, yol, arkada çünkü birden fazla dilde genelleme yapmaya çalışıyorsunuz)
  • Evlat edinmek için geride kaldın

Yani, hayır, mantıklı değil.

Unutmayın, bu dilleri desteklemek için API'lerini şiddetli bir şeylerden arındırmanız ve bir tarayıcı komut dosyası bağlamında mantıklı olmayan parçaları kesmeniz gerekeceğini unutmayın. Burada verilecek çok sayıda tasarım kararı ve hata için çok büyük bir fırsat var.

İşlevsellik açısından, biz sadece muhtemelen konum gerçekten DOM ile çalışıyoruz, bu yüzden bu gerçekten bir sözdizimi ve dil idomu sorunu, bu noktada "Bu gerçekten buna değer mi?" Diye sormak mantıklı.

Akılda tutarak, sadece bahsettiğimiz şey, istemci tarafı komut dosyası oluşturmaktır, çünkü sunucu tarafı komut dosyası, istediğiniz herhangi bir dilde zaten mevcuttur. Bu nispeten küçük bir programlama arenasıdır ve bu nedenle birden fazla dili getirmenin yararı tartışmalıdır.

Hangi dilleri getirmek mantıklı olur? (Uyarı, subjektif malzeme aşağıdaki gibidir)

C gibi bir dile getirmek mantıklı değil çünkü metalle çalışmak için yapılmış ve bir tarayıcıda gerçekten fazla metal yok.

Java gibi bir dile getirmek mantıklı değil çünkü bununla ilgili en iyi şey API'ler.

Ruby veya Lisp gibi bir dile getirmek mantıklı değil çünkü JavaScript, Şema'ya çok yakın güçlü bir dinamik dildir.

Son olarak, hangi tarayıcı üreticisi birden çok dil için DOM entegrasyonunu desteklemek istiyor? Her uygulamanın kendine özgü hataları olacaktır. MS Javascript ve Mozilla Javascript arasındaki farklarla uğraşan ateşten geçtik ve şimdi bu acıyı beş veya altı kat ile çarpmak istiyoruz?

Mantıklı değil.


Oldukça öznel bir cevap, ama bazı iyi noktaları yükselttiğinizde oy vermek istemedim (ve orijinal cevap zaten tartışma başlatıcısı gibi).
Gerbrand

2
Tarayıcıdaki VM'nin ağır olması için gerekli olduğunu düşünmüyorum. Tabii ki zaten Silverlight ve Applets olarak var. İkincisi popülerlik kazanamadı, bence çoğunlukla kötü zamanlama ve çoğunlukla çözülen teknik aptallıklar yüzünden. Komut dosyası etiketi arasında herhangi bir dile izin vermek (kısıtlamalar dahil) oldukça havalı olurdu ve kesinlikle imkansız veya pratik değildir.
Gerbrand

2
Ağırlık (MB)? Muhtemelen tamam. Ağırlık (karmaşıklık)? Yol çok ağır. Sahip olduğunuz herhangi bir çok dilli VM, dil uygulamalarını üstte (örn. JRuby / IronRuby, Clojure, Jython / IronPython) vb. Üzerinde uygulayacaksınız. Ya JVM karmaşıklığı yiyor ya da dil uygulayıcıları yapıyor.
mutlu moron

Birden çok yepyeni platform (IE / Firefox / Safari ...) için birden çok dili yeniden uygulamak şaşırtıcı bir iş gerektirecektir. Ve diller de değişir. "Bu sayfa yalnızca Ruby 1.9 tarayıcısında görünür"? Lütfen hayır.
mutlu moron

4
Soruyu doğru bir şekilde yanıtladığınızı sanmıyorum, sadece neden şu anda tarayıcıda javascript'in yaptığı için diğer dillerin uygun olmadığını düşündüğünüzü söylüyorsunuz. Web için uygun evrensel bir bayt kodu, diğer dillerin derlediği bir şey olacaktır, eğer bu dil yararlıysa, web bayt kodu değil, yaratıcısına bağlıysa, birçok dil bu btw'yi javascript'e (yani dart) derleyerek zaten yapar.
Timotheus

14

Windows'ta, Komut Dosyası Ana Bilgisayarına diğer dilleri kaydedebilir ve IE'de kullanılabilir hale getirebilirsiniz. Örneğin, VBScript kutunun dışında desteklenir (çoğu amaç için JavaScript'ten bile daha kötü olduğu için hiç popülerlik kazanmamış olsa da).

Python win32 uzantıları, Python'u IE'ye böyle kolayca eklemeye izin verdi, ancak Python'un sanallaştırılması oldukça zor olduğu için gerçekten iyi bir fikir değildi: birçok dil özelliği, sözde kısıtlı bir uygulamanın patlamasına izin vermek için yeterli uygulama kancasını ortaya çıkarıyor .

Genel olarak, tarayıcı gibi ağa bakan bir uygulamaya ne kadar karmaşıklık eklerseniz, güvenlik sorunlarının ortaya çıkma olasılığı da o kadar yüksektir. Bir grup yeni dil kesinlikle bu tanıma uyacaktır ve bunlar da hala hızlı gelişen yeni dillerdir.

JavaScript çirkin bir dildir, ancak seçici bir özellik alt kümesinin dikkatli kullanımı ve uygun nesne kitaplıklarından destek alarak genellikle oldukça tolere edilebilir hale getirilebilir. Web komut dosyalarının devam etmesinin tek yolu JavaScript'e artımlı, pratik eklemeler gibi görünüyor.


12

Tarayıcılarda standart bir dilden bağımsız VM'yi kesinlikle memnuniyetle karşılarım (statik olarak yazılmış bir dilde kod yazmayı tercih ederim).

(Teknik olarak) Yavaş yavaş yapılabilir: birincisi büyük bir tarayıcı onu destekler ve mevcut istek uyumlu tarayıcıdan geliyorsa sunucunun bayt kodu gönderme veya kodu JavaScript'e çevirme ve düz metin JavaScript gönderme olasılığı vardır.

JavaScript için derlenen bazı deneysel diller zaten var, ancak tanımlanmış bir VM'ye sahip olmak daha iyi performansa izin verebilir (belki de).

Ama "standart" kısmı oldukça zor olacağını itiraf. Ayrıca kütüphane ile ilgili dil özellikleri (örneğin statik ve dinamik yazma) arasında çatışmalar olacaktır (yeni şeyin aynı kütüphaneyi kullanacağı varsayılarak). Bu yüzden olacağını düşünmüyorum (yakında).


10

Ellerinizi kirletiyormuş gibi hissediyorsanız, ya beyin yıkamışsınızdır ya da hala "DHTML yıllarının" etkilerini hissediyorsunuzdur. JavaScript çok güçlüdür ve etkileşimi istemci tarafına komut vermek olan amacı için uygundur. Bu yüzden JavaScript 2.0 çok kötü bir rap aldı. Demek istediğim, bunlar sunucu tarafı dillerinin açık bir yönü olduğunda neden paketler, arayüzler, sınıflar ve benzerleri. JavaScript, tam gelişmiş nesne yönelimli olmadan, prototip tabanlı bir dil olarak iyidir.

Sunucu tarafı ve istemci tarafı iyi iletişim kurmadığı için uygulamalarınızda sorunsuzluk yoksa, uygulamalarınızı nasıl tasarladığınızı yeniden düşünmek isteyebilirsiniz. Son derece sağlam Web siteleri ve Web uygulamaları ile çalıştım ve bir keresinde "Hmm, JavaScript'in yapabilmesini diliyorum (xyz)" demedim. Bunu yapabilseydi, JavaScript olmazdı - ActionScript veya AIR veya Silverlight olurdu. Buna ihtiyacım yok ve çoğu geliştiriciye de gerek yok. Bunlar güzel teknolojiler, ama bir problemi bir teknoloji ile değil, bir çözümle çözmeye çalışıyorlar.


13
JavaScript'in tam gelişmiş nesne odaklı olmadığını nasıl söyleyebilirsiniz? Kesinlikle bildiğim en nesneye yönelik dillerden biri. JavaScript'teki her şey bir nesne - hatta işlevler. JavaScript'teki OOP, diğer birçok dilde OOP gibi görünmüyor.
Rene Saarsoo

2
OOP, JavaScript'e özgü değildir. Çekirdeğe yerleşik paketler, arabirimler, soyut sınıflar veya yöntem aşırı yüklemesi yoktur ve bir nesneyi genişletemezsiniz - yalnızca bir nesnenin prototipidir, bu da onu OOP tabanlı değil, prototip tabanlı yapar.

3
Ölü yanlış. "Protip" bir Tasarım Paternidir (Gamma ve diğ., S 117-126). Hatırlayacağınız gibi, Tasarım Desenleri Nesneye Yönelik Programlama'daki yaygın tasarımlar etrafında döner. Ve dilin diğer OOP dilleriyle aynı özelliklere sahip olmaması, OOP olmadığı anlamına gelmez.
Dustman

13
Yanlış ölmediniz, bence koymanın en iyi yolu JS sınıf tabanlı OO değil, prototip OO.
Juan Mendes

14
1. Javascript tamamen OOP'tur. OOP sınıflarla değil nesnelerle ilgilidir. 2. JavaScript'te bir nesneyi genişletebilirsiniz, bu da Prototypal nesne yönelimli programlamanın tüm noktasıdır. 3. Soruyu cevaplamıyorsunuz, soru JS'ye saldırmıyor, sadece seçim istiyor. JS'nin harika bir dil olduğunu düşünüyorum, ancak tarayıcıda programlama yaparken başka seçeneklere sahip olmak isterim.
Manuel Ceron

7

Standart bir web VM'sinin bu kadar akla yatkın olduğunu düşünmüyorum. Kullandığınız herhangi bir VM bayt kodu biçiminin hızlı bir şekilde javascript'e dönüştürülmesini ve sonuçta elde edilen çıktının makul derecede verimli olmasını sağladığınız sürece, yeni bir web VM standardını zarif bir şekilde ve tam eski desteğiyle tanıtmanın birkaç yolu vardır. Akıllı bir decompiler muhtemelen bir insanın üretebileceği herhangi bir javascript'ten daha iyi bir javascript üreteceğini tahmin etmek için o kadar ileri giderdim.

Bu özellik sayesinde, herhangi bir web VM biçimi sunucuda (hızlı), istemcide kolayca çözülebilir (yavaş, ancak sunucunun sınırlı denetimine sahip olduğunuz durumlarda mümkündür) veya tarafından önceden oluşturulabilir ve dinamik olarak yüklenebilir yeni standardı yerel olarak desteklemeyen tarayıcılar için istemci veya sunucu (en hızlı).

Yeni standardı yerel olarak destekleyen tarayıcılar, web vm tabanlı uygulamalar için daha yüksek çalışma süresi hızından yararlanır. Bunun üzerine, tarayıcılar eski javascript motorlarını web vm standardına dayandırıyorsa (yani, javascript'i web vm standardına ayrıştırıp çalıştırıyorsa), iki çalışma zamanını yönetmek zorunda kalmazlar, ancak bu tarayıcı satıcısına bağlıdır .


6

Javascript, sayfayı doğrudan kontrol edebileceğiniz iyi desteklenen tek komut dosyası dili olsa da, Flash'ın daha büyük programlar için çok hoş özellikleri vardır. Son zamanlarda bir JIT vardır ve aynı zamanda anında bayt kodu oluşturabilir ( kullanıcı-giriş matematik ifadelerini yerel ikiliye kadar derlemek için flash kullandıkları bir örnek için çalışma zamanı ifade değerlendirmesine bakın). Haxe dili, çıkarım ve statik kod oluşturma yetenekleri ile statik yazım sağlar ve istediğiniz neredeyse tüm çalışma zamanı sistemini uygulayabilirsiniz.


Soruda ne eksik? Flash tam olarak istediği şeyi yapacak gibi görünüyor. Başka bir anadil hakkında konuşmuyoruz, VM istiyor, değil mi? İyi cevap.
mwilcox

6

Bu eski soru hakkında hızlı güncelleme.

Bir "web sayfasının JavaScript" gibi herhangi bir üst düzey dil yerine bayt kodu içerdiğini doğrulayan herkes "olmayacak".

Haziran 2015 W3C açıkladı WebAssembly olduğunu

Web'e derlemeye uygun yeni, taşınabilir, boyut ve yükleme zamanı açısından verimli bir format.

Bu hala deneysel, ancak her gece Firefox ve Chrome Canary'de bazı prototip uygulamaları var ve zaten bazı gösteri çalışmaları var .

Şu anda, WebAssembly çoğunlukla C / C ++ 'dan üretilecek şekilde tasarlanmıştır.

WebAssembly geliştikçe C / C ++ 'dan daha fazla dili destekleyecek ve diğer derleyicilerin de destekleyeceğini umuyoruz .

Projenin resmi sayfasına daha yakından bakmanıza izin verdim , gerçekten heyecan verici!


5

bu soru düzenli olarak yeniden ortaya çıkıyor. bu konudaki duruşum:

A) olmayacak ve B) zaten burada.

af, ne? açıklamama izin ver:

A reklamı

VM sadece bir tür evrensel büyülü cihaz değildir. VM'lerin çoğu belirli bir dil ve belirli dil özellikleri için optimize edilmiştir. statik yazım için optimize edilmiş JRE / Java (veya LLVM): ve dinamik yazmayı veya java'nın ilk etapta desteklemediği diğer şeyleri uygularken kesinlikle sorunlar ve dezavantajlar vardır.

bu nedenle, birçok dil özelliğini (kuyruk çağrısı optimizasyonu, statik ve dinamik yazım, foo bar boo, ...) destekleyen "genel çok amaçlı VM" muazzam, uygulanması zor ve muhtemelen iyi performans elde etmek için optimize edilmesi daha zor olurdu o. ama ben bir dil tasarımcısı ya da vm guru değilim, belki de yanılıyorum: aslında oldukça kolay, henüz kimse bu fikre sahip değildi? hrm, hrm.

reklam B

zaten burada: bir bytecode derleyici / vm olmayabilir, ancak aslında bir taneye ihtiyacınız yoktur. afaik javascript tamamlanıyor, bu yüzden şunlardan biri mümkün olmalı:

  1. X dilinden javascript'e bir çevirmen oluşturun (örn. kahve)
  2. javascript'te X dilini (örn. beyin sikişi ) yorumlayan bir tercüman oluşturun . evet, performans berbat olurdu, ama hey, her şeye sahip olamaz.

reklam C

ne? ilk etapta C noktası yoktu !? çünkü henüz ... henüz yok. google NACL. herkes yapabilirse, bu google. Google çalışmaya başlar başlamaz, sorunlarınız çözüldü. sadece, ah, asla işe yaramayabilir, bilmiyorum. son kez bu konuda okumak gerçekten zor tür bazı çözülmemiş güvenlik sorunları vardı .


onun dışında:

  • javascript ~ 1995 = 15 yıldan beri var. Yine de, tarayıcı uygulamaları bugün farklıdır (en azından artık yetersiz değildir). yani, yeni bir şeye başlarsanız, 2035 civarında çalışan bir çapraz tarayıcı sürümünüz olabilir. en azından çalışan bir alt küme. bu sadece kurnazca farklılık gösterir. ve uyumluluk kütüphaneleri ve katmanları gerekir. Olsa da bazı şeyleri geliştirmek için çalışmıyorum.

  • ayrıca, okunabilir kaynak kodu ne olacak? bir çok şirket "tür-" açık kaynak kodlarını hizmet etmemeyi tercih edeceğini biliyorum. kişisel olarak, eğer bir şeyden şüphelendiğimde veya ondan bir şeyler öğrenmek istediğimde kaynağı okuyabildiğim için oldukça mutluyum. kaynak kodu için Yaşasın!


4

Aslında. Silverlight etkili bir şekilde budur - istemci tarafı .Net tabanlı VM.


4

Muhakemenizde bazı hatalar var.

  1. Standart bir tarayıcıdaki standart bir sanal makine asla standart olmaz. 4 tarayıcımız var ve IE'nin 'standart' ile ilgili çelişen çıkarları var. Diğer üçü hızla gelişiyor, ancak yeni teknolojilerin benimsenme hızı yavaş. Telefonlardaki, küçük cihazlardaki tarayıcılar ...

  2. JS'nin farklı tarayıcılara ve geçmiş geçmişine entegrasyonu, JS'nin gücünü az tahmin etmenize neden olur. Bir standardı taahhüt ediyorsunuz, ancak JS'yi onaylamıyorsunuz çünkü standart ilk yıllarda işe yaramadı.

  3. Başkaları tarafından söylendiği gibi JS, AIR / .NET / ... ve benzerleri ile aynı değildir. JS, mevcut enkarnasyonunda hedeflerine mükemmel bir şekilde uyuyor.

Uzun vadede, Perl ve Ruby javascript'in yerini alabilir. Ancak bu dillerin benimsenmesi yavaştır ve JS'yi asla devralmayacakları bilinmektedir.


3

En iyi nasıl tanımlarsınız? Tarayıcı için veya geliştirici için en iyisi? (Artı ECMAScript, Javascript'ten farklıdır, ancak bu bir tekniktir.)

JavaScript'in aynı zamanda güçlü ve zarif olabileceğini düşünüyorum. Ne yazık ki tanıştığım çoğu geliştirici bunu gerçek bir programlama dili yerine gerekli bir kötülük gibi ele alıyor.

Hoşlandığım bazı özellikler:

  • birinci sınıf vatandaş muamelesi yapma
  • herhangi bir nesneye herhangi bir zamanda işlev ekleyip kaldırabilme (çok yararlı değil, olduğunda zihin üfleme)
  • dinamik bir dildir.

Başa çıkmak eğlenceli ve kurulmuş. Etrafında iken tadını çıkarın çünkü istemci komut dosyası için "en iyi" olmasa da kesinlikle hoş.

Tarayıcı uyumsuzlukları nedeniyle dinamik sayfalar oluşturmanın sinir bozucu olduğunu kabul ediyorum, ancak bu UI kütüphaneleri tarafından hafifletilebilir. Bu artık JavaScript'e karşı yapılmamalı, Swing'in Java'ya karşı yapılması gerekir.


+1 - Dil sorunlarını tarayıcı kodunun kod yorumuyla karıştırmamalı.
JL.

neden bayt kodu seçimini istediğinde JS'yi neden savunmalısınız?
Milind R

3

JavaScript, tarayıcının standart sanal makinesidir. Örneğin, OCaml ve Haskell artık her ikisinin de JavaScript çıktısı alabilen derleyicileri var. Bu sınırlama JavaScript dili değil, sınırlama JavaScript üzerinden erişilebilen tarayıcı nesneleri ve makinenizi tehlikeye atmadan JavaScript'i güvenli bir şekilde çalıştırabilmenizi sağlamak için kullanılan erişim kontrol modelidir. Geçerli erişim denetimleri o kadar zayıf ki, JavaScript'in güvenlik nedeniyle tarayıcı nesnelerine yalnızca çok sınırlı erişime izin veriliyor. Harmony projesi bunu düzeltmek istiyor.


3

Harika bir fikir. Neden bir adım öteye gitmiyorsun?

  • HTML ayrıştırıcısını ve düzen motorunu (tarayıcıdaki tüm karmaşık bitleri gerçekten) aynı VM dilinde yazın
  • Motoru web'de yayınlayın
  • Sayfayı hangi düzen motorunun kullanılacağını ve URL'sini kullanarak sunun

Daha sonra her istemciye yeni tarayıcılar göndermek zorunda kalmadan tarayıcılara özellikler ekleyebiliriz - ilgili yeni bitler web'den dinamik olarak yüklenir. Ayrıca, bir tarayıcıda çalışmış olan her şeyle geriye dönük uyumluluğu korumanın saçma karmaşıklığı olmadan HTML'nin yeni sürümlerini de yayınlayabiliriz - uyumluluk sayfa yazarının sorumluluğundadır. Ayrıca HTML dışındaki biçimlendirme dillerini de deneriz. Ve elbette, motorlara süslü JIT derleyicileri yazabiliriz, böylece web sayfalarınızı istediğiniz herhangi bir dilde yazabilirsiniz.


Şaka yaptığını söyleyemem, ama senin fikrin gerçekten çok havalı.
Milind R

3

Javascript dışında herhangi bir dili olası komut dili olarak memnuniyetle karşılarım.

Güzel olacak Javascript sonra diğer dilleri kullanmaktır. Java muhtemelen etiket arasında çok uygun olmaz, ancak Haskell, Clojure, Scala, Ruby, Groovy gibi diller yararlı olacaktır.

Bir süre önce bir Rubyscript'i geldim ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby ve http://code.google.com/p/ruby- tarayıcıda /
Hala deneysel ve devam ediyor, ancak umut verici görünüyor.
Net için yeni buldum: http://www.silverlight.net/learn/dynamic-languages/ Sadece siteyi buldum, ama ilginç de görünüyor. Apple Mac'imden bile çalışıyor .

Yukarıdakilerin Javascript için bir alternatif sağlamada ne kadar iyi olduğunu bilmiyorum, ancak ilk bakışta oldukça havalı görünüyor. Potansiyel olarak bu, herhangi bir Java veya .Net çerçevesini tarayıcıdan yerel olarak - tarayıcının sanal alanı içinde kullanmanıza izin verir.

Güvenliğe gelince, dil JVM'nin (veya bu konu için .Net motorunun) içinde çalışıyorsa, VM güvenlikle ilgilenecektir, bu yüzden endişelenmemize gerek yok - en azından daha fazla değil çalışan bir şey için yapmalıyız tarayıcı içinde.


2

Muhtemelen, ancak bunu yapmak için büyük tarayıcıları desteklememiz gerekir. IE desteği almak en zor olurdu. JavaScript kullanılabilir olduğu için güvenebileceğiniz tek şey olduğu için kullanılır.


2

ECMAScript et. Hakkında konuştuğum geliştiricilerin büyük çoğunluğu. ark. Sorunun komut dosyası dili olmadığını, ortaya çıkardığı saçma HTML DOM olduğunu kabul edin. DOM ve komut dosyası dilini kapatmak ECMAScript ile ilgili yaygın bir acı ve hayal kırıklığı kaynağıdır. Ayrıca unutmayın, IIS sunucu tarafı komut dosyaları için JScript kullanabilir ve Rhino gibi şeyler ECMAScript'te bağımsız uygulamalar oluşturmanıza izin verir. Bir süre ECMAScript ile bu ortamlardan birinde çalışmayı deneyin ve görüşünüzün değişip değişmediğine bakın.

Bu tür bir umutsuzluk bir süredir ortalıkta. Belirli sorunları içermek veya yeniden yayınlamak için bunu düzenlemenizi öneririm. Aldığınız rahatlamanın bir kısmı hoş bir sürpriz olabilir.

Eski bir site, ama yine de başlamak için harika bir yer: Douglas Crockford'un sitesi .


"HTML DOM" neden ağrı noktası hakkında daha fazla duymak merak ediyorum
Alex Moore-Niemi

2

Zaten VBScript var, değil mi? Bekle, sadece IE destekliyor!
VM hakkındaki güzel fikirleriniz için de aynı şey geçerli. Sayfamı Lua kullanarak komut dosyası yazarsam ve tarayıcınızda onu bayt koduna dönüştürecek ayrıştırıcı yoksa ne olur? Tabii ki, bir bayt kodu dosyasını kabul eden bir komut dosyası etiketini hayal edebiliyoruz, bu bile oldukça etkili olurdu.
Ancak deneyimler, Web'e yeni bir şey getirmenin zor olduğunu gösteriyor: böyle radikal bir değişikliği benimsemek yıllar alacaktı. Kaç tarayıcı SVG veya CSS3'ü destekliyor?

Yanında, ben JS'de "kirli" ne bulmak görmüyorum. Amatörler tarafından kodlanması çirkin olabilir, başka bir yerde kopyalanan kötü uygulamaları yayar, ancak ustalar bunun da zarif bir dil olabileceğini gösterdi. Biraz Perl'e benziyor: genellikle gizlenmiş bir dile benziyor, ancak mükemmel bir şekilde okunabilir hale getirilebilir.


2

Bunu kontrol edin http://www.visitmix.com/Labs/Gestalt/ - kullanıcı silverlight yüklü olduğu sürece python veya ruby ​​kullanmanıza izin verir.


"kullanıcı silverlight yüklü olduğu sürece." bu konuda bir kusur görüyorum.
Origamiguy

Dürüst olmak gerekirse, bunu yapmak Ruby'nin ie6 / 7/8/9 / ff / chrome / safari'ye gömülmesinden daha kolaydır. Heck Chrome zaten flaş içeriyor, neden SL olmasın!
mcintyre321

2

Bu çok iyi bir soru.

JS'de daha büyük programlar geliştirmek için iyi ücretsiz IDE'lerin olmaması nedeniyle sadece JS'de sorun değil. Özgür olan sadece bir tanesini biliyorum: Tutulma. Diğeri ise Microsoft'un Visual Studio'sudur, ancak ücretsiz değildir.

Neden ücretsiz olsun ki? Web tarayıcı satıcıları masaüstü uygulamalarını çevrimiçi uygulamalarla (ve istedikleri) değiştirmek istiyorsa, bize, programcılara, iyi geliştirici araçlarına vermek zorundalar. Basit bir metin düzenleyici, JSLint ve yerleşik Google Chrome hata ayıklayıcısını kullanarak 50.000 satır JavaScript oluşturamazsınız. Eğer bir maoşist değilseniz.

Borland 1987'de Turbo Pascal 4.0 için bir IDE yaptığında, programlamada bir devrimdi. O günden bu yana 24 yıl geçti. Utanç verici bir şekilde, 2011 yılında birçok programcı hala kod tamamlama, sözdizimi denetimi ve uygun hata ayıklayıcıları kullanmıyor. Muhtemelen çok az iyi IDE olduğu için.

Windows, Linux, MacOS, iOS, Symbian vb. İle savaşabilecekleri uygulamalar geliştirmemizi isterse, programcılar için uygun (ÜCRETSİZ) araçlar yapmak web tarayıcısı sağlayıcılarının yararınadır.


Görsel stüdyo ücretsizdir ve ayrıca kod, Atom ve diğer büyük IDE'leriniz var, sanırım yeterince sert
görünmüyorsunuz

1

Gerçekçi olarak, Javascript, herhangi bir tarayıcının uzun süre kullanacağı tek dildir, bu nedenle diğer dilleri kullanmak çok güzel olsa da, bunun olduğunu göremiyorum.

Bahsettiğiniz bu "standart VM" çok büyük olacaktır ve tüm büyük tarayıcılar tarafından benimsenmesi gerekecektir ve çoğu site, web sitelerine diğer tarayıcılardan daha uygun olduğu için yine de kullanmaya devam edecektir.

Bu sanal makinedeki her programlama dilini korumalı hale getirmeniz ve her dilin sisteme erişim miktarını azaltmanız, dillerde çok fazla değişiklik yapılması ve birçok özelliğin kaldırılması veya yeniden uygulanması gerekir. Oysa Javascript zaten bunu akılda tutuyor ve uzun bir süredir.



1

Bir anlamda, Java bayt kodu gibi daha genel bir şey yerine tarayıcıda Javascript gibi daha etkileyici bir dile sahip olmak daha açık bir web anlamına geliyordu.


0

Bence bu o kadar kolay değil mesele . JS ile sıkışıp kaldığımızı söyleyebiliriz, ancak jQuery, Prototype, scriptaculous, MooTools ve tüm harika kütüphanelerde gerçekten çok mu kötü?

Unutma, JS hafif modern tarayıcılarda kullanılan yeni Javascript motorları olan V8, TraceMonkey, SquirrelFish ile daha .

Ayrıca kanıtlanmıştır - evet, sorunlarının olduğunu biliyoruz, ancak bunların birçoğu, erken güvenlik sorunları gibi çözüldü. Tarayıcınızın Ruby kodunu veya başka bir şeyi çalıştırmasına izin veren görüntüleme. Güvenlik sanal alanının sıfırdan yapılması gerekir. Ve biliyor musun? Python kullanıcıları zaten başarısız oldu iki kez .

Javascript, tıpkı HTML ve CSS gibi, zaman içinde gözden geçirilecek ve geliştirilecek . Süreç uzun olabilir, ancak bu dünyada her şey mümkün değildir.


Bildiğim kadarıyla JS sandbox için yapılan her güvenlik kontrolü bayt kodunda izinleri kontrol etmek gibi bir şey yapabilir (ve genellikle yapılır) ve bir grup metne bakarak bu gibi şeyleri yapmak bir bilgisayarın yapması zordur. standart JS yerine istemciye bayt kodu gönderme bunu değiştirmemelidir
GideonMax

0

"JavaScript'in şu anda birlikte çalışmak zorunda olduğumuz pragmatik sorunu anladığınızı" sanmıyorum. Aslında çok güçlü bir dildir. Java uygulamanızı yıllarca tarayıcıda kullandınız ve şimdi nerede?

Her neyse, istemcide çalışmak için "kirlenmenize" gerek yok. Örneğin, GWT'yi deneyin.


0

... Diyorsun ki...

Java ve Java uygulaması Flash ve Adobe AIR vb.

Genel olarak, herhangi bir DEA çerçevesi ihtiyaçlarınızı karşılayabilir; ancak her biri için bunu kullanmanın bir bedeli vardır (tarayıcıda ve / veya özel masaüstünden özel veya / veya daha az seçenekte çalışma süresi kullanılabilir) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

Web dışındaki herhangi bir dil ile Web geliştirmek için GWT: Java geliştirin, Javascript'e derleyin


1
Bu nedenle, bir sanal makineyi standart hale getirme önerisi her yerde bulunur. JavaScript'i "web için makine dili" olarak kullanmak inanılmaz derecede beceriksiz ve verimsiz görünüyor.
newdayrising

Yanlış anladığınızı düşünüyorum, orijinal poster tarayıcıların diğer dilleri desteklemesi gerektiğini değil, java'yı js'ye derlemek yerine java'yı bir VM'ye derleyeceğinizi önermektedir.
GideonMax

0

Zaten hepsinde bayt kodu yorumlayıcıları olan VM'ler var ve bayt kodu da farklı. {Çakra (IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera (Carakan).

Maalesef, Chrome'un (V8) IA32 makine kodunu derlediğini düşünüyorum.


0

tüm tarayıcıların zaten bir VM kullandığını düşünürsek, web için bir VM dili oluşturmanın zor olacağını düşünmüyorum.
Bence birkaç nedenden dolayı çok yardımcı olacağını düşünüyorum:
1. sunucu kodu derlediğinden, gönderilen veri miktarı daha küçüktür ve istemci kodu derleme üzerinde zaman bel değildir.
2. Sunucu hazırlanırken kodu derleyip saklayabildiğinden, JS'yi kısa sürede derlemeye çalışan istemcinin aksine, daha iyi kod optimizasyonları yapabilir.
3. bir dili bayt koduna derlemek JS'ye aktarmaktan çok daha kolaydır.

son not olarak (birisinin başka bir yorumda daha önce söylediği gibi), HTML ve CSS daha basit bir dile derlenir, bayt kodu olarak sayıldığından emin değildir, ancak derlenmiş html ve css'yi sunucudan istemciye gönderebilirsiniz. ayrıştırma ve getirme sürelerini azaltma


-1

IMO, JavaScript, dil, sorun değil. JavaScript aslında oldukça etkileyici ve güçlü bir dildir. Sanırım kötü bir temsilci var çünkü klasik OO özellikleri yok, ama benim için prototip olukla ne kadar çok gidersem, o kadar çok hoşuma gider.

Gördüğüm sorun, web'de desteklemeye zorlandığımız birçok tarayıcıdaki lapa lapa ve tutarsız uygulamalar. JQuery gibi JavaScript kütüphaneleri, bu kirli hissi hafifletmek için uzun bir yol kat ediyor.

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.