Рельсы идут не тем путем.
По-хорошему монолит на рельсах нужно дробить, а то получается 1С:Бухгалтерия, со всеми включенными галочками по-умолчанию. В данном случае умолчания в рельсах слишком greedy.
Взять вот sprockets. Его задача вообще один раз запуститься, минифицировать css и js, и замолчать навеки. При этом он требует кучу разнообразных зависимостей типа execjs, nodejs или v8 от гугла в качестве движка минификации.
Но что делает фреймворк? Sprockets включают в Gemfile, он грузится вместе с полезным кодом, занимает кучу места, мешается под ногами и заставляет программиста танцевать с бубном вокруг задач связанных с деплоем!
Как было бы делать правильно? Минификацию JS и CSS отрезать и делать ее опциональной, отдельной утилитой, если хотите, в составе рельс. Такой же как и rake. Назвать ее minirake и дать набор ключей для запуска. Но! У нас по всему фреймворку нужно протянуть новые названия файлов, которые генерятся при минификации! Потому что как же нам еще разделить код и данные? Короче, считаю это ошибкой дизайна, когда оптимизация НАВЯЗАНА разработчику, то есть для 99% сайтов она будет делаться ПРЕЖДЕВРЕМЕННО.
Тоже самое можно сказать и про turbolinks. Во-первых очень мало народу понимает как оно в реальности работает, соответственно каких косяков ожидать. Это та же самая, мать ее, premature optimization. Всегда гораздо сложнее упрощать что-то сложное, чем добавлять и ускорять по мере необходимости.
Поэтому когда мы логичным образом переходим на деплой рельсового приложения докером, встречаемся лицом к лицу с этими неоптимальными вещами. Идеальный случай - отдельным контейнером разово запускать минификатор, он отработал свое, закрылся и все, до следующего раза. Но нет, в рельсах все приколочено гвоздями к потолку.
И вот здесь детальнее, о чем я имею в виду https://blog.red-badger.com/blog/2016/06/22/docker-and-assets-and-rails-oh-my
По-хорошему монолит на рельсах нужно дробить, а то получается 1С:Бухгалтерия, со всеми включенными галочками по-умолчанию. В данном случае умолчания в рельсах слишком greedy.
Взять вот sprockets. Его задача вообще один раз запуститься, минифицировать css и js, и замолчать навеки. При этом он требует кучу разнообразных зависимостей типа execjs, nodejs или v8 от гугла в качестве движка минификации.
Но что делает фреймворк? Sprockets включают в Gemfile, он грузится вместе с полезным кодом, занимает кучу места, мешается под ногами и заставляет программиста танцевать с бубном вокруг задач связанных с деплоем!
Как было бы делать правильно? Минификацию JS и CSS отрезать и делать ее опциональной, отдельной утилитой, если хотите, в составе рельс. Такой же как и rake. Назвать ее minirake и дать набор ключей для запуска. Но! У нас по всему фреймворку нужно протянуть новые названия файлов, которые генерятся при минификации! Потому что как же нам еще разделить код и данные? Короче, считаю это ошибкой дизайна, когда оптимизация НАВЯЗАНА разработчику, то есть для 99% сайтов она будет делаться ПРЕЖДЕВРЕМЕННО.
Тоже самое можно сказать и про turbolinks. Во-первых очень мало народу понимает как оно в реальности работает, соответственно каких косяков ожидать. Это та же самая, мать ее, premature optimization. Всегда гораздо сложнее упрощать что-то сложное, чем добавлять и ускорять по мере необходимости.
Поэтому когда мы логичным образом переходим на деплой рельсового приложения докером, встречаемся лицом к лицу с этими неоптимальными вещами. Идеальный случай - отдельным контейнером разово запускать минификатор, он отработал свое, закрылся и все, до следующего раза. Но нет, в рельсах все приколочено гвоздями к потолку.
И вот здесь детальнее, о чем я имею в виду https://blog.red-badger.com/blog/2016/06/22/docker-and-assets-and-rails-oh-my
