Почему HTML/JavaScript/CSS не являются компилируемыми языками и будут ли они когда-либо?

Почему HTML/JavaScript/CSS не становятся скомпилированными языками (или, возможно, даже объединяются в один скомпилированный язык)? Что делать, если браузеры запускали "Виртуальную машину браузера" и html/javascript/css источники могли быть скомпилированы в "байт-код браузера". Разве это не помогло бы разработчикам и пользователям?

Я вижу несколько проблем:

Что делать с zillions существующих страниц? Сделайте эту компиляцию необязательной, поэтому, если вы хотите, вы можете использовать простой старый html. Если вы хотите прокормить браузер с помощью скомпилированной страницы, просто используйте .chtml, например.
Как поисковые провайдеры будут индексировать страницы? Сделайте декомпилятор, который декомпилирует байт-код в точные исходные источники (например, как флэш-память может быть декомпилирована). Или поисковые провайдеры могут использовать одну и ту же виртуальную машину и получать нужные им данные.
Как сделать его совместимым со всеми браузерами? Попросите одного централизованного разработчика (скажем, w3c) разработать эту виртуальную машину, а затем каждый браузер включит ее.

Но как насчет преимуществ:

Скорость.
Размер.
Больше нет "свободного" и "неполного" html. Это либо правильно, либо не будет компилироваться.
Выглядит одинаково в каждом (поддерживаемом) браузере.

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

Итак, что мешает нам идти по этому пути (ну, помимо огромных усилий, чтобы все это случилось)?

Ответ 1

А, но Javascript становится скомпилированным языком. Просмотрите Firefox 3.5 с TraceMonkey. Это безумно быстро по сравнению с вашим браузером. Правда, JS никогда не будет C, но он гораздо более динамичный, чем C, и во многом делает его более выразительным и мощным.

Что касается HTML, я не думаю, что отсутствие корректности HTML является огромным ущербом для ускорения. Я думаю, что двигатели, которые объединяют визуальное представление и управляют DOM, должны быть намного лучше (um, IE, я смотрю в вашем общем направлении...). Соответствие CSS должно улучшаться, а сам CSS должен стать более мощным. (Получить в автобусе с CSS 3 человека!)

Но я действительно думаю, что скорость будет улучшаться в Firefox и Chrome до такой степени, что люди действительно начнут использовать ее для разработки основного приложения. Это смешно. Adobe, похоже, продает Flash как свою платформу для динамического веб-контента, MSFT продает Silverlight для динамического веб-контента, а Google просто хочет действительно улучшить HTML и Javascript для отображения динамического веб-контента. И Google довольно хорошо справляется с этим до сих пор, я должен сказать...

Ответ 2

Поскольку HTML и CSS не являются кодом, они не могут быть скомпилированы. Двигатель Google Chrome V8 фактически конвертирует JS в байтовый код, ожидайте, что другие механизмы рендеринга последуют этому примеру!

http://code.google.com/apis/v8/design.html

Недавно мы переработали систему шаблонов php, которую я помог создать, чтобы использовать minify для сжатия нескольких JS и CSS в один файл каждый, так как размеры наших файлов уменьшаются примерно до 20% от исходных объединенных размеров. Minify также делает gzip и кеширование, так что это действительно потрясающе для ускорения веб-сайтов.

http://code.google.com/p/minify/

Короче говоря, вы не можете скомпилировать некод, который является HTML и CSS. JS можно скомпилировать и начать, но все зависит от того, что браузеру нравится делать.

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

Ответ 3

Ваши идеи имеют силу, когда они применяются к JavaScript. Как отмечали другие, в той или иной степени несколько поставщиков пытаются применить эти принципы к JS даже сейчас. Еще один большой шаг в этой области, скорее всего, будет объявлена Chrome OS Google. Однако, когда дело доходит до (X) HTML и CSS, я думаю, что ваши идеи могут не хватать точки.

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

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

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

Ответ 4

V8 javascript engine (также встроенный в Google Chrome, но с открытым исходным кодом и с лицензией на свободу, поэтому вы можете используйте его в следующем браузере, который вы пишете!) компилирует Javascript на собственный машинный код - конечно, он делает это "как раз вовремя" (как и большинство современных компиляторов - Java, С# и т.д.!), а не "впереди времени" "(например, Fortran сделал в 1954 году, когда компьютеры были слишком слабы, чтобы обрабатывать компиляцию в разгаре исполнения). Я был бы удивлен, если другие хорошие JS-движки, такие как те, которые были в самом последнем Firefox и Safari, не сделали то же самое.

Похоже, вы не отстаиваете "javascript как скомпилированный язык" (поскольку он, очевидно, уже скомпилирован, если вы используете хороший движок JS), а скорее компиляцию "впереди времени" (просто когда большинство современных языков по сути отказывается от компиляции в будущем). Нажатие машинного кода, а не компилятивного кода на проводе, звучит как ужасная идея - гораздо больший размер, трудности в поддержке одного процессора против другого, кошмары безопасности в надлежащей песочнице и т.д. И т.д.) С небольшим вознаграждением.

Тем не менее, если вы действительно заинтересованы в том, чтобы нажать на машинный код для клиента, попробуйте nativeclient (пока клиент - это машина x86 - забудьте о каждом смартфоне на планете, многих нетбуках, старых добрых маках и т.д.) - по крайней мере, это promises исправление кошмаров безопасности. Если и когда вы довольны nativeclient, преобразование компилятора "точно в срок" в опережение времени - это гораздо более сложная техническая задача (если вы хотите продолжать использовать Javascript для источников, а не для других языков, конечно).

Ответ 5

Смотрите здесь для предыдущего обсуждения этого вопроса

Не все из приведенных причин обязательно являются действительными, но важно одно: если вы не являетесь Google, серверные циклы процессора намного ценнее циклов на стороне клиента: так проще скомпилировать клиент/оптимизировать то, что довольно часто динамически генерируется HTML/JavaScript, а не сервер.

Кен

Ответ 6

Скорость.

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

Больше нет "свободного" и "полуправильного" html. Это либо правильно, либо не будет компилироваться.

Вы уже получили это, используя [X] HTML.

Выглядит одинаково в каждом (поддерживаемом) браузере.

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

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

Некоторые люди разработали то, что еще не стандартно (т.е. они опережают стандарт)
Некоторые люди еще не разработали что-то стандартное (т.е. они отстают от стандарта)

Ответ 7

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

Ответ 8

Google V8, который является одним из многих javascript-движков javascript нового поколения для javascript в псевдокоде, подобно компиляции .NET. С# на лету. Ничего волшебного здесь. Ожидайте больше этого. поскольку webapps становятся более тяжелыми и более требовательными

Ответ 9

HTML

HTML - это в значительной степени XML. DTD существует для разных версий, и разработчики могут в любое время проверить это.

CSS

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

JS

Как уже упоминалось, JS IS становится скомпилированным языком, за исключением того, что браузер компилирует его для вас, а не для вас.