Czy kiedykolwiek będę w stanie kodować kod przeglądarki po stronie klienta w wybranym języku? [Zamknięte]

15

Zamknięte . To pytanie jest oparte na opiniach . Obecnie nie przyjmuje odpowiedzi.

Chcesz poprawić to pytanie? Zaktualizuj pytanie, aby można było na nie odpowiedzieć faktami i cytatami, edytując ten post .

Zamknięte 6 lat temu .

Będę brutalnie szczery: nienawidzę pisania kodu po stronie klienta w JavaScript. Mówiąc krótko, nie jestem fanem tego języka.

Wydaje mi się głupie, że przeglądarki obsługują język programowania , a nie pośrednią maszynę wirtualną (taką jak CIL lub JVM). Ten ostatni pozwoliłby programistom pisać w wybranym przez siebie języku (do pewnego stopnia), a nie w jednym ustalonym języku. Ten język może ewoluować szybciej, ponieważ tylko zmiany w CIL / JVM / cokolwiek wymagałyby aktualizacji każdej głównej przeglądarki. Funkcje językowe można dodać bez wpływu na starą obsługę przeglądarki.

Ogromne oszczędności wysiłku, jakie powodują pośrednie języki, są dobrze znane . Czy istnieją jakieś inicjatywy promujące „skrypty” przeglądarki w czymś innym niż JavaScript, a zwłaszcza w już zaprojektowanej, opracowanej i zoptymalizowanej maszynie wirtualnej? Czy mają jakiś impet?

programming-languages browser

— Roman Starkov
źródło

zobacz także: Dlaczego nie ma innych języków skryptowych po stronie klienta dla witryn internetowych?

— komar

11

Aby odpowiedzieć na twoje pytanie, tak, podejmowane są wysiłki, aby przestać używać Javascript na rzecz bardziej spójnego języka dla skryptów internetowych. Google kładzie duży nacisk na ich język Dart . Dart ma własną maszynę wirtualną, która jest już wbudowana w Chrome, ale nie jestem pewien, czy inne przeglądarki ją jeszcze przyjęły. Istnieje również dość obiecujący język o nazwie CoffeeScript .

Istnieje również bardzo ambitnie wyglądający projekt o nazwie HaXe, którego celem jest ujednolicenie całego szeregu platform programistycznych w jednym języku.

Uwierz mi, że nie lubisz Javascriptów, ale obawiam się, że wkrótce to nigdzie nie nastąpi - w rzeczywistości wydaje się, że zyskuje dużo rozpędu w aplikacjach Windows 8 HTML5 / JS itp., Ale alternatywy takie jak te, które ja wspomniane zaczynają wyrastać :)

— MattDavey
źródło

9

Ujednolicenie wszystkiego w jednym języku jest dokładnie odwrotnością tego, co jest pożądane. To pozostawia tylko taką samą sytuację jak teraz, tylko z innym językiem zamiast JavaScript. Chodzi o to, że należy kontynuować istniejące wysiłki: IL / CLR jest dobrze ugruntowany, ma już wysokowydajne JITtery dla większości platform, a kilka kompilatorów kompiluje już w nim kilka języków. Aby wprowadzić Internet w XXI wiek, przeglądarki muszą z niego skorzystać, zamiast ciągle próbować upiec własne rzeczy i zaczynać od zera.

— Timwi

3

@ Timwi, CIL jest zbyt ciężki i jest w nim zbyt wiele biurokracji. Nie ma sensu dołączanie pełnego, rozdętego pliku kodu bajtowego z dedykowaną klasą i wszystkimi nieporęcznymi metadanymi do każdej onSomethingprocedury obsługi zdarzeń - parsowanie i interpretacja 10-20 znaków prostego języka skryptowego jest znacznie bardziej wydajna.

— SK-logic,

1

@ SK-logic: Wygląda na to, że masz całkowicie błędny obraz CIL i kodu bajtowego w ogóle. Nie mam pojęcia, co mogłoby sprawić, że myślisz, że binarne metadane są „nieporęczne” w porównaniu do składni wysokiego poziomu, takiej jak JavaScript. Przede wszystkim nie mam pojęcia, dlaczego „każdy moduł obsługi zdarzeń onSomething”. Programy w języku C # najwyraźniej nie kompilują się w wiele zestawów dla każdego modułu obsługi zdarzeń.

