Почему JavaScript, а не стандартная виртуальная машина браузера?

Question

Не имеет ли смысла поддерживать набор языков (Java, Python, Ruby и т. Д.) Посредством стандартизированной виртуальной машины, размещенной в браузере, вместо того, чтобы требовать использования специализированного языка - действительно, специализированного парадигма - только для клиентских скриптов?

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

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

Answer 1

Ну да. Конечно, если бы у нас была машина времени, возвращение назад и обеспечение того, что многие функции Javascript были разработаны по-другому, было бы главным развлечением (и гарантировало, что люди, которые разрабатывали движок IE в IE, никогда не уходили в ИТ). Но этого не произойдет, и мы застряли с этим сейчас.

Я подозреваю, что со временем он станет "Машинным языком" для Интернета, и другие лучше спроектированные языки и API-интерфейсы будут компилироваться в него (и обслуживать различные недостатки движка во время выполнения).

Однако я не думаю, что каким-либо из этих «лучше разработанных языков» будет Java, Python или Ruby. Javascript, несмотря на возможность использования в другом месте, является языком сценариев веб-приложений. Учитывая этот вариант использования, мы можем добиться большего успеха, чем любой из этих языков.

Answer 2

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

1. Собственный клиент Google : технология запуска собственного кода в браузере.
2. Emscripten : компилятор байт-кода LLVM для javascript. Позволяет запускать языки LLVM в браузере.
3. Идея: .NET CLI в браузере, создатель Mono: http://tirania.org/blog/archive/2010/May-03.html

Я думаю, что у нас будет JavaScript долгое время, но это рано или поздно изменится. Есть так много разработчиков, желающих использовать другие языки в браузере.

Answer 3

Ответ на вопрос - Нет, это не имеет смысла.

В настоящее время самые близкие вещи к многоязычной виртуальной машине - это JVM и CLR. Это не совсем легкие звери, и нет смысла пытаться встраивать что-то такого размера и сложности в браузер.

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

• Вы отставали от стабильности.
• Вы отстаете по сложности (кстати, отстаете, потому что вы пытаетесь обобщить на несколько языков)
• Вы находитесь на усыновлении

Так что нет, это не имеет смысла.

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

С точки зрения функциональности, мы, вероятно, всего лишь на самом деле работаем с DOM в любом случае, так что это действительно проблема синтаксиса и языкового соответствия, и в этот момент имеет смысл задать вопрос: это действительно того стоит? "

Учитывая, что only мы говорим о сценариях на стороне клиента, потому что сценарии на стороне сервера уже доступны на любом языке, который вам нравится. Это относительно небольшая арена программирования, поэтому польза от использования нескольких языков сомнительна.

Какие языки имеет смысл вводить? (Предупреждение, субъективный материал следует)

Использование такого языка, как C, не имеет смысла, потому что оно предназначено для работы с металлом, а в браузере практически нет металла.

Использование такого языка, как Java, не имеет смысла, так как в любом случае лучше всего API-интерфейсы.

Использование такого языка, как Ruby или Lisp, не имеет смысла, поскольку JavaScript - мощный динамический язык, очень близкий к Scheme.

Наконец, какой производитель браузеров действительно хочет поддерживать интеграцию DOM для нескольких языков? Каждая реализация будет иметь свои специфические ошибки. Мы уже прошли через огонь, касающийся различий между MS Javascript и Mozilla Javascript, и теперь мы хотим умножить эту боль в пять или шесть раз?

Это не имеет смысла.

Answer 4

В Windows вы можете зарегистрировать другие языки на хосте сценариев и сделать их доступными для IE. Например, VBScript поддерживается «из коробки» (хотя он никогда не приобретал большой популярности, поскольку для большинства целей он даже хуже, чем JavaScript).

Расширения Python для win32 позволили довольно легко добавить Python в IE, как это, но это не очень хорошая идея, так как Python довольно сложен в песочнице: многие языковые функции предоставляют достаточно хуков реализации, чтобы разрешить приложение с предполагаемой ограниченностью вырваться.

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

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

Answer 5

Я бы определенно приветствовал стандартную независимую от языка виртуальную машину в браузерах (я бы предпочел кодировать на статически типизированном языке).

(Технически) Это вполне выполнимо постепенно: сначала один крупный браузер поддерживает его, и сервер имеет возможность либо отправлять байт-код, если текущий запрос поступает из совместимого браузера, либо переводить код в JavaScript и отправлять текстовый JavaScript.

Уже существуют некоторые экспериментальные языки, которые компилируются в JavaScript, но наличие определенной виртуальной машины (возможно) позволит повысить производительность.

Я признаю, что "стандартная" часть была бы довольно сложной, хотя. Также могут возникнуть конфликты между языковыми функциями (например, статическая и динамическая типизация) в отношении библиотеки (при условии, что новая вещь будет использовать ту же библиотеку). Поэтому я не думаю, что это произойдет (скоро).

Answer 6

Если вы чувствуете, что ваши руки пачкаются, значит, вам либо промыли мозги, либо вы все еще чувствуете последствия «лет DHTML». JavaScript очень мощный и хорошо подходит для своей цели, которая заключается в написании сценариев интерактивности на стороне клиента. Вот почему JavaScript 2.0 получил такой плохой рэп. Я имею в виду, почему пакеты, интерфейсы, классы и тому подобное, когда это явно аспекты серверных языков. JavaScript прекрасно работает как язык на основе прототипов, не будучи полностью ориентированным на объект.

