ReactJS *

Создание фронтенда для Web3-приложений - это не только дизайн, кнопки и React. Это мост между пользователем и блокчейном. И ты, как фронтенд-разработчик - тот, кто этот мост может построить...

Представьте дизайн-агентство, которое создает не просто красивые макеты, а целые технологические экосистемы. Один раз вложившись в разработку уникальных компонентов и фирменного стиля, дизайнеры получают возможность генерировать профессиональные сайты со скоростью 50+ проектов в час.

На практике это сводится к простому циклу: вы отправляете промпт в ChatGPT, получаете в ответ конфигурационный файл, загружаете его в приложение и одной командой сборки создаёте готовые, стилизованные страницы. Всё это уже настроено в стартовом шаблоне, включая авторизацию и многоязычный AI-чат.

Или используйте полную автоматизацию так же как в v0, но с прицелом под крупные корпоративные интеграции.

В статье рассматривается библиотека @qtpy/state-management-observable и её React-обёртка @qtpy/state-management-react, объединяющая реактивность, строгую типизацию и удобный API. Если вы ищете альтернативу Redux, Zustand или Valtio с поддержкой undo/redo, granular-подписок, middleware, асинхронных обновлений и прозрачной работы с массивами через Proxy — createObservableStore может стать хорошим выбором.

Привет, хочу рассказать основу о том как быстро начать пилить продвинутые приложения с 3d моделями.

Для того чтобы лучше понимать контекст последующего материала ожидается что у тебя уже есть знания js, а также react.

React остаётся одним из самых популярных инструментов для фронтенд-разработки. Библиотеки UI-компонентов для React значительно развились, предоставляя разработчикам инструменты для создания современных, эффективных и доступных интерфейсов. В этой статье рассмотрим топовые библиотеки UI-компонентов для React, которые стали популярными в 2025 году, и их ключевые особенности.

На старте проекта обычно встает вопрос о выборе готовой ui-библиотеки для решения шаблонных задач, таких как создание форм, инпутов, кнопок и других компонентов. Количество готовых ui-библиотек для React так стремительно растет, что уже сложно остановить свой выбор на какой либо из них. Зато в таком разнообразии каждый может найти библиотеку, подходящую под его задачи. В этой статье хочется рассказать о фреймворке Steroids, который разработан и поддерживается в нашей компании.

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

Признаемся честно: слово «тестирование» вызывает у многих разработчиков примерно такую же радость, как поход к стоматологу. Большинство морщится и думает: «Опять эти тесты... Лучше бы новую фичу запилил!» И я вас прекрасно понимаю — сам когда-то был в лагере скептиков.

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

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

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

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

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

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

Я починил плохой перевод силами ИИ, написав расширение при помощи ИИ. И я удивлён, что до сих пор такого не сделали.

Этот документ — не просто список, а выжимка боли, шишек и неожиданных открытий, с которыми сталкивается почти каждый фронтендер. Неважно, Vue ты выбрал или React, если твое приложение должно работать в браузере на айфоне пятилетней давности — добро пожаловать в клуб. Здесь будет всё: от странностей с Safari до неожиданных проблем с синтетическими событиями.

Нюансы мобильных браузеров и PWA

iOS Safari не поддерживает Notification API без установки PWA

Проблема: На iOS ты не можешь просто вызвать new Notification(...) — API будет недоступно, пока пользователь не установит сайт как PWA на домашний экран. Так же, в Safari просто не будет доступен класс Notification, браузер его просто не имплиментирует на этапе браузерного окна.

Решение:

- Чтобы проверить можно ли использовать уведомления можно написать следующую проверку:

typeof window !== 'undefined' && 'Notification' in window;

🔗 [MDN — Notification API](https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API)

