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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В июне 2015 года W3C объявил WebAssembly, которая

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

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

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

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

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

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

А) не произойдет, и Б) уже здесь.

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

объявление А

ВМ - это не просто универсальное магическое устройство. большинство виртуальных машин оптимизированы для определенного языка и определенных языковых функций. возьмите 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 года. по крайней мере, рабочее подмножество. это отличается только тонко. и нуждается в совместимости библиотек и слоев. нет смысла не пытаться улучшить вещи, хотя.

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

На самом деле. По сути, Silverlight - это виртуальная машина на основе .Net на стороне клиента.

В ваших рассуждениях есть некоторые ошибки.

1. Стандартная виртуальная машина в стандартном браузере никогда не будет стандартной. У нас есть 4 браузера, и IE имеет противоречивые интересы в отношении «стандарта». Три других развиваются быстро, но скорость внедрения новых технологий низкая. А как насчет браузеров на телефонах, небольших устройствах, ...

2. Интеграция JS в различные браузеры и ее прошлая история приводят к недооценке возможностей JS. Вы обещаете стандарт, но не одобряете JS, потому что стандарт не работал в первые годы.

3. По словам других, JS - это не то же самое, что AIR / .NET / ... и тому подобное. JS в своем нынешнем воплощении идеально соответствует его целям.

В долгосрочной перспективе Perl и Ruby вполне могут заменить javascript. Все же принятие этих языков является медленным, и известно, что они никогда не возьмут на себя JS.

Как вы определяете лучше всего? Лучший для браузера или лучший для разработчика? (Плюс ECMAScript отличается от Javascript, но это техническая часть.)

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

Некоторые из функций, которые мне нравятся:

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

Приятно иметь дело, и это установлено. Наслаждайтесь этим, пока он есть, потому что, хотя он не может быть «лучшим» для клиентских скриптов, он, безусловно, приятен.

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

JavaScript - это стандартная виртуальная машина браузера. Например, OCaml и Haskell теперь имеют компиляторы, которые могут выводить JavaScript. Ограничением является не язык JavaScript, ограничение - объекты браузера, доступные через JavaScript, и модель управления доступом, используемая для обеспечения безопасного запуска JavaScript без ущерба для компьютера. Текущие средства управления доступом настолько плохи, что JavaScript разрешается только очень ограниченный доступ к объектам браузера по соображениям безопасности. Проект Гармония пытается это исправить.

Это классная идея. Почему бы не сделать шаг вперед?

• Напишите анализатор HTML и механизм компоновки (все сложные элементы в браузере) на одном языке виртуальных машин.
• Опубликуйте движок в Интернете
• Служите странице с объявлением о том, какой механизм компоновки использовать, и его URL

Затем мы можем добавлять функции в браузеры, не выдвигая новые браузеры для каждого клиента - соответствующие новые биты будут загружаться из Интернета динамически. Мы также могли бы публиковать новые версии HTML без всякой нелепой сложности обеспечения обратной совместимости со всем, что когда-либо работало в браузере - ответственность за совместимость несет автор страницы. Мы также можем экспериментировать с языками разметки, отличными от HTML. И, конечно же, мы можем писать в движки модные JIT-компиляторы, чтобы вы могли создавать сценарии на своих веб-страницах на любом языке.

Я бы приветствовал любой язык, кроме javascript, как возможный язык сценариев.

Что было бы здорово - это использовать другие языки, кроме Javascript. Java, вероятно, не очень подходит для тега, но такие языки, как Haskell, Clojure, Scala, Ruby, Groovy, будут полезны.

Некоторое время назад я пришел кросс-Rubyscript ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby и http://code.google.com/p/ruby- in-browser /
Все еще экспериментальный и в процессе, но выглядит многообещающе.
Для .Net я только что нашел: http://www.silverlight.net/learn/dynamic-languages/ Просто нашел сайт, но тоже выглядит интересно. Работает даже с моего Apple Mac .

Не знаю, насколько хорошо вышеприведенное работает в предоставлении альтернативы для Javascript, но на первый взгляд это выглядит довольно круто. Потенциально это позволило бы использовать любую среду Java или .Net непосредственно из браузера - в песочнице браузера.

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

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

Подавляющее большинство разработчиков, с которыми я говорил о ECMAScript et. и др. в конечном итоге признаем, что проблема не в языке сценариев, а в нелепом HTML DOM, который он раскрывает. Сочетание DOM и языка сценариев является распространенным источником боли и разочарования в отношении ECMAScript. Кроме того, не забывайте, что IIS может использовать JScript для сценариев на стороне сервера, а такие вещи, как Rhino, позволяют создавать автономные приложения в ECMAScript. Попробуйте поработать некоторое время в одной из этих сред с ECMAScript и посмотрите, изменится ли ваше мнение.

Такое отчаяние продолжается уже некоторое время. Я бы посоветовал вам отредактировать это, чтобы включить или перепечатывать с конкретными проблемами. Вы можете быть приятно удивлены некоторым облегчением, которое вы получаете.

Старый сайт, но все же отличное место для начала: сайт Дугласа Крокфорда .

