После нескольких месяцев разработки увидел свет первый релиз (https://github.com/lexborisov/myhtml/releases/tag/v1.0.1) быстрого HTML парсера MyHTML (https://github.com/lexborisov/myhtml/). Код написан на языке Си и распространяется под лицензией LGPL v2.1.
Особенности MyHTML:
- Высокая производительность;
- Асинхронная обработка токенов и построение дерева
- Полная поддержка спецификаций HTML 5 (https://html.spec.whatwg.org/multipage/), по состоянию на 19.06.2016;
- Возможность манипулировать элементами и их атрибутами: добавлять, удалять, изменять
- Поддерживает 39 кодировок на входе. На выходе только UTF-8, вся работа внутри только в UTF-8
- Автоматическое определение кодировки текста. Сейчас доступны unicode: UTF-8, UTF-16LE, UTF-16BE (+ определение по BOM) и русские: windows-1251, koi8-r, iso-8859-5, x-mac-cyrillic, ibm866
- Может работать в Single Mode — без тредов. Так же может быть собран без потоков.
- Возможность парсить фрагменты HTML или парсить кусками (chunks);
- Не имеет внешних зависимостей;
- Поддерживает C99;
- Не испытывает проблем если на вход подать бинарный файл или не валидный HTML;Проект также предоставляет большую подборку примеров (https://github.com/lexborisov/myhtml/tree/master/examples) по использованию и описание API (https://github.com/lexborisov/myhtml/blob/master/include/myh...). На основе данного проекта будет разрабатывается рендер HTML на "голом" Си без зависимотей. Скоро будет завершён CSS-парсер MyCSS (https://github.com/lexborisov/mycss).
URL: https://github.com/lexborisov/myhtml/releases/tag/v1.0.1
Новость: http://www.opennet.me/opennews/art.shtml?num=44782
Круть!)
Вот было бы на haskell-е, тогда бы была бы действительно круть...
Ну а смысл. C достаточно универсален. Биндинги к нему напилить и все круто будет. А хаскель...да, мы любим хаскель.
Ну как минимум с многопоточностью у haskell-а дела обстоят лучше.
А вообще проект мне понравился. Надеюсь что у автора всё получится в полной мере.
Эммм, что-что?Я не ослышался - У хаскеля с многопоточностью дела лучше, чем у С???
Конечно. Аппликативный код распараллеливается лучше итеративного. При словах "многопоточного HTML-парсера" у меня первая мысль была об erlang-е, но я подумал и всё-таки написал про haskell.
> Конечно. Аппликативный код распараллеливается лучше итеративного. При словах "многопоточного
> HTML-парсера" у меня первая мысль была об erlang-е, но я подумал
> и всё-таки написал про haskell.Если он будет такой же как ejabberd - спасибо, но оставьте это себе.
А со сборкой мусора? Будет ли код такой же быстрый как и на си?
Насколько гипотетический парсер на haskell-е будет быстрее|медленнее сабжа сказать трудно. Но достаточно быстрый парсер написать можно. См. ссылку ниже.
зачем такому проекту сборщик?
https://github.com/bazqux/fast-tagsoup
Оно что-то давно не обновлялось, хотя скорость 20-200MB/sec это более чем круть ;)
А что сложного написать? Поставь задачу и вперед.
> Вот было бы на haskell-е, тогда бы была бы действительно круть...Куда это потом девать? Пофапать и выбросить? На сях то оно куда угодно прикручивается при должном желании.
Написано всё очень оптимистично и красиво! Это в итоге использовать можно будет для построения браузерного движка или какие у этого парсера предназначения?
Судя по тому, что будут писать рендер, да ещё и MyCSS на подходе - есть все шансы увидеть новый браузер.
Нету. Главное это layout, rendering и Javascript.
layout, reflow and otherБудет, всё будет. Если почитать статьи к парсеру то там я указывал, что рендер уже есть, но всё написано в черновом варианте. Сейчас же идет разработка чистовика. JS будет сторонний, пока сторонний.
На хабре (https://habrahabr.ru/post/277031) я описывал что за проект и к чему стремлюсь. Возможно скоро я буду делать его не один.
Это вы отрисовку шрифтов к other отнесли?
А куда её отнести? Или отрисовка шрифтов -- это ключевое что есть?
В те 10% задачи, которые займут 90% времени.> Или отрисовка шрифтов -- это ключевое что есть?
Это с какой стороны смотреть. Но если относить в other - вас ждёт открытий чудных, и больших надежд на релиз такого браузера я бы не питал.
Есть большая разница между отрендерить шрифт и отрендерить шрифт с антиалисами на ретина дисплее.Но я и не питаю надежд -- браузеры сейчас настолько сложны в разработке что даже таже опера слилась со своим движком. А браузер который не все сайты будет хорошо показывать не нужен.
Во-первых, это забота библиотек.
Во-вторых - это кому как. У меня вот нет ретины, я всегда отключаю антиалиасинг и мне плевать на поехавшие шрифты на сайте. Зато на скорость работы и возможность кастомизации мне не наплевать. Особенно если это будет возможность кастомизации на сях.
поехавшие шрифты != поехавшие сайты.Сейчас настолько адская смесь из css, js, html и багов разных возрастов, что сделать что-то работающее как надо сильно непросто.
Уважаемый, если вы не измените своим принципам и до конца будете идти по пути качественного кода, с упором на скорость и минимальные потребляемые ресурсы, и в итоге если ещё появится браузер, которым можно будет пользоваться на системе с 256 мегами памяти, то мой вам поклон и запись в постоянные донейторы вашего проекта.
Вообще-то один из простых способов получить скорость и компактность - не давать страницам делать лишнего. Ну там - дефолтное полное отключение JS в неактивных вкладках (с белым списком, конечно), а тои полная выгрузка уже распарсенного и загруженного контента в каких-то разумных (вероятно, слегка сжатых чем-то быстрым вроде imagezero и подобных) форматах на диск, возможность прервать исполнение уже загруженного и запущенного JS и тому подобное. И этого всего в существующих браузерах здорово не хватает.
Секрет в том, что тормоза в браузерах и оплата их разработки идут из одного источника - рекламных сетей. Браузер со встроенной изначально резалкой шлака будет заметно быстрее Хрома, например, даже в том случае, если будет просто Хромиумом со встроенной резалкой шлака.
Я скорее согласен, чем нет. Речь была о том, что это (условно) простой путь получить конкурентоспособный браузер. Но да, финансировать придётся за счёт краудфандинга.
В принципе, совсем необязательно. Есть какое-то количество ниш, в которых был бы очень востребован быстрый браузер, потребляющий минимальное количество ресурсов, а ограниченность возможностей была бы только дополнительным плюсом - автомобильная индустрия, например, или управление промышленным оборудованием.
Деньги там очень серьезные.
Нет там никаких проблем с ресурсами - ни в делах автомобильных, ни в промышленности, куда частенько вообще ПК пихают в железном ящике. Ограничение фич при нужде в движках тоже предусмотрено.А вот power user'ов, для которых подходящего браузера не осталось - этих хватает. Да и денег не особо много надо - если, конечно, оплачивать работу программистов, а не Mozilla Corporation. Скажем так - есть обоснованная уверенность, что, как минимум, с поддержкой/допиливанием при существующей кодовой базе справится команда до 10 человек. Особенно если не хотеть странного, вроде проигрывания видео во время плавной прокрутки страницы (чёрт, да эту плавную прокрутку можно вообще не делать).
И проблемы с ресурсами есть, и с ограничением фич всё очень плохо.Продвинутые пользователи - это ниша, на которую стало принято забивать, она другая, но тоже очень интересная. Только более сложная в собирании с неё денег. Но деньги в ней тоже есть, никто не спорит.
Основные проблемы, которые мне видятся с продуктом для power users (оставляя тему денег на время в стороне)
- нужна максимальная расширяемость, кастомизирумость, гибкость. Для этого нужна очень хорошая архитектура. Это сложно.
- long tail требований. Power users они на то и не лайкатели в инстаграммах, что запросы у них очень уж разные. И запросы эти часто взаимоисключающие.
Архитектура "хребет + плагины, которые можно цеплять цепочками", в общем-то, не так уж сложна. То, что плагин становится сишной либой - не проблема, если надо - интерфейс к другим языкам делается отдельно.long tail этим и решается - плаягинами. Главное, чтобы не надо было писать полноценные движки.
А деньги взимать - краудсорсинговый проект на базовый вариант + оплата отдельных фич (по факту - плагинов тех же) потом. Хотя потом оно и без оплаты будет жить.
Она "не сложна" ровно до момента её имплементации. Особенно вместе требованиями по производительности.Long tail легко решается плагинами в экосистемах типа Wordpress - и, кстати, хорошая архитектура этому весьма препятствует. Где много-много одинаковых людей на каждую фичу, и совсем не power users.
Оплата фичей теоретически вещь неплохая, вот краудсорсинг здесь вселяет гораздо меньше оптимизма.
Да делана такая архитектура сто раз (и мной в том числе) - нет ничего великого в ней. Производительность перестаёт быть проблемой как только перестаёшь видеть плагины как нечто страшное, внешнее и недоверенное. Если у них те же права, что и у остального кода (и они, соответственно, могу всё завалить, конечно) - то всё в порядке.Насчёт long tail не понял - чему хорошая архитектура препятствует?
Хорошая архитектура препятствует набеганию тысяч неквалифицированных разработчиков, которые левой пяткой запиливают тысячи плагинов, не умея ни читать ни писать.
Тогда у нас очень разные понятия о хорошей архитектуре. Вопрос, в общем-то, не в том, сколько тысяч кривых плагинов, а в том, чтобы от них можно было легко отличить не кривые. А так - если каждый может для себя сделать какую-то кастомизацию - это и есть система для power user'ов. Тот же unix shell с утилитами и пайпами взять - они пишут себе какие-то спеифические домашние скрипты, от которых production quality никто в здравом уме и не ждёт - зато точно под конкретные условия.
зачем тебе unix shell убогий? твое корыто это systemd - вот жри его и вперед :)
Вы опять главного не сказали - за этим стоят Ротшильды или Рокфеллеры?
К сожалению тут надо очень долго возится, иначе сайты получятся совсем не юзабельными
> Вообще-то один из простых способов получить скорость и компактность - не давать
> страницам делать лишнего.Во-первых, сейчас сами браузеры пытаются делать много лишнего, от борьбы с фишингом до телеметрии внаглую.
Во-вторых, без разрешения этого лишнего - сайты часто работать перестают. Для понимания, посмотри на twitter bootstrap. Без js половина оформления отваливается, хотя формально js опционален. А оно популярное и на этом каждый второй сайт сделан.
> Уважаемый, если вы не измените своим принципам и до конца будете идти
> по пути качественного кода, с упором на скорость и минимальные потребляемые
> ресурсы, и в итоге если ещё появится браузер, которым можно будет
> пользоваться на системе с 256 мегами памяти, то мой вам поклон
> и запись в постоянные донейторы вашего проекта.Спасибо вам!
Своим принципам я не поступлюсь.
Вы правда (если это вы) собираетесь в одиночку сделать конкурента Firefox и Chrome? Либо вы гений, либо глупец.
Или умный человек, способный поставить задачу премлемого масштаба, не пытаясь реализовать всё, что понапихали в этих кадавров. Ну и читайте внимательнее то, на что отвечаете - "возможно скоро я буду делать его не один."
Заодно можно реализовать много другого.
Да и один в поле тоже воин - http://lambda-the-ultimate.org/node/3851#comment-57760
где-то это было... А точно Линуксу этоже сказали в своё время... И да Google тоже из тех же ребят)))
> Вы правда (если это вы) собираетесь в одиночку сделать конкурента Firefox и
> Chrome? Либо вы гений, либо глупец.К счастью, или сожалению, но мне это говорят часто. Я не пытаюсь сделать, как это модно сейчас говорить, "убийцу" того или другого. Я просто не доволен тем что есть и делаю так как считаю правильным.
В данным момент мне разрешили работать над проектом фуллтайм в рабочее время. Возможно скоро я буду заниматься им не один, но это всё вилами на воде, как обычно.
Я реалист, проект очень большой. Просто вот нахрапом такое не сделать. Можно даже сказать, что браузер это свод современных технологий/решений. В общем, это крайне не простая "штука".
Автор как я считаю, пример исчезающих к сожалению, романтиков IT отрасли. Это раньше корпели над тем, как бы изящней, да эффективней написать каждый кусок кода, сейчас же никого не волнуют такие формальности.Рынку надо продавать, чтобы продавалось новое, надо чтобы тормозило старое. Вокруг сотни браузеров, один прожорливей другого. И проедают они полностью ресурсы современных писюков, хотя например году эдак в 2006-2007, помню в общаге преспокойненько пользовался инетом в опере, со всеми яваскриптами, она тогда полностью проходила acid тесты, и вконтакты и одноклассниками и масса вкладок нормально себе ворочались на Athlon X2 4200 + 1Gb Ram во фре.
Мне кажется в сайтостроении не поменялось так много, чтобы обычный интернет сёрфинг стал требовать на порядок больше ресурсов.
Надеюсь у Автора всё будет получаться, подключатся сторонники и единомышленники - качественные кодеры.
Вокруг 4 браузера. Chrome, Edge, Mozilla, Safari. То, что на движки хрома ещё пара десятков команд натянула свои шкурки (и парочка на мозилловские), ничего не меняет.
Есть несколько экспериментально-академических движков - ну, не движков, а proof of concept поделок.
Все упирается в layout и %^$^%$$#%$#% модель CSS - в результате лок на локе едет и локом погоняет, и пиление их алмазным надфилем требует в условиях "attention span типичного разработчика не превышает 5 секунд" совершенно катастрофических ресурсов по времени и деньгам.
ты кстати зря, firefox за это время например ускорился и течь таки меньше стала опера наоборот протухла адово
Ну вот Mozilla переписала с нуля движок на Rust. Как до хотя бы до беты дойдет посмотрим, как оно.
Там до переписывания и до того что можно было бы назвать движком еще очень далеко.
И волшебное слово Rust само по себе ВНЕЗАПНО не волшебная палочка.
У мозиллы слишком отличается направление движения - "всё упростить, ориентировать на массового пользователя, всё засунуть в веб или хотя бы в джаваскрипт". Тут на чём не пиши - всё равно гадость будет.
Самое смешное, конечно, в том что она будет еще и никому не нужная, потому что Chrome уже есть, и перехромить его не удастся.
Вот то, что до них это не доходит, меня удивляет больше всего.
А в других случаях - с Blackberry, например - не удивляет? Это обыденность, редки наоборот, исключения из этого паттерна - такие как Harley Davidson, например.Ну и чтобы считать что дело именно в "не доходит", нужно имплицитно предполагать что участники процесса разработки Firefox заинтересованы в том чтоб Firefox всех победил. Причем не в формулировке "при прочих равных он бы еще и всех победил" ("растащив пол-завода мы бы еще и выполнили квартальный план") - от этого участники, конечно, не отказались бы - а именно серьезно заинтересованы, в формулировке "ради выполнения квартального плана мы готовы пожертвовать растаскиванием половины завода".
> На хабре (https://habrahabr.ru/post/277031) я описывал что за проект и к чему стремлюсь.
> Возможно скоро я буду делать его не один.А что, набор технологий ничего так, симпатично и со вкeсом. Никакой хипстерской фигни и решения всех мировых проблем, все по делу. Автор крут.
Сравнение с парсером на Rust - http://lexborisov.github.io/benchmark-html-persers/
Ух. Да оно на порядок опережает servo/html5ever. Очень, очень достойный результат.
Это какая ошибка, ведь Rust самый лучший язык, у servo самые лучшие разработчики на самом лучшем языке, Mozilla Foundation самая прогрессивная опен-сорс компания, а поезд Си давно ушел!
Как уже упоминал тёзка, html5ever скорее заглушка, которая ещё будет пилиться. Ну и gumbo тоже, как бы, на Си написан.
Но ведь скорость разработки на прогрессивном языке Rust обгоняет фотоны в вакууме!
Почему же заглушка и будет пилиться? Ведь Servo разрабатывается рекордными темпами и со дня на день вытеснит устаревшие браузеры окончательно?
> Но ведь скорость разработки на прогрессивном языке Rust обгоняет фотоны в вакууме!Казалось бы, причем тут скорость разработки.
> Почему же заглушка и будет пилиться?Так что там с тормозами Gumbo?
> Казалось бы, причем тут скорость разработки.Разве это не одна из уникальных особенностей прогрессивного языка Rust, выгодно отличающая его от устаревших языков Си и С++?
> Разве это не одна из уникальных особенностей прогрессивного языка Rust, выгодно отличающая
> его от устаревших языков Си и С++?Так вы из неолуддитов будете?
> Это какая ошибка, ведь Rust самый лучший язык, у servo самые лучшие
> разработчики на самом лучшем языке, Mozilla Foundation самая прогрессивная опен-сорс компания,
> а поезд Си давно ушел!Разработчики из мозиллы свалили а у менеджеров всегда все самое лучшее. Но, к сожалению, только в маркетинговых буклетиках.
Мсье точно смотрел графики? В каком месте на порядок? Или кто-то не знает, что порядок это в 10 раз, а не на 10%?
> MyHTML Overall time: 0.50890
> HTML5Ever Overall time: 4.50536
Ну как и предполагалось, графиков не смотрели, просто глянули на итоговые цифры.
Может быть вы расшифруете свою мысль, снизойдете до пояснений?
В большей части случаев разница не в 10 раз, а от двух до четырех. То есть финальная разница в 10 раз сделана небольшим количеством сайтов. Причем очень любопытно, что на какой-нибудь паре сайтов сабж справляется за почти одинаковое время, а html5ever с разницей в три раза. Тут два варианта, либо есть проблемы с парсингом каких-то конструкций в html5ever, либо сабж просто скипает парсинг некорректных кусков. И в этом серьезная проблема всего бенчмарка, он сравнивает скорость парсинга, но не проверяет корректность или хотябы равенство результатов у парсеров.
Сравниваются только полноценные парсеры. То есть те кто полностью соответствует спецификации и проходит тесты на правильное построение дерева https://github.com/html5lib/html5lib-tests/tree/master/tree-...Прогон 60к сайтов показал среднее отставание html5ever в ~5 раз.
Еще раз, сравнивались ли деревья, построенные парсерами на этих 60к сайтов, многие из которых скорее всего не полностью следуют спецификациям? Насколько сильно оставание на этих эталонных тестах, а не реальных сайтах?
Чуть ниже по треду есть же ответ: http://www.opennet.me/openforum/vsluhforumID3/108541.html#45
Это не ответ на мой вопрос. Ну разве что считать это признанием в том, что на самом деле бенч был несколько некорректным.
Быть может вы удивитесь, но их нельзя сравнить по конечной серелизации данных. Всё крайне просто, спецификация "живая" и она постоянно меняется. Вот например, тег isindex выкинули из спецификации не так давно. Теперь такого тега нет, теперь он такой же как прочие "безымянные теги", вроде <mynametag>. Поменялась обработка тега menu and menuitem и т.д..Есть общепризнанные тесты на правильное построение дерева: https://github.com/html5lib/html5lib-tests/tree/master/tree-... — тесты охватывают очень многое из спецификации, в особенности всё что связано с битыми тегами и невалидным хтмл. Сейчас сложно сказать с плеча, я как-то не особо изучаю сторонние парсеры, но вроде гумбо гугловский уже устарел, хтмл5эвер не знаю, сюда по логу коммитов он тоже давольно давно не обновлялся.
На момент прохождение бенчмарков хтмл5эвер не проходил все тесты на построения дерева, но это было что-то 10 из 1000 (приблизительно). Про гумбо уж не помню.
Порой даже в разных браузерах можно наблюдать разное построение дерева, со следующими версиями они обновляются.
Я стараюсь поддерживать свежую спецификацию.
Я веду речь о том, что нельзя сравнивать напрямую скорость, если результат выдается неодинаковый. Тем более непонятно, почему при наличии тестов они не были использованы для бенчмарка. А если были, то интересен результат.
Каждый тест парсится меньше чем за 1мс (0.00001). Там нечего тестировать на скорость, это тесты на корректность.Потому и сравнивались всего несколько парсеров. Эти парсеры заявлены с полной поддержкой хтмл. Сравнение корректное, +- в реализации всегда будет, спецификация "живая", но этот +- ни на что не влияет. Чтобы понять почему этот +- ни как не влияет на скорость нужно вникнуть в спецификацию хтмл и понять на какие стадии разбивается анализ хтмл. Это я уже не буду тут описывать, всё есть в свободном доступе.
Могу лишь вас заверить, что корректность бенчмарка подтверждена не одним человеком. Более того, даже теми кто пилит серво.
> Каждый тест парсится меньше чем за 1мс (0.00001). Там нечего тестировать на
> скорость, это тесты на корректность.Это нормально для тестов, но обычно в таких случаях их просто запускают нужное количество раз в цикле. Что мешало сделать так?
> Могу лишь вас заверить, что корректность бенчмарка подтверждена не одним человеком. Более
> того, даже теми кто пилит серво.Ну если уж общались с ними, то может они озвучивали предположения о причинах того, что скорость разнится то в два раза, то в десять.
>Сравнение с парсером на Rust - http://lexborisov.github.io/benchmark-html-persers/Упс.
P.S. Да, некрасиво получается. С другой стороны, кто-то, вообще, на ASM'е пишет.
P.P.S. Больно всяким бидонистам? Обидно? Ну так что делать-то? У низкоуровневых (при наличии мозгов у прогера) - оверхеда-то - нет.
P.P.S.S.
Слава-слава бидонистам! (нужную фигню - вставить)
Прирожденным оптимистам, (на предмет проца и памяти)
Кто способен в поле чистом
Всю систему положить! (без комментариев. Наблюдал)
Не ругай меня, родная, что накодил тут г..на я :D
> на я :DНу что вы, на прогрессивном языке D получилось бы раз в 200 быстрее.
То что ты наблюдал в кабинете информатики своего ПТУ это конечно важные наблюдения, но реальность "немножко" другая. Стыдно не знать что к питону подключаются всякие сишные библиотечки, совмещая скорость Си и простоту питона. К примеру есть вполне себе массовый и шустрый питоновский парсер grab, который написан вокруг обвязки сишной библиотеки lxml. Работает и шустро и просто. Больно, да?
На perl обвязка еще быстрее.Совсем больно?
> На perl обвязка еще быстрее.
> Совсем больно?Во первых, то что на перл быстрее - надо пруф.
Во вторых, больше обвязок, хороших и разных.
> То что ты наблюдал в кабинете информатики своего ПТУ это конечно важные
> наблюдения, но реальность "немножко" другая. Стыдно не знать что к питону
> подключаются всякие сишные библиотечки, совмещая скорость Си и простоту питона. К
> примеру есть вполне себе массовый и шустрый питоновский парсер grab, который
> написан вокруг обвязки сишной библиотеки lxml. Работает и шустро и просто.
> Больно, да?Солнышко, ты хоть усрись, но конечный продюкт, транслируемый в машинный код всякие парсеры-херарсеры не превзойдут. Все равно что сказать: наша картонная мороженка круче Вашей нативной из молока! Всегой-то надо отшелушить десяток слоёв картона. А там - тот самый пломбир.
> x86_64-apple-darwin15.3.0Не интересно.
Полезнее было бы вместо очередного коммента про проявление отсутствия интереса выложить свои тесты. Пусть даже если эти тесты были сделаны на твоей любимой десяточке.
> Полезнее было бы вместо очередного коммента про проявление отсутствия интереса выложить
> свои тесты. Пусть даже если эти тесты были сделаны на твоей
> любимой десяточке.Я могу порыть интернеты, бенчмарки были выложены пару месяцев назад. Тогда, после публикации на reddit, люди тестировали на разных платформах и согласились с результатом. Весь код открыт.
html5ever в нынешнем виде не предназначен для использования в продакшне. Это по сути заглушка для прохождения тестов, которая позже будет полностью переписана. Все делающие выводы из этого сравнения, извините за мой французский, некомпетентные идиоты.
Не нужно ругаться. Откуда у вас эта информация?Где-то три-четыре месяца назад мне писали из мазилы (на работу звали), где некий сотрудник среди прочего утверждал, что в данный момент делаются тюнинг и оптимизации кода. Речи о заглушках и полном переписывании не шло. Хотя я не исключаю, что ребята таки соберутся и перепишут парсер полностью.
В данный момент они утверждают, что их парсер: High-performance browser-grade HTML5 parser
Но и я на месте стоять то не буду.
>Код написан на языке СиДырки присутствуют?
Количество не найденных ещё дырок всегда бесконечно (цэ).
А всё почему? Потому, что ошибка неисчерпаема, как атом.
Как Electron.
Ну, вообще-то реальный веб это не HTML5.Парсер для настоящего (а не сферического в вакууме) браузера, к сожалению, должен поддерживать различные ухищрения чтобы парсить кривой HTML и XHTML различных версий.
Это веб пятилетней давности. Сейчас - либо HTML5, либо что-то, где идеальная отрисовка на фиг не нужна.
> Ну, вообще-то реальный веб это не HTML5.
> Парсер для настоящего (а не сферического в вакууме) браузера, к сожалению, должен
> поддерживать различные ухищрения чтобы парсить кривой HTML и XHTML различных версий.Всё это парсер делает. Всё ровно так же как современные браузеры. Спецификация HTML оговаривает что и как должно происходить в "непонятных" ситуациях.
В спецификации можно посмотреть здесь:
An introduction to error handling and strange cases in the parser:
https://html.spec.whatwg.org/multipage/syntax.html#an-introd...Adoption agency algorithm:
https://html.spec.whatwg.org/multipage/syntax.html#adoption-...
> Не испытывает проблем если на вход подать бинарный файл или невалидный HTML;
Ждём новостей об уязвимостях. Хотя постойте.. нет, никто это не будет использовать.
Уже используют.
Замечательно. Правда, я схему парсинга скрипта неосилил, поэтому вопрос: если в javascript-строке попадется </script> он будет считаться закрывающим тэгом как у всех или нет?
> Замечательно. Правда, я схему парсинга скрипта неосилил, поэтому вопрос: если в javascript-строке
> попадется </script> он будет считаться закрывающим тэгом как у всех или
> нет?Там всё не так сложно, если долго смотреть на картинку)
Да, будет считаться закрывающим, так требует спецификация.
html5ever собирался с флагом --release?
> html5ever собирался с флагом --release?Да, конечно.
А как в тестах проверялась корректность результатов? Т.е. что полученный вариант дерева во всех 4-х тестах на выходе совпадает. А то можно написать самый быстрый парсер, который будет выдавать на выходе полную ерунду. но быстро
Хм, лично меня (в разумных пределах) скорость не очень волнует. Но вот если разработчику будет, в отличие от хромозилл, не плевать на мнение пользователей - это будет основной фичей. Начиная, скажем, от изначальной разработки с учётом возможности эффективно резать/править контент (адблокеры и прочее) и заканчивая удобным контролем из внешнего софта. Или, допустим, возможность подгрузки сишных плагинов, имеющих те же возможности, что и родные компоненты.
расшифруй что значит не плевать на пользователей милок, с чего ты взял что если к твоему мнению не прислушались - то значит плюют на пользователей?
Да. именно это и значит. Примеры я перечислял. А ещё есть многолетние баги, зато какой-нибудь покет запихнуть - это пожалуйста.Вот на разработчиков им не плевать, это да. А как защищать пользователя от кривых рук и эгоистичности этих разработчиков - так в кусты.
а с чего ты взял что ты это все? в твоем приложении используется множественное число, но текст говорит что проблема специфична для тебя.Кроме того, это же opensource молодой человек. У тебя есть исходники и ты можешь это все исправить сам, или можешь заплатить кому-то кто сделает это за тебя, если это важно именно для тебя.
Ну вот я так считаю, что проблема не специфична только для меня. На основании того, что вижу кругом, в том числе здесь на опеннете - можете глянуть на любую новость о мозилле, например.Форкать в этих монстров в одиночку - нереально, организовывать команду - лично для меня мороки много. Появится что-то подходящее - поучаствую, кодом или деньгами. Вон, на сабж донейтить - хоть сейчас.
А вообще - читать нотации идите... да хоть лесом, например.
Если разработчику будет не плевать на мнение пользователей - то шансов как раз нет, потому что толпу пользователей, желающих Chrome, но с перламутровыми пуговицами, вы никогда не перекричите.
Поэтому им надо давать возможность пришить эти самые пуговицы. Как было в мозилле, только круче - чтобы можно было влезть в сами движки.
так вам дали эту возможность. Открыли код. А что за вас еще и пришить должны?
А вы заплатили за эту работу - которая нужна именно вам?
Во-первых, там что открыли, что нет - сложность кода такая, что если нет специализированного API игра не стоит свеч - хоть сам делай, хоть кого-то нанимай, больно дорого. На то, чтобы въехать в код там месяц фуллтайм нужен примерно.Во-вторых, я в гробу видел самостоятельно подобное поддерживать (а там правки в DOM-движок нужны, и немаленькие) или бодаться с корпоративной бюрократией, чтобы подобное приняли в апстрим.
В-третьих, у них много ценностей, которыя я не разделяю - попросту говоря, я не хочу их улучшать, я хочу чтобы они были настолько хреновыми, насколько возможно. От поддержки винды до социальных фич.
Вот за то, чтобы подобная хрень не повторялась, я платить готов - в частности, донейтить автору сабжа в надежде, что получится вещь с более вменяемой архитектурой и направленностью развития.
P.S. у вас какой-то инвертированный взгляд на вещи. "Открытый код" для меня - это дефолт. Закрытый - извращение, для использования которого нужны какие-то особые основания. Поэтому не надо мне баек про "открытый код" как великую милость.
> Во-первых, там что открыли, что нет - сложность кода такая, что если
> нет специализированного API игра не стоит свеч - хоть сам делай,
> хоть кого-то нанимай, больно дорого. На то, чтобы въехать в код
> там месяц фуллтайм нужен примерно.какая разница - сколько. Тебе дали возможность? или нет? Теперь ты ноешь что это сильно сложно для тебя ?
Вы не помните сколько из-за XUL в мозилле было проблем?
Хорошая архитектура - это очень сложно.
Я как раз с ним проблем не припомню. кроме, разве что, тормозности - дык это от того, что они его адово переусложнили и зачем-то прибили к джаваскрипту. А по нынешним временам можно вообще Qt брать и не париться.
> кроме, разве что, тормозности - дык это от того, что они его адово переусложнилиЭто замечательно смотрится в одной фразе с утверждениями о том что архитектура это просто, и проблем с XUL нет.
Особых противоречий нет.
Не было проблем - то есть от него, грубо говоря, никто не умирал. Да, можно сделать быстрее и проще, но можно и оставить как есть.А сложная архитектура может быть, скажем, внутри движка рендеринга страницы, но не выпускать из него эту сложность и организовать плагинную архитектуру - не ахти как сложно.
> Особых противоречий нет.
> Не было проблем - то есть от него, грубо говоря, никто не умирал. Да, можно сделать быстрее и проще, но можно и оставить как есть.Это по состоянию на 2016 год "можно оставить". Вы не помните как оно тормозило именно из-за архитектурных решений вообще и XUL в частности?
> А сложная архитектура может быть, скажем, внутри движка рендеринга страницы, но не
> выпускать из него эту сложность и организовать плагинную архитектуру - не
> ахти как сложно.Очень сложно. Упрощенный, но надеюсь, не до потери смысла, пример - у вас появляется плагин, который работает с layout tree. Что-то добавляет, что-то вырезает, что-то расставляет по-своему - не суть важно. Пускать его после окончания фазы лэйаута - значит фактически заново делать лэйаут, что почти удвоит время рендеринга. Пускать его внутрь - это либо описывать всю внутреннюю кухню вашего layout engine - что само по себе задача большая и скучная, и это будет все равно непонятно для 99% потенциальных плагинописателей, а 99% из оставшегося процента все равно всё сделают неправильно. Либо придумывать такой API, который оставит за кадром все внутреннее алмазно-надфильное выпиливание, и обрамлять большим эксклюзивным локом весь плагин - и API нетривиальное, и тормоза будут как в том варианте с которого мы начали. И так везде, со всеми остановками.
Я на файрфоксе сидел с тех времён, когда он назывался firebird - с оперой вперемешку. Во всяком случае оно было достаточно юзабельным, чтобы не уходить.Да, пускать внутрь. Там же всё равно есть какие-то свои модули, верно? А если там они так мутно взаимодействуют, что без поллитра не понять - то либо разгребать, либо хорошо документировать. Либо через год-два самого разработчика этот бардак догонит, что, собственно, с мозиллой сейчас и произошло, а до этого - с оперой. Принцип "модули должны быть понятны стороннему человеку с разумными усилиями" - это как раз критерий хорошей архитектуры, особенно на сях, где бороться с бардаком сравнительно сложно.
> Во всяком случае оно было достаточно юзабельным, чтобы не уходить.На юниксах особенно некуда было уходить. А на всех остальных платформах никто массово долгое время и не приходил, пока мощности процессоров не возросли, стоимость памяти не обвалилась.
Можно ли было сделать не так тормозящий XUL? Можно, но для хорошей имплементации хорошей архитектуры нужно еще на порядок больше усилий.> Да, пускать внутрь. Там же всё равно есть какие-то свои модули, верно?
> А если там они так мутно взаимодействуют, что без поллитра не
> понятьНе мутно, но сложно. Не всякое сложно - мутно, хотя и из наблюдений за софтверным ландшафтом чаще всего складывается именно такое впечатление.
Посмотрите на редкие хорошие проекты - LuaJIT, Yesod. Они не мутные, но они сложные.> то либо разгребать
Уменьшать связность компонентов, упрощать логику их взаимодействия и увеличивать их размер? Будет очень медленно.
> либо хорошо документировать.
Этот кейс я описал. Он ничему не поможет. Либо это будет краткое, даже пусть и точное описание ("моноид в категории эндофункторов"), которое никому ничего не даёт, либо толстый учебник, который никто не будет читать и на поддержание которого в актуальном состоянии будет уходить 99% времени. К тому же таланты к написанию хороших учебников есть у довольно малой части популяции.
> Либо через год-два самого разработчика этот бардак догонит, что, собственно, с мозиллой сейчас и произошло
Это разные проблемы, в общем случае ортогональные. LuaJIT, например, бардак не догнал.
> Принцип "модули должны быть понятны стороннему человеку с разумными усилиями" - это как раз критерий хорошей архитектуры
Как лозунг на стенку для воспитания джуниоров в правильном духе - годится.
> особенно на сях, где бороться с бардаком сравнительно сложно.
От языка эти вещи очень мало зависят. В разных языках бардак выглядит немного по-разному и создается немного разными средствами - только и всего.
А с чего ты взял что проблема специфична только для него? Ты пробовал писать багрепорты авторам? Или думаешь он единственный кто пробовал?
> А с чего ты взял что проблема специфична только для него? Ты
> пробовал писать багрепорты авторам? Или думаешь он единственный кто пробовал?Писал и не раз. Когда это было интересно автору он правил, нет - patches are welcome.
А вы не пробовали присылать патчи авторам вместо того что бы скулить "ах бага не фиксится" ?
Кстати - куда донейты слать?
Хороший вопрос. Я им не задавался и даже не знаю как это организовывается. Вот пару месяцев назад мне предлагали биткоинов, но я как-то застеснялся и отказался. Да и они незаконны у нас, вроде.
У вас - это в России? Насколько я понимаю, не то чтобы незаконны, скорее власти пока сами решить не могут, как к ним относиться. Но счёт в палке (и соответствующая кнопка Donate) точно возможны.А если помечтать - то проект на indiegogo с какого-то момента был бы к месту...
Ждем выход браузера на этом деле.
Вот это проектик... Автор молодец!P.S. Гулять так гулять! Я бы еще посмотрел парсер на асме :) Лет 10 назад какой-то профессор сообщал, что разработал супербыстрый парсер с использованием SIMD-инструкций. Там вроде там неплохое ускорение получалось.
SIMD-инструкции используются в довольно небольшой части парсинга, такой как проматывание до искомого символа, например.
И сюда их встроить совсем несложно.
Интерестно, а можно будет потом этот "браузер" (парсер+рендерер) портануть на ARM11 для Symbian 9.x с помощью P.I.P.S.?
Стотыщный парсер протухшего HTML - оно надо? Гипертекст ущербен изначально, его основной смысл был в простейшем форматировании + ссылки (типа как сейчас markdown). Но совр. сайты и принципы дизайна ушли намного дальше даже полиграфии, поэтому без нового языка веб тихо деградирует и наполняется разной говённости сайтегами, где дизайнер тратит уйму времени на элементарные вещи.
Уже давно настало время за языком, неким гибридом внутреннего формата Adobe Illustrator и XAML.
Ну, молодой человек, раз уж вы сами вышли к доске, расскажите нам о внутреннем формате AI.
Мы вас внимательно слушаем.
В старых версиях -- PostScript, в новых -- PDF.
Ну вот! А я-то и не подозревал.
Но мы должны идти глубже!
Вопрос первый: а что такое, собственно, PDF?
Вопрос второй: а что, в браузере правда не хватает еще одной ВМ, теперь еще для обсчета ПостСкрипта? Его просто распарсить недостаточно, в отличие от.
Вопрос третий: а со всей массой написанных за последние 20 лет скриптов и стилей мы будем прощаться без всякого сожаления?
Вопрос ключевой а зачем нам вся эта головная боль, если уже существует SVG?
Переписать React на PostScript - я хотел бы на это посмотреть!
А зачем нужно парсер HTML делать многопоточным? По-моему, даже у компиляторов промышленного уровня парсеры не делают многопоточными, потому что основное время тратится совсем не на парсинг.
Затем что быстрый парсер нужен далеко не только компиляторам.
Я бы даже сказал что компиляторам он нужен в последнюю очередь.
Прирост в скорости разбора среднестатистической веб-страницы будет практически незаметен, зато сложность и ресурсоёмкость многопоточного парсера будет ощутимо выше.А в компиляторах быстрые парсеры нужнее, потому что, в отличие от браузеров, компиляторы тратят большинство времени именно на компиляцию, а не на ожидание данных по сети и рендеринг.
Кому он будет незаметен?
Тому кто разбирает тысячи страниц в секунду, например, безо всякого рендеринга?
В этом случае да, согласен.
И, кстати, именно поэтому в GCC, в конце концов, отказались от bison и переписали парсер вручную.
> Поддерживает C99;Важная особенность? :)
Нет, но глаз радует! :)
Вот будете в прошлое путешествовать, сразу поймёте.
Тогда надо было написать "поддерживает ООП" или что-нибудь "визуальное". Школота это понимает.
Жду не дождусь нативного браузера под андроид.>Возможность добавлять, изменять и удалять элементы и их атрибуты;
Это киллер-фича (при соотв реализации).
К примеру, запретил
document.write
(все равно им одну рекламу вставляют)
И весь этот шлак удаляется на уровне парсинга, соотв не надо исполнять егойный выхлоп.
При этом сайт может остаться работоспособным и динамичным.
> К примеру, запретил document.writeКто же вам мешает провести натурный эксперимент? Поправьте пару строчек отвечающих за обработку document.write в Chromium или Firefox, да и пройдитесь по интернетам.
Спасибо, отличный софт!
Всегда рад помочь!
Неужели я вижу что-то, написанное не на новеньком модном Go/Rust/etc.?
На страницы таблоидов еще изредка попадает что-то написанное на Scala, но всё реже.
Clojure и D, недавние фавориты, уже совсем забыты.
> While I've never used html5ever it's landing page mentions that the DOM representation is pluggable (and suggests that the DOM included is mostly for demonstration purposes). Based on your benchmark repo it seems you're using a very simple C lib api wrapper around html5ever that indeed uses the proof-of-concept DOM.
> So you're benchmarking [i]something[/i], I'm just not sure it really means much (it's not the DOM servo uses, and even if you used that; it's not an apples-to-apples comparison since a real browser DOM is likely meant to be fast at post-load JS+CSS integration, and not just quick building).
> Personally, I think misleading benchmarks simply distract from a pretty cool pet project, so I'd just get rid of them (or think about with what you can make realistic comparisons, and how)https://www.reddit.com/r/programming/comments/4snfz7/the_fir...
Читал. Странный комментарий. Автор предполагает и он не прав.
Все исходники в публичном доступе, всё можно посмотреть и потрогать.
Прекрасный проект, спасибо вам. Попробую написать обвязочку для luajit
Вам спасибо! Для вас делаю.
Было бы крайне здорово. Вот ещё бы кто с обвязочкой для python помог.
Джва года ждал. Когда уже запилят браузер? Я недавно видел принципиально новый пармер javascript на Си.
Дело это не простое, но реализуемое. По прогнозам сложно что-то сказать. Могу сказать одно, что это дело не двух недель и даже не двух месяцев.Можно ссылку на js на сях?
http://duktape.org/Он достаточно тормозной по сравнению с v8 и уж тем более luajit, но JS спецификациям, вроде бы, соотвествует. Еще есть v7 от cesanta, но там бездна GPL оккупации и весьма специфический стиль. Со скоростью, когда я его смотрел, были катастрофические проблемы.
Очень интересный набор фич и производительность, спасибо за работу!Жалко, что проекта не было, когда я искал подходящий (как минимум, по скорости) парсер html для своего rspamd - пришлось написать собственный велосипед, заточенный только под фильтрацию спама. Впрочем, возможно, будет иметь смысл перейти на ваше решение в будущем.
Спасибо!Если перейдете на MyHTML то дайте знать, интересно кто использует у себя и как.