🔗 [WebKit — Push Notifications](https://webkit.org/blog/12945/meet-web-push-on-ios/)

Пару лет назад единственной настольной игрой, в которую я играл онлайн с друзьями, была «Монополия». Со временем она начала надоедать, и мне захотелось чего‑то нового. Моим открытием стала Machi Koro — экономическая карточная игра, где победа зависит не столько от случайности, сколько от выбранной стратегии, что выгодно отличает её от «Монополии».

На тот момент я не нашёл достойных онлайн‑аналогов Machi Koro, что и подтолкнуло меня к созданию собственной реализации. В этой статье я подробно расскажу о технической стороне проекта: от составления требований до выбора стека технологий.

Устали от бесконечных споров о CSS-методологиях? В этой статье я рассказываю, как объединил БЭМ и Tailwind в мощный гибридный подход, который спас мой проект и нервную систему. Узнайте, как избавиться от мучительного нейминга, решить проблему с отступами и ускорить разработку в два раза.

Никакого догматизма — только практический опыт и реальные примеры использования лучших сторон обоих подходов.

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

Сегодня рассмотрим, как тестировать React‑хуки с помощью @testing-library/react-hooks.

Если вы занимаетесь фронтенд-разработкой, то наверняка работали со Storybook — удобной витриной компонентов, на которой красиво лежат компоненты и примеры их использования. Его любят за интерактивную документацию, возможность визуального контроля и изолированной разработки. Но замечали ли вы, сколько действий приходится делать, чтобы взять компонент из Storybook и вставить его в реальный проект? 

Наверняка вы сталкивались с ситуацией: нашли компонент в Storybook, затем переключились обратно в IDE, скопировали код, вставили, адаптировали, проверили, и повторили снова. Кажется, многовато действий для простой вставки компонента, правда? Постоянные переключения между браузером и IDE, ручной копипаст и отсутствие связи с уже написанным кодом делают этот процесс неудобным и медленным.

Storybook Studio: всё в одном месте...

Тут я расскажу о том, как я впервые с нуля поднимал проект на React, используя связку FSD, TanStack Router, TanStack Query и Effector — и как мы всё это далее подружили подружили или нет 🙂.

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

KafkaRail гудел на фоне.

Паб The Broken Tag, где начиналось утро героев, только просыпался — запах старого эля, крошки лог‑файлов, и бильярдный стол под тусклым светом прожектора. Через узел маршрута /corp/news метропоезд пронёсся, как push‑уведомление на рассвете. День в Киберляндии начинался.

JSON откинул капюшон куртки BitStone Protocol с QR‑патчем на рукаве, кивнул Mr. Parseley и заказал, как обычно, Schema Fresca. Он прошёл к бильярдному столу английского пула, стоявшему под старым плакатом «Keep Calm and Close Tags», где RAMmy спорил с TryCatch о синтаксисе ударов.

Привет! На связи Михаил Шпаков, руководитель разработки в Timeweb Cloud.

Мы создаём облако, в котором удобно запускать и управлять проектами: от простых ВДС до масштабных решений с Kubernetes и десятками интеграций. Мы много думаем о том, как сделать инфраструктуру не только стабильной, но и понятной.

Когда вы работаете в облаке, всё выглядит структурировано: список серверов, IP-адресов, баз данных, кластеров. Но в какой-то момент возникает вопрос: а как всё это связано между собой?

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

Мы в Timeweb Cloud решили это изменить. Инфраструктура — это карта, а не таблица. Её нужно рисовать, а не запоминать.

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

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

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

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

В этот момент мы начинаем задаваться вопросом: «а как нужно писать и организовывать код на самом деле?». В поисках ответа мы читаем статьи, смотрим обучающие видео, доклады и неизбежно натыкаемся на Feature‑Sliced Design (FSD).

В 2022-м мы окончательно задолбались.

Каждый новый проект все по кругу: таблички, формы, фильтры, CRUD. Всё снова, как в Groundhog Day. Копипастить старое было больно, собирать с нуля – ещё хуже. И главное, ощущение абсурда: 2022 год, а мы продолжаем лепить админки вручную, будто на дворе 2015.

Окей, логичный шаг – найти готовое решение.

Мы правда пытались не изобретать велосипед

Первым делом пошли смотреть на CMS. Попробовали Strapi – мощный зверь, но если вам просто нужно бэку выдать пару CRUD’ов, то тянуть за собой целую экосистему с философией и особым образом жизни, это как стрелять из базуки по воробьям.

Дальше, дизайн-системы вроде Salesforce Lightning, Fluent UI и Fusion Design. Компоненты красивые, но по факту это просто UI-кирпичики. Всю бизнес-логику, связи между сущностями, обработку данных всё равно пишешь сам. Хотели сэкономить время, а получили “ты теперь ещё и архитектурой займись”.

React-Admin показался перспективным. Но мы быстро поняли, что он хочет, чтобы ты делал вещи его способом. А мы хотели делать их по-своему. Онбординг тяжёлый, кастомизация сложная, UI на любителя. Как часто бывает: сначала кажется, что ты взял инструмент, а потом он берёт тебя.

Мы поняли: компромиссы – это медленно