CSS *

Привет, Хабр.

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

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

Здравствуйте, товарищи! Продолжаю писать о своих приключениях в мире open source. Сегодня речь пойдет о маркетинге, а точнее: про один из каналов - площадки для стартапов, типа Product Hunt.

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

Привет, Хабр!

CSS часто преподносит сюрпризы, способные запутать даже опытных разработчиков. Я понимаю их раздражение. Тут всё закономерно.

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

И всё же, несмотря на все потраченные нервы, CSS мне нравится. Поэтому хочется, чтобы разработчики реже тратили время на борьбу с его особенностями. Изменить стандарты языка не в моих силах, но я смог собрать несколько неочевидных моментов, которые в своё время поставили в тупик меня и моих коллег.

Пришёл поделиться с вами. Давайте посмотрим, что я подготовил.

Как вырваться из замкнутого круга навязываемых акулами BigTech сомнительных технологий на простор устойчивого развития? Как сделать так, чтобы код внедряемой сейчас Дизайн‑системы — через пару лет опять не превратился в очередную, никому не нужную и максимально не удобную, «тыкву‑легаси»? Как выйти из дурного холивара с модными фреймворками на фронтенде и сделать библиотеку переиспользуемых компонент подходящую сразу для всех технологий и «на века»?)))

Ваша команда работает с большим количеством различных недокументированных проектов, основанном на одном визуальном языке? У вашей корпорации есть строгий брендбук и огромное количество клиентских веб‑сервисов написанных на разных фреймворках, которые по факту выглядят немного по‑разному в «одних и тех же мелочах»? Ваши фронты «пишут каждый свой фреймворк для дизайна заново каждый раз на каждом проекте»? Знакомо? UUI спешит к вам на помощь!

Мода на технологии все стремительней меняется, а браузер и простой интерфейс в нем остается. Вышел новый модный фреймворк и заказчику хочется проект именно на нем? Да пожалуйста! Легко! Так мы становимся максимально независимы от капризной и накаченной лоббированием индустрии реализуя основную задачу. Поставляя единый гайдлайн повсюду.

50 итераций колесом мыши, чтобы просмотреть содержимое одного выпадающего списка. Это не баг — это фича Хабра и десятков других сайтов.

Раньше в Sass был только @import, который создавал кучу проблем: глобальное загрязнение, конфликты имён, дублирование кода. В новых версиях (Dart Sass) @import объявлен устаревшим — вместо него пришли @use и @forward. Переход на модульную систему — это не просто замена одного слова на другое, а смена парадигмы. Теперь каждый файл — изолированный модуль со своим пространством имён.

В статье на реальных примерах показано:

- как подключать переменные, миксины и функции через @use;

- почему больше не работает @import 'file' и как исправить старый код;

- что такое встроенные модули (math, list, map, string, color) и зачем их подключать вручную;

- как гибко настраивать темы через !default и with();

- чем @forward отличается от @use и как с его помощью собирать публичное API проекта;

- как избежать ошибок с повторными импортами и конфигурацией.

Материал будет полезен всем, кто пишет на Sass и хочет идти в ногу с развитием инструмента.

Меня зовут Виталий, я из команды ArcaneGaming.
Сегодня я хочу рассказать вам о своем пет-проекте, который немного вышел из-под контроля и превратился в полноценный продукт.
Встречайте - Snuffer!

😫 С чего всё началось?
Знаете это чувство, когда вам пишет клиент (или, что еще хуже, мама):

Обратимся к статистике: по данным с https://httparchive.org/ за последние 6 лет средний размер веб-страницы значительно увеличился. Если в декабре 2019 года средний вес десктопной веб-страницы составлял 1,9 МБ, то сейчас он уже 2,9 МБ для десктопа и 2,6 МБ для мобильных устройств. Это рост на 50% за 6 лет, причём изображения составляют до 40% общего веса страницы.

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

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

Я решил провести эксперимент: оптимизировал и переконвертировал изображения в JPEG, WebP и AVIF, сохранив качество на глаз неотличимым от оригинала.

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

Если в вашем коде и макетах до сих пор живут значения типа #0055FF — вы копите технический долг, ведь если понадобится изменить этот цвет на другой, придется менять и все компоненты, где используется это значение. А про разные темы вообще можете забыть...

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

Многие верстальщики используют Flex на автомате просто потому, что привыкли к нему за долгие годы. Grid часто кажется чем-то избыточным или пугающим из-за своего специфического синтаксиса. На самом деле эти инструменты не заменяют друг друга, а решают принципиально разные задачи.

