Да, я его действительно ненавижу. Мне кажется, что команда React'а презирает разработчиков, и я презираю их в ответ. Все их решения направлены на то, чтобы сделать разработку сложнее, медленнее и непредсказуемее. На сегодняшний день они даже умудрились сломать работу JavaScript. Уму непостижимо, почему им это сходит с рук.
Команда JavaScript for Devs подготовила перевод статьи о том, почему Google Переводчик может ломать React и другие современные веб-приложения. Причина в том, что расширение вмешивается в DOM, нарушая работу виртуального DOM и вызывая ошибки вроде removeChild и insertBefore. Автор показывает реальные кейсы, обходные пути и поднимает важный вопрос: имеет ли фреймворк право на полный контроль над DOM?
Добро пожаловать в ещё одну шпаргалку по React! Но подождите, это не то, что вы подумали — не просто набор случайных примеров кода и банальных объяснений, как в других шпаргалках.
Обещаю, это будет по-настоящему полезно. Мы вместе разберёмся, как работает ReactJS, и как реализованы все его крутые фичи «за кулисами», с помощью интерактивных демо, которые я специально подготовил для вас. Это поможет вам реально понять, как всё устроено, и применять знания на практике.
Миграция с одного фреймворка на другой, например, с Angular на React, — задача, с которой сталкиваются многие команды. Причины могут быть разными: устаревший стек, проблемы с поддержкой, нехватка специалистов на рынке или потребность в более современных инструментах. Так или иначе, в какой-то момент становится очевидно: продолжать развивать проект на старом фреймворке становится дороже и рискованнее, чем перенести его на новый.
Меня зовут Александр Марченко. Я руководитель команды Frontend-разработки в ОК. В этой статье я расскажу о особенностях и способах миграции Angular приложения на React, а также поделюсь своим опытом.
Solo developer journey: Как я довел B2B платформу от 8.5/10 до 8.8/10, исправил 13 критических багов, прошел Context7 MCP аудит и успешно задеплоил на production с первыми пользователями.
После первой части (концепция и MVP) и второй части (решение технических проблем), настал момент истины - финальная подготовка к production.
Я разобью весь свой путь на три части. Потому что ещё не дошёл до конца 🙂
По мере разработки буду рассказывать, что получилось, а вы - как всегда - подскажете, где я налажал и как можно сделать лучше.
Команда JavaScript for Devs подготовила перевод статьи, в которой разработчик с восьмилетним опытом работы с React делится неожиданным открытием: Solid.js оказался проще, логичнее и… приятнее в использовании. Меньше перерендеров, ближе к нативному вебу, честное поведение API и настоящие веб-компоненты — кажется, у React появился достойный конкурент.
Фронтенд давно упёрся в потолок оптимизаций. Мы научились грамотно мемоизировать, батчить обновления, выносить тяжёлые вычисления в воркеры, но каждый раз упираемся в одну и ту же проблему: компоненты всё ещё перерисовываются чаще, чем нужно.
React стал символом этой модели. Благодаря Fiber и Concurrent Mode он действительно стал быстрее, но его архитектура по‑прежнему опирается на дерево компонентов и диффинг виртуального DOM. Даже с умным планировщиком React всё ещё «пересчитывает дерево», а не конкретные зависимости данных.
И вот на этом фоне появилась Signals — архитектура, которая предлагает другой путь.
Не оптимизировать старую модель, а избавиться от неё, сделав обновления атомарными и точечными. Без VDOM, ререндеров и догадок.
В этой статье мы разберём, чем «сигнальная реактивность» отличается от компонентной, и на реальных примерах из Solid.js и Angular Signals посмотрим, где именно проходит граница между «умным диффом» и «fine‑grained реактивностью».
Привет, Хабр.
Давайте по-честному. Искать работу в IT - это боль. Это не похоже на то, что нам обещали: интеллектуальные задачи, интересные проекты, уважение. Вместо этого мы получили бесконечный скроллинг hh.ru, вымученные сопроводительные письма и звенящую тишину в ответ.
Как консультант, я вижу всю изнанку этого процесса, и хочу поделиться, почему все так хреново. Это игра с поломанными правилами, где побеждает не самый талантливый, а самый выносливый.
Продолжение статьи о разработке B2B платформы международной торговли
Прошло несколько месяцев с момента публикации первой части, где мы рассказали о концепции и начальном этапе разработки LiqTrade. За это время проект прошел путь от MVP до полноценной production‑ready платформы.
В этой статье я хочу поделиться реальными проблемами, с которыми мы столкнулись, и способами их решения. Никакого идеализированного «как всё прекрасно работает» — только честный разбор косяков, рефакторинга и технического долга.
Дисклеймер: Если вы ищете статью в стиле «10 строк кода, и ваш стартап взлетел» — это не здесь. Здесь будет про то, как мы 3 раза переписывали систему ролей, боролись с circular dependencies и почему наш bundle вырос до 1.2 МБ (спойлер: мы его победили).
Что, если каждый правильный ответ в викторине приносил бы тебе крипту?
Я решил проверить эту идею — и собрал Solana Quiz, децентрализованное приложение, где пользователи проходят ежедневные квизы с вопросами от OpenAI и получают Solana‑токены за правильные ответы.
Да, это реально работает. И да — токен мы тоже создаём сами 😎
Привет, Хабр!
В этой статье речь пойдет об интересной задаче на одном из моих проектов. Он был разработан на React для документооборота сотрудниками. Так уж вышло, что со времен старта проекта основным текстовым WYSIWYG-редактором был небезызвестный Jodit. За долгие годы было написано много кастомных плагинов, например, для работы с упоминаниями сотрудников, и нас устраивала его надежность, хоть его внешний вид был далек от идеала.
И вот однажды заказчик пришел с запросом:
Привет!
Я Таня, фронтенд-разработчик в KTS и студент магистратуры МГТУ им. Баумана. На одном из недавних проектов я работала над интересной фичей — визуальным представлением аудиоданных, a.k.a. звуковой спектрограммой. Казалось бы, штука нехитрая: кто не видел график, прыгающий в такт с музыкой на разных частотах? Он есть в любом секвенсоре, на любом диджейском пульте и даже в динамическом островке последних айфонов.
Однако задача оказалась нетривиальной, поскольку для целей проекта мне нужно было разработать звуковую спектрограмму на React и MobX в особом дизайне. Подробных разборов этой темы и готовых решений я не нашла, поэтому в процессе пришлось самостоятельно разобраться с кучей тонкостей и нюансов. Результат можете посмотреть по ссылке.
А в этой статье я расскажу, как сделать такую же звуковую спектрограмму, а также как изменять ее стиль и другие параметры.
Вы тоже хоть раз ловили себя на мысли: «А может, ну его, этот Node.js — перепишем всё на Rust, и будет летать?»
Поздравляю — вы не одиноки. Я тоже через это прошёл.
В этой статье я разложу по полочкам, когда действительно стоит лезть в Rust, а когда лучше остаться на TypeScript и просто выспаться. Без фанатизма, маркетинга и с примерами из практики.
Всем привет!
Давайте представим, что от бизнеса поступил запрос: "Нам надо, чтобы при входе на сайт сразу же открывалось модальное окно авторизации для сканирования клиентского QR-кода."
Вы запускаете стабильно работающий проект, применяете useEffect с необходимой фичей и пустой зависимостью, а затем - начинаете тестировать.
И вот незадача: модальное окно открывается на миллисекунду и моментально закрывается.
При этом: логи в порядке, стейты меняются корректно, но модальное окно живет своей жизнью и наотрез отказывается работать, как ей предписано.
Я потратил довольно длительное время на поиски этой ошибки. Но затем, удалив setTimeout, который мы использовали для анимирования модального окна, заметил, что все стало работать корректно.
Длительный поиск вариантов анимирования открытия/закрытия модального окна не помог.
Но стоит отметить, что я узнал множество способов и комбинаций его анимирования: как при помощи сторонних зависимостей, так и нативных.
Использование сторонних зависимостей я отбросил сразу. Смириться, что все модальные окна на проекте отныне будут работать без красивых анимаций я не мог, поэтому сразу же приступил к поискам решения данной проблемы.
Совершенно случайно наткнувшись на статью @GragertVD, которая, словом, не подходила под мои критерии поиска - я открыл для себя совершенно новый обработчик события onAnimationEnd и наконец решил указанную выше проблему.
Именно поэтому мне захотелось рассказать о том, как я это сделал.
В этой статье я расскажу:
Пошаговое руководство по симуляции солнца, дождя, снега и грозы в интерактивном трехмерном приложении для прогноза погоды.
Меня всегда интересовала визуализация данных с помощью Three.js / R3F и я подумал, что приложение для прогноза погоды будет отличным началом. Одна из моих любимых открытых библиотек, @react-three/drei, содержит множество прекрасных инструментов, вроде облаков, неба и звезд, которые отлично подходят для визуализации погоды в 3D.
В этом туториале мы научимся преобразовывать данные из API в трехмерный опыт, добавив немного изюминки и веселья в визуализацию погоды.
Пробуем собрать свой минималистичный starter-kit.
Комедия в трех действиях. Туториал из трех частей.
Создадим причудливый конфиг на webpack + собственный роутинг в первой части. Реализуем реактивные хранилища во второй и уменьшим сложность с помощью веб-компонентов в третьей.
«Ну вот, опять эти формы...» — знакомая мысль? Мы постоянно ищем способ сделать их удобными и предсказуемыми, но идеальное решение все никак не находится. В этой серии статей Артем Леванов, Front Lead в WebRise, подробно разберет, с какими сложностями мы сталкиваемся, изучим разные подходы и в итоге придем к элегантному решению: как описывать все формы на сайте, используя всего по одному компоненту для каждого типа полей.
Команда JavaScript for Devs подготовила перевод статьи о SolidJS — реактивной UI-библиотеке, которая выглядит знакомо для React-разработчиков, но работает совсем иначе. Автор разбирает ключевые отличия: почему в Solid нет виртуального DOM, как устроены сигналы, эффекты и прокси-хранилища, а также какие привычки из React ломают реактивность. Если вы давно хотели понять, как SolidJS работает под капотом, эта статья — отличный старт.
Эта книга не столько о коде, сколько о целостном подходе к взаимодействию с продуктологами и подотчетными разработчиками.
Она о том, как должно меняться мышление у middle-разработчика в сторону senior-разработчика. Автор в частности поясняет, что «цель этой книги — дать вам справочник для работы с новыми и legacy-проектами во фронтенде и бэкенде, а также для работы по их развертыванию».
Автор приводит приемы senior-разработчиков, чтобы «работать скорее на уровне системы, чем отдельных строк кода» и находить оптимальные/компромиссные решения.
