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

Платный трафик на лендинг с формой захвата — это почти всегда мусорные заявки. Номер 123, номер 1111111, четыре цифры вместо телефона. Заявка засчитана, деньги за клик списаны, позвонить некому.

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

Эту печальную историю стоит прочесть всем, кто еще не понял разницы между «создать» и «владеть» применительно к программному обеспечению.

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

Начну с контекста. Я играю в EA FC (ранее FIFA) в режиме Clubs (11×11), где каждым виртуальным игроком управляет человек. Сам по себе режим интересный, но мне, как человеку, который любит цифры и аналитику, довольно быстро стало не хватать доступной статистики.

Я пришёл в лигу, у которой уже был свой сайт (я в этой статье опущу тему о том, что я администрировал проект порядка 3 лет). Там статистику собирали вручную: люди пересматривали записи матчей и заносили базовые показатели — голы, ассисты, перехваты, отборы и так далее. На основе этих данных считались различные рейтинги: лучшие игроки, бомбардиры, разрушители и прочее.

Выглядело это примерно так: набор таблиц, где действия сгруппированы по категориям и амплуа.

Если кратко - да все с ними ТАК. Это замечательный набор современных браузерных технологий, для решения реальных задач веб-разработки. Веб-компоненты позволяют делать очень многое, более просто и элегантно, чем это было бы без них. А главное, они позволяют, с потрясающей гибкостью, решать задачи “со звездочкой” - те, которые немного выходят за рамки и требуют более творческого подхода от разработчика.

Почему-же тогда по Хабру гуляют, кхм… некие одиозные личности (не будем показывать пальцем) и рассказывают нам про то, что веб-компоненты это ужас-ужас и полный провал? Давайте разберемся.

На дворе 2026 год. В мире неспокойно. Военные конфликты, санкционные войны, передел рынков, борьба за ресурсы. Кажется, что мировая финансовая система уже давно живёт в режиме постоянной турбулентности, и никого это не удивляет.

А что у нас по крипте?

На момент написания статьи биткойн держится в районе 70 тысяч долларов. Кто-то скажет: опять рухнул. И формально будет прав. Относительно недавнего исторического максимума в 126 тысяч долларов это действительно серьёзное снижение — почти в два раза. Но давайте обернёмся и посмотрим на ситуацию не в масштабе недель или месяцев, а в масштабе последних лет.

Не так давно сама идея о том, что биткойн может стоить 100 тысяч долларов, для многих звучала как «бред сумасшедшего». Причём не только для рядовых скептиков, но и для вполне серьёзных и влиятельных экономистов. Сосем недавно отметка в 10 тысяч казалась фантастикой. Потом рынок долго привыкал к 20 тысячам. Затем спорил, возможны ли 50. А сегодня рост до 200 тысяч уже выглядит лишь вопросом времени.

Мы быстро ко всему привыкаем

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

За это время криптоиндустрия уже успела пройти через многое. Эра ICO — время, когда рынок буквально заливали деньгами за одни лишь обещания. Бум L2-решений и новых блокчейнов. Затем волна NFT, различных Web3-сервисов, GameFi-игр и множества других трендов.

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

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

$47 за неделю на LLM API — при том что половина запросов тривиальные. Поставил ClawRouter — open source роутер, который анализирует промт по 15 параметрам и отправляет в самую дешёвую подходящую модель. За следующую неделю потратил $1.80. Рассказываю, как работает, что понравилось, что нет и какие есть альтернативы.

Привет!

Это одиннадцатый выпуск Frontend Status — дайджеста по фронтенд-разработке.

В этом выпуске:

📺 Плейлист по отладке Next.js с Sentry.

🤖 Рэйчел Эндрю и Эдди Османи — два взгляда на AI: когда использовать, а когда координировать целый оркестр агентов.

🛡️ GlassWorm: атака через невидимые Unicode-символы в npm-пакетах и расширениях VS Code.

🎨 CSS Anchor Positioning: два круга, стрелка и ноль строк JS от Темани Афифа.

⚛️ Storybook MCP для React, data-testid как признак недоступности и пошаговые туры через React Joyride.

👁️ Vue Devtools не работает в продакшене? QA-инженер написал свой инспектор.

🌎 Chrome 147 с scoped view transitions, Safari TP 240 и дайджест веб-платформы за март.

🖌️ Осмысленное трение в UX, ARIA-роли для дизайнеров и тест масштабирования шрифтов в Figma.

…и многое другое.

