Почему HTML/JavaScript/CSS не являются компилируемыми языками и будут ли они когда-нибудь?
Почему HTML/JavaScript/CSS не становятся скомпилированными языками (или, возможно, даже объединяются в один скомпилированный язык)? Что, если в браузерах запущена "Браузерная виртуальная машина", а источники html/javascript/css могут быть скомпилированы в "байт-код браузера". Разве это не очень поможет разработчикам и пользователям?
Я вижу несколько проблем:
Что делать с миллионами существующих страниц? Сделайте этот сборник необязательным, поэтому, если хотите, вы можете использовать обычный старый html. Если вы хотите загрузить браузер скомпилированной страницей, используйте, например,.chtml.
Как поисковые системы будут индексировать страницы? Создайте декомпилятор, который бы декомпилировал байт-код в точные исходные источники (например, как flash может быть декомпилирован). Или провайдеры поиска могут использовать ту же виртуальную машину и получать от нее нужные данные.
Как сделать его совместимым со всеми браузерами? Пусть один централизованный разработчик (скажем, w3c) будет разрабатывать эту виртуальную машину, а затем каждый браузер будет встраивать ее.
Но как насчет преимуществ:
- Скорость.
- Размер.
- Нет больше "свободного" и "полу-правильного" HTML. Это либо правильно, либо не скомпилируется.
- Выглядит одинаково в каждом (поддерживаемом) браузере.
Если не байт-код, то, по крайней мере, происходит некоторое собственное сжатие, html, вероятно, не самый эффективный способ хранения данных. Я знаю, что есть gzip, но зачем каждый раз сжимать страницы на сервере и распаковывать в браузере, если мы можем сжать его один раз и передать в браузер?
Так что же мешает нам пойти по этому пути (ну, кроме огромных усилий, чтобы все это произошло)?
9 ответов
Ах, но 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 пока неплохо справляется, надо сказать...
Поскольку 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. Нам нужно больше таких действий, чтобы веб продвигался вперед.
Ваши идеи имеют смысл, когда они применяются к JavaScript. Как уже отмечали другие, в той или иной степени несколько поставщиков пытаются применить эти принципы к JS даже сейчас. Другим важным шагом в этой области, вероятно, станет Chrome OS, анонсированная Google. Тем не менее, когда дело доходит до (X)HTML и CSS, я думаю, что ваши идеи могут упустить смысл.
Всемирная паутина - это не ошибочная и непоследовательная прикладная платформа, а огромная и беспрецедентная коллекция взаимосвязанных документов. Сила Интернета заключается в абстракции данных от часто жестких (и ломких) визуальных макетов и все более сложной функциональности на странице, в значительной степени предоставляемой с помощью JavaScript. Кодирование этих страниц в (X)HTML идеально подходит для того, чтобы сделать их доступными для самой широкой аудитории как с точки зрения браузеров, так и с точки зрения технических знаний, необходимых для создания страницы.
Все больше и больше веб используется в качестве платформы приложений - что является мощным и захватывающим использованием этой технологии - но мы не можем упускать из виду тот факт, что эти Ajax-управляемые приложения "Web 2.0" являются просто документами с расширенной функциональностью. Компиляция не имеет смысла для документа, и сжатие уже происходит (через gzip и тому подобное).
С практической точки зрения, W3C движется в темпе ледника, и производители браузеров переключаются между "прыганием с пистолетом", поддерживающими экспериментальные функции в незавершенных спецификациях, и тратят свое время на поддержку других спецификаций, которые были на столе и широко используются годами., Целые процессы похожи на выпас кошек. Я бы не стал затаить дыхание на то, чтобы они в скором времени внесли такие радикальные изменения, которые вы предлагаете.
Механизм JavaScript V8 (также встроенный в Google Chrome, но с открытым исходным кодом и свободно лицензируемый, так что вы можете использовать его в следующем написанном вами браузере!) Компилирует Javascript в машинный код - конечно, он это делает "как раз вовремя" (как большинство современных компиляторов - Java, C# и т. д.), а не "раньше времени" (как это сделал Фортран в 1954 году, когда компьютеры были слишком слабы, чтобы справляться с компиляцией в разгар выполнения). Я был бы удивлен, если бы другие хорошие движки JS, такие как в самых последних версиях Firefox и Safari, не делали то же самое.
Похоже, вы не пропагандируете "javascript как скомпилированный язык" (поскольку он, очевидно, уже скомпилирован, если вы используете хороший движок JS), а скорее "опережающую" компиляцию для него (как раз тогда, когда большинство современных языки по существу отказываются от преждевременной компиляции). Вытеснение машинного кода, а не компилируемого кода по проводам звучит как по большей части ужасная идея - гораздо больший размер, трудности в поддержке одного ЦП против другого, кошмары в области безопасности при правильной загрузке его в песочницу и т. Д., И т. Д.) С незначительными с точки зрения компенсации преимуществами.
Тем не менее, если вы действительно заинтересованы в передаче машинного кода клиенту, попробуйте nativeclient (если клиент является машиной x86 - забудьте о каждом смартфоне на планете, о многих нетбуках, старых добрых компьютерах и т. Д.) - по крайней мере, это обещает исправить кошмары безопасности. Если и когда вы довольны nativeclient, то преобразование своевременного компилятора в более ранний является гораздо более сложной технической задачей (если, конечно, вы хотите продолжать использовать Javascript для исходных текстов, а не для других языков, разумеется).).
Скорость.
Вы предполагаете, что для анализа HTML требуется значительное время. Однако может случиться так, что это время будет незначительным по сравнению со временем, необходимым для чего-то другого, например, времени, необходимого для размещения текста в окне конечного пользователя.
Нет больше "свободного" и "полу-правильного" HTML. Это либо правильно, либо не скомпилируется.
Вы уже получили это, используя [X]HTML.
Выглядит одинаково в каждом (поддерживаемом) браузере.
Вы, кажется, говорите, что должен быть только один браузер, или что все браузеры будут поддерживать его одинаково.
Интернет-стандарты не случаются, когда единый орган (w3c) реализует что-то и объявляет это стандартом. Вместо этого интернет-стандарты имеют множество независимых организаций, создающих несколько реализаций. Следствием является:
- Некоторые люди разработали что-то, что еще не является стандартным (то есть они опережают стандарт)
- Некоторые люди еще не разработали что-то стандартное (то есть они отстают от стандарта)
Смотрите здесь для предыдущего обсуждения по этому вопросу
Не все приведенные причины обязательно являются действительными, но одна важная из них заключается в том, что, если вы не Google, циклы ЦП на стороне сервера гораздо более ценны, чем циклы на стороне клиента: поэтому клиенту легче компилировать / оптимизировать то, что Довольно часто динамически генерируется HTML/JavaScript, а не сервер.
кругозор
Google V8, который является одним из многих механизмов javascript нового поколения, "компилирует" javascript в псевдокод, так же, как.NET "компилирует" C# на лету. Здесь нет ничего волшебного. Ожидайте большего от этого, особенно как веб-приложения становятся все тяжелее и требовательнее
HTML
HTML в значительной степени XML. DTD существует для различных версий, и разработчики могут проверить это в любое время.
CSS
CSS не является языком программирования, однако я согласен с тем, что "скомпилированный" CSS может работать, поскольку компиляция сжимает его. Однако с той поддержкой, которую имеет CSS, и с количеством необходимых хаков, которые необходимы CSS, вы никогда не сможете скомпилировать его без ошибок.
JS
Как уже упоминалось, JS становится компилируемым языком, за исключением того, что браузер компилирует его для вас, а не для вас самих.
Я думаю, что ваша идея обоснована, однако до сих пор нет способа обеспечить соблюдение стандарта. Таким образом, если бы была не поддерживаемая функция, есть большая вероятность, что вся страница просто не будет ничего отображать. В текущей настройке критическая информация все еще может быть передана.