Ну, у нас уже есть VBScript, не так ли? Подождите, только IE поддерживает это!
То же самое для вашего хорошего представления о ВМ. Что если я создаю скрипт на моей странице с использованием Lua, а в вашем браузере нет парсера для преобразования его в байт-код? Конечно, мы могли бы представить тег сценария, принимающий файл байт-кода, который даже был бы весьма эффективным.
Но опыт показывает, что трудно привнести что-то новое в Интернет: потребуются годы, чтобы принять радикально новое изменение, подобное этому. Сколько браузеров поддерживают SVG или CSS3?

Кроме того, я не вижу, что вы считаете "грязным" в JS. Это может быть некрасиво, если кодируется любителями, распространяя плохую практику, скопированную в другом месте, но мастера показали, что это тоже может быть элегантный язык. Немного похоже на Perl: часто выглядит как запутанный язык, но его можно сделать отлично читаемым.

Проверьте это http://www.visitmix.com/Labs/Gestalt/ - позволяет использовать python или ruby, если у пользователя установлен silverlight.

Это очень хороший вопрос.

Проблема не только в JS, так как в отсутствии хороших бесплатных IDE для разработки более крупных программ на JS. Я знаю только одну бесплатную: Затмение. Другой хороший вариант - Visual Studio от Microsoft, но не бесплатный.

Почему это будет бесплатно? Если производители веб-браузеров хотят заменить настольные приложения онлайн-приложениями (и они этого хотят), то они должны предоставить нам, программистам, хорошие инструменты для разработчиков. Вы не можете создать 50 000 строк JavaScript, используя простой текстовый редактор, JSLint и встроенный отладчик Google Chrome. Если вы не макогист.

Когда Borland сделал IDE для Turbo Pascal 4.0 в 1987 году, это была революция в программировании. 24 года прошло с тех пор. Позорно, в 2011 году многие программисты все еще не используют завершение кода, проверку синтаксиса и правильные отладчики. Вероятно, потому что есть так мало хороших IDE.

В интересах производителей веб-браузеров создать надлежащие (БЕСПЛАТНЫЕ) инструменты для программистов, если они хотят, чтобы мы создавали приложения, с помощью которых они могут бороться с Windows, Linux, MacOS, iOS, Symbian и т. Д.

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

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

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

Может быть, вы ищете собственный клиент Google.

В некотором смысле наличие в браузере более выразительного языка, такого как Javascript, вместо более общего, такого как байт-код Java, означает более открытый веб.

Я думаю это не так просто . Можно сказать, что мы застряли с JS, но разве это так плохо с jQuery, Prototype, scriptaculous, MooTools и всеми фантастическими библиотеками?

Помните, JS легкий , тем более с V8, TraceMonkey, SquirrelFish - новыми движками Javascript, используемыми в современных браузерах.

Это также доказано - да, мы знаем, что у него есть проблемы, но у нас есть много таких проблем, как ранние проблемы с безопасностью. Изображения, позволяющие вашему браузеру запускать код Ruby или что-либо еще. Безопасность песочница должна быть сделана на пустом месте. И знаешь, что? Python люди уже потерпели неудачу два раза в этом.

Я думаю, что Javascript будет пересматриваться и улучшаться со временем, так же, как HTML и CSS. Процесс может быть долгим, но не все возможно в этом мире.

Я не думаю, что вы «понимаете прагматическую проблему, заключающуюся в том, что JavaScript - это просто то, с чем нам приходится работать сейчас». На самом деле это очень мощный язык. У вас был Java-апплет в браузере годами, и где он сейчас?

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

... ты имеешь в виду...

Java и Java-апплет Flash и Adobe AIR и т. Д.

В общем, любая структура RIA может удовлетворить ваши потребности; но для каждого есть цена, которую нужно заплатить за использование (например, время выполнения доступно в браузере, и / или в собственности, и / или в меньшем количестве опций, чем у чистого рабочего стола). http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

Для разработки Web с любым языком, не связанным с Web, у вас есть GWT: разработка Java, компиляция в Javascript

Потому что все они уже имеют виртуальные машины с интерпретаторами байт-кода, и байт-код также отличается. {Чакра (IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera (Каракан).

Извините, я думаю, что Chrome (V8) компилируется в машинный код IA32.

хорошо, учитывая, что все браузеры уже используют виртуальную машину, я не думаю, что будет сложно создать язык виртуальной машины для Интернета.
Я думаю, что это очень помогло бы по нескольким причинам:
1. поскольку сервер компилирует код, объем отправляемых данных меньше, и клиент не тратит время на компиляцию кода.
2. поскольку сервер может скомпилировать код в процессе подготовки и сохранить его, в отличие от клиента, который пытается сократить время компиляции JS, он может оптимизировать код.
3. компилировать язык в байтовый код намного проще, чем в JS.

В качестве заключительного замечания (как кто-то уже сказал в другом комментарии), HTML и CSS компилируются до более простого языка, не уверенного, считается ли он байтовым кодом, но вы также можете отправлять скомпилированные html и css с сервера на клиент, который будет сократить время разбора и выборки

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

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