— Timwi

1

@ Timwi, jem ECMA-335 na śniadanie, więc zbyt dobrze wiem, jak nieporęczny jest CIL. Węzły DOM są często generowane dynamicznie. Nie ma możliwości dodania czegoś do istniejącego modułu w CIL - musisz zdefiniować nowy moduł. I nie możesz dodawać do klasy - musisz zdefiniować nową klasę (z dołączonymi nieporęcznymi metadanymi). I po prostu porównaj koszt czytania, JIT i wykonania CIL z parsowaniem, wykonywaniem i natychmiastowym odrzucaniem małego ciągu tekstowego. Istnieje wiele przypadków, w których interpretacja ad hoc jest znacznie wydajniejsza niż jakakolwiek kompilacja.

— SK-logic

2

@ Timwi, proponujesz użyć kodu bajtowego jako wspólnego mianownika i formatu komunikacji, prawda? Chodzi mi o to, że obecna specyfikacja CIL jest prawie bezużyteczna. ExpandoObject nie ma znaczenia. Twój pogląd na złożoność analizy jest niejasny. Moduł CIL zawiera własną tabelę referencyjną zestawu, tabelę tokenów metadanych, a dopiero potem klasy i metody. Porównaj wysiłek włożony w czytanie i JIT wszystkich tych nieporęcznych rzeczy z interpretacją ciągu trywialnego języka wysokiego poziomu. Koszt analizy wynosi tutaj prawie zero. Po prostu wypróbuj oba podejścia i porównaj się.

— SK-logic

5

Sam Javascript może być postrzegany jako język pośredni, definiujący maszynę wirtualną, na którą można kompilować inne języki. W projektach takich jak GWT pojęcie to już się rozwija. To może nie być to, co zaprojektujesz od zera, ale już staje się faktem, że możesz skompilować „swój ulubiony język” w JavaScript.

— John Snelson
źródło

5

Zasadniczo nie. Utknąłeś w Javascript.

Powiedziawszy to, w przeszłości podejmowano wysiłki, aby wprowadzić na rynek inne języki (aplety Java, vbscript itp.). Każdy z nich nigdy tak naprawdę nie zyskał przewagi, jaką ma javascript, ponieważ javascript jest zintegrowany .

Jedynym sposobem na zbudowanie tego, o czym mówisz, byłoby stworzenie języka skryptowego działającego na maszynie wirtualnej, skompilowanego po stronie klienta, a następnie uruchomionego. Następnie każda przeglądarka musiałaby zaimplementować maszynę wirtualną we własnej bazie kodu, aby cały kod działał na wszystkich przeglądarkach. Następnie musisz upewnić się, że istnieją jakieś standardy, aby wszystkie przeglądarki wykonywały polecenia w ten sam sposób. Oczywiście, ponieważ przeglądarki są tworzone niezależnie, prawdopodobnie pojawią się dziwactwa, o których twórcy będą musieli pamiętać.

Ale teraz właśnie opisaliśmy Javascript.

Ostatecznie twoje wybory to:

przyzwyczaić się do Javascript
spróbuj użyć języka kompilującego się do Javascript. (Pamiętaj, że nadal będziesz chciał zweryfikować JavaScript, co powoduje powrót do opcji 1).
użyj języka istniejącego jako wtyczka do przeglądarki, takiego jak ActionScript (Flash), ActiveX, aplet Java, .Net (SilverLight). Pozwala to uniknąć problemu z wieloma dostawcami / implementacjami języka, ale nie integruje języka.

Zasadniczo, jeśli chcesz zintegrowanego języka, utkniesz w JavaScript.

— Richard
źródło

2

Innym wyborem byłoby użycie języka, który kompiluje się w javascript i użyć tego.

— Jetti,

@Jetti Czy myślisz o tym CoffeeScript ? To motto - jak to nazywają „Złota reguła” - „To tylko Javascript” . Ale jeśli piszesz coś, co zasadniczo jest JavaScript, czy tak naprawdę nie piszesz Javascript? To tak, jakby argumentować, że jQuery nie jest javascript, ponieważ jest czystszy i łatwiejszy w użyciu.

— Richard

2

spójrz na tę listę języków, które kompilują się w javascript

— Jetti

