VueJS *

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

С примерами работы на TypeScript, React, Vue и Angular можно ознакомиться на домашней странице проекта Layout Virtual.

Репозиторий с проектом тут.

PrimeTek, бывшая PrimeFaces, запустила PrimeUI — новую лицензионную модель для экосистемы PrimeNG, PrimeReact и PrimeVue. Это подаётся как унификация бренда, но по сути компания собирает свои ключевые продукты под одной коммерческой оболочкой. Раньше они существовали как набор отдельных библиотек, которые монетизировались через дополнительные продукты и сервисы. Теперь вся экосистема превращается в единый лицензируемый актив.

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

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

1. Type checking — TSCheck vs TSGO

2. Linting — ESLint vs Biome vs Oxlint

3. Bundling — Webpack → Vite → Rsbuild

4. API-контракты — Кодогенерация без AI

5. React-оптимизации — React Compiler в production

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

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

Меня это изменение не задело — я давно уже переехал с Кинопоиска на Letterboxd.

Не буду сегодня останавливаться на моих впечатлениях от Letterboxd в целом (спойлер: они смешанные). Но вот интересно посмотреть, как там обстоят дела со статистикой просмотренного.

Хорошая новость в том, что она есть. Вот примеры для профиля целиком и за конкретный год. Но плохая новость в том, что статистика доступна только на платной Pro-подписке.

Что очевидно подталкивает нас к тому, чтобы сделать своё решение, где будет вся нужная нам статистика бесплатно и в лучшем виде. Тем более, Letterboxd позволяет выгрузить всю свою личную информацию в виде архива.

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

Astro — фреймворк для сайтов, который минимизирует поставку JavaScript на клиент, обеспечивая высокую производительность. 22 июня вышла седьмая версия, в которой разработчики серьёзно прокачали скорость. Компилятор .astro переписали на Rust, туда же перенесли обработку Markdown и MDX, а движок рендеринга заменили на систему с очередями. Вкупе с Vite 8 и новым бандлером Rolldown сборки ускорились на 15–61% по внутренним бенчмаркам. А поскольку самая быстрая сборка — та, которую не нужно запускать вовсе, в Astro 7 также стабилизировали кэширование маршрутов и добавили экспериментальных CDN-провайдеров кэша для Netlify, Vercel и Cloudflare.

В Astro 7 добавили продвинутый роутинг: появляется точка входа src/fetch.ts, дающая полный контроль над конвейером обработки запросов в Astro. Для разработки с участием ИИ Astro теперь умеет определять coding agents, запускать dev-сервер в фоне и выводить структурированные JSON-логи, когда агентам нужен машиночитаемый ответ.

Недавно под постом в канале MoscowJS разгорелся спор — со мной и организатором насчёт смола. Даже не столько насчёт смола, сколько в целом: стоит ли выбирать новые технологии или нет. Думаю, это касается не только смола, а любых новых фреймворков и библиотек.

Претензии вроде бы логичные, чтож, давайте разберем их

Частенько ли у вас возникает желание пойти в одну очень популярную песочницу ? Я думаю раз в пол года - год у многих возникает такое желание. И также часто возникает желание поставить парочку сотен модов…

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

UI-kit, которым пользуются несколько продуктовых команд, нельзя просто отправить в будущее и переписать под новый дизайн. За ним тянется прошлое: старые CSS-переменные, публичный API, кастомизации у потребителей и независимые релизные циклы. При этом бренд уже меняется, дизайнеры приносят новую палитру, типографику, motion, скругления и тёмную тему и всё это нужно аккуратно посадить на компоненты, которые продолжают работать в продакшене.

Привет, Хабр! Меня зовут Амир, я Senior Vue.js Frontend Developer в экосистеме Лукоморье. Уже шесть лет я развиваю фронтенд большой внутренней ERP-платформы, в том числе внутренний UI-kit: около 50 компонентов на Vue 3 и TypeScript, которыми пользуются несколько продуктовых команд в Ростелекоме.

В этой статье расскажу, как мы устроили для UI-kit такое «назад в будущее»: в одной долгоживущей ветке sova провели редизайн поверх работающих компонентов, сохранили публичный API для команд-потребителей и перевели визуальный слой на новую архитектуру. Мы внедрили 3-tier-систему дизайн-токенов, собрали pipeline на Style Dictionary и Tokens Studio for Figma, оставили старые CSS-переменные через legacy-алиасы, а заодно закрыли несколько долгов библиотеки: типизацию шаблонов, встроенный SVG-спрайт на 816 иконок, утилиту темизации и вынос runtime-зависимостей с сокращением бандла с 940 до 150 КБ.

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

