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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

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

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

• Как рассказали другие, JS не совпадает с AIR/.NET/... и тому подобное. JS в своем нынешнем воплощении прекрасно соответствует его целям.

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

Ответ 10

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

A) не будет и B) уже здесь.

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

ad A

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

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

объявление B

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

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

ad C

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

кроме этого:

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

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

Ответ 11

Действительно. Silverlight - это просто виртуальная VM.

Ответ 12

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

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

Июнь 2015 W3C объявила WebAssembly, что это

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

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

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

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

Я расскажу вам о официальной странице проекта, это действительно интересно!

Ответ 13

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

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

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

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

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

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

Ответ 14

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

Ответ 15

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

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

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

Ответ 16

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

Ответ 17

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

Ответ 18

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

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

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

Ответ 19

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

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

Ответ 20

Отметьте http://www.visitmix.com/Labs/Gestalt/ - позволяет использовать python или ruby, если у пользователя установлен Silverlight.

Ответ 21

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

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

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

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

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

Ответ 22

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

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

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

Ответ 23

Возможно, вы ищете собственного клиента Google.

Ответ 24

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

Ответ 25

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

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

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

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

Ответ 26

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

Во всяком случае, вам не нужно "грязно" работать на клиенте. Например, попробуйте GWT.

Ответ 27

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

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

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

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

Ответ 28

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

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

Ответ 29

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

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

Ответ 30

JavaScript - ваш единственный родной, стандартный вариант. Если вы хотите много власти, возьмите jQuery, но если вам нужно сделать еще кучу, подумайте над написанием аддона для Firefox? или аналогичные для IE и т.д.