Блог

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

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

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

Ну, да. Конечно, если бы у нас была машина времени, вернуться назад и убедиться, что многие функции Javascript были разработаны по-другому, было бы важным времяпрепровождением (это и обеспечение того, чтобы люди, которые разработали CSS-движок 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, так что это действительно проблема синтаксиса и языка idom, и в этот момент имеет смысл спросить: «Действительно ли это того стоит?»

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

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

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

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

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

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

Июнь 2015 года W3C анонсировала веб-сборку, которая

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

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

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

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

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

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

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

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

объявление А

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

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

объявление В

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

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

объявление C

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

помимо этого:

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

Действительно. Silverlight фактически является именно этим — клиентской стороной .Виртуальная машина на базе сети.

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

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

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

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

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

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

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

Некоторое время назад я получил перекрестный рубискрипт … 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 framework изначально из браузера — в песочнице браузера.

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

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

Подавляющее большинство разработчиков, с которыми я говорил об ECMAScript и др., в конечном итоге признают, что проблема не в языке сценариев, а в нелепом 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. Я знаю только одно бесплатное приложение: Eclipse. Другая хорошая — это Visual Studio от Microsoft, но не бесплатная.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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