Binary HTML

Так собираются же так и делать, WebAssembly

WebAssembly

1. Нужно сделать очень безопасную виртуалку, иначе получится как с флешем.
2. Нужно сделать не тормозную виртуалку, иначе получится как с жабой.
3. Нужно чтобы не получилось как с системГ.

А вообще бинарные нередактируемые форматы это зло. Особенно если это было текстом, а не видео/аудио.

Ну, это JS, а про хтмл пока ничего вроде не слышно.

почему до сих пор хтмл не конпелируют в бинари

gzip, например. И прочие sdch.

Опера Мини давно так делает

Напомни, какой от этого профит.

Меньше тратить трафика на загрузку текста и ресурсов проца на его парсинг.

Изменения надо вводить по шагам. Сначала было сжатие, потом - бинарный протокол HTTP/2.0, потом WebAssembly, а потом уже и бинарный html можно.

Напомни, какой от этого профит.

Меньше тратить трафика на загрузку текста и ресурсов проца на его парсинг.

Я спрашивал «какой» - в цифрах. На чем ты собираешься экономить - и так понятно.

https://en.wikipedia.org/wiki/HTTP_compression

Гзип не компилирует тэги в бинарные сочетания.

Напомните, почему до сих пор хтмл не конпелируют в бинари, чтоб меньше места занимало?

Легаси. Куча софта работает с HTML. Если объявишь бинари, кто весь софт будет переписывать? Вася Пупкин?

чтоб меньше места занимало

Делают gzip, плюс есть современные форматы сжатия с HTML словарем прямо в браузере, а не в архиве. Поддерживается хромом и файрфоксом. Так что смысла в бинаре особо нет. А в памяти браузеров HTML и так на бинарные структуры ложится.

скомпилить код под эти две архитектуры можно заранее

Хром так и делает, компилит и кеширует. Но если надо всё и сразу, то уже пилят wasm.

При нынешнем вебе это капля в море. Вопрос не в том как пожать html, а как много веб сайт содержит всякого кода, который он подтягивает. По объему задачу решает банальный gzip. По скорости выигрыш будет небольшой, потому что реально эффективную компиляцию нельзя делать ни для html, ни для css, ни для javascript. Компиляция больше будет походить на минификацию + бинарный формат. Но всё равно забирать браузер всё это барахло будет и будет интерпретировать, иначе всякие angular придётся переписывать, а это кому-то надо?

Не будет ни бинарного html ни замены js на webassembly. Поэтому не будет и перехода. Сжатие и http2 это из другой оперы, они решают свои задачи почти ничего не ломая. html и js дорабатывают также - из расчёта ничего не сломать, а нагородить новые возможности по новому. Во многом благодаря такому вот подходу web стал популярным, этакий аналог winapi, только крос-платформенный - почти ничего не ломается, даже относительно древнее, хотя конечно что-то всё равно поломали:)

Плюсую. Веб стал так популярен потому, что он открыт и прост. Бинарные форматы не позволили бы ему так развиться.

Тора гой, ты пробовал заверстать сайт под основные браузеры хоть раз?

Открытость стандартов компенсируется необязательностью их выполнения. И единственный браузер, который их как-то соблюдает - links2.

2. Нужно сделать не тормозную виртуалку, иначе получится как с жабой.

Ну-ка на джаву не гнать. Уже сто лет как не тормозит.

... если выполняется на сервере с 128 гигами озу и Xeon E5-2699 V5 о 32 ядрах.

бинарные нередактируемые форматы это зло

но добро по сравнению с XMLем

http://s00.yaplakal.com/pics/pics_original/1/6/1/4883161.jpg

Да, и занимаюсь решением всяких проблем связанных с этим. И с поддержкой говна мамонта, и чтобы новые фичи работали:D Да, .это ад, но переход на бинарность проблем не решит никак. Стандарты не станут соблюдаться просто потому, что кто-то там возьмёт и придумает ещё один стандарт, теперь уже бинарный. Его также будут реализовывать по своему. Будет совершенно обычная ситуация, когда один и тот же код на С++ в каком-нибудь хроме тормозить раз этак в 20 по отношению к edge, а другой код наоборот. Где-то будут сыпаться ошибки, где-то бинарный формат будет поддерживаться не полностью и тд и тп.

Так вот, бинарный html сломает всё нахрен, ничего в замен не дав, все те костыли которые уже люди научились обходить начнут учиться обходить заново. Знаете ли, это уже происходило дохрена раз в индустрии когда закапывали Corba, потом закапывали, да не закопали soap, скоро начнут закапывать rest наигравшись. А грабли останутся всё те же потому, что проблемы всё те же. Вот если бы основные разработчики браузеров взяли, сели и договорились что стандарты будут поддерживать в первую очередь, а всё остальное по остаточному принципу. Причём поддерживать так, что одинаковый код будет одинаково и предсказуемо работать. Но это фантастика, так что просто успокойтесь:)

Ну да, у нас ведь текстовый трафик занимает больше всего места

Посчитай на досуге, сколько хтмла и жабаскрипта в одной странице какого-нибудь юлмарта (причем у них случай далеко не клинический).

