Веб-разработка *

На днях я стряхнул пыль с небольшого пет-проекта. Это простой блог, наверняка каждый из вас хотя бы думал о таком для себя.
В 2015 году я бы просто закинул файлы по FTP на хостинг за 100 рублей. Время деплоя: 30 секунд.
В 2026 году я потратил 4 часа. Я настраивал Edge Middleware, дебажил рассинхрон HTML между клиентом и сервером (hydration mismatch) и разбирался, почему облако не хочет дружить с моей базой данных из-за долгого пробуждения функций (холодного старта).

Где мы свернули не туда?
Это колесо Сансары, которое дало новый оборот.

10 лет назад OpenVPN считался надёжным инструментом. Сегодня он блокируется за секунды. За это время сменилось пять поколений протоколов — каждый новый рождался как ответ на то, чему научился цензор. Это история гонки вооружений между математикой и политикой. И она ещё не закончена.

И где мы сейчас ?

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

вот пример:

SELECT
price * quantity AS total_price,
(price * quantity) * 0.15 AS tax,
((price * quantity) + ((price * quantity) * 0.15)) AS grand_total
...

Здесь price * quantity вычисляется несколько раз, и tax вычисляется дважды. Но это выглядит еще ок, в реальности это зачастую всякие монструозные свитч-кейсы с NULLIF, COALESCE и прочими ребятами.

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

Long story short, это делается так:

В 2013 году на Randomwire была опубликована интересная статья. В ней автор указал на интересные особенности японского дизайна. Японцы известны своим минимализмом, но в случае сайтов у них, почему-то, всё наоборот. Страницы пестрят всевозможными цветами, что уже нарушает 3 принципа дизайна, плюс на них используются мелкие иконки и мно-о-о-о-го текста.  Да вы и сами видите пример этого буйства фантазии на скриншоте выше, сделанном в ноябре 2022 года.

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

И вот мне стало интересно, как обстоят дела сейчас, и можно ли как-то количественно оценить дизайн японских сайтов? Собственно, этим я и занялся.

В последние несколько дней я начал замечать странную вещь: находясь под средствами обхода блокировок, у меня перестают работать отечественные ресурсы — вроде Яндекс Маркета, Яндекс Телемоста и других сервисов.
Но стоит отключить обход — всё снова функционирует нормально.

Получается парадоксальная ситуация: людям, которые просто хотят посмотреть котиков на YouTube или спросить ChatGPT о какой-нибудь ерунде, снова начинают вставлять палки в колёса.

Из этого напрашивается тревожный вывод: суверенный интернет уже не где-то в теории — он буквально дышит нам в спину. Интернет, в который всё сложнее попасть извне. Интернет, который постепенно замыкается сам на себе.

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

Привет! Я — Аля, старший продакт-менеджер выделенных серверов в Selectel. Представьте, вашей команде нужно разработать новый интерфейс для продукта. Вы ставите задачу на дизайнера, а он приносит статичные картинки экранов в Figma. На встрече команда смотрит на них и понимает, что половина сценариев не продумана. Возникают вопросы: «Что будет, если пользователь нажмет на кнопку или данные не загрузятся?» И вместо того, чтобы передать задачу в разработку, вам приходится выяснять детали в комментариях и чатах.

Нам это хорошо знакомо. Долгие циклы согласований, переделки после релиза, сложности с тестированием — все это было частью нашего процесса. Чтобы решить эти проблемы, мы решили попробовать AI-инструменты для прототипирования. В статье расскажу, как Figma Make и другие сервисы помогли нашей команде ускорить создание прототипов и сократить количество правок. Будет полезно тем, кто устал от цикла «получить макет → найти проблему → подождать правки → повторить».

Помните сказку про мальчика, который кричал «волки»? Примерно так же в 2025 году случилось с «программированием на CSS». Вышла функция if(). Блогеры преждевременно хайпанули: всё, теперь у нас условия в CSS. Разработчики пошли читать спецификации, попробовали — и довольно быстро выяснилось, что внутри условного выражения style() возможностей почти нет. Многие разочаровались и похоронили идею.

