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

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

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

  1. Что делать с миллионами существующих страниц? Сделайте этот сборник необязательным, поэтому, если хотите, вы можете использовать обычный старый html. Если вы хотите загрузить браузер скомпилированной страницей, используйте, например, .chtml.

  2. Как поисковые системы будут индексировать страницы? Создайте декомпилятор, который будет декомпилировать байт-код в точные исходные коды (например, например, flash может быть декомпилирован). Либо поисковые провайдеры могут использовать ту же виртуальную машину и получать от нее нужные данные.

  3. Как сделать его совместимым со всеми браузерами? Пусть один централизованный разработчик (скажем, w3c) будет разрабатывать эту виртуальную машину, а затем каждый браузер будет встраивать ее.

А как же преимущества:

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

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

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

Ответы [ 9 ]

19 голосов
/ 17 июля 2009

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

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

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

4 голосов
/ 17 июля 2009

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

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

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

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

4 голосов
/ 17 июля 2009

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

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

2 голосов
/ 17 июля 2009

Механизм JavaScript V8 (также встроенный в Google Chrome, но он с открытым исходным кодом и свободно лицензируется, поэтому вы можете использовать его в следующем написанном вами браузере!) Компилирует Javascript на нативный компьютер код - конечно, он делает это «вовремя» (как большинство современных компиляторов - Java, C # и т. д.), а не «опережает время» (как это сделал Фортран в 1954 году, когда компьютеры были слишком слабы для обработки компиляции в разгар казни). Я был бы удивлен, если бы другие хорошие движки JS, такие как в самых последних версиях Firefox и Safari, не делали то же самое.

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

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

1 голос
/ 17 июля 2009

Speed.

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

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

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

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

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

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

  • Некоторые люди разработали что-то, что еще не является стандартным (то есть они опережают стандарт)
  • Некоторые люди еще не разработали что-то стандартное (то есть они отстают от стандарта)
1 голос
/ 17 июля 2009

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

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

Ken

0 голосов
/ 17 июля 2009

HTML

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

CSS

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

JS

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

0 голосов
/ 17 июля 2009

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

0 голосов
/ 17 июля 2009

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

...