Czy praktyczna byłaby statycznie wpisana alternatywa dla JavaScript na stronach internetowych?

Preferowanie dynamicznego i statycznego pisania jest w dużej mierze kwestią gustu, a różni ludzie uważają, że są mniej lub bardziej odpowiednie w różnych sytuacjach.

Moje pytanie brzmi: czy technicznie możliwe byłoby posiadanie statycznie wpisanej alternatywy dla JavaScript do rozszerzania strony internetowej po stronie klienta itp.?

Z pewnością nie ma technicznego powodu, aby coś takiego nie istniało. Nie ma nic szczególnego w kodzie po stronie klienta, który nakazuje stosowanie dynamicznie pisanych języków.

Ponieważ jest bardzo mało prawdopodobne, że inny język znajdzie szerokie zastosowanie, najlepszym rozwiązaniem byłoby utworzenie statycznie typowanej wersji JavaScript (tj. Języka zbliżonego do java) i preprocesora, który konwertuje to na normalny JavaScript.

Na przykład skrypt wygląda następująco:

<script type="text/staticjavascript">
   String foobar(int foo, String bar) {
      String result="";
      for (int i=0; i<foo; i++) {
         result += bar;
      }
      return result;
   }
</script>

a preprocesor sprawdza, czy każda zmienna, funkcja, obiekt itp. jest używany poprawnie zgodnie ze swoim typem, i zmienia skrypt na

<script type="text/javascript">
   function foobar(foo, bar) {
      var result="";
      for (var i=0; i<foo; i++) {
         result += bar;
      }
      return result;
   }
</script>

które każda przeglądarka może obsłużyć.

Moje pytanie brzmi: czy technicznie możliwe byłoby posiadanie statycznie wpisanej alternatywy dla JavaScript do rozszerzania strony internetowej po stronie klienta itp.?

Pewnie. Google Web Toolkit kompiluje statycznie wpisane Javy do JavaScriptu ... Pomyślcie o tym: wszystko piękno i elastyczność Java, z całą wydajność maszyny generowane JavaScript!

