Сменные языковые движки для браузеров. Почему бы и нет?

Question

Firefox имеет движок JavaScript SpiderMonkey. Chrome имеет V8 Javascript Engine.

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

С другой стороны, программисты долго мечтали о своем любимом языке в браузере. Настолько, что у нас есть такие продукты, как GWT (для java), parenscript (для общего lisp), HJScript (для haskell), и я уверен, что многие другие библиотеки для многих других языков позволяют программистам оставаться на своем любимом языке и генерировать код на стороне клиента.

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

Так где же наши сменные двигатели?

Answer 1

Вам не нужны подключаемые движки, просто согласованный формат байт-кода. Сейчас Google идет по этому пути с NaCl и PNaCl, которые основаны на LLVM. Таким образом, любая программа, скомпилированная в безопасное подмножество байт-кода LLVM, может быть запущена в браузере.

Answer 2

Полагаю, вы забыли про апплеты и вставили. Оба предлагают именно то, что вы хотите. И оба сосут по одной и той же причине.

Answer 3

Поставщики браузеров не могут даже договориться о распространенном видеоформате (см. Дискуссию html5 <video>) или о том, как должен выглядеть объект document DOM, и вы хотите, чтобы они согласовали весь языковой интерфейс?

Удачи.

Answer 4

В прошлом мы шли по этому маршруту.

Более старые версии IE поддерживали VBScript в качестве языка сценариев в дополнение к JScript.

Результатом стала целая загрузка сайтов, которые работали только в IE.

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

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

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