Разница между ними кроется в самом подходе к пространству. Flex создавался для работы в одном измерении, когда вам нужно выстроить элементы в строку или столбец. Grid же мыслит сразу в двух плоскостях, позволяя контролировать и ряды, и колонки одновременно.

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

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

Привет, Хабр!
Меня зовут Артём, я фаундер Leadl.ai. Мы строим AI-агента для поиска b2b-клиентов, и одна из его ключевых задач это мониторинг чатов и различных источников.
Звучит просто, пока не сталкиваешься с масштабом.

У нас в пуле 20000+ чатов в 15 источниках. Суммарно около 1000 000 000 сообщений в сутки. Из них реально полезных (запросы на услуги, поиск подрядчиков, вакансии) от силы 3-5%. Остальное: флуд, криптоспам, «доброе утро», мемы и бесконечные стикеры.

Задача: вытащить эти 3-5% качественных сообщений. Первой мыслью было отдать всё на откуп большой LLM типа GPT-4o. Посчитали. Среднее сообщение 50 токенов. 100 000 сообщений 50 токенов/сообщение ($10 / 1M токенов) = $50 в день только на input. Добавьте сюда output и prompt — и счёт легко перевалит за $100-150/день или $3000-4500/месяц. Для стартапа это путь в никуда.

Нам нужен был pipeline, который бы отсеивал мусор на ранних этапах, чтобы до дорогого LLM-скоринга доходило не более 5-10% от всего потока. Вот как мы его построили, через какие грабли прошли и что из этого вышло.

Знаете это чувство, когда сидишь на очередном спринт-планировании, команда пытается оценить таски, а планинг покер тормозит так, что успеваешь кофе сварить, пока карточка загрузится?

Вот у меня в AGG TEAM такая же история была. Мы пробовали:

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

И здесь приходит на помощь RxJS

RxJS часто пугает своей сложностью. Прикол в том, что вам не нужно знать все 100+ операторов. Достаточно освоить базовую пятёрку, которая покроет 80% проблем.

Привет, Хабр!

Мне грустно, что вы не используете многие HTML- и CSS-фичи. Я не могу смотреть на это, бездействуя, поэтому пришёл к вам. Хочу поделиться своим списком фич, которые уже давно пора использовать.

Конечно, я подумал о кроссбраузерности. Поэтому все фичи хорошо поддерживаются во всех современных браузерах с 2023 года. Я специально проверил их в «Can I use».

Давайте посмотрим, что я вам подготовил.

История фронтенда хорошо показывает, что инструменты редко исчезают мгновенно. Чаще они проходят понятный цикл: сначала решают конкретную проблему и быстро набирают популярность, потом становятся привычной частью стека, а со временем уступают место следующему подходу. Примерно так развивается и CSS-in-JS. Когда он появился, это выглядело логичным шагом: стили рядом с компонентами, темы, токены и удобная интеграция с React. Со временем стало ясно, что у этой модели есть и ограничения — стили генерируются в рантайме, усложняется SSR, а в больших приложениях начинают накапливаться накладные расходы. Появились попытки сделать CSS-in-JS легче и быстрее. Одной из них стал Stitches: он сохранил удобный DX и заметно сократил рантайм. Но развитие проекта остановилось, а требования к фронтенду продолжают расти. Поэтому всё чаще обсуждают другой подход — перенос генерации стилей на этап сборки. В этой логике и появился StyleX.

Это перевод статьи Брайана Тимана (Brian Teeman) о переопределении макета материала Joomla, с разделением блока вводного текста и полного текста материала. С примером возможного оформления.

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

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

В 2026 году выбор инструмента для стилизации — это не вопрос вкуса, а вопрос архитектуры. Мы разберём, где Tailwind CSS v4 выигрывает у признанных лидеров: компонентных библиотек (MUI, Ant Design) и CSS-in-JS решений (Styled Components).

Сайт Словарус 2.0 – это вторая улучшенная версия сайта с русской заменой иностранных слов, который я ранее делал по заказу Love Media и лично господина Маркелова.

Задача. Восстановить сайт из веб-архива и сделать его лучше.

словарус.рф

Обзор на браузерные API, которые стали Widely available в феврале 2026. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде. В этом месяце всё довольно скучно и одиноко.

Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем. 2.5 года назад также каждый месяц выходили новые фичи в браузере, а вот их уже пора начинать применять.