yv
ну вот однобуквенные
https://share.effector.dev/QN4dv16F
https://share.effector.dev/QN4dv16F
но без учитывания сжатия это имхо вообще нерелевантное сравнение, нужно смотреть минифицированный+сжатый код
Size: a a a
2020 March 22
l
gzip не учитывается
l
так как он работает вообще на другом уровне — энтропия, информация, вот это всё. размер библиотеки преимущественно снижается, но гзипнутый размер растёт линейно
l
В коде доменов так и просится использование прототипов, чтобы не создавать лишние функции и замыкания.
ну вот там бинды и были. прототипы особо нигде не помогают, я уже прикидывал
не помогают потому что вынос любого метода из юнитов библиотеки должен быть безопасен, особенно у доменов
const {createStore} = createDomain()
не помогают потому что вынос любого метода из юнитов библиотеки должен быть безопасен, особенно у доменов
const {createStore} = createDomain()
T
Это аргумент
yv
так как он работает вообще на другом уровне — энтропия, информация, вот это всё. размер библиотеки преимущественно снижается, но гзипнутый размер растёт линейно
но бандл доставляется в браузер почти всегда со сжатием, поэтому имеет смысл учитывать и, например, в некоторых местах писать более вербозно, зато уменьшая энтропию.
но имхо, даже если тут есть выигрышь на пару десятков байт в размере — замыкания дают больше пользы, чем размер.
ну, это моё мнение, я не навязываю :)
но имхо, даже если тут есть выигрышь на пару десятков байт в размере — замыкания дают больше пользы, чем размер.
ну, это моё мнение, я не навязываю :)
l
но бандл доставляется в браузер почти всегда со сжатием, поэтому имеет смысл учитывать и, например, в некоторых местах писать более вербозно, зато уменьшая энтропию.
но имхо, даже если тут есть выигрышь на пару десятков байт в размере — замыкания дают больше пользы, чем размер.
ну, это моё мнение, я не навязываю :)
но имхо, даже если тут есть выигрышь на пару десятков байт в размере — замыкания дают больше пользы, чем размер.
ну, это моё мнение, я не навязываю :)
тогда возникает вопрос а почему gzip а не brotli? а почему полный размер — максимально утрированная ситуация, а не точное измерение размера в зависимости от активности использования библиотеки с учётом dead code elimination?
yv
тогда возникает вопрос а почему gzip а не brotli? а почему полный размер — максимально утрированная ситуация, а не точное измерение размера в зависимости от активности использования библиотеки с учётом dead code elimination?
может добавить size-limit тогда? :) там и бротли есть, можно после каждого билда локально смотреть, как поменялся размер
l
нет, size-limit не нужен
l
так же как все другие помощники для старта разработки, бесполезные спустя два с половиной года
l
мы пробовали интегрировать size-limit ещё год назад
l
но это абсурд, в первую очередь никаких лимитов нет
l
во вторую — вокруг эффектора существует огромный пайплайн сбора статистики
l
учёт без gzip уже интегрирован в процесс разработки, каждый коммит обновляет сводную информацию по размеру http://effector-size-report.s3-website-eu-west-1.amazonaws.com/
а из-за методичности использования подхода уже есть возможность строить график изменения размера во времени
а из-за методичности использования подхода уже есть возможность строить график изменения размера во времени
l
переход от сбора отчётов на aws s3 к size-limit на данном этапе это явная деградация)
yv
про size-limit это я просто набросил :) несерьёзно
моё мнение выше:
> замыкания дают больше пользы, чем размер
моё мнение выше:
> замыкания дают больше пользы, чем размер
l
статистика собирается роллап-плагином при билде
l
про size-limit это я просто набросил :) несерьёзно
моё мнение выше:
> замыкания дают больше пользы, чем размер
моё мнение выше:
> замыкания дают больше пользы, чем размер
это не мнение, это частный случай
l
всё зависит от интенсивности использования хелпера