@Jetti Może wszystko by się udało. Ale z dziwactwem wsparcia dla różnych przeglądarek, denerwowałbym się poleceniem któregokolwiek z nich i nie weryfikowaniem faktycznie wygenerowanego javascript.

— Richard

1

Tyle że javascript jest całkowicie okropnym językiem pośrednim i bardzo trudnym do konsekwentnego wykonywania.

— Milind R.

4

W rzeczywistości nie nienawidzisz javascript, jak opisano w standardach Ecma, ale nienawidzisz okropnej implementacji w różnych przeglądarkach , z ich dziwactwami, błędami i wtfs. JavaScript po stronie serwera jest naprawdę przyjemny. Również model DOM jest przyczyną 80% bólu po stronie javascript po stronie klienta.

Jeśli nadal chcesz używać innego języka, możesz użyć GWT , który w zasadzie pozwala napisać Javę, a następnie skompilować w (brzydkim) javascript lub CoffeeScript , który jest syntaktycznym cukrem nad JS, który kompiluje się w JS.

— Clement Herreman
źródło

9

Nie mogę mówić za romkyns, ale ja nienawidzę samego JavaScript ( w uzupełnieniu do problemów, o których mowa). Nie jest zorientowany obiektowo, nie ma pisania statycznego, nie ma użytecznej obsługi błędów i nie ma użytecznych ram nowoczesnej funkcjonalności. Jest to również niespójne i nieporęczne. Nawiasem mówiąc, najbardziej znienawidzona funkcja JS, wstawianie średników, jest w standardzie ECMA.

— Timwi

1

@ Timwi, jest oparty na funkcjach i możesz napisać kod OO, jeśli chcesz. Pisanie statyczne jest fajne, ale jeśli kod jest dobrze napisany (małe funkcje, prawidłowe określanie zakresu), rzadko stanowi to problem. Jeśli chodzi o wstawianie średników, uważam, że jest to lekka irytacja. Tylko raz mnie ugryzł, ponieważ miałem powrót i otwarcie {obiektu na różnych liniach. Jakiego „szkieletu nowoczesnej funkcjonalności” brakuje?

— CaffGeek

2

Sam JavaScript nie jest najlepszym językiem (grzecznie mówiąc). Nie dbam o rzeczy zorientowane obiektowo (im mniej - tym lepiej), o jego dynamiczny system typów (niestety jest on naprawdę potrzebny w tego rodzaju języku skryptowym), ale obecność instrukcji i brak właściwego listy i krotki są denerwujące. Zarówno do pisania w JavaScript, jak i do implementacji kompilatorów ukierunkowanych na JavaScript.

— SK-logic,

2

@Timwi: nie postrzegasz zorientowanych na objet jako złą rzecz, chociaż nie zawsze tak jest. Nie postrzegaj OOP jako srebrnej kuli paradygmatów rozwoju. Świetne jest także funkcjonalne podejście, takie jak JS lub Scala. Możesz mieć OOP w JS, ale główna różnica polega na tym, że jest to programowanie prototypowe, a nie programowanie klasowe. OOP to szeroka nazwa, która nie ogranicza się do Java / C #. Oparty na prototypach różni się od opartych na klasach i jest dobrze wykorzystywany, jest tak potężny jak oparty na klasach.

— Clement Herreman,

2

@ClementHerreman: JavaScript nie jest ograniczony do strony klienta, ale ta dyskusja dotyczy strony klienta. JavaScript jest ograniczony do opartego na prototypach, co jest wadą w porównaniu z IL, która pozwoliłaby na użycie praktycznie dowolnego języka.

— Timwi

2

To pytanie pojawia się od czasu do czasu.

Dlaczego nie mamy innych języków w tagach skryptowych zamiast tylko Javascript

Wcześniej IE wprowadziło VB jako alternatywę dla Javascript. Myślę, że już widzisz, jak to doprowadziłoby do piekła standardów, gdyby złapało ...

Dlaczego więc nie wspólny standardowy język pośredni?

Jest stary podcast Brendana Eicha wyjaśniający, dlaczego nie widzi pośredniego języka kodu bajtowego w najbliższej przyszłości:

http://www.aminutewithbrendan.com/pages/20101122

http://news.ycombinator.com/item?id=1893686

Podstawowym problemem jest to, że podczas gdy język pośredni (jak bajty CIL i JVM) stara się być ogólny, przez większość czasu okazuje się, że jest zbyt niski i zbytnio powiązany z oryginalnymi językami wysokiego poziomu, które się do niego skompilowały. Na przykład tak naprawdę nie można zaimplementować funkcji rekurencyjnych tail w JVM - jakie inne funkcje języka lub opcje implementacji nie będą w stanie zaimplementować, jeśli zbyt wcześnie połączymy się z niskim poziomem abstrakcji kodu bajtowego?

Tymczasem Javascript jest elastycznym językiem wysokiego poziomu z wprowadzoną semantyką i wieloma, różnymi, wydajnymi implementacjami. W przyszłości możemy zobaczyć sam Javascript jako język pośredni - niestety jest to nieco niedojrzałe i niewiele języków kompiluje się do JS na dzień dzisiejszy.

— hugomg
źródło

Ale ten argument dotyczy JavaScript tak samo, jak dotyczy JVM i CIL, prawda? :) Jedyne, co dzieje się w JavaScript, to fakt, że jest już obsługiwany przez wszystkie przeglądarki.

