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

9

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

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

Armand
источник
3
Почему бы и нет? `` ``
Джош К
2
Вы говорите о гипотетическом статически типизированном языке, который должен реализовывать каждый браузер, или уже существующих возможностях?
user281377 15.12.10
2
Вы могли бы использовать Java-апплеты, я полагаю.
Дэвид Торнли
@ammoQ, который вы упоминаете, Гипотетический
Арманд
@ Боже, я не знаю. @ Дэвид LOL, спасибо за это!
Арманд

Ответы:

22

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

GrandmasterB
источник
1
Дарт имеет необязательную статическую типизацию, но компилируется в обычный Javascript. www.dartlang.com
Nishant George Agrwal
16

Поскольку маловероятно, что другой язык найдет широкое применение, лучше всего было бы создать статически типизированную версию 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>

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

user281377
источник
5
+1 за прагматичный подход
Гари Роу
На самом деле этот вопрос не о прагматизме, а о теории. Буду обновлять.
Арманд
2
Я также предложил бы использовать вывод типа.
Оливер Вейлер
Вспомогательный метод: очень хорошее предложение, но я не изменяю свой пример сейчас, так как вывод типа сделал бы статическую версию очень похожей на динамическую версию, поскольку пример очень прост.
user281377 16.12.10
4
Я не думаю, что статически типизированный javascript будет очень близок к java, кроме как синтаксически. У Javascript и Java есть много различий, помимо статической и динамической типизации - ОО на основе классов и на основе прототипов. Поскольку ваш пример кода основывается на классах, я бы сказал, что «staticjavascript» является неправильным обозначением для этого языка, и его лучше назвать «java на стороне клиента». +1 для компиляции в javascript, хотя (кстати, Google Web Toolkit компилирует java в javascript).
sepp2k
8

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

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

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

Shog9
источник
3
Я не могу полностью сказать, шутите ли вы о «преимуществах» GWT. Если да, браво. Работа с GWT была одним из самых безумных переживаний в моей жизни.
Николь
@Renesis: Как будто работа с Javascript и браузерной совместимостью уже не сводила с ума? Но у него есть отличные функции, такие как загрузка нескольких изображений в одном изображении, а затем их вырезание на клиенте.
Макнейл
1
@Macneil Возможно, они уже исправили это, но когда я работал со Sprites, это практически сводило на нет все преимущества, потому что он автоматически записывал другие свойства фона CSS, которые вы, возможно, не хотели, поэтому вам приходилось каждый раз загромождать CSS, чтобы переопределить его. ,
Николь
6

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

TMN
источник
2
+1 для объяснения возможных причин , почему не , а не просто ответить , если это возможно.
4

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

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

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

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

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

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


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

Anon.
источник
Итак, нет проблем со статической типизацией? Я не слишком обеспокоен практичностью этого завоевания.
Арманд
1
@Alison: вы можете поместить любое текстовое содержимое в тег скрипта (за одним исключением - оно не может содержать последовательность символов </script>). Вы можете вставить туда код Brainf * ck, если вы действительно этого хотите. Тогда все, что вам нужно сделать, - это внедрить переводчик для выбранного вами языка в браузере, который вы хотите использовать.
Анон.
@Anon. спасибо, очень интересно Если это так просто, возможно, это было где-то сделано. Я помню, <script type="vbscript">однажды ...
Арманд
Элисон: vbscript был только для IE, и некоторые люди использовали его, когда доля IE на рынке была> 90%. Сегодня, когда доля IE на рынке составляет около 50%, а в некоторых частях мира, вероятно, меньше, это серьезный запрет; и до тех пор, пока ни один браузер снова не получит такую ​​большую долю рынка, не ожидайте появления чего-либо подобного новому скриптовому языку на стороне клиента.
user281377 15.12.10
@Alison: Internet Explorer по- прежнему поддерживает VBScript в качестве языка сценариев ... Я должен знать, у нас есть интранет-сайты, которые его используют (и, следовательно, требуют Internet Explorer - ура!)
Дин Хардинг
2

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

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

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

Марси
источник
Хотите объяснить?
back2dos
Добавлен дополнительный абзац.
Марси
Я бы только добавил, что единственная причина, по которой это может быть непрактичным, это текущая ситуация. Если бы мы вернулись к моменту незадолго до выпуска Javascript, все было бы иначе.
Яков
1

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

back2dos
источник
1

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

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

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

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

Филипп
источник
0

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

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

mithrandi
источник
0

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

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

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

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

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

jqueryrocks
источник