Dlaczego nie ma innych języków skryptowych po stronie klienta dla stron internetowych? [Zamknięte]

35

Dlaczego obecnie jest dostępna obsługa JavaScript i niektórych VBScript w przeglądarkach? Wiem, że JavaScript jest dobry, ale czy opcja użycia innego języka programowania nie pomogłaby w promowaniu różnych stylów programowania?

web-development javascript browser

— Eric Packwood
źródło

1

Zobacz to pytanie na temat Przepełnienia stosu: stackoverflow.com/questions/2872037/…

— Corey

1

Twoje pytanie dotyczy właśnie tego, dlaczego Google stworzył GWT .

— jhocking

1

Uważam, że sednem interfejsu API DOM było zapewnienie obsługi wielu języków. Chodzi o to, że JS jest naprawdę dobrze przystosowana do tego wyzwania. Normalizuje się, jakby niczyja działalność, a pierwszorzędne funkcje były ogromne w paradygmacie opartym na zdarzeniach. Tak naprawdę sprowadzało się to do tego, że nikt nie chciał pozwolić MS podjąć tej decyzji i nikt nie wymyślił lepszej niż JS. Aplety Java były naprawdę NAPRAWDĘ kiepskie.

— Erik Reppen

33

Nie ma potrzeby dodawania suportu dla wielu języków, rozwiązaniem byłoby ujednolicenie ogólnego kodu bajtowego, który mógłby być stosowany przez implementatory języków. Ale obecnie nie ma na to żadnych planów (zostało to zasugerowane).

Języki można również zaimplementować oprócz Javascript. JavaScript jest na tyle dobry, że można na nim zaimplementować inne języki. I jest już wiele tego przykładów.

— nkassis
źródło

3

+1 - Za wskazanie, że JavaScript jest potężnym językiem, który może być użyty jako abstrakcja dla innych języków. Ciekawym projektem byłoby napisanie rozszerzenia Firefox, które działałoby po stronie klienta C ++ lub Java! <script type="text/cpp" src="test.cpp"></script>.

— jmort253

2

@ jmort253, spójrz na klienta natywnego.

— dan_waterworth

Natywny klient jest zdecydowanie interesujący, ale dopóki Mozilla go nie przyjmie, nie będzie żadnej trakcji. Ostatnio sprawdziłem, że nie są jeszcze gotowi na przyjęcie.

— nkassis

1

Znalazłem Gestalt ~ kilka lat temu: gestalt.codeplex.com to dobry przykład budowania innych języków skryptowych na JavaScript.

— Jim Schubert

2

Kolejny przykład: Google Web Toolkit ? Java jest skompilowana do JavaScript

— MarkJ

21

JavaScript jest de facto standardem i istnieje od 1996 roku. Bycie standardem po prostu dlatego, że nie ma konkurencji, nie jest do końca uczciwe, ale nie słyszałem dużo narzekań na to, dlaczego nie ma innego języka.

Dodanie kolejnego „standardowego” języka promuje różne zabawne małe problemy.

Jak będą działać z innymi językami?
Czy DOM będzie udostępniany?
Czy skrypty napisane w obu mogą nadal działać?
Przenoszenie bibliotek do obu

— Josh K.
źródło

8

Właściwie myślę, że JavaScript jest językiem używanym w Gecko Mozilli. W IE mamy JScript. Większość innych przeglądarek używa czegoś, co mniej więcej odpowiada specyfikacjom ECMAScript. Wszystkie te języki są dla uproszczenia nazywane „JavaScript”, podczas gdy w rzeczywistości się różnią.

— Mchl

1

Możesz mieć wiele języków, które generują ten sam kod bajtowy. Spójrz na JVM - Groovy, Java, Scala, Clojure, jRuby można bezpośrednio skompilować do kodu bajtowego JVM. W ten sposób będą dzielić ten sam interfejs API DOM i mogą być interoperacyjne. Chociaż implementacja z JavaScript VM jest wykładniczo trudniejsza, ponieważ jest interpretowana.

— David Sergey

21

Pomyśl o niespójności między przeglądarkami pod kątem obsługi samego języka JavaScript. Pomyśl teraz, jak by to było, gdyby było więcej języków.

