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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так что бы вы сделали со всеми этими питонами и рубинами в браузере ?!

1). Все еще пишете клиентские приложения со сценариями? Что ж, это прекрасно делается с помощью JavaScript.

2). Написание клиент-серверных приложений с использованием сокетов? Почему бы не написать их просто без браузера?

3). Пишете автономные приложения? Просто делай это так, как ты делаешь сейчас.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А) не случится и Б) уже здесь.

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

объявление А

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

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

объявление B

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

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

объявление C

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

кроме этого:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом нет смысла.

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

Отличная идея. Почему бы не пойти дальше?

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

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

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

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

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

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

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

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

Те браузеры, которые ДЕЙСТВИТЕЛЬНО поддерживают новый стандарт, выиграют от увеличения скорости выполнения приложений на основе веб-виртуальных машин. Вдобавок ко всему, если браузеры основывают свои устаревшие движки javascript на стандарте веб-vm (т.е. анализируют javascript в стандарте веб-vm и затем запускают его), им не нужно управлять двумя средами выполнения, но это зависит от поставщика браузера. .

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

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

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

a new portable, size- and load-time-efficient format suitable for compilation to the web.

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

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

as WebAssembly evolves it will support more languages than C/C++, and we hope that other compilers will support it as well.

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

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

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