Посчитай на досуге, сколько хтмла и жабаскрипта в одной странице какого-нибудь юлмарта (причем у них случай далеко не клинический).

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

Ну-ка на джаву не гнать. Уже сто лет как не тормозит.

... если выполняется на сервере с 128 гигами озу и Xeon E5-2699 V5 о 32 ядрах.

... если кое-кто не знает значение слова «оптимизация» и плодит тонны ненужных объектов

1. Нужно сделать очень безопасную виртуалку, иначе получится как с флешем.

Для html не нужна виртуалка, оно не выполняется. JS не обязательно компилировать в код целевой системы, можно в байткод. И выполнение этого JS не будет особо отличаться от выполнения текущего текстового. Прочитай, как работает v8.

А вообще бинарные нередактируемые форматы это зло.

Из «бинарные» не обязательно следует «нередактируемые». Вполне вероятно, что тот же html тебе приходит бинарно, в виде gzip. Текст внутри. Т.е. ты его всё равно не можешь напрямую редактировать. Да и какая разница? Если формат будет открытым и хорошо документированным, можно будет просто открыть инспектором браузера, любым редактором для этого формата (коих появится очень много).

3. Нужно чтобы не получилось как с системГ.

Это тут каким боком?

gzip, например. И прочие sdch.

Так это надо разжать, а потом распарсить. Если условный новый html будет бинарным, то «парсилка» станет проще и быстрее.

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

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

Ты уверен что бинарный формат позволит сэкономить больше чем банальный gzip? А то, что наверное процентов 90 трафика это видео и картинки?

Если условный новый html будет бинарным, то «парсилка» станет проще и быстрее.

На каком утюге тормозит парсинг html? Не js а именно html?

на джаву не гнать. Уже сто лет как не тормозит.

Толсто.

Я сегодня ради смеху взгромоздил на древний ноут vuze (azureus), так там разве что интерфейс подтормаживает. Загрузка проца на уровне 10-15%, памяти при десятке раздач меньше 200 метров. Браузер жрет больше. Это при том, что софтина жуткий комбайн уровня nero и acdsee, из которого реально нужно процентов пять функционала, но при этом в «легком» vuze leap его все же недостаточно.

А вообще бинарные нередактируемые форматы это зло.

Чем оно хуже, чем минифицированный JavaScript, используемый повсеместно?

HTML же из общего с XML имеет угловые скобки, браузеры по спеке обязаны разгребать любую невалидную кашу. XHTML провалился, а ты ещё компилировать что-то предлагаешь.

Напомните, почему до сих пор хтмл не конпелируют в бинари, чтоб меньше места занимало?

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

Меньше тратить трафика на загрузку текста и ресурсов проца на его парсинг.

И доведут процесс как с игрушками на цпп, когда всё по многу раз падает в самый ответственный момент, а на трах с перезагрузками уходит слишком много времени.

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

Алсо, ты не понимаешь сути бинарного формата, где смотреть (контейнер mkv) я уже сказал. По логике работы он мало отличается от xml, но гораздо быстрее парсится.

Единственный браузер, который нормально отображал частично загруженные страницы - старая опера на Presto

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

Алсо, ты не понимаешь сути бинарного формата, где смотреть (контейнер mkv) я уже сказал. По логике работы он мало отличается от xml, но гораздо быстрее парсится.

Это ты не понимаешь. Если просто сжимать передаваемые данные, то для этого матрёшка не нужна - пакеты и так архивируются, xml та ещё кака, заточенная под чтение через ООП, на котором выжрать лишний гигабайт можно несколькими кликами мыши - создали несколько лишних объектов, а что у них под капотом мы не ведаем пока программа не поведёт себя странно. Вот и выходит, что простые экономичные варианты бинарного формата смысла вводить особо и нет, а замудрёные нафиг не нужны.

в говнопятом хтмл это постарались сломать

Proof?

на паскале надо браузер писать, вот там точно никогда ничего не падает

Proof?

кенгуру

экономия на спичках.
Multimedia >> text

на паскале надо браузер писать, вот там точно никогда ничего не падает

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

Проблему жирного DOM'а это не решит.

э давай не путайся в показаниях. это в с++ добавить функционал без помощи авторов программы - проблема. а в паскале все збс. именно поэтому вебкит и хром написаны на паскале

А тут не добавлять функционал нужно а всю структуру программы ломать. Слишком много вбросов говнеца набрасывали в стандарт, даже оперописатели забили поддерживать изделие за которое им деньги платят. Да и сейчас, на чужом движке что-то не очень у них получается: попробовал через не самую древнюю хроперу качнуть пару файлов с меги - и %опа! «файл подготавливается, файл подготавливается» и ничего не качается хоть час жди - хтмл5 во всей красе.

оперописатели забили поддерживать изделие за которое им деньги платят

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

Слишком много вбросов говнеца набрасывали в стандарт
хтмл5 во всей красе

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

Ну и сайтоклепатели, лепящие свои пероделки под одного хромога тоже те ещё норкоманы.

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

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

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

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

Разупорись и больше не пей столько стекломоя.

Ты слишком много прыгал когда компилял, мозги стряслись.