— Michael Brown
źródło

5

Tak, już tam jest, po stronie klienta VBScript ... uugh, wzdrygam się.

— ocodo

1

+1 Myślę, że nasze głowy eksplodowałyby, gdybyśmy mieli podzbiór innych języków do zapamiętania dla każdej z głównych przeglądarek i ich wersji. Dobra odpowiedź.

— jmort253

4

Może to być podstępne, ale ... obsługa JavaScript [ECMAScript] w przeglądarkach od samego początku była bardzo spójna. To, co było niespójne, to ich implementacja DOM (i powiązanych metod). Z praktycznego (i historycznego) punktu widzenia trudno jest je rozdzielić - ponieważ jedynym prawdziwym zastosowaniem JS było manipulowanie DOM w przeglądarce - ale wraz z rozwojem JS po stronie serwera (takie jak NodeJS), w rzeczywistości stało się to dość ważnym rozróżnieniem.

— josh3736

miał napisać prawie dokładnie to jako odpowiedź, internet ma wystarczająco dużo standardów, których nie przestrzega się ani nie obsługuje. fakt, że pomieszany bałagan, który mamy, działa tak dobrze, jak to robi, jest niczym innym jak cudem.

— Ryathal,

1

Josh ma rację. To tutaj podłączasz się do pomylonego pomysłu na to, jak poszczególne rzeczy mają się renderować i być dostępne dla JS, że rzeczy stały się brzydkie, ale IE w końcu przynajmniej bierze udział w długotrwałych problemach z interfejsem API na tym froncie (chociaż nadal pozostają w tyle za najnowszymi w prawie wszystkim ze względu na fatalną decyzję MS o połączeniu przeglądarki z nawigatorem plików - jackassami).

— Erik Reppen

6

Przeglądarki muszą być znormalizowane, aby wszystko, co tworzysz, działało wszędzie, we wszystkich przeglądarkach.

Jeśli masz wiele języków, musisz upewnić się, że wszystkie działają bardzo podobnie. Jeśli jesteś programistą i masz wybór języków, które mogą, ale nie muszą być obsługiwane w niektórych lokalizacjach, oznacza to dodatkowy ból głowy.

JavaScript jest bardzo elastycznym językiem, jest konieczny, funkcjonalny, może być OOP (po modzie z prototypami) i jest interpretowany. Teraz z przyzwoitymi silnikami, jak w Chrome, jest w stanie zrobić dobre rzeczy. Dodatkowe języki po prostu przywróciłyby tę sytuację, popatrzą tylko na VBScript, IE, a więc wszystko, co jest w nim napisane, jest powiązane z konkretną przeglądarką i platformą, koszmarem.

— Orbling
źródło

2

Ważnym punktem jest tutaj „z przyzwoitymi silnikami jak w Chrome”. Robienie czegokolwiek, nawet łagodnego opodatkowania, powoduje, że nawet IE8 zaczyna kuleć, jakby miał złamaną nogę, podczas gdy najnowsze wersje Firefoksa i Chrome od zawsze, gdy go używałem (był to powód, dla którego zmieniłem infact), pomijają bez utraty rytmu.

— Matthew Scharley,

1

@Matthew Scharley: IE jest ogólnie powolny, w rzeczywistości z każdą wersją wydaje się gorzej. Muszą podnieść poprzeczkę, bo inaczej się z tego wycofają. Jedynym powodem, dla którego IE ma jakiekolwiek wstrzymanie, jest włączenie systemu operacyjnego, teraz muszą ustawić selektor przy pierwszym użyciu, co znacznie spadło.

— Orbling

„może być OOP” ... To jest OOP! Dziedziczenie nie jest tym, co definiuje OOP. Obiekty są.

— KaptajnKold

@KaptajnKold: Zaskakujące jest to trochę debaty w środowisku akademickim. Zgadzam się, że JS jest zdolny do OOP, ponieważ ma obiekty, które jednak nie zawsze są nadmiernie wykorzystywane przez niektórych. Prototypowy system różni się znacznie od zwykłego smaku OOP, co dodatkowo usuwa go ze standardowej definicji „języka OOP”. Podobnie jak w przypadku większości języków, zależy to od tego, jak go używasz - kiedy go używam, jest to OOP.

