Как украсть лучшие практики в Rails и как избавить Rails от ruby-based фронтенда (Часть 1)

Много лет назад, на заре становления frontend сборщиков, автор Ruby on Rails (DHH) сделал ruby сборщик Sprockets. И в целом он решал свою задачу какое-то время.

Однако мир не стоял на месте и во фронтенде возникло множество инструментов и подходов. При этом Rails прилип к своим методам, а DHH все еще пытается скрестить бульдога с носорогом и выпускает очередной Sprockets под вывеской Propshaft.

С моей точки зрения все это выглядит довольно сомнительно.

Любой современный сборщик полностью заменяет Sprockets/Propshaft и становится единственным инструментом для поддержки проекта, исключая зоопарк Rails-like решений, которые разваливаются каждые 2-3 года и заменяются на что-то еще следуя предпочтениям DHH.

Как это сделать? Можем ли мы это организовать?

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

Попробуем разобраться.

Как украсть лучшие практики в Rails и как избавить Rails от ruby-based фронтенда (Часть 2)

Зачем вообще нужен Sprockets?

Давным давно приличных сборщиков JS/SCSS кода было не так много. И DHH решил что надо бы сделать свой вариант решения задачи.

1️⃣ Надо было всем файлам-ассетам (картинки, js, css) в продакшене добавлять HASH. Это было нужно, чтобы бороться с агрессивным кешированием браузеров и обеспечивать в браузере самые свежие скрипты и стили.

Практика хорошая. Однако, я всегда задавался вопросом. Экосистема Rails такая умная и классная, но она ничтожно мала по сравнению с PHP, Python, NodeJS. И в этих экосистемах люди не сильно то парятся о добавлении hash к продакшн файлам.

Не обманывал ли Не слишком ли драматизировал DHH? Может быть не все так страшно?

Живут же как-то люди в других стеках и зарабатывают миллионы миллиардов без добавления hash к ассетам.

Кстати, а вы что думаете на этот счет?

2️⃣ Sprockets помогал делать компиляцию scss в css, coffee script в javascript, минимизировать бандлы и держать их под контролем через ручное управление.

Однако, этот функционал совсем не уникальный, а ручное управление бандлами, через манифест файлы, нууу, скажем так, не самый современный подход.

3️⃣ К 2020 году экосистема фронтенда была настолько зрелой и живущей по своим правилам, что делать свой фреймворко-зависимый сборщик кажется странным. Но у DHH есть жгучее желание удерживать за Rails завание full-stack фреймворка. Иначе концепция всей его работы за 20 лет развалится.

В этом я вижу причину его попыток создания и промоушена Propshaft и ImportMaps.

Это настолько выдающиеся инструменты, что никто за границами Rails экосистемы активно ими не пользуется; А rails разработчики не всегда понимают как они в принципе работают. Одни сплошные рекламные Wow и Amazing, а на практике — задают простой вопрос, а как оно себя ведет на больших проектах? Кто-то уже пробовал? А что с поддержкой? И сами дают ответ — подождем года 3. Вдруг DHH опять что-то придумает.

Как украсть лучшие практики в Rails и как избавить Rails от ruby-based фронтенда (Часть 3)

Сегодня в новых Rails проектах мы имеем смешение стилей и подходов.

Самое плохое, что строгой позиции Rails team нет.

Мы вообще-то тут в Rails толкаем No Build,- говорит DHH.

Однако, закрыть глаза на популярность Tailwind не получается. Давайте придумаем как его внедрить в Rails без использования привычных FE сборщиков.

И вообще у нас тут import maps встроенные в браузер.

Правда без обвязки ruby кодом c этой штукой пользоваться невыносимо. Но это DHH-way! Надо толкать в массы!

Правда рельсовый import maps тянет за собой новый способ установки зависимостей, о котором обычный фронтендщик со стороны ничего не знает.

А профессиональных рельсовых фронтендщиков, которые могут развивать системы длительно, в экосистеме процентов 5.

А еще надо понять и принять существование Propshaft.

Ой вей!
Что за зоопарк? А оно точно надо?

Как украсть лучшие практики в Rails и как избавить Rails от ruby-based фронтенда (Часть 4)

А можем ли мы иметь полностью идентичную систему, которую реализует Rails, но с использованием только 1 инструмента?

Чтобы фронтендщики были полностью погружены в свои привычные инструменты, могли легко ставить и использовать все что им нужно, иметь эффективную сборку и хеши для ассетов любых типов?

То, что это можно — это бесспорно. Vite или Webpack может это организовать.

Нужно понять сложность. А она не такая большая.

Допустим, у нас есть файл assets/images/logo.jpg который лежит в каталоге app/assets/images/logo.jpg

1️⃣ Чтобы он был доступен в среде разработки нам нужно всего лишь одну rails или vite миддлвару (я бы предпочел vite), которая будет перехватывать имя файла и отдавать его из фактического каталога нашего проекта.