— Roman Starkov,

Chodzi o to bardziej subtelnie - JavaScript jest opisany na wyższym poziomie niż większość języków pośrednich, więc implementacje mają więcej miejsca na nogi w wyborze, co robić. (Oczywiście to nie wszystko morze róż - chciałem tylko zaznaczyć, że nie jesteśmy pierwszymi, którzy myślą o IL dla Internetu i że nie jest to takie proste)

— hugomg

1

Tak. Możesz już skompilować Dart, Coffeescript i Java do Javascript. Masz Emscripten, który jest backendem kompilatora dla LLVM do generowania kodu bajtowego Javascript (i LLVM obsługuje chyba kilka języków).

Ale oprócz kompilacji do JS, nie w krótkim czasie. IE6 ma 10 lat i wciąż się rozwija. Mam nadzieję, że obecne przeglądarki (które nie obsługują innych języków) nie przetrwają tak długo, ale będą dostępne jeszcze przez kilka lat, wywołując cykl „ogryzania ogonów” „nadal musimy obsługiwać przeglądarki obsługujące tylko Javascript, więc musimy używać Javascript ”w znacznie trudniejszy sposób niż powiedzieć CSS3 - Twoja strona może działać bez CSS3, ale spróbuj sprawić, by działała bez skryptów po stronie klienta.

— alex
źródło

0

Może masz szczęście. To jest akapit otwierający przesłanie na forum webkit-dev:

Wiele języków kompiluje się dziś w JavaScript, aby działać w Internecie. Alternatywnie, eksperymentowaliśmy z włączaniem różnych środowisk wykonawczych w WebKit do uruchamiania na stronach internetowych wraz z JavaScript ...

Można zobaczyć resztę wiadomości tutaj .

— pgfearo
źródło

0

JavaScript jest duszą przeglądarek, dlatego większość nowych prób generuje JavaScript (CoffeeScript jest tego wyraźnym przykładem).
W GWT kodujesz logikę po stronie klienta w języku programowania Java, a zestaw narzędzi z generuje JavaScript.

ClojureScript to ciekawy projekt, jeśli używasz kodowania Lisp.

Wygląda więc bez względu na wszystko, JavaScript zostanie tutaj. (COBOL sieci może?).

— Chiron
źródło

0

„Każdy klient może pomalować samochód na dowolny kolor, pod warunkiem, że jest czarny”. -- Henry Ford

Istnieje już wiele kompilatorów, które atakują javascript, i możesz wybrać dowolny język, który kompiluje javascript.

Twój link omawiający wartość języków pośrednich omawia je w kontekście wdrażania pakietu kompilatora, a nie dostarczania kodu, który zostanie wysłany przez sieć i uruchomiony na komputerze klienckim. JavaScript może nie być najlepszym formatem do tego celu, ale cokolwiek to jest, nie będzie przypominał kodów bajtowych CIL ani java.

Jeśli nie znosisz javascript, sugeruję przejście do przestrzeni Embedded, Scientific lub programowania gier, gdzie C, Fortran i C ++ rządzą gniazdem. Linia aplikacji biznesowych bardzo przenosi się do Internetu, a to oznacza więcej Javascript, nie mniej.

— Sean McMillan
źródło