Да, мы не спешим очень быстро меняться и следовать за модой которая во фронте часто меняется. В этом плане да, не выросли. Неспешно используем Angular ещё с первой, js версии и постепенно дошли до 19-ой. Bootstrap 5-ой версии тоже закрывает часть наших задач. Он хорошо документирован, прост и продуман, в него легко погружать программистов. Менять его тоже пока не собираемся. Не спешим никуда, медленно и поступательно развиваемся.
У нас два приложения на 4+ и 5+ мегабайт в прод сборке. Чанки анализируем через http://esbuild.github.io/analyze/ после сборки ng build --stats-json Хороший анализатор. Рекомендую.
Прелоад не используем. Наоборот, грузим только то, что нужно сейчас пользователю. Приложение у нас с настроенным service worker'ом, он фоном смотрит на сервер и если был свежий релиз - сам тихонько загрузит все чанки и предложит обновиться в UI. Это удобно. Пользователь не отвлекается на загрузку и видит кнопку обновления только если все чанки были уже загружены браузером.
Да, холодный старт будет медленнее, но не могу придумать сценариев в нашем окружении где webpack был бы быстрее и оптимальнее Vite. Гибче, может быть, но не быстрее. Не зря на него официально перевели Angular. Надо смотреть ваше приложение, гонять его в Performance анализаторе консоли Google Chrome с разными настройками и искать узкое место. Сервер http2? Он корректно настроен? Надо смотреть зачем вам сразу при старте грузить много кода если можно показать UI, дать с ним работать и догружать куски интерфейса на ходу. Общих рекомендаций к сожалению не дам, надо в детали погружаться.
Не понимаю, что вы доказываете? Критика ради критики.
Вот смотрите, у нас Angular и Taiga UI, супер-крутая библиотека от Тинькова. Angular 16 выходит в мае 2023, а Taiga с поддержкой Angular через 15 месяцев, в августе 2024. Как в этом случае обновиться за 1-2 месяца после релиза?
Менять тайгу на что-то другое, переписывать код приложения и переучиваться всем на ходу? Ставить в legacy peer deps режиме и ловить баги? Если зависимостей мало или они быстро обновляются - можно порадоваться за вас. Если нет - обновляемся через 1-1.5 года после выпуска свежего ангуляра.
Обновление спустя 1-2 месяца после релиза - это круто. Вы молодцы, завидую.
Мы больше ориентированы на бизнес-процессы клиентов и их потребности. Технический долг возвращаем когда он в самом деле появляется.
У нас большая кодовая база и обновление спустя пару месяцев после релиза мы точно не сможем делать т.к. внешние зависимости могут быть несовместимы с новой версией по полгода и далее. Форкать чужие библиотеки и потом назад переходить с форка на основную ветку - не всегда оправдано.
"никаких side effects не возникает" - здесь вот не соглашусь. Это риск. Ни раз нарывались на регрессии как в Ng так и в свежих версиях библиотек. Для себя выбрали стратегию не частых обновлений, с вдумчивым и растянутым по времени бета-тестом. Когда сотрудники могут 1-2 месяца работать с next версией продукта и только после этого будет общий релиз.
Tree shaking сильно эффективнее работает с мелкими чанками
Один большой модуль даст вам более быструю полную загрузку приложения, но доступным для действия пользователя приложение станет заметно позже. Т.е. в браузере долгое время будет отображаться процесс загрузки, вместо (пусть даже частично) доступного интерфейса. Stand alone даёт более быстрый интерактив в браузере
Так же маленькие чанки дают возможность локально использовать Hot Module Replacement (HMR) для стилей и шаблонов. Это значительно ускоряет обновление в браузере при активной работе со стилями или html
Что делать если есть проблемы с исчерпанием лимита соединений
Смотрите детально почему вы загружаете много всего при старте. Это в самом деле необходимо?
Можно использовать супер-крутую штуку @defer - https://angular.dev/guide/templates/defer для lazy load части компонентов. Вы можете совсем не грузить код с которым пользователь не работает и делается это элементарно, без сложное конфигурации. У @defer есть разные стратегии загрузки кода - idle, viewport, interaction, hover, ... Возможно сможете перенести часть функционала на отложенную загрузку и облегчите приложение в целом.
В итоге мое мнение - чем меньше будут чанки тем лучше. Даже если их будет много.
Ну хотя бы цены на оборудование сравните — камера, эффекты, звук, по минимуму. Посчитайте цены в США, Москве и Хабаровске. Ещё среднюю зарплату прикиньте. Возможностей у нас меньше.
Несомненно все фильмы которые вы указали стоящие, но сделаны они были в США. У нас намного сложнее полноценный фильм любителям снять.
Для дальнего востока России это очень крутой проект, делают как умеют, на одном энтузиазме. Для Хабаровска это вообще можно сказать самородок.
Зря вы так грубо, добрее надо быть.
Отключаю JS и Flash по умолчанию по трём причинам:
1. Не доверяю вражеским сайтам. XSS, уязвимости в браузере/flash'е.
2. Компьютер у меня не быстрый, при 5-6 открытых вкладках с Flash и JS волшебством Firefox начинает тупить.
3. Для _чтения_ страниц JS понты и Flash реклама не нужна. Я же смогу прочитать текст без прекрасного кернинга?
Сайты которыми пользуюсь постоянно добавляю в белый список NoScript и Flashblock в два клика.
Все подобные писькомерки времени загрузки страдают одной проблемой — не учитывается _физическое_ расположение сервера и клиента.
Вы из Перми, пермский сайт загрузите быстрее чем я из Владивостока. У меня частенько трафик до Москвы идёт через Лондон. Да и каналы у всех разные.
Ping google.ru — 137мсек. Главная сайта webo — 3.2сек (быстро, но не очень).
Google Webmaster Tools говорит что мой Владивостокский, оптимизированный сайт (Page Speed Score: 95/100, 86кб страница с пустым кэшем) медленно грузится. Но умалчивает из какой точки мира он замеряет скорость.
Поэтому не удивляйтесь что у вас с автором разные цифры.
Статья красивая, диаграммы кошерны, но цифры для всех будут разными :)
> успешные спортсмены, как правило, изначально хороши
Ерунда, не согласен. Супер-вундеркинды от природы (люди с великолепной генетикой) хороши только по сравнению с офисным планктоном, но им нужны годы упорных тренировок чтобы достичь минимальных результатов в спорте высоких достижений.
Великий и ужасный Лэнс Армстронг восстановился после рака, химиотерапии и стал кататься ещё лучше. Не помню дословно, но он говорил как-то так:
— Мне жаль людей которые верят в чудо, в спорте нет чудес, выигрывает тот кто больше остальных работал.
— Я шесть часов в день кручу педали и поэтому выигрываю.
Пеле, Марадона и Аршавин тоже :) начали играть в футбол в 7 лет!
Емельяненко говорил про важность объема работы, проделанной на тренировке. Чем больше тем лучше.
DateInput в самом деле не использует widget factory, но есть такие планы :)
// TODO rename to «widget» when switching to widget factory
Подход описанный TheShock в сам деле часто встречается в сторонних плагинах и мне часто доставляет проблемы когда у плагина есть замкнутые, анонимные функции, а настроек для их кастомизации нет:
var privateMethod = function () {
// private method, used for plugin
};
Приходится править исходный код плагина и получать геморрой при обновлении.
У самого jQuery можно переопределять отдельные части. Например можно делать так при отладке/поиске узкого места:
$.fn.find = console.log;
Да, мы не спешим очень быстро меняться и следовать за модой которая во фронте часто меняется. В этом плане да, не выросли. Неспешно используем Angular ещё с первой, js версии и постепенно дошли до 19-ой. Bootstrap 5-ой версии тоже закрывает часть наших задач. Он хорошо документирован, прост и продуман, в него легко погружать программистов. Менять его тоже пока не собираемся. Не спешим никуда, медленно и поступательно развиваемся.
У нас два приложения на 4+ и 5+ мегабайт в прод сборке. Чанки анализируем через http://esbuild.github.io/analyze/ после сборки
ng build --stats-jsonХороший анализатор. Рекомендую.
Прелоад не используем. Наоборот, грузим только то, что нужно сейчас пользователю. Приложение у нас с настроенным service worker'ом, он фоном смотрит на сервер и если был свежий релиз - сам тихонько загрузит все чанки и предложит обновиться в UI. Это удобно. Пользователь не отвлекается на загрузку и видит кнопку обновления только если все чанки были уже загружены браузером.
Да, холодный старт будет медленнее, но не могу придумать сценариев в нашем окружении где webpack был бы быстрее и оптимальнее Vite. Гибче, может быть, но не быстрее. Не зря на него официально перевели Angular. Надо смотреть ваше приложение, гонять его в Performance анализаторе консоли Google Chrome с разными настройками и искать узкое место. Сервер http2? Он корректно настроен? Надо смотреть зачем вам сразу при старте грузить много кода если можно показать UI, дать с ним работать и догружать куски интерфейса на ходу. Общих рекомендаций к сожалению не дам, надо в детали погружаться.
Не понимаю, что вы доказываете? Критика ради критики.
Вот смотрите, у нас Angular и Taiga UI, супер-крутая библиотека от Тинькова. Angular 16 выходит в мае 2023, а Taiga с поддержкой Angular через 15 месяцев, в августе 2024. Как в этом случае обновиться за 1-2 месяца после релиза?
Менять тайгу на что-то другое, переписывать код приложения и переучиваться всем на ходу? Ставить в legacy peer deps режиме и ловить баги? Если зависимостей мало или они быстро обновляются - можно порадоваться за вас. Если нет - обновляемся через 1-1.5 года после выпуска свежего ангуляра.
Обновление спустя 1-2 месяца после релиза - это круто. Вы молодцы, завидую.
Мы больше ориентированы на бизнес-процессы клиентов и их потребности. Технический долг возвращаем когда он в самом деле появляется.
У нас большая кодовая база и обновление спустя пару месяцев после релиза мы точно не сможем делать т.к. внешние зависимости могут быть несовместимы с новой версией по полгода и далее. Форкать чужие библиотеки и потом назад переходить с форка на основную ветку - не всегда оправдано.
"никаких side effects не возникает" - здесь вот не соглашусь. Это риск. Ни раз нарывались на регрессии как в Ng так и в свежих версиях библиотек. Для себя выбрали стратегию не частых обновлений, с вдумчивым и растянутым по времени бета-тестом. Когда сотрудники могут 1-2 месяца работать с next версией продукта и только после этого будет общий релиз.
Здравствуйте. Мы на Vite и маленькие чанки это прекрасно.
Плюсы stand alone и небольших чанков
Возможность использовать lazy load компонентов прям в роутинге https://angular.dev/reference/migrations/route-lazy-loading
Tree shaking сильно эффективнее работает с мелкими чанками
Один большой модуль даст вам более быструю полную загрузку приложения, но доступным для действия пользователя приложение станет заметно позже. Т.е. в браузере долгое время будет отображаться процесс загрузки, вместо (пусть даже частично) доступного интерфейса. Stand alone даёт более быстрый интерактив в браузере
Так же маленькие чанки дают возможность локально использовать Hot Module Replacement (HMR) для стилей и шаблонов. Это значительно ускоряет обновление в браузере при активной работе со стилями или html
Что делать если есть проблемы с исчерпанием лимита соединений
Смотрите детально почему вы загружаете много всего при старте. Это в самом деле необходимо?
Можно использовать супер-крутую штуку @defer - https://angular.dev/guide/templates/defer для lazy load части компонентов. Вы можете совсем не грузить код с которым пользователь не работает и делается это элементарно, без сложное конфигурации. У @defer есть разные стратегии загрузки кода - idle, viewport, interaction, hover, ... Возможно сможете перенести часть функционала на отложенную загрузку и облегчите приложение в целом.
В итоге мое мнение - чем меньше будут чанки тем лучше. Даже если их будет много.
Для дальнего востока России это очень крутой проект, делают как умеют, на одном энтузиазме. Для Хабаровска это вообще можно сказать самородок.
Зря вы так грубо, добрее надо быть.
> Не смотря на то, что кэширование может быть настроено на уровне HTTP протокола,
> часто оно не удовлетворяет реальным требованиям.
Автор знает про http кэш, но ставит себе задачу кэшировать _клиентом_. Именно в это суть топика.
Кто-то в javascript видео декодер делает, кто-то эмулятор для запуска linux, а автор изобретает «повторно используемый кэширующий прокси».
Извращение это или нет — тема для отдельного разговора. Я лично не вижу ничего плохого в обдуманном использовании предложенного решения.
Например PHP при включении сессий отправляет заголовки:
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
Неуместные комментарии про название стран очень скучны, никому не интересно их читать.
Давайте ещё православный срач на тему -тся -ться устроим.
Если сайт разваливается, не работает, я выключаю JS. Или ухожу с сайта :)
1. Не доверяю вражеским сайтам. XSS, уязвимости в браузере/flash'е.
2. Компьютер у меня не быстрый, при 5-6 открытых вкладках с Flash и JS волшебством Firefox начинает тупить.
3. Для _чтения_ страниц JS понты и Flash реклама не нужна. Я же смогу прочитать текст без прекрасного кернинга?
Сайты которыми пользуюсь постоянно добавляю в белый список NoScript и Flashblock в два клика.
«Америка в шоке: Усама хранил конфиденциальную информацию в личной почте и Dropbox!»
Вы из Перми, пермский сайт загрузите быстрее чем я из Владивостока. У меня частенько трафик до Москвы идёт через Лондон. Да и каналы у всех разные.
Ping google.ru — 137мсек. Главная сайта webo — 3.2сек (быстро, но не очень).
Google Webmaster Tools говорит что мой Владивостокский, оптимизированный сайт (Page Speed Score: 95/100, 86кб страница с пустым кэшем) медленно грузится. Но умалчивает из какой точки мира он замеряет скорость.
Поэтому не удивляйтесь что у вас с автором разные цифры.
Статья красивая, диаграммы кошерны, но цифры для всех будут разными :)
Ерунда, не согласен. Супер-вундеркинды от природы (люди с великолепной генетикой) хороши только по сравнению с офисным планктоном, но им нужны годы упорных тренировок чтобы достичь минимальных результатов в спорте высоких достижений.
Великий и ужасный Лэнс Армстронг восстановился после рака, химиотерапии и стал кататься ещё лучше. Не помню дословно, но он говорил как-то так:
— Мне жаль людей которые верят в чудо, в спорте нет чудес, выигрывает тот кто больше остальных работал.
— Я шесть часов в день кручу педали и поэтому выигрываю.
Пеле, Марадона и Аршавин тоже :) начали играть в футбол в 7 лет!
Емельяненко говорил про важность объема работы, проделанной на тренировке. Чем больше тем лучше.
DateInput в самом деле не использует widget factory, но есть такие планы :)
// TODO rename to «widget» when switching to widget factory
Подход описанный TheShock в сам деле часто встречается в сторонних плагинах и мне часто доставляет проблемы когда у плагина есть замкнутые, анонимные функции, а настроек для их кастомизации нет:
var privateMethod = function () {
// private method, used for plugin
};
Приходится править исходный код плагина и получать геморрой при обновлении.
У самого jQuery можно переопределять отдельные части. Например можно делать так при отладке/поиске узкого места:
$.fn.find = console.log;
rootjQuery — кэш часто встречаемого $(document). Улучшает производительность.