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

Привет, Хабр! Меня зовут Василий Беляев. Я руководитель группы разработки по направлению фронтенда в ИТ-компании «Криптонит». В этой статье хочу поделиться опытом и рассказать об оптимизации библиотек: о том, с какими проблемами мы столкнулись, и как их пошагово решили.

Для начала кратко опишу фронтовый стек у нас в «Криптоните»: мы те ребята, которые не пишут на React. У нас все проекты и библиотеки написаны на Vue + Composition API. Из дополнительных инструментов мы используем следующие:

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

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

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

Обычно мы разрабатываем продукт, проверяем соответствие рынку (Product-Market Fit) и только спустя месяцы или годы решаем: «Пора выходить на глобальный уровень».

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

Как же с этим справиться? Заморозить разработку на неделю и рефакторить каждый компонент?

В последнее время я вижу много решений, основанных на compiler-driven подходе. Обещание заманчивое: добавьте пару строк кода, и приложение «само» станет мультиязычным.

Однако есть существенные недостатки.

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

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

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

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

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

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

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

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

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

В общем расскажу про импортозамещение Dassault Systèmes 3DExperience, далее Enovia, а точнее - той её части, которая на протяжении многих лет востребована многими крупными предприятиями: гибкого движка для построения бизнес-приложений, с возможностями управления жизненным циклом (без привязки к тяжелому САПР).

Это кейс о комплексном подходе: как одновременно думать про backend, DevOps, продукт, UX и бизнес-метрики. О том, как делать продукты, держа в голове всю картину сразу.

Три недели назад у меня была проблема: найти билеты на Бали для 5 человек с гибкими датами и определённой длительностью поездки. Агрегаторы не справлялись — приходилось проверять комбинации вручную.

На сегодняшний день у меня работающий продукт: телеграм-бот, который проверяет 1000+ комбинаций маршрутов в час, находит билеты с экономией до 52% и уведомляет пользователей в нужный момент.

Что между этими точками:
• Эксперимент "весь код пишет AI" (Claude справился на 90%)
• Обход защитных механизмов сайтов и реверс-инжиниринг API
• Построение аналитики с метриками CTR, retention, воронками

Спойлер: билет туда-обратно может быть на 40% дешевле суммы двух билетов в один конец

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

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

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

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

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

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

У меня в ленте бесконечно мелькают размышления о том что все профессии больше не нужны, и только продакты/маркетологи/дизайнеры…etc останутся на коне благодаря вайбкодингу. Так вот, не останутся. Но кони у многих загнутся (Фотографы и копирайтеры, привет!).

По моей версии единственными конкурентными останутся T-shaped специалисты, так называемые принципалы. У которых есть хорошая база академического образования в визуальном дизайне, чтобы делать сочную картинку, есть понимание психологии пользователя, запросов рынка и методологий исследований. Которые знают как собрать минимально необходимую дизайн-систему с нуля под каждый определенный продукт, знают как собрать это всё в каком-нибудь Flutter/FlutterFlow, правильно заанимировать, как проработать воркфлоу и все корнер-кейсы, могут упаковать продукт в эффектную айдентику, создав бренд с нуля. При этом ещё и знают где и как продвигать продукт, ну а архитектуру и базы данных со всеми подключенными ручками уже могут делегировать нейросетям. 

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

Давайте честно: если ваш пет-проект или стартап сегодня встречает юзера формой Email + Пароль + Повторите пароль, вы теряете конверсию. Никто не хочет запоминать очередной набор символов для "очередного сервиса". Все хотят одну кнопку: "Войти как...".

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

В 2026 году асинхронный Python уже никого не удивляет. Мы привыкли к автоскейлингу в облаках, но что делать, если ваш бюджет на инфраструктуру равен нулю, а в распоряжении есть только «печка» из 2012 года? Рассказываю про личный опыт выжимания максимума из FastAPI на AMD FX-8320: от тюнинга ядра Linux и PostgreSQL до миграции на Ed25519 и использования Rust-сервера Granian.

