Как украсть лучшие практики в 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

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

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

Спасибо.
(Адресат поймет)

Уже 3-4 года в отпуск не беру ноутбук. Это было не просто заставить себя и успокоить мозг.

Всегда приходилось много работать и это стало образом жизни.

В какой-то момент пришлось учиться отдыхать, а не только работать.

До первого в этом году отпуска дополз с трудом. Но ничего. Посадка уже через час. 🍸🍹😎🏖️⛱️🤿

Великая миграция с вебпакера на vite (или аналоги)

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

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

Надо совместить в голове кучу ограничений и деталей, прежде чем ты сможешь точно спланировать этот процесс и ничего не поломать.

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

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

Вообще, ZERO-dependency решения вижу как будущий тренд.

Если его еще нет, то я его объявляю прямо сейчас 😂

Мне стыдно показывать свой код

Мой хороший знакомый, сеньор-помидор, много лет назад, выступая на конференции сказал: «мне стыдно показывать свой код. Он состоит из простых, коротких методов, которые может написать любой новичок»

Другой знакомый, еще в 2012 году сказал в личной беседе - «главная задача ИТ инженера - сокращать сложность и управлять ею»

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

Условно, многим проектам лучше сделать 20 отдельных и простых и не оптимальных запросов к базе, чем один супер sql join который никто и никогда не сможет быстро модифицировать.

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

Но, может быть, это лишь мой информационный пузырь и мой частный опыт.

Божечки, сколько ж тебе лет 🙈

Кажется, один из первых моих гемов для рельса. 2011 год.

Благодаря этому опенсорс проекту меня несколько раз брали на хорошую работу.

Почему-то в то время мало кто в РФ делал свои опенсорс проекты. Да еще и относительно успешные.

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

Layered Design for Ruby on Rails Applications

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

О книге (отзыв)

Там кстати распродажа по 9.99
👉 Страница книги

Если вы по каким-то причинам хотите устроиться к Марсианам — то в книге можно получить информацию по подходам и гемам, которые они наверняка использую в ежедневной практике. Ну и получить плюс в карму при прохождении интервью.

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

Все здраво, все логично, понятно почему и зачем.

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

Мне бы хотелось большей догматичности изложения — в стиле — делай так (вот шаги 1,2, 3) и не делай вот так — мы пробовали, это не работает.

Искренне рад за Владимира, что он осилил такой проект, как книга. Это очень много труда и усилий.

Layered Design for Ruby on Rails Applications

Новости с пылу с жару.

По неофициальной информации (но напрямую от автора) — скоро второе переиздание 😁

https://youtu.be/QGQ9quiAgXM

Видео блог:
Ruby / Rails. Учить самому? Учить других?
Работал, работал, решил записать видео.

Рассуждаю на несколько тем:
- Почему там мало актуальных и адекватных курсов по IT?
- Почему разработчики не занимаются обучением?
- Нужно ли программирование в эпоху ИИ?
- Зачем учить Ruby и Rails? Это же не популярные инструменты.