Уже почти июнь подходит к концу, а я так и не выпустил эту статью. Исправляюсь.
Обзор на браузерные API, которые стали Widely available в мае 2026. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде.
Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем. 2.5 года назад также каждый месяц выходили новые фичи в браузере, а вот их уже пора начинать применять.
Друзья, сегодня отличный день, чтобы сделать свою первую статью на Хабре, который я читаю многие годы. Сегодня я успешно запустил в прод свой первый полноценный хобби (пет) проект.
Два года назад работая с замечательной командой консультантов института Адизеса, мы столкнулись с проблемой наличия бесплатного гибкого софта для построения орг.моделей. Быстро собрать подразделения и функции, перетащить ветки в новое место, покрасить и так что бы не рисовать линии и квадратики, а только сосредоточиться на самой модели, потому что все это происходит во время страт. сессии, где сидят руководители тех самых подразделений. А подразделений и веток много, сценариев много – кого-то временно скрыть или свернуть, кого-то скопировать как типовую функцию в другие ветки. Все делать нужно быстро и на большом экране и не всегда в логике HR штатной модели (а точнее всегда не в ней). Миро, Фигма и прочие конструкторы не подходят по той или иной причине.
Так у меня родилась идея приложения ORGFORMAT. Но только спустя два года я нашел время, чтобы ее реализовать.
Но мало сделать приложение, не менее важным было сделать легкий обмен сформированными моделями, возможность их просмотра и доработки участниками. А еще лучше часть рутины по низшим ветвям отдать ИИ на проверку или доработку. Так родилась еще одна идея – создать формат моделей, который говорит и на языке программы (data-to-diagram), и на языке человека, и на языке ИИ, и не зашит никакими лицензиями и нечитаемым кодом. То есть открытый формат. Было важно, чтобы формат работал с иерархическими моделями и не позволял никакие кросс-связи буквально, что бы пользователи не творили хаос между ветвями. Только прямая естественная потоковая иерархия и прямая ответственность. Но и признаки блокам нужны, так как не все способна отразить иерархия - так пришла идея тегов, как гибкая система реквизитов (а во многом и, по сути, мини база данных, при необходимости. Лайфхак!). Так же очень хотелось, что бы модель не только строила связи, но и по ним могла что-то посчитать - конечно же нужна универсальная ценность (value), но не ограничивать ее только одним типом, а дать свободно выбирать, что считать и в каких единицах схмерения – бюджет, время, единицы товара или количество населения страны. И это тоже нам надо! Для всего это отлично подошел хорошо известный ИТ-ишникам формат YAML, который для людей открыт, как текст, а для машины, по сути, четкая структура данных. Вот и отлично, я собрал на его базе прототип структуры и необходимых атрибутов. И дал короткое название .orgf. Сгенерировал несколько моделей через ИИ и дал проверить результат другой ИИ – результат великолепный. ИИ легко переводила любые данные в этот формат, хоть штатное расписание из Екселя, хоть выгруженные в PDF структуры функций и процессов. Прототип открытого формата ORGF себя полностью оправдал! Так получилось, что модели и формат появились раньше самого редактора моделей (приложения). Ну что же есть понятный запрос, теперь надо было сделать под него софт!
Мы рады объявить о релизе MDN MCP-сервера. MCP (Model Context Protocol) — это открытый стандарт, который позволяет ИИ-инструментам подключаться к внешним источникам данных. MDN MCP-сервер использует этот протокол, чтобы доставлять документацию MDN и данные о совместимости браузеров прямо в твой редактор кода или IDE.
Хочу поделиться кейсом, когда разработка типичного tab-switcher превращается в настоящее архитектурное решение.
Webnative - фреймворк для разработки нативных приложений на языках веба с использованием нативных webview компонентов.
Когда я первый раз пришёл на встречу со стейкхолдером в роли аналитика, я честно не знал с чего начать. Вопросы в голове были — но не в том порядке. Половину забыл по ходу. Вышел с ощущением что поговорили хорошо, но непонятно о чём.
Я поискал готовые шаблоны. Нашёл Excel-таблицы, PDF-чеклисты и десятки статей с советами. Ни одно из этого не открывалось быстро прямо на встрече и не помогало думать в реальном времени.
Поэтому я сделал BA Toolkit — набор интерактивных инструментов для структурирования BA-встреч. Открываешь в браузере, идёшь по шагам, фиксируешь всё на месте.
Три месяца спустя — три инструмента в продакшене, открытый код на GitHub и эта статья.
Привет, Хабр!
В общении с коллегами я всё чаще замечаю, что многие не знают о последних возможностях CSS. Кто-то настолько занят повседневными задачами, что просто не успевает следить за новинками. Кому-то это не особенно интересно. А кто-то уже много лет использует знакомые подходы и не видит причин что-то менять.
Как человеку, который является поклонником CSS, мне немного грустно это наблюдать. Столько интересных возможностей остаётся без внимания! А ведь с их помощью код нередко становится короче, надёжнее и проще для понимания. Поэтому я собрал несколько примеров популярных решений прошлого и переписал их, используя новинки CSS, вышедшие за последние несколько лет.
Давайте посмотрим, что у меня получилось.
Когда возникает идея создать браузерный IRC-клиент без JavaScript, приходится сталкиваться с классической проблемой фронтенда: все насколько привыкли гнать динамику через JavaScript, что перестали замечать возможности HTML/CSS с щепоткой серверной магии по реализации многих фич. HTTP Streaming существует с давних времён, а CSS эволюционировал настолько, что может справиться с логикой состояний — но мы упорно продолжаем грузить мегабайты JavaScript (и иногда даже WebAssembly) для решений, которые вполне можно реализовать иначе.
Идея создать IRC клиент без JavaScript не совсем нова (хоть это и выяснилось уже после создания такого :) ). Ещё в нулевых появился CGI:IRC — настоящий IRC клиент, который может работать полностью без JavaScript, позволяя людям общаться в реальном времени через браузер, даже если JavaScript по каким-то причинам не работал. Но это было в эру table-layouts, и когда CSS не был так развит, как сейчас. Сегодня возможностей больше, и мы воспользуемся ими, чтобы навернуть функциональность, которая не видана CGI:IRC.
Результат можно глянуть (хоть и с дополнительной стилизацией и изменениями, которые не так важны для статьи) здесь, а ещё на GitHub
Когда маркетологи хотят всё: сырые данные в GA4, запись сессий в Метрике, хитмапы в Clarity и при этом «Lighthouse 100» в PageSpeed Insights — приходится изобретать. Расскажу, как мы это сделали на небольшом проекте и во что это обошлось по времени и нервам.
Проект — нишевый агрегатор российских хостинг-провайдеров. Более 120 страниц в sitemap, 31 статья, десятки категорий услуг, живые цены, сравнения. Стек: Astro 6 + Strapi 5 + Tailwind 4, плюс Partytown, PostgreSQL, Nginx и обычный VPS на Ubuntu. Сайт собирается в статику во время билда, никакого SSR в рантайме нет.
На desktop — Lighthouse 100 / 100 / 100 / 100. На mobile с жёстким throttling (4x slow CPU) — 99 / 100 / 100 / 100. В реальных условиях и по Chrome UX Report — 100 везде. LCP на desktop — 0,5 секунды, на mobile throttled — 1,7 секунды. CLS — ноль. TBT — 10 ms на мобильном и 0 ms на десктопе.
Каждый раз, когда я хотел поправить отступ или цвет в процессе разработки, я делал одно и то же:
открыл DevTools → нашёл элемент → поменял значение → понравилось → скопировал → переключился в редактор → нашёл файл → вставил.
Это семь шагов ради однострочного изменения. Я сделал LiveStyleSync, чтобы это был один шаг.
Привет, Хабр!
Мне всегда нравилось следить за тем, как развивается CSS. Стараюсь следить за новыми возможностями, чтобы не пропускать что-то действительно важное. И недавно подумал: «А почему бы не рассказать о них читателям Хабра?» Так я и оказался здесь.
Я составил список новинок, которые кажутся мне особенно интересными и важными. Они всё ещё экспериментальные. Браузеры только в последние месяцы начали поддерживать их. Так что это суперсвежие штуки.
Давайте посмотрим, что я вам подготовил.
В прошлой статье я рассказывал, каково в одиночку тащить фуллстек-проект, который разросся до кино-соцсети. В комментариях несколько раз спросили про конкретику — «покажи код», «как сделал, что не выглядит как очередной пет-проект». Логично: дизайн — это то, по чему встречают. Поэтому держите вторую часть, уже техническую и с кодом. Без маркетинга, только решения, которые реально сделали интерфейс «дорогим», и пара бэкенд-хитростей в довесок.
Сразу дисклеймер: я не дизайнер. Всё нажито методом «смотрю на референсы (Letterboxd, Mubi, KinoPoisk HD) и пытаюсь повторить ощущение». Оказалось, премиальность — это не про дорогие шрифты, а про несколько повторяющихся приёмов. Разберём пять.
1. Акцентный цвет из постера фильма — фича, которая дороже всего «продаёт»
Самое заметное решение. Раньше у меня на всех страницах был один статичный фиолетовый акцент — и это выглядело дёшево и одинаково. Идея: пусть каждая страница фильма подсвечивается доминантным цветом его постера. Заходишь на мрачный нуар — интерфейс уходит в холодный синий, открываешь комедию — тёплый янтарь. Страница будто «сделана под этот фильм».
Делается без всяких ML, прямо в браузере через canvas: рисуем постер в крошечный буфер 32×48, усредняем цвета (выкидывая чёрные рамки и серость), переводим в HSL и принудительно «насыщаем», потому что постеры часто тусклые. Результат кладём в CSS-переменную — и весь интерфейс подхватывает её.
Если вы веб‑разработчик и хоть раз подключали шрифт «потому что он красивее, чем системный Arial» — есть ненулевая вероятность, что у вас на сайте лежит коммерческий гарнитур без лицензии. Российский бизнес три‑пять лет назад массово открыл для себя, что это не безобидно: за период 2021–2025 годов через арбитражные суды по шрифтовым искам взыскано 15,3 млн ₽ (данные Коммерсанта), число исков выросло в 2,5 раза за пять лет, и тренд продолжается.
При этом проверить свой сайт на потенциально опасные шрифты — технически нетривиальная задача. Парсить CSS «как получится» через регулярки не работает: получаются ложные срабатывания на CSS‑ключевые слова, на источниках вроде Яндекс.Метрики, на иконочных шрифтах. Дальше — про правовую сторону вопроса и про то, как мы написали детектор, который этим не страдает.
Исторически создание карусели в веб-разработке означало использование какой-либо JS-библиотеки. Slick, Swiper, Flickity, Embla Carousel и другие заполняли пробел платформы. Каждая из них увеличивала размер сборки, имела свои особенности обеспечения доступности и накладные расходы на обработку событий. Полный минифицированный пакет Swiper v11 весит приблизительно 140 КБ; даже модульные импорты составляют 40-60 КБ для ядра и навигации. Умножьте это на бесчисленные маркетинговые страницы, галереи товаров в электронной коммерции и макеты с большим количеством медиаконтента, которые зависят от каруселей, и расходы сильно возрастут: долгое время до интерактивности, блокировка основного потока во время инициализации и большой размер передаваемых данных на каждой странице, где используется слайдер.
Правильная файловая структура - скелет любого фронтенд-приложения. В Vue 3 нет строгих предписаний, как раскладывать файлы по папкам, кроме базового разделения components/, views/. Но с ростом проекта хаотичное размещение кода быстро превращается в проблему. В этой статье разберём популярные подходы к организации Vue-проектов: от простейшего плоского до микрофронтендов.
Медиа-запросы (media queries) - это основа отзывчивого дизайна. Мы используем их для определения того, как должен меняться дизайн на основе размеров области просмотра (viewport). Но синтаксис min-width и max-width может вызывать путаницу, и в некоторых случаях вызывает проблемы макета (layout), которые трудно выявить.
Цель этой статьи - убедить вас использовать запросы диапазонов (range queries), начиная с сегодняшнего дня.
Я попробовал собрать маркетинговый сайт через Claude Design - и быстро упёрся в лимиты токенов и непрозрачность облачного тула. Перешёл на Open Design - open-source альтернативу, которая цепляет твой Claude Code, держит дизайн-систему как DESIGN.md в репозитории и работает локально. Под катом - четыре практики, которые сработали на сайте конференции: design-as-code в git, симлинк дизайнера в код сайта, два markdown-файла под бренд и дизайн токены, и как мы учили автономных агентов делать сайт с помощью нашей дизайн системы
wkhtmltopdf долгое время был одним из основных инструментов для генерации PDF из HTML. Мы столкнулись с ним на собственном проекте, но, когда потребовалось реализовать сложные макеты, колонтитулы и повторяющиеся заголовки в многостраничных документах — возникли проблемы.
В этой статье — краткий обзор альтернатив (Headless Chrome, Puppeteer, Playwright, WeasyPrint, Gotenberg), их плюсы и минусы, а также наш итоговый выбор и подводные камни, которые всплыли в процессе внедрения.
Привет, Хабр!
Мне нравится рассказывать про HTML и CSS. Отдельное удовольствие — находить очень старые фичи языков, о которых редко кто знает. Сегодня я пришёл как раз с ними.
Я подобрал список фич, которые стали полностью поддерживаться в браузерах восемь лет назад или раньше. Есть даже одна, которая работала, когда я пришёл во фронтенд.
Только, пожалуйста, не думайте, что это какие-то устаревшие возможности. Я считаю, что в сегодняшней разработке они всё так же полезны.
Давайте посмотрим, что я подготовил.
Не нашел на хабре информации про эту замечательную опенсорсную программу - Übersicht.
Xочу поделится опытом как у меня получилось решить мою боль с постоянным забыванием, что нужно сделать и что запланировано.
Последней каплей стал случай на работе, когда меня спрашивают про тайминг очередной встречи, я залезаю в рабочий календарь Битрикса - все пусто, говорю да я свободен, а потом через час вспоминаю что на это время записан к зубному и дальше переговоры переносы и прочее, а можно было. бы решить вопрос за 2 секунды.
Конечно вы скажете сам виноват, делай стикеры на монитор, веди все в одном месте, открывай нужные программы, это да но лень, я только недавано приучил себя использовать таск менеджеры, и заносить туда информацию, это мне еще ориентироваться на то что я там записал?)
Начну с таск менеджеров.
Я долго искал таск-менеджер, который бы не был просто «еще одним приложением», куда я забрасываю дела и забываю про них. Мне было важно видеть свои задачи, а не вспоминать, что нужно открыть очередную программу и проверить, что там на сегодня.
Календарь в Google — понятно, встречи там. А задачи и напоминания? Todoist, Things, Singularity, напоминания Apple — это все хорошо, но каждый раз лезть в отдельную программу, это лишние 10–15 секунд, которые отбивают всякое желание планировать. Todoist я долго пользовался, почти год но мне не хватало одной важной фишки: Вот Календарь с задачами и встречами и справа тут же окно с не распределенным задачами и можно драгдропом перекинуть их в нужный день и в нужное место.
