Pull to refresh

Comments 17

самое большое приложение состоит из 10 000 модулей и без оптимизаций собирается 28 минут. Мы смогли ускорить сборку до двух минут!
Как часто и в каких случаях у вас запускается эта сборка?
Каждый раз, когда нужно собрать приложение.
Локально на машине разработчика проект собирается каждый день, но локальный запуск не такой ресурсоёмкий — в dev сборке нет оптимизаций и можно собирать только нужные для разработки части приложения. В CI проект собирается от нескольких раз до нескольких десятков раз за день.
У нас в N1.RU самое большое приложение состоит из 10 000 модулей

А это нормально в браузер столько модулей?
Столько модулей на одну страницу — это конечно же ужасно. Но в бандле мечты конечно же не так ;) Статистика сборки вебпака говорит, что для сборки нашего самого большого приложения задействовано 10 000 модулей. Само же приложение содержит кучу страниц и эти 10 000 модулей по ним размазаны. В самом докладе собственно про это и рассказывается

Можно кстати во многих случаях вообще обойтись нативным JS интерфейсом new Date. Пока что в текущем проекте так и работаем, и в целом всё нормально.

moment часто бывает нужен для third-party библиотек. И тут никуда не денешься. Остается только надеяться, что он рано или поздно отомрет, как jQuery.
Только если это не будет так больно решать средствами браузера, что вряд ли произойдет в ближайшее время. Есть очень многие вещи (например, format / subtract / startOf), которые решают задачу намного быстрее, чем это делать с нативным Date.
Вопрос в том, как часто его придется использовать. Для простого бложика будет проще написать функцию, которая будет форматировать дату публикации, чем тащить за собой весь moment.

Как уже писали выше — есть же date-fns. Импортируешь только нужные функции, а дальше Tree Shaking делает свое дело. moment сейчас это действительно тяжелое легаси и не более того.

Вопросы про SVG порадовали. Неужели люди настолько часто добавляют\удаляют иконки в проекте что для этого нужен вебпак? Какой-то вебпак головного мозга получается. Можно же просто руками собрать спрайт, вместо раскидывания всех иконок по проекту. Можно сделать несколько таких спрайтов для разных частей приложения. Проблема высосана из пальца на самом деле и получается что инструмент диктует решение, а не здравый смысл.

А теперь к позитивному: сталкивались ли с FOUC при асинхронных стилях и как лечили?
сталкивались ли с FOUC при асинхронных стилях и как лечили?

Как я понимаю, вопрос про загрузку стилей при SPA переходе с одного чанка на другой. При SPA переходе мы загружаем стили и JS, если на момент загрузки JS стили еще не загружены, мы ждем не больше 300мс их дозагрузки и рендеримся. Это не полностью решает FOUC, но в целом стало немного лучше.


Для мобильной версии сайта у нас все стили идут инлайном в html разметку, как критический CSS. Там очень мало стилей и мы решили их просто зашить в html, чтобы не иметь никаких проблем с FOUC.

Спасибо за доклад, много интересных рекомендаций.


А подставлять в html только нужные js и css чанки на этапе серверсайд рендера ещё не пробовали?) Я примерно пол года проходил этот квест, но в итоге всё получилось..


Начинается всё примерно здесь: https://github.com/faceyspacey/react-universal-component.
И оно того стоит, да.

Мы тоже успешно прошли этот квест ;) но только у нас vue.js и готовых решений не было. Если вкратце, со стороны SSR мы отдаем:


  • app.js — ядро приложения
  • common.js — общие части для многих чанков
  • manifest.js — тот самый рантайм вебпака из доклада
  • чанк текущей страницы
  • app.css
  • common.css
  • стили текущей страницы
  • Если есть критические стили для страницы, то их вшиваем в html в тэг <style>, а все стили указанные в предыдущих пунктах грузим неблокирующим способом. Примерно как описано здесь

А каким образом вы определяете, какие конкретно стили нужны для текущей страницы? Просто интересно, как вы это решили без сторонних библиотек.

Все приложение поделено на модули. По сути модуль у нас это отдельная страница, например модуль главной страницы. У всех асинхронных чанков имя 1 в 1 как у модуля. Во время сборки мы собираем manifest.json, где зашит мапинг имени чанка в название ресурса.
Например:


{
  "MainPage.css": "css/MainPage.d41d8cd98f00b204e9800998ecf8427e.css",
}

На стороне серверного рендеринга мы достаем из собранного манифеста по имени модуля путь до его css и вставляем соответствующий style тэг в разметку.


Сейчас должно быть куча плагинов, которые это автоматизируют, но у нас свой велосипед встроенный в другой велосипед.


Надеюсь ответил на вопрос :)

Не совсем корректно освещен вопрос минификации, а точнее то что Uglify уже мертв, но раньше работал из коробоки при mode:production, как и Terser, что пришел ему на смену.


Ну и, конечно, отдельная сборка ESM/ES5 бандлов в вашем случае будет немного не возможна (долго). Могу порекомендовать devolution как легкое решение проблемы.

Вам достаточно было заменить moment.js на $mol_time и не плясать вокруг тришейкинга. lodash, bluebird вообще можно безболезненно выкинуть. Ну а замени вы React на $mol_view всё ваше приложение стало бы меньше, чем один только вендорный бандл.

Sign up to leave a comment.