Будет ли практически реализована статически типизированная альтернатива JavaScript на веб-страницах?

Предпочтение динамической и статической типизации в значительной степени зависит от вкуса, и разные люди находят их более или менее подходящими в разных ситуациях.

Мой вопрос заключается в том, будет ли технически возможно иметь статически типизированную альтернативу JavaScript для расширения веб-страниц на стороне клиента и т. Д.?

Там, конечно, нет технической причины, чтобы такая вещь не могла существовать. Нет ничего особенного в клиентском коде, который предписывает использование динамически типизированных языков.

Поскольку маловероятно, что другой язык найдет широкое применение, лучше всего было бы создать статически типизированную версию JavaScript (т. Е. Язык, близкий к java) и препроцессор, который преобразует его в обычный JavaScript.

Например, ваш скрипт выглядит так:

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

и препроцессор проверяет, что каждая переменная, функция, объект и т. д. правильно используются в соответствии с их типом, и изменяет сценарий на

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

с которым может справиться каждый браузер.

Мой вопрос заключается в том, будет ли технически возможно иметь статически типизированную альтернативу JavaScript для расширения веб-страниц на стороне клиента и т. Д.?

Конечно. Google Web Toolkit компилирует статический типизированный Java в JavaScript ... Просто подумайте об этом: всей красоте и гибкости Java, со всей производительностью машины сгенерированных JavaScript!

Если серьезно, вы могли бы сделать это для всех видов языков, и многие пытались (есть или были компиляторы для C и C #). Будет ли конечный результат практичным или нет, зависит от того, чего вы пытаетесь достичь: Google выбрал единую платформу для разработки очень больших клиентских приложений и имеет собственный движок JavaScript для загрузки; вы вполне можете обнаружить, что принятие такого зверя для эффектов наведения мыши и странного вызова AJAX приносит гораздо больше боли, чем просто научиться жить с небольшим количеством нетипизированного кода ...

Большинство преимуществ статически типизированных языков реализуются во время компиляции. Если язык будет интерпретироваться на клиенте, то значительная часть этих преимуществ будет потеряна. Если вы компилируете их на сервере, то вам нужно выяснить, как загрузить их и запустить на клиенте (подумайте, элементы управления ActiveX). Вы можете использовать гибридный подход (скомпилировать в некоторую промежуточную токенизированную форму), но тогда вы в основном вернетесь к Java-апплетам.

Уже существует.

ActionScript 3 (язык сценариев, стоящий за Flash и Flex) - это диалект ECMAScript, который реализует строгие типы, и вы можете использовать его более или менее таким же образом на стороне клиента, что и JavaScript (отличие состоит в том, что AS3 требует флэш-плагин, и компилируется). Лично я стараюсь держаться от него подальше, но если вы находитесь в «статичном» лагере, поверните его.

Это отвечает на главный вопрос, и теперь, когда он у нас есть, ваш второстепенный вопрос становится «Практичен ли Flash?» Ответ "да", с несколькими "если" и "но" с

• ... если вам нужно скрыть свой код по любой причине.
• ... если вы хотите очень, очень (прошлый уровень jQuery) высокий уровень интерактивности
• ... но даже без HTML5 кросс-браузерная совместимость в последнее время значительно улучшается.
• ... но HTML5 скоро появится.
• ... но одним из главных преимуществ статической типизации / компиляции (в отличие от интерпретации) является дополнительная скорость, которую она позволяет оптимизировать (а Flash не очень хорошо работает, несмотря на систему типов)

Теоретически, вы можете разместить любые скрипты на странице, которую вы хотите. В конце концов, у <script>тега есть typeатрибут.

Единственный барьер - получение достаточной доли рынка с точки зрения реализации в различных браузерах, чтобы его можно было использовать.

Так что да, это маловероятно на данный момент.

Будет ли это практичным? Нет .

Является ли это возможным? Да!

Разработка собственной статически типизированной альтернативы JavaScript в лучшем случае отнимает много времени. В худшем случае вы не сможете убедить ни один из существующих браузеров реализовать свой клиентский язык сценариев, и вам придется писать свой собственный.

Может быть, вы найдете ответ здесь: /programming/86426/why-require-javascript-rather-than-supporting-a-standard-browser-virtual-machine

Примечание: по моему мнению, более свежие ответы более проницательны, несмотря на более низкий балл.

Вы можете использовать такие языки, как haXe, чтобы писать код статически типизированным способом и экспортировать его в javascript. JavaScript становится очень быстрым, поэтому его достаточно в качестве языка вывода. Попытка применить статически типизированный язык в качестве веб-стандарта практически невозможна. Попытки ввести статическую типизацию в JavaScript не увенчались успехом по широким причинам для обсуждения.

Будет ли это технически возможно? Если это будет реализовано в Java, я бы сказал, «очень, очень сложно, но возможно» без значительного снижения производительности.

На самом деле я пишу от руки статически типизированный DSL в Java прямо сейчас, и я нашел единственный способ избежать проверки типов во время выполнения - использовать универсальные шаблоны и подавлять «непроверенные» предупреждения ... то есть до тех пор, пока не настало время реализации многомерные массивы (параметры класса должны быть известны во время компиляции и, таким образом, по своей природе конечны, тогда как многомерные массивы представляют бесконечное число типов ...) Все еще пытаюсь выяснить это, к сожалению - я уверен, что я Вы столкнетесь с аналогичными проблемами с пользовательскими классами.

Дело в том, что я продолжаю спотыкаться о подобных проблемах, но, посидев на этом некоторое время, я придумаю хорошее решение. Итак, чтобы сделать это и получить преимущества в производительности от статической типизации (без проверки типов во время выполнения), я бы сказал, что это чрезвычайно сложно, но не невозможно. Минус производительности, я бы сказал, трудно, но очень возможно.

Я знаю, что это старый вопрос, просто подумал, что мой опыт может быть ценным для кого-то.

Технически возможно написать сценарии на стороне клиента на любом языке сценариев, который поддерживает пользовательский агент (браузер). На практике единственным широко поддерживаемым языком является JavaScript / ECMAScript. Убедить производителей браузеров внедрить и поддержать новый язык на данном этапе вряд ли удастся; таким образом, если вы хотите использовать новый статически типизированный клиентский язык, вам нужно будет либо перевести новый язык в JavaScript, либо реализовать для него интерпретатор в JavaScript.

Есть несколько проектов, которые уже делают что-то подобное; например, Google Web Toolkit , как упоминалось в одном из других ответов.

Учитывая, что у вас нет надежды получить все браузеры, которые используются в реальном мире, для поддержки нового языка; язык должен будет компилироваться в jscript.

Поскольку все примеры в Интернете представлены на языке jscript, язык должен выглядеть в основном как jscript.

Я думаю, что есть область действия с «подмножеством» jscript, которое проверяется статической проверкой, но также является допустимым jscript. Например:

• У всех переменных должен быть комментарий, в котором говорится, что они вводятся перед первым использованием.
• Все использования переменных должны быть действительны с вышеуказанным.
• Функции / класс нельзя использовать, если они не были объявлены в комментарии.
• Комментарий в верхней части js-файла должен содержать список всех других js-файлов, от которых он зависит.

Необязательная статическая типизация была частью гармонии проекта ECMAScript - произойдет ли это когда-нибудь в клиентском [браузерном] JavaScript, я думаю, неизвестно. Смотрите эту ссылку в Википедии: http://en.wikipedia.org/wiki/ECMAScript#Future_development