Я совсем не опытный фронтендер, но вайбкодинг уважаю и люблю. Отдельная боль - это создание стабильных и хороших UI для своих проектов. И вот представь: используешь Claude Code в разработке своего очередного стартапа-единорога и пытаешься объяснить агенту что нужно поправить: "сделай кнопку темнее и ту фигуру закругленней". Какую? «Ну ту, в сайдбаре». Так их там три. «Вторую сверху, с иконкой». Агент правит первую и как итог - ты возмущаясь, пишешь подробное описание с координатами, классами, соседними элементами и всё равно 50 на 50, что он поймёт. Если знакома эта боль, то есть интересная штука под названием Agentation.

Реноме у него довольно рекламное: за пару месяцев проект набрал 120 000+ загрузок на npm и наделал много шума, став частью воркфлоу многих разработчиков, которые активно vibe-кодят с AI. В этой статье разберем: что это за штука, как устроена изнутри, зачем нужна версия 2.0 с MCP, как завести и пользоваться самому и стоит ли вообще тратить время. Спойлер - если ты React-разработчик и работаешь с AI-агентами, то да, попробовать стоит.

В блоге Beeline Cloud мы временами обращаемся к ретротематике: писали про необычные RFC конца 80-х и 90-х годов, про возрождение текстовых игр. Сегодня заметен новый виток интереса к сайтам «как в ранние 90-е». Рассказываем, почему такая популярность — не просто дань ностальгии, и предлагаем подборку англоязычных технических блогов в формате «ничего лишнего, только текст»: от шпаргалок DevOps-специалиста до инструментария для моддеров WarCraft.

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

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

Мы будем делать схематичную анимацию фейерверков и конфетти по нажатию на кнопку при помощи JS. Изученные принципы универсальны для любого ЯП. Нам понадобится немного знаний ООП, тригонометрии, физики и совсем чуть-чуть геометрии. Вот что получится в итоге:

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

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

Показываем, как реализовать технические гарантии безопасности сделок с помощью MultiSig-кошельков, Node.js, smart-контрактов, TronWeb v5. Разбираем код и логику проектирования P2P-платформы, которая не может украсть деньги пользователя (даже если захочет) 👇

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

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

SQL-инъекцию мы лечили 20 лет и вылечили. Prompt injection — фундаментально нерешаема. Это не я придумал. OWASP ставит её на первое место второй год подряд. Найдена в 73% продакшн AI-систем при аудитах.

Вы не за статистикой сюда пришли. Вы пришли за мясом. Ниже — 10 кейсов, которые не попали в типичный пересказ про Chevrolet за доллар. Тут пострашнее.

Когда мы говорим про скринридеры, почти все сначала думают так: «Ну он просто читает HTML со страницы».

Это не так.

Скринридер не видит экран, не читает HTML напрямую, и не “ходит” по странице, как человек с мышкой.

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

Многогранный мониторинг Angie - продолжение истории

 Мы привыкли, что веб-сервер - это чёрный ящик, который просто гонит трафик. Стандартные метрики Angie представлены широким спектром. Но что, если нам надо еще больше? Что если, прямо на уровне сервера, без изменения кода приложения, можно в реальном времени видеть, что именно клиенты добавляют в корзину, строить гистограммы времени ответа бэкендов, или подсчитать буквально что угодно и делать это с производительностью атомарных операций в памяти? Сегодня разбираем мощнейший модуль metric в Angie.

Доступность интерфейсов в web3 и финтех-проектах по-прежнему редко рассматривается как обязательная часть архитектуры. Чаще всего внимание уделяется визуальной составляющей и функциональности, тогда как сценарии использования без мыши или без экрана остаются вне фокуса. В этом разборе я анализирую доступность Moni с точки зрения незрячего пользователя (сам являюсь им) и параллельно даю конкретные технические рекомендации, которые могут улучшить удобство использования интерфейса в целом.