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?
źródło
Odpowiedzi:
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ć :)
źródło
onSomething
procedury obsługi zdarzeń - parsowanie i interpretacja 10-20 znaków prostego języka skryptowego jest znacznie bardziej wydajna.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.
źródło
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:
Zasadniczo, jeśli chcesz zintegrowanego języka, utkniesz w JavaScript.
źródło
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.
źródło
{
obiektu na różnych liniach. Jakiego „szkieletu nowoczesnej funkcjonalności” brakuje?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.
źródło
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.
źródło
Może masz szczęście. To jest akapit otwierający przesłanie na forum webkit-dev:
Można zobaczyć resztę wiadomości tutaj .
źródło
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?).
źródło
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.
źródło