— Orbling

3

Zamiast wbudowywać je w przeglądarki, producenci lubią budować nieporęczne wtyczki do przeglądarek - Java, Flash, Silverlight itp. Gwarantuje to spójność między platformami.

— Kirk Broadhurst
źródło

Cóż, nie chodzi tu o zapewnienie spójności między platformami, ale o kontrolę. Ponieważ kontrolujesz wtyczkę i nie musisz odpowiadać nikomu innemu.

— jhocking

W porównaniu do problemów z szybkim uruchamianiem brudnego javascript, „niezgrabne” wtyczki są znacznie lepsze. Kiedyś negatywnie odczuwałam kwestię pobierania wtyczek do przeglądarki, ale jest zdecydowanie bardziej otwarta niż „uniwersalnie zaimplementowany javascript”.

— Milind R

2

Jednym z powodów jest to, że praktycznie różni dostawcy różnych przeglądarek nie mogą nawet uzgodnić standardowej implementacji Javascript, a Javascript istnieje już od zawsze, przynajmniej z perspektywy języka WWW. Dlatego większość ludzi słusznie uważa, że wprowadzenie innego języka po stronie klienta do ekosystemu i zapewnienie wszystkim dostawcom wsparcia, jest praktycznie niemożliwe, a większość ludzi, którzy mogliby to zrobić, jest już zaangażowana w problemy ze standaryzacją Javascript, które moim zdaniem są znacznie lepsze wykorzystanie ich czasu.

— davidk01
źródło

Prawie to, co chciałem powiedzieć. Ważną (w tej dyskusji) różnicą między językiem po stronie klienta a językiem po stronie serwera jest to, że przeglądarki muszą implementować język po stronie klienta.

— jhocking

2

Istnieje kilka odpowiedzi, które twierdzą, że obsługa wielu języków sprawiłaby, że twórcy przeglądarek internetowych bardzo obrzydliwie upewnili się, że są zgodni ze wszystkimi językami. Wydaje mi się to nieprawidłowe.

Na przykład Java jest niezwykle dobrze zdefiniowanym standardem. Zasadniczo wszystko, co musisz zrobić, to ujawnić DOM przeglądarki jako API Java i uruchomić wirtualną maszynę Java (JVM) w przeglądarce internetowej. Można określić, że kod skryptowy będzie musiał być dostarczony w postaci skompilowanych i podpisanych plików JAR lub w postaci kodu źródłowego JavaScript. Jeśli przeglądarka napotka JavaScript, może albo uruchomić go przez dedykowanego interpretera (jak ma to miejsce dzisiaj), albo przez Rhino na JVM. Jeśli napotka pliki jar, tworzy nowy moduł ładujący i piaskownicę bezpieczeństwa, ładuje kod bajtowy Java do pamięci i wykonuje go. Byłoby to całkowicie wstecznie kompatybilne z istniejącymi stronami internetowymi i pozwoliłoby przeglądarce, jednym pociągnięciem, obsługiwać dziesiątki języków, które działają w JVM.

Inne zalety:

JVM skorzystał z dekady ulepszeń wydajności. Jest teraz bardzo szybki, stabilny i dojrzały. Założę się, że zobaczysz znaczną poprawę wydajności w stosunku do interpretowanego javascript.
W miarę jak aplikacje po stronie klienta stają się coraz większe i bardziej złożone, zwiększają się zalety ustrukturyzowanych języków pisanych na maszynie, takich jak Java i Scala.
Miałbyś dostęp do prawdziwej wielowątkowości, a za pośrednictwem Scali biblioteka kolekcji zoptymalizowana pod kątem przetwarzania wielordzeniowego.
Możesz użyć dowolnej z tysięcy bibliotek Java typu open source w przeglądarce.
Dzięki bibliotekom takim jak openGL przeglądarka może zapewnić dostęp do zaawansowanych możliwości obliczeniowych grafiki i kart graficznych.
Jeśli miałeś uruchomioną Javę po stronie klienta i serwera, możesz dodatkowo skorzystać z komunikacji klient-serwer poprzez bardzo skompresowaną, binarną serializację obiektów-grafów = szybsze ładowanie i wykonywanie stron internetowych.