В конце 2025 года Chrome выкатил революционный Range Syntax For Style Container Queries. Обновлённый style() научился сравнивать переменные между собой и поддерживать диапазонные выражения. Мы наконец‑то получили мощную условную логику в CSS, но мало кто это заметил.

В этой статье мы попытаемся реанимировать идею программирования на CSS. На примере интерфейсного паттерна — «выделение диапазона дат в календаре» — разберём, как обычная JS‑логика превращается в CSS‑логику (спойлер: очень просто).

Вспомните нулевые — браузерные страницы мигали баннерами и интерактивными элементами, игры запускались прямо во вкладке, а Flash Player был знаком почти всем. Но в 2020 году Adobe завершила его поддержку и начала блокировать Flash-контент. Так и закончилась эта история, а что было бы, если всё пошло иначе? Историю Flash и альтернативный сценарий разбираю в статье. 

Ты понимаешь, что баг хорош, если первым делом думаешь: «Как это вообще может происходить?»

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

Разумеется, сначала я обвинил в этом React.

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

Чтобы подтвердить свою теорию, я рассказал Claude¹, что загрузка дэшборда тормозит и что проблемы наверняка в React, попросив проанализировать их и ранжировать по степени серьёзности. Конечно же, Claude обнаружил в React кучу подозрительных аспектов — ненужный повторный рендеринг, отсутствующие мемоизации и так далее. К тому же он подсказал, что мы всё ещё не используем React Compiler. Я попросил Claude выполнить первый проход решения самых простых и самых серьёзных проблем React, но…

Практически ничего не поменялось. Возможно, дело всё-таки не в React.

Итак, я закатал рукава и начал тщательное расследование.

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

Вопросы по HTML и CSS всё реже встречаются на собеседованиях для фронтендеров. Но в основном это касается позиций middle и выше. А вот для начинающих специалистов они всё ещё есть.

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

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

Сразу скажу, что буду душнить. Так что вы сами рассудите, кто из нас лучше отвечает.

Давайте начнём!

Привет, Хабр! Меня зовут Владимир, я Python-разработчик в команде IMV в Авито. Мы разрабатываем продукт, который помогает оценивать рыночную стоимость товара, будь то автомобиль, квартира или холодильник. Мы часто пишем тесты, и в этой статье я расскажу, как разные подходы к юнит-тестированию влияют на качество тестов, когда они помогают проекту, а когда — мешают, и почему само по себе наличие тестов ещё не гарантирует пользы. Статья будет полезна разработчикам, тимлидам и всем, кто пишет юнит-тесты и поддерживает код в долгоживущих проектах.

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

Недавно я посмотрел фильм «Тетрис» (2023) и поймал себя на мысли, что история создания — не менее увлекательна, чем сама игра. А ещё она вдохновила меня на идею, взять классическую механику и добавить в неё щепотку… песка.

Помните времена, когда статический сайт был сайтом-визиткой на голом HTML, а любой серьёзный проект требовал CMS?

Мы привыкли считать нормальным сайт на WordPress, «Битриксе» или хотя бы самописном Django. Статика же оставалась уделом гиков, документации и страниц о скором запуске.

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

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

Мне нравится смотреть, как верстают современные фронтендеры. Забавно наблюдать, как меняется вёрстка с годами. И сразу скажу, что не всё «плохо». Но ошибки, конечно же, есть. Раньше были свои примеры «плохого» кода, сейчас другие. О них хочу поговорить в этой статье.

Я составил список распространённых примеров кода «с душком». Старался быть объективным, но судить только вам, насколько это у меня получилось.

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

Я в IT больше 10 лет. Начинал с верстки, вырос в фронтенд-разработчика, потом стал тимлидом, далее менеджером проектов и сейчас руковожу отделом разработки решений для бизнеса. Я знаю JavaScript. Я люблю JavaScript. И именно эта любовь сыграла со мной злую шутку.