Задача: человек регистрируется, оплачивает, получает ключ на почту и сразу подключается. Без ручной работы с моей стороны. Под капотом — FastAPI, Marzban, PostgreSQL, React, ЮKassa, Resend. Расскажу про архитектуру, грабли и неочевидные решения.

Pinterest — не просто соцсеть для рецептов и идей. Это мощная визуальная поисковая система, которая может приводить целевой трафик на статьи, если правильно «подружить» её с сайтом. В этом руководстве я покажу, как сделать так, чтобы Pinterest сам находил новые статьи, подхватывал картинки и описания и создавал пины — без ручного копирования.

Если у вас есть собственный сайт — вы наверняка проверяли его работу с телефона. Открыли, полистали, остались довольны: «Всё летает». Но это не гарантия, что так же быстро сайт загрузится у ваших посетителей.

Представьте: пользователь заходит на ваш сайт с iPhone (неважно, нового или трёхлетней давности) — и страница зависает, изображения грузятся по одному, скролл дёргается. Через 5–10 секунд он просто закрывает вкладку и уходит к конкурентам. Проблема не в вашем телефоне или интернете, а в скрытых особенностях браузера Safari и устройств iOS.

Ниже — руководство по оптимизации, которое поможет избежать таких сценариев. Пройдитесь по чек‑листу и убедитесь, что каждый пункт выполнен. Даже если ваш сайт кажется быстрым, с большой вероятностью он теряет часть аудитории на Safari.

Сегодня детально расскажу про сердце JMatrixPlatform - статусно-ролевой доступ к данным. Это основа платформы, доступная сразу "из коробки", которая реализует продвинутый RBAC с привязкой прав к статусам объектов. Вы не найдёте в общем доступе внятного и современного описания такой методологии, тем более с примерами реализации "из коробки", а это означает, что сегодня очередной эпизод погружения в Области тьмы ИТ, куда не заглядывают модные фреймворки.

Когда разработчик начинает писать на Next.js с TypeScript, первая реакция часто довольно холодная. Вместо того чтобы двигаться быстрее, он начинает чаще видеть ошибки. Где-то не совпал shape объекта, где-то строка не подходит в более узкий тип, где-то TypeScript напоминает, что значение может быть undefined. На этом месте легко сделать неправильный вывод. Кажется, что TS просто добавляет трение и требует больше служебного кода.

Обычно проблема не в TypeScript, а в способе мышления. Если использовать его как набор аннотаций поверх уже написанного кода, пользы действительно немного. Но если смотреть на типы как на систему контрактов между слоями приложения, картина меняется. Особенно в Next.js App Router, где у нас постоянно есть границы server и client, внешний ввод из URL, формы, мутации и разные состояния интерфейса.

В этот момент TypeScript перестаёт быть типизацией ради типизации. Он начинает отвечать на более важный вопрос: какие состояния в проекте вообще допустимы, а какие не должны пройти дальше границы. По такой модели я выстроил один из своих проектов Workbench. Не начинать с мысли давайте везде поставим типы, а начинать с мысли где у нас проходит граница, что в неё входит и что из неё может выйти. После этого многие решения в коде становятся почти очевидными.

Представьте себе: вы закончили большую задачу, написали много строк кода, проверили всё, даже подумали над названием каждой переменной! Но откладываете создание PR на день, два, три…из-за того, что не хочется идти в ревью и получать критику?

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

Просыпаюсь утром, открываю ленту - и сразу два инцидента. Оба про npm. Оба серьёзные. И оба произошли в один день.

Первый - в Axios (да, тот самый, который стоит вообще везде) три часа раздавал RAT-троян. Второй - Anthropic случайно выложила полные исходники Claude Code в публичный npm. Полмиллиона строк с промптами и архитектурой.

Вот и доброе утро)

Ошибки в API часто воспринимаются как второстепенная часть контракта – до тех пор, пока интеграции не начинают ломаться в самых неожиданных местах. В этот момент выясняется, что одного HTTP-кода недостаточно: без ясной структуры и контекста ошибки превращаются в источник неопределённости и лишней работы. В статье разберём, как проектировать ошибки как полноценный элемент API – с понятной семантикой, единым форматом и возможностью для автоматической обработки.

В Symfony есть встроенный компонент Serializer, который покрывает 90% задач. Но его часто обходят стороной, то ли по привычке, то ли из-за того, что документация показывает только тривиальные примеры. А между тем, Serializer — гибкий и вполне годный инструмент, если понимать его архитектуру.

Разберём, как он устроен.

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

Эта статья - о том, что я настраивал, зачем, и почему в 2026 году одного SEO уже недостаточно.

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

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

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

Я прикинул, и понял, что проблем там гораздо больше, чем кажется ..