Здравствуйте, хочу задать какому-нибудь опытному просто Верстальщику, или FrontEnd разработчику такой "философский" вопрос: Как писать нормальную архитектуру своему сайту? Особенно если верстка с макета, знаете, нарисовано куча всякой фигни в хаос, а тебе из этого нужно сделать адаптивную структуру, и похожие стили сделать еще и побольше кодом чем фотками, а так же в краткие сроки. Неужели нет каких-то Фреймворков для именно "Стурктуры" Верстки? Не Bootstrap тупой, а как паттерны проектирования. Я не верю что нет. Но в гугле не нашел. Потому-что писать нормальную структуру с нуля, это либо убийство времени, либо мэга г**но-код. Что делать? С чего начать разгребать?
Не претендую ни на что, создавал для себя includeHTML
Просто посмотрите и решите: юзать или нет. Асинхронная/синхронная рекурсивная загрузка HTML, JS, CSS с функцией-обработчиком.
xmoonlight, очень понравился скрипт, полезный. Только async вариант не асинхронный, т.к ждёт загрузки 1. самой библиотеки ,2.html страницы. Т.е когда ваш скрипт погружен как async, нужной функции, очевидно, не будет.
Тру асинхронный вариант будет как раз через атрибуты тегов.
Для этого надо запускать не по window.onload,а по domcontentready, сам скрипт с async, и вообще сперва при загрузке скрипта запустить функцию, а потом и по загрузке дома. Будет прям очень быстро работать.
А ещё... Написать обертку с localstorage, и грузить туда, чтобы типа один раз всего грузить статику. Будет прям огонь
mr-troll, Спасибо за отзыв! Сохранил, буду оптимизировать.
Сохранять всю статику в локал-сторадж - думал, но решил, что или оффлай-приложение (т.е. всю статику храним на клиенте), или работаем в он-лайн: cache headers (управлять кешированием с сервера).
Дабы сэкономить место на клиентском устройстве (не засорять) - ПОКА решил не прибегать к сохранению в локал-сторадж HTML/JS/CSS-файлов/кусков (т.к. в основном работа в он-лайне всегда ведётся).
Только async вариант не асинхронный, т.к ждёт загрузки 1. самой библиотеки ,2.html страницы. Т.е когда ваш скрипт погружен как async, нужной функции, очевидно, не будет.
Речь шла немного про другое. Когда рендерятся теги - там загрузка HTML-частей идёт параллельно (включая рекурсивную загрузку при вложенности: внутри одного HTML-куска тег загрузки дргуого HTML-куска и т.д.).
Тру асинхронный вариант будет как раз через атрибуты тегов.
Вот тут - не понял... Поясните.
Для этого надо запускать не по window.onload,а по domcontentready, сам скрипт с async, и вообще сперва при загрузке скрипта запустить функцию, а потом и по загрузке дома. Будет прям очень быстро работать.
Она стартует и сейчас сама автоматически сразу, после инициализации функции. Зачем её запускать ДО DOM'а, если он ещё не готов и делать этой функции нечего (может я в логике что-то упустил, подскажите)?
Можно сделать флажок, типа enable_cache_in_local - внутри самой функции. Скорее всего когда грузят - выберут какой-то один вариант. Есть ещё sessionstorage если не засорять хочется.
Она стартует и сейчас сама автоматически сразу, после инициализации функции
Нет. Порядок событий такой:
1) Сперва весь html парсится в dom-content. Останавливая отрисовку на всех блокирующих ресурсах. Т.е. стили, скрипты без async, defer, или module. Когда они загрузились и отработали - запускается domcontentloaded, с домом уже можно работать.
2) потом начинают загружаться все картинки, ифреймы и прочие не блокирующие ресурсы, (например шрифты с font-display). Запускаются defer скрипты и т.п. Когда загрузились они - запускается window.onload.
Асинхронные скрипты - в любой момент времени, но до события window.onload.
Т.е. у тебя есть код
У тебя начнёт парсится дом. Дойдёт до асинк скрипта, начнёт его грузить асинхронно. Дойдёт до #menu, вставит div в dom. Начнёт грузить большой файл. Долго. Вероятнее всего уже на этом этапе отработает async скрипт, и должен, (по моей задумке) , запуститься первый раз. И собрать всё что он уже успел в доме найти. Например menu. Запустит асинхронную подгрузку и всё. Дальше браузер пойдёт параллельно обрабатывать стили, и потом грузить дальше весь остальной код в дом, включая #defer_load. Когда всё загрузит, наступит domcontentloaded, вот на него надо бы повесить уже второй повторный обработчик который пройдёт и начнёт асинхронно грузить то что скрипт не догрузил когда выполнился.
Потом начнут грузиться картинки всякие. И наступит window.onload. Когда уже прям куча времени прошло. Т.е. если страничка вся грузится секунд 5-20 (поставь 3g эмуляцию в браузере), то критичные куски кода, например меню, будут без наполнения. Сайт будет не юзабельным, и юзер заплачет.
Тут правило простое. На window.onload вешают все незначительные вещи. яндекс.метрику, чаты типа Jivosite, и т.п.
Всё остальное надо запускать asap, либо по готовности документа.
При этом, ещё пункт про нужность двух запусков. Асинхронный скрипт может запуститься после domcontentloaded, а тут ты бац, и запустишь первый проход не зависимо от этого принудительно. =)
Начнёт грузить большой файл. Долго. Вероятнее всего уже на этом этапе отработает async скрипт, и должен, (по моей задумке) , запуститься первый раз. И собрать всё что он уже успел в доме найти. Например menu. Запустит асинхронную подгрузку и всё. Дальше браузер пойдёт параллельно обрабатывать стили, и потом грузить дальше весь остальной код в дом, включая #defer_load.
Сейчас так и происходит: при обходе DOM-"дерева", как только встречается следующий ресурс, он даёт команду на загрузку, а саму загрузку файла - не ждёт и парсит "дерево" дальше, ищя следующий объект вложения и т.д. до завершения обхода всего "дерева" целиком. (но да: всё это происходит в секции window.onload)
Как я понимаю:
1. HTML-код верхнего уровня - загрузится полностью (до начала ренедринга DOM, т.е.
Сперва весь html парсится в dom-content.
)
2. При первом ASYNC-вызове includeHTML.js (2-я строка в примере кода) функция будет рекурсивно грузить все ресурсы с 1-го уровня и вглубь до того момента, пока не обойдёт всё "дерево" зависимостей ПОЛНОСТЬЮ и ДО КОНЦА.
3. Поскольку функция будет уже проинициализирована, то все сторонние скрипты смогут использовать её вызов в любой момент сразу же после загрузки includeHTML.js через ASYNC.
Отсюда у меня возникает вопрос:
Когда всё загрузит, наступит domcontentloaded, вот на него надо бы повесить уже второй повторный обработчик который пройдёт и начнёт асинхронно грузить то что скрипт не догрузил когда выполнился.
Что значит фраза: "не догрузил, когда выполнился"?
Скрипт же, вроде, как я понимаю, должен будет загрузить ВСЕ РЕСУРСЫ В ТЕГАХ и НЕ В ТЕГАХ в первом проходе обработчиком и достаточно ЛИШЬ ОДНОГО ВЫЗОВА в ASYNC для того, чтобы всё загрузить?.... (или я что-то упустил?!...)
И ещё:
1. Если я помещу загрузку (именно непосредственную вставку HTML в теги) ранее рендеринга блокирующих ресурсов, не будет ли это визуально видно как "битая" страница превращается в нормальную в режиме анимации?
2. Кроме рендеринга HTML-кусков - есть ещё загрузка и js, и css, и здесь уже ВАЖЕН ПОРЯДОК загрузки (в зависимости от требований конкретного проекта)! Вот с ними как быть, если я добавлюсь в ASYNC? (т.е. как тут разрулить процесс загрузки корректно?...)
При этом, ещё пункт про нужность двух запусков. Асинхронный скрипт может запуститься после domcontentloaded, а тут ты бац, и запустишь первый проход не зависимо от этого принудительно. =)
От чего зависит: после он запустится или нет (от кода функции, от браузера "под капотом", или какой-то 3-й вариант ещё есть)?
И что значит
и запустишь первый проход не зависимо от этого принудительно.
? (если я буду напрямую грузить сверху по HTML-коду в ASYNC и без событий - то этого должно быть достаточно, как я понял...)
Как я понял, если я гружу его выше всех в ASYNC-режиме, то этого достаточно, чтобы не грузить его дважды: вторично - в domcontentloaded. (или снова я упустил что-то?)
xmoonlight, Щас постараюсь ответить. Можно либо в почту или скайп перенести дискуссию. либо раз уж это образовательный ресурс - продолжим флудить здесь. И я максимально простыми словами постараюсь изложить мысль.
Итак. Для начала. Схематичный код твоей библиотеки. Для тех кто не смотрел гитхаб:
Комментирую что происходит тут. В текущий момент, ты можешь скрипт загружать с async, без async, с defer как хочешь. Разницы НЕТ! Она в любом из вариантов (код библиотеки), спарсится до события window.onload.
Поэтому, она привязывается к этому событию. Потому что, оно, в любом случае, произойдёт после подгрузки этой библиотеки.
Далее. Отступление. Что такое загрузка dom и что такое блокирующий скрипт:
Контент документа не загружается сразу весь. Он парсится последовательно. Пример:
В данном случае начнёт загружаться html в domcontent. Загрузится титл. Дойдёт до скрипта и всё. Остановится. Параграф не попадёт на первом шаге в дом. Потому что скрипт foo - блокирующий. Браузер остановит вообще всё. Будет загружать foo.js, парсить его и выполнять. Только после этого добавит в дом параграф.
Почему? Потому что браузер ожидает что этот скрипт может коренным образом поменять весь дом.
Например в foo.js может быть document.write('<h1>somethign</h1>');
Т.е. это равносильно коду
Т.е. сначала он всё выполнит в яваскрипте, потом пойдёт парсить дальше, увидит что появился <h1> вставит его в документ. И только после этого вставит параграф.
Теперь рассмотрим событие domcontentloaded относительно скрипта foo.js. На момент выполнения foo.js - документ не загружен полностью, событие не наступило. Но, с уже загруженными частями документа (например <title>) скрипт может работать.
Допустим вместо foo.js - твоя библиотека includehtml.js , а вместо title некий <div data-src="menu.html"></div>
Что произойдёт. Браузер начнёт парсить dom, найдёт див. вставит. Найдёт твою библиотеку. Выполнит.
Библиотека просканирует текущий dom, в document.body будет только один тег, див. Оно его там начнёт асинхронно грузить, в это время уже пойдёт дальнейшая работа с дом. Он загрузит #load_later, и начнёт условно подгружать другие ресурсы если есть, картинки там, видео и т.п.
Когда всё загружено, выполнится window.onload, и начнёт уже загружаться твоя старая функция, (т.е. прошло куча времени с момента запуска), и загружит таки load_later.html
Далее. Нам надо рассмотреть два следствия. Что будет когда includehtml.js будет таки загружен как async, и что будет если поменять window.onload на document.DOMContentLoaded. Начнём по порядку.
Поменяем код на
<html>
<div data-src="menu.html"></div>
<script async src="includehtml.js">
bla bla bla some code
<div id="load_later" data-src="load_later.html"></div>
bla bla bla some code 2
</html>
Какое отличие? Скрипт не будет блокировать парсинг дом. Это раз. Т.е. браузер вставит тег скрипт за меню и пойдёт дальше парсить документ. Этот скрипт больше никак не влияет вообще на парсинг dom браузером.
includehtml.js - начнёт грузиться как минимум после того как в дом вставится <div data-src="menu.html"></div>.
Когда он загрузится и выполнется - он обработает menu.html. Будет ли на этот момент в доме #load_later или нет - не известно. Скрипт асинхронный, когда загрузится тогда загрузится. Он может выполниться раньше, а может позже. Может выполниться даже после ВСЕЙ ЗАГРУЗКИ DOM! Важно. Т.е. после события domcontentloaded.
Что будет если просто поменять window.onload - на domcontentloaded? Ну. скрипт очевидно будет обрабатываться быстрее, потому что сперва наступает domcontentloaded. Но что если скрипт асинхронный и загрузится после этого события? includeHTMLAuto внутри навешенного обработчика - не выполнится. А вот прямой вызов, который мы добавили вне обработчика - выполнится.
Т.е. схема работы при загрузке библиотеки будет:
1) выполнить includeHTML - какой есть
2) по загрузке dom выполнить что осталось.
При этом конечно надо поправить библиотеку так чтобы она поддерживала эти два вызова. Т.е. не загружала повторно menu.html например.
Т.е. схема работы при загрузке библиотеки будет:
1) выполнить includeHTML - какой есть
2) по загрузке dom выполнить что осталось.
При этом конечно надо поправить библиотеку так чтобы она поддерживала эти два вызова. Т.е. не загружала повторно menu.html например.
Вот это - более, чем понятно! :)
Что произойдёт. Браузер начнёт парсить dom, найдёт див. вставит. Найдёт твою библиотеку. Выполнит.
Библиотека просканирует текущий dom, в document.body будет только один тег, див. Оно его там начнёт асинхронно грузить, в это время уже пойдёт дальнейшая работа с дом. Он загрузит #load_later, и начнёт условно подгружать другие ресурсы если есть, картинки там, видео и т.п.
Вот тут, как я понимаю, и есть разрыв: неполный DOM при первом вызове!
И моя библиотека и браузерный DOM-обходичик будут в режиме race condition, используя HTML-текст (для заполнения DOM), как общий входной пул.
Может можно, чтобы не дёргать потом 2-й раз:
1. Как-то следить за "курсором" браузерного обработчика по HTML-разметке во время его прохода при формировании DOM?
2. Или попробовать обработать в своём скрипте (распарсить "вручную")
HTML-разметку при первом вызове (избегая DOM)? Но не будет ли это медленнее?
3. Или, после завершения обхода начального "дерева" (тех тегов, что уже обходчик браузера загрузил выше), проверить наступление события изменения DOM-структуры (если не дошли до события window.onload), и если DOM изменился - рекурсивно себя дёрнуть, чтобы не ждать window.onload ?
Т.е. как-то надо понять, как самому лучше превратиться в обходчика разметки напару с браузером не ожидая и не мешая друг другу)
Вот тут, как я понимаю, и есть разрыв: неполный DOM при первом вызове!
И моя библиотека и браузерный DOM-обходичик будут в режиме race condition, используя HTML-текст (для заполнения DOM), как общий входной пул.
В целом так, да. Но у тебя нет задачи race condition. Т.е. не надо пытаться отловить когда прям появился нужный элемент в доме. Достаточно просто запустить функцию когда будет собственно загружена сама функция. И всё. А потом загрузить когда будет готов весь дом.
Может можно, чтобы не дёргать потом 2-й раз:
1. Как-то следить за "курсором" браузерного обработчика по HTML-разметке во время его прохода при формировании DOM?
Увы, нельзя. Точнее можно, но это будет ООЧЕНЬ тормозить систему.
2. Или попробовать обработать в своём скрипте (распарсить "вручную")
HTML-разметку при первом вызове (избегая DOM)? Но не будет ли это медленнее?
Не очень понял. Но короче я предлагаю только 2 вызова. При этом второй раз скорее всего будет вхолостую, т.е первый уже всё сделает. Это быстро. Там единственный медленный момент, это
node.querySelectorAll('include,div[data-src],div[data-include]');
Я бы поставил жёсткое условие ставить на все нужные элементы - класс. Например - это конечно будет менее элегантно, зато селектор по классу ну очень быстрый. И после прохода как раз просто этот класс убрать - чтобы второй проход его не учитывал.
3. Или, после завершения обхода начального "дерева" (тех тегов, что уже обходчик браузера загрузил выше), проверить наступление события изменения DOM-структуры (если не дошли до события window.onload), и если DOM изменился - рекурсивно себя дёрнуть, чтобы не ждать window.onload ?
Ну моё предложение не привязываться к onload, а привязаться к domloaded, ну и дёргание себя, не рекурсивно а просто первый раз сам себя дёргаешь, а второй по событию. И всё. Этого на 100% достаточно.
Т.е. как-то надо понять, как самому лучше превратиться в обходчика разметки напару с браузером не ожидая и не мешая друг другу)
У Пола Айриша есть вроде выступления на тему как браузер что парсит. У кого-то ещё не помню.
У Дмитрия Сошникова можно про контексты исполнения почитать dmitrysoshnikov.com/ecmascript/javascript-the-core... там идея в том что вычисления в основном потоке - например синхронны. Например в момент твоей работы с dom - браузер временно тормознёт любую свою работу с дом.
Слишком часто дом дёргать не надо. 2 раза достаточно. Тут важно помнить, что большинство твоих обращений к dom могут вызвать realign, или даже полный reflow документа.
объясняю чо такое:
У тебя есть таблица на 10000 строк.
Браузер считавет кусок (chunk) информации, в несколько килобайт. захватив например 1000 строк. Кладёт в dom.
Параллельно начиная рисовать dom на экране. Типа шапку таблицы, где она расположена относительно других элементов, какая ширина, высота у неё, несколько строк первых. В это время html-парсер парсит дальнейший html в некий временный dom. Браузер заканчивает отрисовку и говорит чо там ещё у нас в доме? О, ещё 1000 строк. Перемещает из временного дом в основной и начинает рисовать их. Проверяя там всякие размеры снова, позиционирование, слои. Это называется realign, если вдруг в 1001й строке таблице контент оказался шире чем в предыдущих 1000. В этот момент ты говоришь браузеру чо там по тегам инклуд, querySelectorAll('include')? Браузер такой, блин, чо-то от меня хотят. Дайте мне dom весь какой прошли, заньте туда из временного не отрисованного дом 10000 элементов. Выдаёт тебе результат селектора. И такой, нифига ж тут дом поменялся, делаем пересчёт всего заного, и заново рисует тебе всю таблицу, понятно имея чуть больше данных, но всё равно ты его принудительно дёрнул её перерисовать. Поэтому если прям жёстко дёргать события изменения дома - то fps отрисовки печально просядет.
Поэтому и идея дёрнуть два раза. Один когда твоя библиотека подгрузилась. Второй когда дом и так уже весь готов и начально отрисован. (Рефлоу и репейнтов после загрузки конечно ещё много будет, когда там шрифты загрузятся, картинки, они тоже всё принудительно заставляют пересчитать, но это уже отдельная тема).
Простой