Poważnie, możesz to zrobić dla różnych języków, a wiele próbowało (istnieją lub były kompilatory dla C i C #). To, czy wynik końcowy jest praktyczny, czy nie, zależy od tego, co próbujesz osiągnąć: Google szuka spójnej platformy do tworzenia bardzo dużych aplikacji po stronie klienta i ma własny silnik JavaScript do uruchomienia; może się okazać, że przyjęcie takiej bestii do efektów zawisu i dziwne wywołanie AJAX wprowadza znacznie więcej bólu niż po prostu nauka życia z odrobiną niepisanego kodu ...

Większość zalet języków o typie statycznym jest realizowana w czasie kompilacji. Jeśli język będzie interpretowany na kliencie, wówczas wiele z tych korzyści zostanie utraconych. Jeśli skompilujesz je na serwerze, musisz dowiedzieć się, jak je załadować i uruchomić na kliencie (pomyśl formanty ActiveX). Możesz przejść na podejście hybrydowe (skompilować do jakiejś pośredniej postaci tokenizowanej), ale w zasadzie wracasz do apletów Java.

Już istnieje.

ActionScript 3 (język skryptowy Flasha i Flexa) to dialekt ECMAScript, który implementuje silne typy, i możesz go używać w mniej więcej taki sam sposób po stronie klienta jak JavaScript (z tą różnicą, że AS3 wymaga wtyczki flash, i jest skompilowany). Obecnie osobiście staram się od niego unikać, ale jeśli jesteś w „statycznym” obozie, daj mu wir.

To odpowiada na zasadnicze pytanie, a teraz, kiedy już je mamy, drugie pytanie brzmi: „Czy Flash jest praktyczny?” Odpowiedź brzmi „tak”, z kilkoma „jeśli” i „ale”

• ... jeśli chcesz ukryć kod z jakiegokolwiek powodu.
• ... jeśli chcesz mieć bardzo, bardzo (wcześniejszy poziom jQuery) wysoki poziom interaktywności
• ... ale nawet bez HTML5, kompatybilność między przeglądarkami staje się ostatnio znacznie lepsza.
• ... ale wkrótce pojawi się HTML5.
• ... ale jednym z głównych rysunków pisania statycznego / kompilacji (w przeciwieństwie do interpretacji) jest dodatkowa prędkość, na jaką pozwala poprzez optymalizacje (a Flash tak naprawdę nie ma bardzo dobrej prędkości, pomimo systemu typów)

Teoretycznie możesz umieścić dowolne skrypty na wybranej stronie. W końcu <script>tag ma typeatrybut.

Jedyną barierą jest uzyskanie wystarczającego udziału w rynku pod względem wdrożenia w różnych przeglądarkach, aby warto było z niego korzystać.

Tak, w tym momencie jest to mało prawdopodobne.

Czy byłoby to praktyczne? Nie.

Czy to możliwe? Tak!

Opracowanie własnej statycznie wpisanej alternatywy dla JavaScript byłoby w najlepszym razie czasochłonne. W najgorszym przypadku nie byłbyś w stanie przekonać istniejących przeglądarek do wdrożenia języka skryptowego klienta i musiałbyś napisać własny.

Może znajdziesz swoją odpowiedź tutaj: /programming/86426/why-require-javascript-rather-than-supporting-a-standard-browser-virtual-machine

Uwaga: Moim zdaniem nowsze odpowiedzi są bardziej wnikliwe pomimo niższego wyniku.

Możesz używać języków takich jak haXe do pisania kodu w sposób statyczny i eksportowania go do javascript. JavaScript staje się bardzo szybki, więc wystarcza jako język wyjściowy. Próba wprowadzenia statycznie wpisanego języka jako standardu internetowego jest prawie niemożliwa. Próby wprowadzenia statycznego pisania do JavaScript nie powiodły się z powodów, dla których warto dyskutować.

Czy byłoby to technicznie możliwe? Jeśli ma zostać zaimplementowany w Javie, powiedziałbym „bardzo, bardzo trudny, ale możliwy” bez znaczącej utraty wydajności.

Właściwie piszę teraz statycznie wpisaną DSL w Javie, a jedynym sposobem, w jaki udało mi się uniknąć sprawdzania typu środowiska wykonawczego, jest użycie ogólnych i pomijanie „niesprawdzonych” ostrzeżeń… to znaczy, dopóki nie nadszedł czas na wdrożenie tablice wielowymiarowe (parametry klasy muszą być znane w czasie kompilacji i dlatego są z natury skończone, podczas gdy tablice wielowymiarowe reprezentują nieskończoną liczbę typów ...) Wciąż próbuję to rozgryźć, niestety - jestem pewien, że ja napotkam podobne problemy z klasami zdefiniowanymi przez użytkownika.

Rzecz w tym, że wciąż napotykam tego rodzaju problemy, ale po dłuższym siedzeniu wymyślam dobre rozwiązanie. Tak więc, aby to zrobić i mieć korzyści płynące z wydajności pisania statycznego (bez sprawdzania typu środowiska wykonawczego), powiedziałbym, że jest to niezwykle trudne, ale nie niemożliwe. Pomijając wydajność, powiedziałbym, że trudne, ale bardzo możliwe.

Wiem, że to stare pytanie, pomyślałem, że moje doświadczenie może być dla kogoś cenne.

Technicznie możliwe jest pisanie skryptów po stronie klienta w dowolnym języku skryptowym obsługiwanym przez klienta użytkownika (przeglądarkę). W praktyce jedynym szeroko obsługiwanym językiem jest JavaScript / ECMAScript. Przekonanie twórców przeglądarek do wdrożenia i obsługi nowego języka na tym etapie raczej nie odniesie sukcesu; dlatego jeśli chcesz użyć nowego statycznie wpisanego języka po stronie klienta, musisz przetłumaczyć nowy język na JavaScript lub zaimplementować dla niego interpreter w JavaScript.

Istnieje kilka projektów, które już robią coś takiego; na przykład Google Web Toolkit , jak wspomniano w jednej z pozostałych odpowiedzi.

Biorąc pod uwagę, że nie masz nadziei, że wszystkie przeglądarki używane w prawdziwym świecie będą obsługiwały nowy język; język będzie musiał się skompilować do jscript.

Ponieważ wszystkie przykłady sieci są w jscript, język powinien wyglądać jak jscript.

Myślę, że istnieje zakres z „podzestawem” jscript, który jest sprawdzany przez statyczny moduł sprawdzający, ale jest także prawidłowym jscript. Na przykład:

• Wszystkie zmienne muszą mieć komentarz, który mówi, że istnieją typy przed pierwszym użyciem.
• Wszystkie zastosowania zmiennych muszą być zgodne z powyższym.
• Funkcje / klasa nie mogą być używane, jeśli nie zostały zadeklarowane w komentarzu #
• Komentarz na górze pliku js musi zawierać listę wszystkich innych plików js, od których zależy.

Opcjonalne wpisywanie statyczne było częścią projektu Harmony projektu ECMAScript - chyba, że ​​tak się stanie w klienckim [opartym na przeglądarce] JavaScript jest chyba nieznany. Zobacz ten link w Wikipedii: http://en.wikipedia.org/wiki/ECMAScript#Future_development