firebase.js ПРОСТО ОГРОМНЫЙ (и что мы можем с этим сделать)

[k12th]

Постарайтесь нас не осуждать, нам нужны работающие importы в универсальном коде

Да, но зачем вебпак-то? babel-node же.

говорю webpack-подразумеваю react

Почему? и то и другое никак друг на друга не завязаны.

[romanonthego]

на самом деле все проще — так удобнее.
Нужно собирать пререндер-entry, который использует babel с кастомным конфигом (static вот это все), нужно пересобирать его на лету для горячей перезагрузки сервера и просто для единообразия.
кроме того собраный бандл уже независим от babel-node и прочего и запускается просто `node build/server.js`

[romanonthego]

что касается webpack — инфраструктуры не обязаны быть связаны разумеется, но видимо уже въелось в подкорку :)

[Iskin]

Есть специальный инструмент, чтобы автор опенсорс-библиотеки сам контролировал размер и пользователям не надо было использовать хаки

https://github.com/ai/size-limit

[romanonthego]

да, но как ответила команда firebase:

The size issue is something we want to address as it is a known barrier to entry for those looking to use Firebase.

Возможно ситуация изменится в последующих релизах, но пока вот так.

[animhotep]

в заголовке буква е пропущена firbase.js

[romanonthego]

исправлено, мои извинения

[hdfan2]

И ещё в тексте «клиене».

[bro-dev]

В статье нету пункта где говорится почему 100кб это плохо?

[evocatus]

Потому что сайт бывает нужно загрузить за те секунды, что телефон словит 2G между станциями метро. Потому что экономия этих килобайт может сэкономить кругленькую сумму на хостинг или позволить держать не один сайт на одном сервере. Потому что чем быстрее загружается страница, тем позитивнее опыт её использования у клиентов.

А если коротко, то те, кто собирает готовое из лего и настолько обленились и деградировали, что им даже лень хоть что-то подпилить напильником, не могут называться программистами

[nsinreal]

На 100-мегабитном интернете при втором заходе на сайт (при грамотном кешировании) даже 2мб — это не плохо.
Но вот для тех, кто впервые заходит на сайт — это плохо.
Для тех, кто заходит на сайт через 2G/3G — это плохо.
Для тех, у кого слабый CPU время парсинга становится убер-высоким.

Если ваши зависимости весят по 100кб, то с развитием проекта у вас вылезет больше одной такой зависимости, что приведет к раздуванию бандла до неприличных размеров

[vintage]

У firebase разве нет рест апи, которое можно использовать напрямую, а не через говнолибу?

[romanonthego]

либа не говно, просто большая. rest есть но не realtime и менее удобный.

[vintage]

А чего кроме говна могли туда навалить так много? :-) На поднятие вебсокет-соединения и приём-передачу сообщений много кода не надо.

[superconductor]

А в чем смысл убирать firebase из бандл И добавлять preload link на него? Он же таким образом будет касаться параллельно и замедлит загрузку бандла, нет?

[romanonthego]

ну вот именно потому что параллельно — в результате получится быстрее (https://github.com/webpack/webpack/issues/3216 — тут подробнее).
Но это именно оптимизация — preload/prefetch имеет более низкий приоритет чем собственно скрипты, и вставлять вы можете его предполагая с какой вероятностью пользователю понадобится firebase на данной странице.

[vintage]

58Кб — это, очевидно, после минификации и gzip сжатия.

[faiwer]

Если собирать вот так: NODE_ENV=production ./node_modules/.bin/webpack -p + webpack.DefinePlugin, то бандл будет радикально меньше. Будут вырезаны различные отладочные коды, плюс будет uglify. Затем сжимаем gzip (превентивно или оставляем на усмотрение nginx & пр.). И получается, что если не перегружать зависимостями то < 100 KiB. Если проект средних размеров, то < 300 KiB. 2 MiB это ну очень много.

[romanonthego]

ох, тут по порядку:
1) бандла 2 — vendor.js и app.js; vendor.js включает в себя почти все из node_modules, app — соответственно код самого приложения. совокупно получается около 210-220кб в сжатом виде. Плюс такого подхода — пока мы не добавили зависимость или не обновили версию зависимости в package.json — vendor.js не инвалидируется. Ну и грузится параллельно;
2) нужно вручную следить что бы библиотки не утащили несколько версий lodash например или react-router+react-router/es или еще что-то типа того;
3) нужно следить за размером некоторых библиотек и выносить их вот так (или любым имным способом) в ленивую загрузку или уменьшать их размер если это возможно. популярный выстрел себе в ногу — momen.js и его локали: ;
4) uglify/gzip — разумеется; babili и иные минификаторы работают менее стабильно и дают эффект хоть и лучший — но не настолько лучший на моей практике что бы заморачиваться. пока опыт с ними отрицательный.