Я работаю фронтенд‑разработчиком больше пяти лет. За это время я увидел много продакшн‑кода на Vue. Там есть одна повторяющаяся ошибка. Разработчики передают объект props в функцию watch целиком. Код компилируется. Ошибок в консоли нет. Проблема проявляется позже. Компонент усложняется и получает новые поля. Vue делает обход реактивных значений при такой прямой передаче. Система подписывает вотчер на все ключи объекта. (Тут система реагирует даже на те поля, которые в логике колбэка вообще не используются).

Это дает конкретные наблюдаемые эффекты в работе приложения.

Как из миксинов для валидации форм вырастает полноценная TypeScript-библиотека с плагинами, масками и 500+ скачиваниями в неделю. История рефакторинга, архитектурных решений и работы над ошибками длиной в 10 месяцев.

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

Все новые таймеры будут сохраняться в базу данных SQLite3, поэтому нужно будет написать CRUD-операцию для создания таймера. Также я добавлю операции для удаления и редактирования записей. К новому функционалу я подключу кнопки редактирования и удаления. Это позволит пользователю полноценно управлять таймерами.

Заваривайте чай, доставайте вкусняшки — пора «высаживать грядки из помидоров»! 🍅

Миграция большого legacy-проекта с Vue 2 на Vue 3 — это не только про код. Основная сложность начинается ещё до первого коммита: оценка объёма работ, поиск несовместимых API, планирование и организация процесса разработки.

Почему вообще это важно, и как донести эту мысль до бизнеса я уже описывала в другой своей статье «Ты всё ещё думаешь или уже мигрируешь на Vue 3». Рекомендую почитать.

А тут я поделюсь своим опытом, где мне пришлось лидировать миграцию: самостоятельно составлять план миграции, оценку времени, рисков и проводить саму миграцию.

Принципы SOLID, DRY, KISS во фронтенде работают ровно так же, как в любой другой разработке. Но если открыть почти любой проект, всё равно натыкаешься на мешанину.

Причём дело обычно не в том, что код «грязный» — он как раз бывает типизирован и проходит linter. Дело в том, что эти принципы отвечают на вопрос «как написать», а не «зачем мы вообще это пишем». А без ответа на «зачем» чистый код превращается в красиво оформленную путаницу.

На примере такой вещи, как store попробуем ответить на вопрос: что вообще такое контракт, зачем же нужна типизация и действительно ли это помогает в разработке.

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

Последние полгода я активно применяю LLM в своей работе. Автокомплитом от Github Copilot я пользуюсь с момента начала бесплатного бета-тестирования, а с выходом Opus 4.5 стало возможно отдавать железяке на реализацию целые блоки логики. Нужно только организовать виртуальную клетку, внутри которой он будет вынужден писать работающий код.

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

Всем привет. Я занимаюсь фронтендом в небольшой команде сервиса бронирования отелей. Хочу как я 8 дней ловил утечку памяти на проде, несколько раз думал, что починил, и каждый раз ошибался. А последний фикс был не в нашем коде, а в патче самого Vue, который через неделю апстрим откатил как регрессионный. У нас в результате осталась одна патч-версия, в которой утечки нет; обычный minor/patch update сейчас для нас не безопасен без повторной проверки heap-снапшотами.

Наш стек Nuxt 3.18 + Vue 3.5.x + TypeScript, SSR, Pinia, PM2 cluster, nginx перед Node. Обычный каталог отелей с тысячами SEO-страниц вида /oteli-v-{город}/{подборка}

Привет. Недавно пришлось повозиться с @tanstack/vue-table. Задача была стандартная: нужна таблица с сортировкой, фильтрами и редактированием ячеек. Казалось бы - идеальное время подключить готовое решение. Но не всё так гладко. Делюсь мыслями, граблями и тем, как я в итоге выкрутился.

Как перестать копировать формы и построить масштабируемую архитектуру

В enterprise-приложениях формы множатся быстро: create, edit, import, create-from-lead, duplicate — и вот у вас уже шесть копий одной формы, а внутри условный ад из if (mode === …).

Почему mode prop и giant form component не масштабируются, как разделить форму на четыре слоя: presentation, orchestration, context, data source. Что такое capabilities и почему они лучше условной логики. Как адаптеры отвязывают форму от source entities. Куда прятать submit, валидацию и внешний store. Как тестировать такую архитектуру изолированно.

Когда я начинал делать Gooly, мне казалось, что главная проблема — отсутствие нормального инструмента для организации мероприятий.

Но спустя месяцы разработки и общения с пользователями я понял гораздо более неприятную вещь: большинство social-продуктов умирают не из-за плохого кода, а из-за пустоты внутри системы.

В этой статье — про cold start, хаос чатов, выгорание организаторов, network effects и то, почему живой Telegram часто побеждает «идеальный» новый сервис.