Это длинный текст про то, как изнутри устроена Micra.js — маленькая библиотека, которая добавляет реактивность к HTML, отрендеренному на сервере. Я написал её, чтобы закрыть конкретную нишу: страницы и админки, где сервер уже отдаёт готовую разметку, а на клиенте нужно лишь немного интерактивности — переключить вкладку, открыть модалку, отфильтровать таблицу, сходить за данными. Раньше для этого тянулись к jQuery, потом к Alpine. Micra — это попытка дать тот же «сахар», но предсказуемо, типизированно и с учётом Content-Security-Policy.
В этой статье я хочу рассказать про инженерию: что происходит под капотом, почему именно так, и какие концепции из «большого» программирования прячутся за каждым модулем. По дороге я постараюсь объяснить вещи вроде микрозадач, абстрактного синтаксического дерева и алгоритма наибольшей возрастающей подпоследовательности.
Пару недель назад я писал, что у библиотеки появился второй читатель — языковая модель. Тогда я думал, что главная задача — научить LLM правильно её готовить. Но потом решил, что не менее полезно послушать, что LLM думает о самой библиотеке.
Я скормил llms.txt другой модели и попросил разобрать: чего не хватает «идеальному фреймворку для тех, кому React — оверхед». Часть идей взял на заметку. Примерно тогда же я доводил до конца PR с Micra в js-framework-benchmark — один из самых авторитетных бенчей JS-фреймворков, где рядом React, Vue, Svelte, Solid и другие. При ревью этого PR его автор указал на проблему, которая пересеклась с одним из пунктов от модели.
В прошлой заметке я выложил Micra.js — маленький реактивный фреймворк для server-rendered страниц. Дальше пошли две недели, за которые я выпустил несколько версий.
Добавил в Micra кросс-библиотечный бенчмарк. Постарался сделать честную страницу, где Micra, Alpine, petite-vue, Stimulus и голый ванильный JS гоняют одни и те же сценарии в соседних фреймах.
Цифры оказались приятно-неприличными. Обновить 5 строк в списке из 1000:
Я помню время когда jQuery был UI-библиотекой для работы с DOM по умолчанию. Потом появился Knockout.js, Backbone.js и так мы дошли до React/Vue/Svelte. Фронтенд стал сложнее. Но такая сложность нужна не всегда. В мире всё ещё существуют простые сайты, состоящие из нескольких страниц, небольшие SaaS, панели управления и блоги. Часто таким решениям не требуется большой и сложный фронтенд. И в этом случае тоже приходится думать с помощью какого инструмента решать задачу создания интерфейса. В своих проектах я пробовал разные подходы — от Vanilla.js до React-а и всё пытался подобрать удобное решение, позволяющее совместить в себе реактивность и возможности взаимодействия с DOM и поддержку серверного рендеринга. А еще для простых сайтов не хочется тянуть кучу зависимостей. Иногда достаточно просто подключить библиотеку извне.
Так в ходе поиска баланса я набросал Micra.js — небольшую UI библиотеку на 5 Kb. Она имеет свои плюсы и минусы, абсолютно неуникальна и не претендует на звание заменителя всех других библиотек. Скорее это сборник практик, которые сформировались в единое решение.
Что это и как работает
Micra.js — это лёгкий реактивный фреймворк, который работает через shallow‑Proxy, отслеживая только верхний уровень state. Любое изменение top‑level свойства вызывает ререндер, а вложенные объекты нужно заменять целиком. Все синхронные обновления состояния батчатся в один microtask, поэтому несколько записей приводят к одному ререндеру. При первом рендере Micra сканирует DOM, собирает директивы (data-text, data-if, data-model и др.) и кэширует их, чтобы последующие обновления были быстрыми и не требовали повторного обхода дерева.
Выражения в директивах выполняются через быстрый путь для простых обращений к свойствам или через компиляцию с глобальным кэшем для сложных выражений. Внутри выражений доступен расширенный exprState, включающий методы компонента и хелперы (prop, emit, fetch). Списки с data-each и data-key обновляются через keyed‑diff: переиспользуются существующие DOM‑ноды, создаются только новые, а исчезнувшие удаляются. Каждый data-component создаёт независимый инстанс со своим состоянием, методами, props из data-* и собственным жизненным циклом. Компоненты общаются через event bus, а доступ к конкретному экземпляру возможен через Micra.instances().
Как видите, ничего нового и уникального. Некоторые решения компромиссны. Например, проксирование top-level. Для решений типа "показать модалку", "отфильтровать таблицы" выглядит достаточно. Меньше багов, выше производительность, так как нет лишних обходов. Но я не исключаю, что позже приду необходимости deep‑proxy.
В то же время, я собрал сборник рецептов и набор компонентов, которые можно копировать и использовать. В качестве эксперимента, хочу попробовать обучить AI использовать Micra.js в качестве замены React. Задачка, конечно, требует времени, потому что кодовая база с React огромна. В то же время, это не всегда играет на руку. Примеры кода могут быть и хорошими и плохими и корректировка достигается с помощью правильный скиллов и гайдлайнов. И я думаю, что если это можно сделать с одной библиотекой, то можно и с другой.
В рамках работы над open-source проектом работал над задачкой по генерации тем. То есть в проекте было несколько тем: одни темы имели светлый и темный режим, другие - только светлый или только темный. И задача сводилась к тому, чтобы сделать для всех тем светлый и темный режим.
Вот на скриншоте показаны несколько темных тем: Dracula, Solarized, Gruvbox, Monokai, Moonlight. В теории можно взять и инвертировать светлоту, получив тем самым светлую тему. В теории теория и практика не отличаются. На практике всё совсем наоборот 😀. Чтобы объяснить почему, полезно сначала посмотреть на то, как устроена работа с цветом в принципе.
На днях с подачи приятеля подключил Garmin MCP к Claude Code. Опыт интересный. В первую очередь, потому что все эти данные мне и так известны и доступны в виде сухой статистики в Garmin Connect. Хотелось попробовать новый опыт взаимодействия.
С декабря прошлого года работаю над парой проектов, которые идут рука об руку. Про первую вкратце писал в итогах прошлого года. Про вторую не говорил, потому что показать было нечего. Теперь вот есть — TrueNorth
Недавно добавил на Syn-co.me новую функцию — поиск удобного времени для встреч. Если вы уже пользовались сайтом, то знаете: он показывает время всей команды на одном таймлайне. Просто добавляете участников с их часовыми поясами, и сразу видно, кто работает, кто спит, кто только проснулся.
Теперь при добавлении участников из разных городов, а алгоритм предлагает, когда лучше всего созвониться. Причем не просто "когда все не спят", а когда время действительно удобное для всех. Или хотя бы максимально справедливое, если идеального варианта не существует.
Проблема
Представьте: ваш коллега в Токио, партнер в Нью-Йорке, а вы в Москве. Когда в Москве 14:00 (отличное время для звонка), в Нью-Йорке 6 утра (кто-то еще спит), а в Токио уже 20:00 — конец рабочего дня.
Можно, конечно, открыть мировые часы и начать перебирать: "А если в 10 утра по Москве? Нет, подождите, тогда в Токио будет..." Через пять минут такой арифметики голова идет кругом.
Как это работает
Алгоритм проверяет каждые полчаса в ближайшие два дня и оценивает, насколько удобно это время для каждого участника. Не все часы одинаково хороши для встреч.
Оптимальное время — середина рабочего дня, примерно с 10 до 16 часов. Люди уже проснулись, выпили кофе, разобрали почту. Максимальная продуктивность.
Хорошее время — начало или конец рабочего дня. С 9 до 10 утра или с 16 до 17 вечера. Можно созвониться, но кто-то может быть не в лучшей форме.
Приемлемое время — чуть за границами обычного расписания. Например, 8:30 утра или задержаться до 18:00. Неудобно, но терпимо.
Некомфортное время — приходится серьезно менять планы. Встать пораньше в 7 утра или остаться после работы до 19:00. Такие встречи лучше избегать, но иногда выбора нет.
Алгоритм выбирает варианты, где всем хотя бы приемлемо, и сортирует их от лучших к худшим.
Что делает время действительно удобным
Тут начинается самое интересное. Я бы выделил три столпа на которых основана логика алгоритма.
Справедливость важнее общего удобства. Лучше, когда всем "хорошо", чем когда двоим "отлично", а одному "ужасно". Поэтому алгоритм в первую очередь смотрит на того, кому хуже всего. Если есть вариант, где минимальный комфорт выше — он побеждает.
Чем раньше, тем свежее. Потому что ранние встречи обычно продуктивнее поздних. Хотя и всё индивидуально, но обычно к вечеру люди устают, думают о доме, концентрация падает. При прочих равных алгоритм предпочитает утренние варианты.
Избегаем экстремальных часов. Никто не хочет созваниваться в 5 утра или в 11 вечера. Такие варианты получают серьезный штраф. Также учитывается обеденное время — встреча с 12 до 13 нравится немногим.
Гибкость как параметр
Иногда нужно быстро найти время, и все готовы немного подвинуть свое расписание. Иногда важно никого не беспокоить вне рабочих часов.
Поэтому в инструменте есть параметр гибкости — от 0 до 12 часов. С нулевой гибкостью алгоритм ищет только время в пределах рабочих часов. С гибкостью в 3-4 часа появляются варианты, где кто-то начинает чуть раньше или задерживается. Чем выше гибкость, тем больше вариантов, но тем менее комфортными они становятся.
Когда компромиссы неизбежны
Иногда приходится признать: идеального времени нет. Если участники размазаны по всему миру, кому-то точно будет неудобно.
Для Москвы, Нью-Йорка и Токио практически невозможно найти время, когда всем комфортно. Разница часовых поясов слишком велика. В таких случаях алгоритм предлагает несколько вариантов с разными компромиссами.
Может быть, один раз неудобно будет Токио, в следующий раз — Нью-Йорку. Справедливость можно обеспечить не за одну встречу, а в серии созвонов.
Про Syn-co.me
Инструмент работает прямо в браузере. Никаких регистраций, никаких серверов, никакого сбора данных. Вся информация о команде кодируется в URL — можете сохранить в закладки или отправить коллегам.
Изначально Syn-co.me создавался как простой таймлайн часовых поясов команды. "Stop doing timezone math in your head" — главная идея. Поиск времени встреч — логичное продолжение: показывать не просто "когда все свободны", а "когда всем будет действительно удобно".
Казалось бы, мелочь — подобрать время для звонка. Но эти мелочи съедают время и нервы. Особенно когда участников больше двух и часовые пояса разбросаны. Возможно, я слишком много думаю про расписания. Но когда постоянно работаешь с людьми из разных часовых поясов, начинаешь ценить инструменты, которые просто работают и не требуют усилий.
Статья «Rails for Everything» на Literally The Void отстаивает универсальность Ruby on Rails для разработки различных типов проектов, опровергая стереотип о его ограниченной применимости и подчеркивая преимущества использования полного стека Rails вместо разделения на микросервисы, в то время как комментарии на Reddit отражают разнообразие мнений разработчиков об актуальности фреймворка в 2025 году, его производительности и сравнении с современными альтернативами.
Petr.codes в «Flexible API versioning with Rails» предлагает гибкий подход к версионированию API в Ruby on Rails, рассматривая проблемы традиционных методов и демонстрируя эффективную архитектуру с использованием наследования и модулей в контроллерах, что позволяет разработчикам легко управлять изменениями между версиями API без дублирования кода.
Статья Мартейна Холса «The European Accessibility Act for websites and apps» разъясняет требования Европейского акта о доступности для цифровых продуктов, описывая сроки внедрения, технические стандарты и необходимые меры соответствия, которые должны предпринять разработчики и владельцы бизнеса для обеспечения доступности своих веб-сайтов и приложений в соответствии с законодательством ЕС.
Марк Мэнсон в статье «Why You Should Quit the News» утверждает, что следует отказаться от регулярного потребления новостей, поскольку они вызывают стресс, фокусируются на негативе и отнимают время, которое можно потратить на более ценные занятия, при этом большинство новостных материалов не имеют практического влияния на нашу повседневную жизнь.
Алекс Рассел в своей статье «If Not React, Then What?» критикует React за создание избыточного уровня абстракции над веб-платформой, что приводит к проблемам с производительностью и большим JavaScript-пакетам, и предлагает Web Components как более эффективную альтернативу, которая работает в гармонии с нативными возможностями браузера и следует принципам прогрессивного улучшения.
Ахмад Шадид выпустил гайд о новых CSS свойствах — «Relative Colors».
На днях решил автоматизировать рутинную работу при старте разработки. Не знаю, почему раньше до этого не доходил. Но вот буквально на днях пришло осознание, что есть пробел, который надо закрыть.
В чем проблема? Каждый раз переключаясь с одного проекта на другой приходится совершать одни и те же действия: открыть терминал, перейти в нужную директорию, запустить несколько разных процессов в разных вкладках, открыть редактор кода.
Я когда-то пробовал разбираться с tmux, но бросил. Было непонятно, и не очень надо. Сейчас использую WezTerm. Это современный кроссплатформенный терминальный эмулятор и мультиплексер. До этого работал с iTerm2, Wrap.dev, Kitty. Пробовал даже Alacrity. Но прижился WezTerm. Он довольно производительный (не самый-самый), но норм. Написан на Rust. Поддерживает GPU-ускорение рендеринга. Имеет встроенную поддержку шрифтов с лигатурами и поддерживает конфигурацию на Lua. В общем, он стоит того, чтобы его попробовать.
Для работы над проектом я обычно две вкладки. Одна содержит 3-4 панели, в каждой из которых запускаются
— Redis-сервер
— Rails-сервер
— Сборка фронта
Еще одна вкладка в редакторе с Neovim для работы с кодом.
В результате экспериментов, я пришел вот к такой конфигурации. Это ссылка на gist, чтобы не копировать все 200 строк кода в пост.
Сам файл .wezterm.lua лежит в корневой директории пользователя. В общем, ничего не обычного. Базовая конфигурация WezTerm выглядит так. Остальное в gist — пример настройки панелей.
Представьте, что вы строите дом. Можно быстро построить его из доступных материалов, игнорируя некоторые строительные нормы, чтобы скорее въехать. Или можно делать всё по правилам, но это займёт больше времени. В первом случае вы "берёте в долг" – экономите время сейчас, но потом придётся исправлять недочёты, причём обычно с гораздо большими затратами.
То же самое происходит в разработке программного обеспечения. Каждый раз, когда команда выбирает быстрое временное решение вместо правильного, она берёт в долг у будущего. И как любой долг, технический долг имеет свои проценты – чем дольше его не отдавать, тем дороже обходится его обслуживание.
За 19 лет работы с различными проектами я выделил три верных признака того, что технический долг начинает тормозить бизнес:
Во-первых, разработка новых функций постоянно замедляется. То, что раньше занимало пару недель, растягивается на месяц или больше. Разработчики боятся трогать старый код, опасаясь сломать существующий функционал. А некоторые части системы становятся "священными" – к ним вообще никто не хочет прикасаться.
Во-вторых, адаптация новых разработчиков превращается в квест. Когда документация устарела, а код содержит самописные решения десятилетней давности, даже опытному разработчику требуется очень много времени, чтобы начать эффективно работать. Это существенно повышает стоимость найма и замедляет масштабирование команды.
В-третьих, каждый релиз становится лотереей. Вы исправляете одну проблему, но появляются две новые. Отсутствие или недостаточность автоматических тестов и современных инструментов разработки превращает каждое обновление в стрессовое событие для команды.
Здесь надо оговориться, что технический долг можно разделить на две категории: стратегический и случайный. В первом случае мы принимаем осознанное решение идти на компромиссы. Это может быть вызвано целью ускориться сейчас. Но также все должны понимать, что отложенная оптимизация должна состояться. Во втором же случае, тех долг может быть вызван неоптимальными решениями из-за недостатка опыта, недостатка вводных данных при проектировании архитектуры или несогласованности в командной работе.
По моему опыту, команды, которые активно работают над техническим долгом, в среднем более продуктивны. Однако, чтобы сосредоточиться на работе с тех долгом, надо сперва оценить масштаб работ.
Я бы предложил начать с простого — с простых вопросов команде: сколько времени занимает добавление типовой фичи? Насколько уверенно вы чувствуете себя при внесении изменений? Какие части системы вызывают больше всего проблем?
Дальше можно перейти к количественным метрикам: времени между релизами, количеству инцидентов, времени на исправление ошибок. А затем постараться внедрить современные инструменты позволяют измерить качество кода, его сложность, уровень тестового покрытия.
Работа с техническим долгом – это не разовая акция, а постоянный процесс. Я рекомендую начать с трёх шагов:
Первое – выделите ресурсы на технические улучшения. Классическое правило: 20% времени команды должно уходить на технический долг. Да, это может казаться дорого, но альтернатива обойдётся дороже.
Второе – внедрите культуру качества. Каждый новый код должен быть лучше старого. Код ревью, автоматические тесты, современные инструменты разработки должны стать стандартом, а не роскошью.
Третье – действуйте постепенно. Не пытайтесь переписать всё сразу. Начните с самых проблемных мест, которые больше всего тормозят развитие. Каждое улучшение должно приносить измеримую пользу бизнесу.
Технический долг – это не приговор, а естественная часть развития любого проекта. Важно научиться им управлять. Как показывает мой опыт работы с разными проектами, инвестиции в качество кода окупаются сторицей через ускорение разработки, стабильность системы и удовлетворённость команды.
Последние пару недель нет времени ни писать, ни бегать. Сначала боролся с соплями, потом со знаниями. Из интересного, почти отказался от VS Code и перешёл в VIM. Тут надо сразу оговориться, я пишу vim, но подразумеваю nvim. То есть в том контексте, о котором я пишу разницы нет.
Помню, как впервые пытался использовать навигацию по файлу с помощью hjkl. Выглядело жутко неудобно. Сейчас, кстати, не сильно лучше.
На frontendmasters.com есть классный курс, если есть возможность оплатить подписку, советую оплатить и посмотреть. Я его прошел. Но сложно взять и посмотреть кучу роликов. На практике эти знания сразу применить невозможно. В итоге запоминаешь лишь часть информации и потом пытаешься применить по необходимости.
Вообще я долго пытался понять что неудобно в vim и почему он для меня не работает. И в какой-то момент пришла мысль о том, что я пытаюсь использовать его как использую все остальные GUI редакторы. А надо изменить подход. То есть мало отказаться от использования мышкой, надо еще изменить способ мышления. Идея не в том, чтобы мыслить не символами и хоткеями, а командами.
Композиция команд — это очень мощная концепция в Vim/Neovim. Например, команда может состоять из трех частей:
— Оператор (что делать)
— Модификатор (сколько раз или как)
— Движение (с чем делать)
Примеры:
d2w - delete 2 words
da{ - delete around {}
y$ - yank to end of line
ciw - change inner word
c3j - change 3 lines down
Вот к примеру основные операторы
d - delete (удалить)
y - yank (копировать)
c - change (изменить)
p - put (вставить)
и основные движения
w - слово
b - назад по словам
e - конец слова
$ - конец строки
0 - начало строки
^ - первый непробельный символ в строке
А теперь представьте как можно их компоновать. Поначалу это сильно ломает мозг. Начинаешь думать какие клавиши нажать, чтобы изменить слово внутри кавычек или прыгнуть сначала наверх файла, а потом вернуться назад. Переключиться между разными файлами тоже в начале сложно.
Более того, команды регистрозависимые. Например,
word - последовательность букв, цифр и символа подчёркивания
WORD - последовательность не пробельных символов
Поэтому
example_variable_name # три words, то есть три нажатия w
example_variable_name # один WORD
some-compound-word # три words
some-compound-word # один WORD
gg — прыжок к началу файла, а G — к концу. Команд так много, что сложно все запомнить. Но я стараюсь каждый раз, когда чувствую сложность и непонимание "как сделать так чтобы было удобно" идти гуглить и пытаться запомнить как же.
Вот последние находки для разделения одно окна на панели
— <C-w>v или :vsp - вертикальное разделение
— <C-w>s или :sp - горизонтальное
Для навигации между панелями:
— <C-h> - в левое окно
— <C-j> - в нижнее окно
— <C-k> - в окно сверху
— <C-l>- в правое
То есть идея понятна, те же hjkl + нажатый Ctrl.
А еще метки. Про них наверное отдельно надо писать. Если кратко, то ma ставит метку 'a'. mb — метку 'b'. Не важно где была поставлена эта метка в этом файле и сегодня ли. Но
- `a и `b позволяет переключаться между файлами или теми блоками где вы были очень быстро
- `` позволяет вернуться к предыдущей позиции
- '. возвращает к последним изменениям
В общем, пока я нажимал www, гуляя по словам, было прикольно, но как-то странно. Потому что преимущества с обычным редактором не были заметны. А вот метки как раз принесли очень интересные возможности.
PS: Как я писал в начале поста "я почти отказался от VS Code". Мне все еще нравится VS Code. Он прекрасен и привычен. Поэтому когда я устаю разбираться с vim, я просто переключаюсь на VS Code.
Вышел в свет Rspack 1.0, это сборщик модулей написанный на Rust. Судя по тестам он в несколько раз быстрее Webpack и чаще всего быстрее Vite (за исключением HMR режима).
С тех пор как David Heinemeier Hansson перешел на линукс, он много рассказывает о том, как прекрасен VIM. В общем-то я с ним согласен. Вот его пост на эту тему Wonderful vi
SQLite кажется недооценен. Почитайте почему его стоит использовать Why you should probably be using SQLite. Кстати, в Ruby on Rails 8 планируется поддержка SQLite в продакшене.
Последние пару неделю работаю над блогом. До этого я писал, что он работает на Nuxt.js + Wordpress. И до начала октября все было именно так. Nuxt.js на фронте, бэкенд (если можно так выразится) на Wordpress. И утверждал и продолжаю утверждать, что панель управления Wordpress одна из самых удобных.
В целом, меня всё устраивало. Но были нюансы, которые очень хотелось исправить. Например, мне ужасно не нравится версионирование записей в Wordpress. Пока пишешь один пост, получаешь множество сохранений в черновик. Я знаю для чего это, но мне это не нравится.
Еще один момент — система плагинов и технически сложная кастомизация. Чтобы что-то сделать в админке, например, добавить кастомные поля к посту, нужно ставить плагин. Все это здорово, но кажется, что ты не владеешь продуктом. Если завтра плагин обновится и с ним будет проблема, это может поломать сайт. Так совпало, но спустя неделю после переезда у Wordpress и wpengine был спор о правах и отчислениях. Дошло до того, что команда Wordpress выпустила свой плагин Secure Custom Fields.
Доработка темы для Wordpress в 2024-м уже не кажется простой задачей. Темы стали сложнее, в них куча логики и разбираться, если честно, нет ни времени, ни желания.
Так что с недавнего времени я переехал на Ruby on Rails. Это интересный опыт. С одной стороны, хотелось посмотреть версию 7.2 в работе. С другой, хотелось быстренько сделать проект так, как хочется внутри, без лишнего усложнения. Без проблем и экспериментов не обошлось.
Попробовал Active Storage, понял что мне не нравится это решение и откатил всё обратно. В итоге, решил, что картинки я буду заливать на CloudFire при создании поста, а удалять их буду вручную. Решение не совсем идеальное, но оно работает и на текущий момент меня устраивает.
Вообще старался сделать всё как можно проще. После админки Wordpress это сильно заметно 😀
Из функционала: подписка на RSS, оптимизация и конвертация картинок в webp на стороне рельс, а не на CloudFire, собственный сборщик статистики. Не люблю Google Analytics, а большинство других аналитик платные. Мне же интересно общее количество посещений, страны и устройства. Нет так уж много, согласитесь. Ранее я использовал SimpleAnalytics. Отличный сервис, но на этот раз решил реализовать свою версию. Ну и конечно же самый настоящий серверный рендеринг приготовленный на самом настоящем сервере. Без костылей и хаков 😀.
В планах есть еще идеи по улучшению и доработки. Например, email рассылка, конвертация :) => 😀, хранение черновика заметки в localStorage, кросс-постинг в телеграм канал и прочие нужные и ненужные штуки. В общем, всё то, что неизбежно ведет систему к усложнению.
Перенес управление доменом на Cloudflare. И пришлось немного почитать документацию, как же настроить и соединить сайт на railway.app и домен на Cloudflare.
В первом приближении всё казалось просто. Railway.app генерирует проекту CNAME. Казалось бы бери, подставляй конфиг и всё. На практике оказалось чуть интереснее и документацию пришлось почитать немного внимательнее.
Этот блог работает на WordPress. Точнее его часть — админка. А фронтенд на nuxtjs. Когда-то я много работал с WordPress. Был даже модератором русскоязычного сообщества, делал темы и сайт на заказ. И вот что хочу сказать: панель управления WordPress была и остается одной из лучших. Знаете слоган у Эппл “это просто работает”. Так вот то же самое можно сказать про админку вордпресса. Кликаешь пару кнопок и всё, можно писать.
Но за такое удобство приходится платить. Размер базы растет как на дрожжах. Версионность и черновики штука хорошая, но некоторые вещи сохраняются избыточное количество раз. В каталоге с изображениями через некоторое время начинается хаос, через полгода-год туда вообще лучше не смотреть — непонятно используются ли загруженные картинки или уже нет. Плагины и темы тоже стоят отдельной дискуссии. За столько лет развития WordPress написано огромное количество плагинов. Часть из них уже давно стали платными и перешли на систему месячных подписок. В результате обновления от разработчиков приходят чуть ли не каждую неделю и следить за всем стало очень сложно. WordPress стал очень сложным продуктом.
Но сложными стали многие системы. Помню как лет десять назад раскладывал в директориях css и js и прогонял gulp-task, чтобы мои псевдокомпонентики склеивались в банды. Потом появился вебпак, react/vue и компоненты стали настоящими, не псевдо. Потом структура приложений и сервисов усложнялась и вот уже появляются различные архитектурные слои. Нельзя просто взять и, простите, наговнякать. Надо все разложить по полочкам, настроить вебпак, отрастить бороду. Усложнился и javascript. Вот менеджеры состояний, вот веб-сокеты, local first подход. В какой-то момент проектирование архитектуры пет-проектов стало такой, что пока все подготовишь, уже запал кончился. А список пакетов из npm, которые еще надо установить — нет. Не то, чтобы это прям плохо, это естественное развитие и взросление системы. Просто стало сложно следить и управлять всем этим.
Но я тут начал книжку про Ruby on Rails читать. И для закрепления знаний, конечно писать код. И знаете что? В мире есть место где можно говнякать. Что 10 лет назад, что сейчас. Хочешь свалить все стили в assets/stylesheets? Пожалуйста. Хочешь вмонстрить кусок скрипта прямо во вьюху? Не возбраняется. Тем более, что это местами очень даже удобно. И вот я раньше сильно плевался от подобного подхода. Но сейчас… Не то чтобы я стал сторонником, но если кусок скрипта нужен только на этой странице, то может быть проще вздохнуть и добавить его туда.
И вот пет-проект на рельсах, где можно немного отступить от привычных норм выглядит каким-то глотком свободы. Уверен, что развивая проект, со временем он тоже станет сложным и его придется делать архитектурно красивым и структурированным. Но вот сейчас, кажется, я до конца понимаю как вышло так, что Ruby on Rails стал таким популярным, почему каждый год все ждут когда же он помрёт. А DHH раз за разом выпускает новую версию и RoR всё ещё популярен.
Мне кажется потому, что это то самое место, где все ещё можно г… Гибко решать свои задачи. Ну вы поняли 😀
Решил разобраться в VIM. Вообще я часто пользуюсь им, для быстрого редактирования файлов. Этакая разовая работа. Но полноценно переключиться на работу с VIM у меня не получается. По умолчанию использую VS Code + VIM плагин. Получается неплохой симбиоз: удобные хоткеи VS Code + удобная навигация внутри файла. Но одно дело удалять строчки и прыгать туда-сюда по файлы, а другое дело полноценно работать с большим проектом.
Обычно многие статьи заканчиваются командами h, j, k, l. А дальше читайте официальную документацию, там всё подробно описано. А выйти-то как? А как отступ добавить?
Так вот, отступ в режиме NORMAL задаётся через двойное нажатие >. И тут вот какая проблема: статьи-то на самом деле хорошие, просто команд и сценариев так много, что всего не перечислишь. А еще есть куча разнообразных форков со своими доработками. Например, я пользовался LunarVim. В целом, было неплохо, но некоторые вещи долгое время не исправлялись. И вот однажды я полез искать как же поправить один баг и с удивлением обнаружил, что проект не развивается.
Решил попробовать Astronvim. Проект оказался поинтереснее: быстрее, более структурированнее. И как-то так увлекся настройкой (что-то добавил, что-то переназначил), что в итоге сделал свой форк.
В какой-то момент, устав читать документацию и статьи, я купил себе книжку Practical VIM. Сначала читал демо, потом еще раз читал демо. Понял, что очень понравилось. Простой английский, легкое повествование. Текст читается прекрасно. К слову, у меня есть ещё одна книга про VIM “Изучаем vi и VIM”. Так вот в этой книге я продвинулся всего на четыре главы. В общем, “Practical VIM” понравилась больше.
И вот к примеру пара цитат из книги:
The combination of operators with motions forms a kind of grammar. The first rule is simple: an action is composed from an operator followed by a motion. Learning new motions and operators is like learning the vocabulary of Vim. If we follow the simple grammar rules, we can express more ideas as our vocabulary grows. Neil, Drew. Practical Vim (pp. 24-25). Pragmatic Bookshelf. Kindle Edition.
и
when an operator command is invoked in duplicate, it acts upon the current line. So dd deletes the current line, while >> indents it. Neil, Drew. Practical Vim (p. 25). Pragmatic Bookshelf. Kindle Edition.
Ещё книга содержит много отсылок к документации. При желании можно пойти и узнать больше деталей. В общем, книга классная, рекомендую.
Что касается VIM и ежедневного его использования, могу сказать, что в процессе чтения книги снова появился живой интерес к использованию. Некоторые вещи уже не выглядят болью. Еще один важный момент — готовый настроенный конфиг. Возможно, когда-нибудь я попробую всё настроить с нуля. Но вот прямо сейчас хочется использовать то, что работает из коробки. Поэтому решения вроде AstroNvim хорошо подходят.
Пробовал несколько раз Helix Editor, но там слишком много хотекеев переделано по-своему. Ребята хотели сделать понятнее, а получилось запутанее. Потому что сложно переучиться на другие команды и хотекеи.
Вывода у статьи не будет. Скорее это просто чекпоинт на тему “вот узучаю VIM”.
Немного про разработку. Работал тут с Playwright. До этого писал тесты на Cypress. И после двух лет на Cypress кажется, что вдохнул свежего воздуха. При параллельном выполнении тестов Playwriter прогоняет их быстрее. А еще он запускает отдельный процесс для управления браузером, вместо выполнения тестов непосредственно в браузере.
В результате, переписал тесты к блогу на Playwriter и настроил Github Action.
Из интересного: для запуска тестов Nuxt + Playwriter нужно в playwright.config.js указать reuseExistingServer: true.