— Patrick Arnesen
źródło

1

Możesz już uruchomić kod JVM. Nazywa się to apletem Java

— Raynos

1

Wierzę, że JavaScript zyska jeszcze większą popularność jako standardowy język dla sieci. Obserwujemy wzrost JavaScript po stronie serwera. Oto kilka przykładów implementacji tego potężnego języka na serwerze:

Serwer WWW POW SJS - JavaScript po stronie serwera dla serwera WWW POW, który działa jako rozszerzenie przeglądarki Firefox lub jako aplikacja XULRunner. SJS odgrywa podobną rolę jak PHP w Apache, ponieważ może łączyć się z bazami danych i generować treści po stronie klienta.
NodeJS - JavaScript po stronie serwera, który wykorzystuje model oparty na zdarzeniach. Jest zbudowany przy użyciu silnika JavaScript V8 Google . NodeJS jest reklamowany jako narzędzie do tworzenia skalowalnych programów sieciowych. Serwer WWW „Hello World” można napisać tylko w 6 krótkich liniach!
Jaxer - serwer JavaScript, który interpretuje wszystkie bloki skryptów runat="server"jako JavaScript po stronie serwera. Całe aplikacje internetowe można pisać w JavaScript.
Rhino - JavaScript dla Java - Mozilla stworzyła tę implementację JavaScript po stronie serwera, która działa na Javie. Jest to zasadniczo podobna koncepcja do Querces PHP dla Java , Jython, JRuby i wielu innych abstrakcji innych języków, które działają na JVM. Rhino jest zwykle używane do osadzania JavaScriptu w Javie w celu zapewnienia narzędzi skryptowych dla użytkowników końcowych, ale może być również używane do przenoszenia kodu po stronie klienta na serwer bez konieczności przepisywania logiki biznesowej w innym języku!
JQuery Claypool - framework JavaScript po stronie serwera wykorzystujący moc JQuery na serwerze. Bardzo fajny! Został opracowany przy użyciu implementacji JavaScript po stronie serwera EnvJs w przeglądarce.
EnvJs - bezgłowa przeglądarka zbudowana na Rhino.

Wiele z tych implementacji i struktur pokazuje, że JavaScript staje się tak potężną siłą w rozwoju sieci, że liderzy społeczności już zaczęli przenosić JavaScript na serwer. JavaScript jest niezwykle potężnym funkcjonalnym językiem programowania, a wraz z upływem czasu wydaje mi się, że będzie ewoluował.

Podsumowując, wydaje się sprzecznością przenosić inne języki do przeglądarki, gdy zamiast tego możemy przenieść ten jeden język przeglądarki na serwer i wypełnić tę lukę w bardziej jednolity sposób.

— jmort253
źródło

+1 za wskazanie, że JavaScript nie ogranicza się do przeglądarki

— Gary Rowe

1

Istnieje kilka przykładów narzędzi, które będą kompilować inne języki dla javascript, w tym Haskel, Lisp i Python (prawdopodobnie inne). Jeśli więc chcesz pracować w jednym z tych języków, możesz to zrobić.

I myślę, że jeden z moich profesorów z uniwersytetu napisał implementację programu w JavaScript. Więc jeśli lubisz schemat, możesz to zrobić.

— Zachary K.
źródło

0

Ludzie pracowali nad brakiem wbudowanej różnorodności na dwa sposoby: używając wtyczek, takich jak aplety Flash lub Java, i budując warstwy, które używają javascript jako swojego „kodu maszynowego”, takiego jak jquery lub Google Toolkit. Gdyby istniał nowy styl rozwoju, który byłby wystarczająco popularny, ludzie mogliby znaleźć sposób, aby go wprowadzić.

Pamiętaj, że jeśli utworzysz środowisko uruchomieniowe .net w javascript i stanie się ono popularne, niektóre kręgi będą przeklinać twoje imię w Internecie na zawsze.

— Karl Bielefeldt
źródło

Obwiniaj formularze internetowe i IE. Mógłbyś sikać twórcom interfejsu WWW mniej, dźgając ich gorącymi pokerami. Nie dobre dla skojarzenia marki.

— Erik Reppen