В индустрии есть опасная иллюзия: «Если ты знаешь JavaScript, ты – фулстек». Node.js дал нам, фронтендерам, суперсилу. Мы можем писать серверный код на том же языке, что и клиентский. Мы можем использовать одни и те же типы, одни и те же библиотеки.

Нам кажется, что разница между фронтендом и бэкендом — только в том, где выполняется код.
В браузере нет fs (файловой системы), а на сервере нет window. Вот и вся разница, да?

Нет. Разница не в синтаксисе. Разница в мышлении. И я узнал это самым тяжелым способом – положив релиз.

Бьюсь об заклад вы привыкли к инструментам разработчика в Chrome. Ежедневная проверка вёрстки, просмотр логов или анализ загрузку страницы делается на автопилоте. Но что если есть альтернатива, которая в некоторых моментах работает иначе и часто даже лучше?

Инструменты разработчика в Firefox создавались отдельно и имеют свою историю. Их команда не ставила задачу сделать копию Chrome. Вместо этого они сфокусировались на своих идеях о том, как сделать отладку более наглядной. В результате некоторые вещи там реализованы более прямолинейно и понятно. Конечно, не всё идеально, и у Chrome есть свои преимущества. Об этом сегодня и поговорим.

В этой статье мы посмотрим на Firefox DevTools в деталях. Отойдем от банальных соревнований в стиле «у кого DevTools длиннее». Вместо этого разберем, в каких ситуациях панель Firefox может сэкономить вам время, а в каких всё же удобнее остаться в Chrome. Откроем для себя несколько приёмов, которые можно добавить в свою ежедневную работу, независимо от браузера.

Наверное, каждый из нас ловил себя на мысли: что отправить на день рождения в этот раз? Просто текст, тёплую фотографию или голосовое сообщение? И сразу вспоминается это чувство, когда ищешь или обдумываешь креативный текст, а потом вспоминаешь о милой картинке с котиком, гифке с шампанским или стандартном «С ДР!» — и отправляешь, чисто для галочки.

Со временем я заметил: когда получаешь такое поздравление в Telegram, становится немного грустно, что человек хоть и поздравил, но не потратил время на то, чтобы обдумать и искренне пожелать чего-то хорошего и уникального только про тебя. Хотя понимаешь — это нормально. Поколение постарше привыкло обмениваться этими милыми, но безликими посланиями. Хотя не все делают это из-за нежелания — некоторым просто понравилась картинка, вот и скинули.

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

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

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

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

Создание блоков с вырезами всегда было трудоёмким, даже для вырезов простейшей формы. Фронтендеры годами тренировались мысленно рассекать блоки на части: прямоугольничек для контента, прямоугольничек для выреза и ещё парочка рядом с ним. И вдруг парадигма поменялась...

Простые вырезы теперь делаются в десять раз быстрее. Одной строчкой кода. Да, надо менять мышление и забывать про нарезку блоков. И как же это приятно!

В статье мы сверстаем карточку с круглым вырезом двумя способами: традиционно‑дедовским и современным. Затем сравним объём кода, простоту и гибкость получившихся реализаций. И порадуемся, что будущее уже наступило!

Я не нашел на хабре достойного представления фрейморка Jaspr сообществу и решил представить сам. Flutter, безусловно, хорошая магия: один код для всех платформ, в том числе и Web. Но за магию приходится платить. Платить мегабайтами загрузки, муками с SEO и ощущением, что ты принёс на пляж боулинг — вроде и весело, но как-то не к месту. Команда Flutter и сама честно говорит: Flutter Web создан для веб-приложений, а не для веб-сайтов. Для сложных дашбордов, PWA, для всего, что живёт за логином — да. Для контентного сайта, блога, лендинга — увы.

Знакомьтесь, Jaspr. Веб-фреймворк на Dart, который осознанно отказывается от канваса и пиксельной магии Flutter в пользу старого доброго HTML и CSS. Он выглядит как Flutter, ощущается как Flutter, но на выходе даёт то, что поисковики и браузеры любят и понимают: обычный HTML-документ и DOM. А попробовать на вкус его можно здесь.