Я вам доказал, что innerHTML внутри отрабатывает дольше на простом примере. Зафигачте 1000 элементов через innerHTML:
var html = "<div>Текст 1</div>...<div>Текст 1000</div>"
aaa.innerHTML(html)
B попробуйте создать те же самые элементы в цикле через дом добавляя их по одному в aaa.appendChild(node).
Скорость будет почти одинаковая. Это как доказательство, что основное время уйдет на оверхед.
Я опроверг ваше заявление:
Но innerHTML и DOMParser.parseFromString отрабатывает быстрее, чем постройка дом-дерева через методы DOM API по отдельности.
Опять же, выше я вам объяснил где будет выигрывать innerHTML.
Что это за синтетический тест, с измерением перфоманса на создание 1-2 дом узлов, когда один из них текстовый? Зачем это нужно делать через парсер адекватному человеку?
Вполне себе хороший тест. Показывает, что innerHTML медленнее. А точнее то, что вы не правы со своим заявлением, что он быстрее.
Давайте вы добавите в свой узел пару другую вложенных элементов, а еще назначите им атрибуты. И замерите снова.
Простите, но добавляйте сами, что хотите. Простым примером вам было показано как оно отрабатывает. Я хорошо знаю как оно устроено внутри и могу создать тесты там где inner выиграет и проиграет. Но выше я создал именно голые тесты, равные условия, чтобы показать, что вы не правы.
Дорого звать из js функции движка. innerHTML быстрее если нафигачить туда много HTML. Если сделать чистый тест по одному тегу, к примеру
<div>Текст</div>
и покрутить в цикле с реальным добавлением в текущий документ, то innerHTML проиграет в 3-4 раза.
Более того, если в innerHTML отдать сразу 1000 тегов и тоже самое создать с помощью дом то время выполнения будет почти одинаковое.
Но если в innerHTML зафигачить сразу кучу хтмл-а то он отработает быстрее. Потому, что он сразу передаст всё в движок и не будет делать вызовы по Н раз.
Отсюда, надо понимать, что и как использовать.
Код для примера:
1-2 mc
<div id="aaa"></div>
<script>
let aaa = document.getElementById("aaa");
let t0 = performance.now();
let node;
for (let i = 0; i < 1000; i++) {
if (node) {
aaa.removeChild(node)
}
node = document.createElement("div");
let text = document.createTextNode("Text " + i);
node.appendChild(text);
aaa.appendChild(node);
}
let t1 = performance.now();
let res = document.createTextNode("Time: " + (t1 - t0) + " milliseconds.");
aaa.appendChild(res)
</script>
7-8 mc
<div id="aaa"></div>
<script>
let aaa = document.getElementById("aaa");
let t0 = performance.now();
for (let i = 0; i < 1000; i++) {
aaa.innerHTML = "<div>Text " + i + "</div>";
}
let t1 = performance.now();
let res = document.createTextNode("Time: " + (t1 - t0) + " milliseconds.");
aaa.appendChild(res)
</script>
Ну, а как вы создадите ещё одно дерево? Понятно, что парсер можно создать один раз и держать его при себе. Всё остальное прийдется создавать каждый раз. Потому, что во время парсинга всё это используется/необходимо. Думаю, напишу статью о том как всё устроено в хтмл. Можете посмотреть в спецификацию: https://html.spec.whatwg.org/multipage/parsing.html#parsing-html-fragments
Собственно, по этому innerHTML крайне дорогая штука в браузерах. innerHTML — это и есть парсинг фрагмента. Всегда лучше пользоваться напрямую через интерфейсы.
Чанки (chunks) — фрагменты.
Браузеры процесят хтмл кусками. Прилетело по сети 4к данных, эти данные идут на парсинг и так далее. Данные могут быть прерваны в любом месте, соответственно и продолжить обработку надо уметь с того места где закончил. Но, тут магии нет, если ты посмотришь на спецификацию то поймешь, что она написана так, чтобы это работало "из коробки". Токенизатор на вход принимает codepoint (unicode) по одной штуки и решает куда дальше рулить. Это обычная стейт машина.
Фрагменты — парсинг хтмл фрагментов очень важен. Это так называемый innerHTML. Штука эта довольно тяжелая для выполнения. Как оно должно работать так же описывает спецификация. Тяжелая она потому, что для неё необходимо создавать новый парсер, новый Document объект и root element + всякая логика.
Сделать, хотя бы, парсинг хтмл быстрым задача тоже интересная.
Ты, конечно, молодой и активный. Но прежде чем делать громкие заявления изучи как устроены текущие браузеры, посмотри почему они все отрабатывают страницы одинаково (спецификации).
Конечно, фигачить из головы куда интереснее. Делать что-то по спецификациям нудное занятие.
Чтобы что-то сделать лучше необходимо понять текущие проблемы. Нужен опыт. У тебя, к сожалению, опыт отсутствует как в программировании так и в понимании браузерных движков.
О каком легаси вы пишете? В спеках всё довольно логично и понятно. Есть, конечно, шероховатости, но в целом всё ясно.
Как вы поймёте, что сайт «нормально» отображается с помощью вашего движка? Что это будет за урезанная спека которая сможет предоставить весь нужный набор опций для верстки и будет лучше чем сейчас?
Чтобы вам хоть как-то попытаться пропихнуть свою спеку вам надо стать гуглом, и то не прокатит.
Есть стандарт который все знают и поддерживают, опираются на него. Идея написать свой движок, но если чего отдавать на отрисовку гуглу за гранью разумного.
Важно, чтобы ожидания сходились с заявлениями. У вас, к сожалению, нет парсера HTML, CSS, у вас нет сериализаторов. Да и странно заявлять о сериализации даных. Куда важнее заявить о парсинге чанков, парсинге фрагментов. У вас нет работы с неймспейсами. Не знание HTML спецификации сразу кинулось в глаза после фраз о кавычках, это самое стандартное поведение, зачем это оговаривать отдельно? У вас есть что-то, что вы сами придумали и назвали это парсером HTML, CSS.
Я никак не пытаюсь «наехать». И я искренне обрадовался когда прочитал заголовок, но по факту у вас пустышка + непонимание базовых вещей. Если вы хотите, то можете написать мне, что нибудь да обсудим.
Я уже было обрадовался, подумал вот, есть такие же психи как и я. Но, посмотрев исходники разочаровался.
1) Каким спецификациям соответствует парсинг HTML? Я так понял, что вы из головы написали парсер. Штука эта давольно сложная, тем более чтобы написать её правильно с заделом на будущее. Судя по вот этому о скоростях мечтать не приходится. Это действительно весь HTML парсер? Это тоже странно выглядит.
2) Каким спецификация соответствует парсинг CSS? Опять же, судя по коду никаким. Вы просто взяли из головы то, что знаете о CSS и сделали для этого парсинг. Вообще, CSS раздербанить ни фига не простая задача. Уж поверьте моему опыту.
3) У вас не верно сделана сериализация HTML. Точнее сказать, она сделана из каких-то ваших соображений. В спецификации чётко описано поведение сериализатора.
К сожалению, вы не сможете показать страницу быстрее других, у вас для этого ничего нет.
А теперь попугаю, немного :).
У вас исходники всего этого дела занимают 312КБ. Чтобы хоть как-то оценить насколько ничего нет: в проекте lexbor один только html парсер занимает 1.8МБ. DOM, в котором почти ничего нет, только минимум для создания и удаления нод, элементов, атрибутов 100КБ.
Чтобы понять масштаб того, что надо делать посмотрите мой roadmap, и это процентов 10 от полноценного браузерного движка.
Ваши бы силы да в нужное русло.
Поправьте меня если я где-то ошибся.
Я далёк от дизайна. Но! Что конкретно хотел донести автор? Кто такой Артём? Возможно, это только предположение, но возможно подобные тексты лучше подходят для формата ФБ или ВК?
Так оно и есть. В самой первой своей статье, вроде в первой, я как раз и писал, что хочу добиться лёгкой встраиваемости движка. Там же я упоминал про игрушки, ui и что-то ещё. По этой причине я и пишу всё на Си без зависимостей. Это обеспечит лёгкую переносимость.
Я думал в направлении создать движок с простым и функциональным апи и предоставлять его по двум лицензиям: бесплатно для бесплатных/открытых проектов, платно для коммерческих. Именно с уклонов на веб-приложения.
Тут мне пока не понятно. Я больше программист. Решиться двигаться исключительно в одну сторону сам не могу. Нужен какой-то понимающий в этом деле партнёр, наверное.
Да, вы мыслите в верном направлении. Собственно, особых надежд на БОЛЬШИХ и нет, у них проблем хватает. Но, думаю многим будет интересно узнать как оно внутри с примерами кода и примерами как использовать.
Я ну пойму, вы что хотите доказать?
Я вам доказал, что innerHTML внутри отрабатывает дольше на простом примере. Зафигачте 1000 элементов через innerHTML:
B попробуйте создать те же самые элементы в цикле через дом добавляя их по одному в aaa.appendChild(node).
Скорость будет почти одинаковая. Это как доказательство, что основное время уйдет на оверхед.
Я опроверг ваше заявление:
Опять же, выше я вам объяснил где будет выигрывать innerHTML.
Вполне себе хороший тест. Показывает, что innerHTML медленнее. А точнее то, что вы не правы со своим заявлением, что он быстрее.
Простите, но добавляйте сами, что хотите. Простым примером вам было показано как оно отрабатывает. Я хорошо знаю как оно устроено внутри и могу создать тесты там где inner выиграет и проиграет. Но выше я создал именно голые тесты, равные условия, чтобы показать, что вы не правы.
При этом я дописал, что:
Нет. Не быстрее.
Дорого звать из js функции движка. innerHTML быстрее если нафигачить туда много HTML. Если сделать чистый тест по одному тегу, к примеру
и покрутить в цикле с реальным добавлением в текущий документ, то innerHTML проиграет в 3-4 раза.
Более того, если в innerHTML отдать сразу 1000 тегов и тоже самое создать с помощью дом то время выполнения будет почти одинаковое.
Но если в innerHTML зафигачить сразу кучу хтмл-а то он отработает быстрее. Потому, что он сразу передаст всё в движок и не будет делать вызовы по Н раз.
Отсюда, надо понимать, что и как использовать.
Код для примера:
1-2 mc
7-8 mc
Ну, а как вы создадите ещё одно дерево? Понятно, что парсер можно создать один раз и держать его при себе. Всё остальное прийдется создавать каждый раз. Потому, что во время парсинга всё это используется/необходимо. Думаю, напишу статью о том как всё устроено в хтмл. Можете посмотреть в спецификацию: https://html.spec.whatwg.org/multipage/parsing.html#parsing-html-fragments
Собственно, по этому innerHTML крайне дорогая штука в браузерах. innerHTML — это и есть парсинг фрагмента. Всегда лучше пользоваться напрямую через интерфейсы.
Я ему уже выше писал, что если захочет то пусть пишет мне лично, расскажу, что знаю.
Эх, вы либо вообще не понимаете о чём я пишу, либо, я даже не знаю. В общем, удачи вам.
Всё описано в спецификации. Там есть чудный алгоритм adoption agency algorithm, а так же reconstruct the active formatting elements.
Смотрим как оно работает в описании.
Следует помнить, что сайт заблокирован, под руку попали когда телеграмм блокировали.
Чанки (chunks) — фрагменты.
Браузеры процесят хтмл кусками. Прилетело по сети 4к данных, эти данные идут на парсинг и так далее. Данные могут быть прерваны в любом месте, соответственно и продолжить обработку надо уметь с того места где закончил. Но, тут магии нет, если ты посмотришь на спецификацию то поймешь, что она написана так, чтобы это работало "из коробки". Токенизатор на вход принимает codepoint (unicode) по одной штуки и решает куда дальше рулить. Это обычная стейт машина.
Фрагменты — парсинг хтмл фрагментов очень важен. Это так называемый innerHTML. Штука эта довольно тяжелая для выполнения. Как оно должно работать так же описывает спецификация. Тяжелая она потому, что для неё необходимо создавать новый парсер, новый Document объект и root element + всякая логика.
Сделать, хотя бы, парсинг хтмл быстрым задача тоже интересная.
Ты, конечно, молодой и активный. Но прежде чем делать громкие заявления изучи как устроены текущие браузеры, посмотри почему они все отрабатывают страницы одинаково (спецификации).
Конечно, фигачить из головы куда интереснее. Делать что-то по спецификациям нудное занятие.
Чтобы что-то сделать лучше необходимо понять текущие проблемы. Нужен опыт. У тебя, к сожалению, опыт отсутствует как в программировании так и в понимании браузерных движков.
Но шуму ты наделал много.
Как вы поймёте, что сайт «нормально» отображается с помощью вашего движка? Что это будет за урезанная спека которая сможет предоставить весь нужный набор опций для верстки и будет лучше чем сейчас?
Чтобы вам хоть как-то попытаться пропихнуть свою спеку вам надо стать гуглом, и то не прокатит.
Есть стандарт который все знают и поддерживают, опираются на него. Идея написать свой движок, но если чего отдавать на отрисовку гуглу за гранью разумного.
Важно, чтобы ожидания сходились с заявлениями. У вас, к сожалению, нет парсера HTML, CSS, у вас нет сериализаторов. Да и странно заявлять о сериализации даных. Куда важнее заявить о парсинге чанков, парсинге фрагментов. У вас нет работы с неймспейсами. Не знание HTML спецификации сразу кинулось в глаза после фраз о кавычках, это самое стандартное поведение, зачем это оговаривать отдельно? У вас есть что-то, что вы сами придумали и назвали это парсером HTML, CSS.
Я никак не пытаюсь «наехать». И я искренне обрадовался когда прочитал заголовок, но по факту у вас пустышка + непонимание базовых вещей. Если вы хотите, то можете написать мне, что нибудь да обсудим.
Размер тут как показатель, на глаз прикинуть.
Привет!
Я уже было обрадовался, подумал вот, есть такие же психи как и я. Но, посмотрев исходники разочаровался.
1) Каким спецификациям соответствует парсинг HTML? Я так понял, что вы из головы написали парсер. Штука эта давольно сложная, тем более чтобы написать её правильно с заделом на будущее. Судя по вот этому о скоростях мечтать не приходится. Это действительно весь HTML парсер? Это тоже странно выглядит.
2) Каким спецификация соответствует парсинг CSS? Опять же, судя по коду никаким. Вы просто взяли из головы то, что знаете о CSS и сделали для этого парсинг. Вообще, CSS раздербанить ни фига не простая задача. Уж поверьте моему опыту.
3) У вас не верно сделана сериализация HTML. Точнее сказать, она сделана из каких-то ваших соображений. В спецификации чётко описано поведение сериализатора.
К сожалению, вы не сможете показать страницу быстрее других, у вас для этого ничего нет.
А теперь попугаю, немного :).
У вас исходники всего этого дела занимают 312КБ. Чтобы хоть как-то оценить насколько ничего нет: в проекте lexbor один только html парсер занимает 1.8МБ. DOM, в котором почти ничего нет, только минимум для создания и удаления нод, элементов, атрибутов 100КБ.
Чтобы понять масштаб того, что надо делать посмотрите мой roadmap, и это процентов 10 от полноценного браузерного движка.
Ваши бы силы да в нужное русло.
Поправьте меня если я где-то ошибся.
Но не все браузеры его вразумеют, лучше пользовать '. Весь список.
Так как комментарии буквально одинаковые, ответил ниже.
Я думал в направлении создать движок с простым и функциональным апи и предоставлять его по двум лицензиям: бесплатно для бесплатных/открытых проектов, платно для коммерческих. Именно с уклонов на веб-приложения.
Тут мне пока не понятно. Я больше программист. Решиться двигаться исключительно в одну сторону сам не могу. Нужен какой-то понимающий в этом деле партнёр, наверное.