2️⃣ в production среде ассеты компилируются (в том числе добавляется hash) и их оригинальное имя assets/images/logo.jpg сохраняется в manifest, и в нем разрешается в условное assets/images/logo-akdh86d.jpg

На стороне ruby/rails делается простой хелпер, который читает манифест и находит фактический файл.

Что одно, что другое — дело 3-4 javascript или ruby функции. Понимая идею — это может сделать любой новичок.

И эти 3-4 функции адаптируются к любому сборщику, любой версии в любой момент.

Если бы DHH не цеплялся за ruby код — он бы мог не тратить силы на написание своего сборщика, а сделать все тоже самое на JS примерно за 1 рабочий день.

Как украсть лучшие практики в Rails и как избавить Rails от ruby-based фронтенда (Часть 5)

К чему этот выпад в сторону Rails фронтенда? Что, самый умный?

Ну, во-первых — то, что делает DHH и команда, это не божественное решение высеченое в граните.

В нем, как и во всем есть свои компромиссы и личные установки, которые далеко не всегда идеальны в современных реалиях. И часто идут вразрез текущему положению дел, в угоду личным соображениям.

Я даю вам пищу для размышлений. Инструменты нужно выбирать под себя и свой проект.

А если вы достаточно информированы и понимаете основную идею, то часто можно решить задачу таким способом, который будет супер удобен и эффективен именно вам;

Что ж ты сам не сделал идеальный Rails фронтенд?

А кто сказал, что не сделал? Другое дело, что заменить разношерстный набор инструментов одним — это дело требующее некоторых усилий, и как правило хорошо оплачивается заказчиками, тк это сильно сокращает время на поддержку и развитие. И далеко не всегда коммерческие решения следует выкладывать в опен сорс.

Как минимум вы теперь знаете, что кто-то это делает и это отлично работает.

У меня все.

Ваша критика и соображения приветствуются.

Золотой век уже AI инструментов прошел?

Я уже писал, что создание более менее рабочего и поддерживаемого кода — это движение малыми шагами и держа все под контролем.

Было очень круто работать в таком стиле 3-4 месяца назад.

Быстрый запрос — мгновенный ответ. Получаешь нужные улучшения и переключаешься на что-то другое.

Как птичка собираешь пушинки и соломинки и строишь свое гнездо.

Теперь по умолчанию в Клоде включен режим думающего агента.

Ты ему даешь запрос — он что-то там думает. Как истинный коуч выдает тебе изнанку размышлений и план реализации (чтобы провалидировать понимание и согласовать действия с клиентом) — потом зависает — потом не торопясь делает правки — потом зависает и ждет одобрения на выполнение действий — а потом еще и сам себя корректирует.

Цикл обратной связи увеличился с 3 секунд до минуты.

Ручной режим и возврат к старой версии ситуацию не решает. Кажется модель стала специально работать дольше. Может хотят новый более дорогой тариф ввести?

Все это, как минимум, раздражает.

Ruby on Rails. Chapter 1. (Сентябрь 2025)

По итогам недавней серии видео по Rails на моем канале, назрела необходимость сделать закрытый коммерческий блок лекций, чтобы это поддерживало мои open source и открытые инициативы.

Иначе без финансовой поддержки любая инициатива просто умирает.

Я не хочу, не могу и не планирую делать курсы.

Я 100% времени работаю с клиентам и решаю реальные технические и организационные задачи бизнеса.

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

Никакого инфобиза — только реальная работа.

Никаких обещаний быстрого успеха — только боевые знания и навыки и только монотонный упорный труд.

Это будет за деньги, но первым партнерам будет особое предложение.

Первую часть лектория буду готовить к концу сентября. Пройти простой опросник и присоединиться можно тут:

👉 https://forms.gle/pfSiiM9HfpuArVk1A

Лекциям по rails быть!

1️⃣ Я удивлен количеством откликов, которые поступили за первые сутки. Спасибо!

Ваши ответы и идеи лягут в основу.

2️⃣ Я не скрываю, что я часто критикую и ставлю под сомнение некоторые подходы Rails.

Я вижу в этом особую ценность для слушателей. Я не буду вам вешать лапшу о том, что Rails way это единственно правильный выбор и только DHH знает как надо. Я буду показывать Rails c разных сторон.

Но что если я не прав? Что если меня заносит не туда? ....

3️⃣ Я обратился к самому злому Rails разработчику из тех, кого я знаю и попросил быть ревьюером моих лекций по Rails. И я получил согласие.

Все что я буду готовить для слушателей будет проходить жестокое ревью. Для меня это вызов.

Лекции Rails 2025. Chapter 1. Я планирую подготовить ко второй половине сентября.

Оставить мнение о том, что в него должно войти можно по ссылке.

Вас это ни к чему не обязывает, можно просто поделиться своими мыслями:

👉 https://forms.gle/pfSiiM9HfpuArVk1A

В свете новостей от глобальном сливе паролей я пошел посмотреть как там дела с моими аккаунтами. Сегодня я узнал, что у меня когда то был аккаунт на Пикабу.

Ломай меня полностью!