Да, дурацкое SEO с этим придурочным лайтхаусом, где почему-то решили, что юзер не хочет пялиться на пустой экран пока скрипты загрузятся, распарсятся и исполнятся.
Динамика с адекватным cache-contol + CDN тоже неубиваемая штука
Яростно плюсую насчёт раздельных запросов. Http/2 уже десять лет как везде поддерживается, оверхед у трёх параллельных запросов уже почти нулевой. А один-два из них, глядишь, и попадут или в кэш браузера, или в кэш эджа CDN; и скорость ответа быстрее, и нагрузка на бэк меньше.
Стили конечно особняком стоят, соглашусь. Но тут есть нюанс: Бандлер постарается сохранить порядок импортов в выхлопе, но совершенно не факт, что у него это получится если структура чанков станет сложнее плоского списка: при наследовании энтрей и аснхронном импорте. Хорошо, что у нас теперь есть @layer, и мы можем вручную устанавливать специфичность, а не полагаться на порядок импорта!
А IDE — ну так у IDE есть оператор. Вводить автомат чтобы он огородился от действий других автоматов — Скайнет уже победил?)
Чувствую, что нахватаю минусов, но… не очень понимаю, зачем люди сортируют импорты.
От этого же нет практической пользы: машинам наплевать на порядок, а люди всё равно эту простыню импортов не читают и проматывают сразу на реализацию.
Я видел мерж реквесты, которые откладываются на день из-за неправильного переноса строки между импортами. Я видел мерж конфликты от того, что кто-то решил отсортировать импорты по алфавиту. Человеческие усилия и время впустую, и чего ради?
Кажется, вы изобрели японскую ISO-2022-JP, со всеми её минусами. Из-за переключения режима кодирования эта кодировка сложна при обработке строк и создаёт риски XSS, настолько, что современные браузеры её или не автодетектят или вообще не поддерживают.
Её «младшая сестра» Shift-JIS проще, но даже её уже почти полностью вытеснила UTF-8.
Ну вот я не вижу, где в примере о бронировании номера хоть какая-то транзакционность или просто атомарность. Незанятость номера проверяется, ага. А если через 1 мс она изменится потому что кто-то другой забукал номер? Если всё это завёрнуто в одну большую транзакцию, то где обработка нарушения ограничений при её коммите?
Похоже, что эти безусловно красивые абстракции только помешают довести этот прототип до уровня production ready
Пишу: для получения списка элементов (например, имена файлов или список урлов, ничего не писал про их содержимое!), нужно прочитать объект-коллекцию (например, директорию), вы говорите, что это штука инородная и чуждая.
А потом говорите, что чтобы получить метаданные файла нужно прочитать файл директории.
Просто мысли вслух по поводу круда (не статьи), если позволите.
Мы можем создать элемент, прочитать его, обновить и удалить. А как насчёт получить список элементов? В этом месте говорят: легко! Это тоже Read, но не элемента, а коллекции. Но по такой логике создание и удаление элемента — это просто обновление коллекции, верно. Тогда зачем в C.R.U.D нужны C и D?
Может быть, это было актуально для HTTP/1.1, но с HTTP/2 браузер может загружать не меньше сотни ресурсов за раз, при этом у каждого запроса внутри коннекции есть приоритет.
Дефёрнутые скрипты грузятся с приоритетом Low Стили — Highest Картинки с Low пока не попадут во вьюпорт, после чего их приоритет динамически повышается до High. Полная таблица тут: https://web.dev/articles/fetch-priority
Поэтому можно сильно не переживать, что кто-то у кого-то будет сильно канал отъедать. К тому же, через fetchpriority можно приоритет подтюнить. Например, если заведомо известно, что одна конкретная картинка будет показываться на первом экране, не грех ей поставить fetchpriority=high
Поэтому скрипты надо подключать перед закрывающим тегом , а не в секции .
Тут, похоже, парсер теги съел.
Если это про подключение скриптов перед закрывающим <body>, то уж сильно дедовский метод. Лучше таки подключать их в <head>, но с атрибутом defer и после стилей. Так они пораньше начнут потихоньку грузиться по сети с приоритетом Low не дожидаясь того, как весь ответ html долетит целиком
Как только данные приходят, соединение закрывается, и клиент сразу же открывает новое. <…> Именно на базе этого подхода реализованы технологии вроде Server-Sent Events (SSE).
Нет, это неправда, не вводите людей в заблуждение! SSE не закрывает соединение после отправки сообщения, у вас же на диаграммах это изображено
Ну справедливости ради, в http/0.9 тоже никаких заголовков не было, был один-единственный метод и ноль майм-типов. И обратную совместимость ломали уже три раза, с каждой мажорной версией. Может быть, и не технические ограничения перевесили чашу весов
Да, дурацкое SEO с этим придурочным лайтхаусом, где почему-то решили, что юзер не хочет пялиться на пустой экран пока скрипты загрузятся, распарсятся и исполнятся.
Динамика с адекватным cache-contol + CDN тоже неубиваемая штука
Яростно плюсую насчёт раздельных запросов. Http/2 уже десять лет как везде поддерживается, оверхед у трёх параллельных запросов уже почти нулевой. А один-два из них, глядишь, и попадут или в кэш браузера, или в кэш эджа CDN; и скорость ответа быстрее, и нагрузка на бэк меньше.
Стили конечно особняком стоят, соглашусь. Но тут есть нюанс: Бандлер постарается сохранить порядок импортов в выхлопе, но совершенно не факт, что у него это получится если структура чанков станет сложнее плоского списка: при наследовании энтрей и аснхронном импорте. Хорошо, что у нас теперь есть
@layer, и мы можем вручную устанавливать специфичность, а не полагаться на порядок импорта!А IDE — ну так у IDE есть оператор. Вводить автомат чтобы он огородился от действий других автоматов — Скайнет уже победил?)
Чувствую, что нахватаю минусов, но… не очень понимаю, зачем люди сортируют импорты.
От этого же нет практической пользы: машинам наплевать на порядок, а люди всё равно эту простыню импортов не читают и проматывают сразу на реализацию.
Я видел мерж реквесты, которые откладываются на день из-за неправильного переноса строки между импортами. Я видел мерж конфликты от того, что кто-то решил отсортировать импорты по алфавиту. Человеческие усилия и время впустую, и чего ради?
Кажется, вы изобрели японскую ISO-2022-JP, со всеми её минусами. Из-за переключения режима кодирования эта кодировка сложна при обработке строк и создаёт риски XSS, настолько, что современные браузеры её или не автодетектят или вообще не поддерживают.
Её «младшая сестра» Shift-JIS проще, но даже её уже почти полностью вытеснила UTF-8.
Ну вот я не вижу, где в примере о бронировании номера хоть какая-то транзакционность или просто атомарность.
Незанятость номера проверяется, ага. А если через 1 мс она изменится потому что кто-то другой забукал номер?
Если всё это завёрнуто в одну большую транзакцию, то где обработка нарушения ограничений при её коммите?
Похоже, что эти безусловно красивые абстракции только помешают довести этот прототип до уровня production ready
SQL-транзакций в языке бизнеса нет, поэтому и в коде не будет?
Я вас не понимаю.
Пишу: для получения списка элементов (например, имена файлов или список урлов, ничего не писал про их содержимое!), нужно прочитать объект-коллекцию (например, директорию), вы говорите, что это штука инородная и чуждая.
А потом говорите, что чтобы получить метаданные файла нужно прочитать файл директории.
Ну как так?
Я имею в виду самый обычный листинг. Чтобы получить список файлов в папке, не обязательно же читать их содержимое?
Understandable, have a nice day.
Просто мысли вслух по поводу круда (не статьи), если позволите.
Мы можем создать элемент, прочитать его, обновить и удалить. А как насчёт получить список элементов?
В этом месте говорят: легко! Это тоже Read, но не элемента, а коллекции.
Но по такой логике создание и удаление элемента — это просто обновление коллекции, верно. Тогда зачем в C.R.U.D нужны C и D?
Тут опечатка? Потому что изменять и модифицировать — это вроде одно и то же
Может быть, это было актуально для HTTP/1.1, но с HTTP/2 браузер может загружать не меньше сотни ресурсов за раз, при этом у каждого запроса внутри коннекции есть приоритет.
Дефёрнутые скрипты грузятся с приоритетом Low
Стили — Highest
Картинки с Low пока не попадут во вьюпорт, после чего их приоритет динамически повышается до High.
Полная таблица тут: https://web.dev/articles/fetch-priority
Поэтому можно сильно не переживать, что кто-то у кого-то будет сильно канал отъедать. К тому же, через
fetchpriorityможно приоритет подтюнить. Например, если заведомо известно, что одна конкретная картинка будет показываться на первом экране, не грех ей поставитьfetchpriority=highТут, похоже, парсер теги съел.
Если это про подключение скриптов перед закрывающим
<body>, то уж сильно дедовский метод. Лучше таки подключать их в<head>, но с атрибутомdeferи после стилей.Так они пораньше начнут потихоньку грузиться по сети с приоритетом Low не дожидаясь того, как весь ответ html долетит целиком
Если бы в английском были отдельно have-служебный и have-обычный-переходный (как haber и tener), вот это добавление got может и не понадобилось бы
Интересно, почему никто не упомянул svgo?
Выбрал картинку наугад.
Сырой вес: 374 346, при передаче клиенту она жмётся гзипом до 231 321 ("wire bytes").
После
npx svgo@latest: 79 409 несжатая, 27 860 по проводу.Похоже, это из какой-то древней методички, просто sha с солью уже давно недостаточно.
NIST рекомендует хотя бы PBKDF2 с хотя бы 600 000 итераций. (Грубо говоря, это sha256 выполненный 600 000 раз).
А ещё лучше, что-нибудь более специализированное и защищённое от перебора на видеокарте.
Пардон за душнения, я понимаю, что это пет-проект. Но не дай боже кто-нибудь это прочитает и в прод утащит)
Нет, это неправда, не вводите людей в заблуждение!
SSE не закрывает соединение после отправки сообщения, у вас же на диаграммах это изображено
Ну справедливости ради, в http/0.9 тоже никаких заголовков не было, был один-единственный метод и ноль майм-типов. И обратную совместимость ломали уже три раза, с каждой мажорной версией.
Может быть, и не технические ограничения перевесили чашу весов
Только векторный гипертекстовый фидонет, только харкор!
Поэтому и говорю, шапочка из фольги. Это оффтопик и есть, сорри, если не в тему