Если в ваших приложениях отсутствует прозрачность из-за того, что на стороне сервера и на стороне клиента связь отсутствует, возможно, вы захотите пересмотреть архитектуру своих приложений. Я работал с чрезвычайно надежными веб-сайтами и веб-приложениями, и я ни разу не сказал: «Хм, я действительно хотел бы, чтобы JavaScript мог делать (xyz)». Если бы он мог это сделать, то это был бы не JavaScript - это был бы ActionScript, AIR или Silverlight. Мне это не нужно, как и большинству разработчиков. Это хорошие технологии, но они пытаются решить проблему с помощью технологии, а не ... ну, решение.

Answer 7

Я не думаю, что стандартная веб-виртуальная машина настолько невероятна. Существует несколько способов, с помощью которых вы могли бы изящно и с полной поддержкой устаревших стандартов внедрить новый стандарт веб-ВМ, если вы гарантируете, что любой используемый вами формат байт-кода виртуальной машины может быть быстро декомпилирован в javascript и что полученный вывод будет достаточно эффективным Я бы даже зашел так далеко, что предположил, что умный декомпилятор, вероятно, сгенерирует лучший javascript, чем любой javascript, который человек может создать сам).

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

Те браузеры, которые действительно поддерживают новый стандарт, выиграют от увеличения скорости выполнения приложений на основе веб-виртуальной машины. Вдобавок ко всему, если браузеры основывают свои устаревшие механизмы javascript на стандарте web vm (то есть, разбирают javascript в стандарте web vm и затем запускают его), им не нужно управлять двумя средами выполнения, но это зависит от поставщика браузера. .

Answer 8

В то время как Javascript является единственным хорошо поддерживаемым языком сценариев, с которого вы можете напрямую управлять страницей, Flash имеет несколько очень полезных функций для больших программ. В последнее время он имеет JIT и также может генерировать байт-код на лету (посмотрите оценку выражений во время выполнения , чтобы узнать пример, где они используют flash для компиляции математических выражений, введенных пользователем, вплоть до собственного двоичного кода). Язык Haxe дает вам статическую типизацию с выводом и с возможностями генерации байт-кода, вы можете реализовать практически любую систему времени выполнения по вашему выбору.

Answer 9

этот вопрос регулярно появляется моя позиция по этому вопросу:

A) не произойдет и B) уже здесь.

простите, что? позвольте мне объяснить:

объявление A

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

Таким образом, «универсальная многоцелевая виртуальная машина», которая поддерживает множество языковых функций (оптимизация хвостовых вызовов, статическая и динамическая типизация, буферизация foo bar, ...), будет колоссальной, сложной для реализации и, вероятно, более сложной для оптимизации, чтобы получить хороший результат. производительность из этого. но я не являюсь языковым дизайнером или виртуальным гуру, может, я ошибаюсь: на самом деле это довольно просто, только у кого-то еще не было идеи? хрм, хрм.

объявление B

уже здесь: может не быть компилятора байт-кода / vm, но на самом деле он вам не нужен. afaik javascript завершен, поэтому должно быть возможно:

1. создать переводчик с языка X на javascript (например, coffeescript)
2. создать интерпретатор в javascript, который интерпретирует язык X (например, brainfuck ). да, производительность была бы ужасной, но эй, не может быть всего.

объявление C

что? во-первых, не было точки C !? потому что нет ... пока. Google NACL. если кто-то может это сделать, это гугл. как только Google начнет работать, ваши проблемы будут решены. только, это может никогда не сработать, я не знаю. в последний раз, когда я читал об этом, были некоторые нерешенные проблемы безопасности действительно хитрого типа.

---

кроме этого:

• javascript был там с ~ 1995 года = 15 лет. Тем не менее, реализации браузеров сегодня отличаются (хотя, по крайней мере, это уже не невыносимо). поэтому, если вы начнете что-то новое, у вас может быть версия, работающая между браузерами около 2035 года. по крайней мере, рабочее подмножество. это отличается лишь тонко. и нуждается в совместимости библиотек и слоев. нет смысла не пытаться что-то улучшить.

• также, как насчет читаемого исходного кода? я знаю, что многие компании предпочли бы не использовать свой код как "своего рода" открытый исходный код. лично я очень рад, что могу прочитать источник, если подозреваю что-то подозрительное или хочу извлечь уроки из этого. ура для исходного кода!

Answer 10

Быстрое обновление по этому старому вопросу.

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

июнь 2015 г. W3C объявлено WebAssembly , то есть

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

Это все еще эксперимент, но уже есть некоторая прототипная реализация в Firefox Nightly и Chrome Canary, и уже есть некоторая демонстрационная работа .

В настоящее время WebAssembly в основном предназначена для производства на C / C ++, однако

по мере развития WebAssembly будет поддерживать больше языков, чем C / C ++, и мы надеемся, что другие компиляторы также будут поддерживать его .

Я позволю вам поближе взглянуть на официальную страницу проекта, это действительно захватывающе!