ReactJS *

Ранее мы обсуждали самые основы ленивой загрузки и то, почему она вообще важна. А в этой статье мы рассмотрим следующее:
- Как бандлеры анализируют файлы исходного кода, строят деревья зависимостей и генерируют файлы для сборки.
- Как они генерируют файлы JavaScript из исходного кода.
- Как браузеры решают, какие сгенерированные файлы следует загружать, чтобы отобразить ленивую страницу/компонент.
- И как мы можем уменьшить размер и количество загружаемых файлов, правильно настроив структуру файлов и корректно используя статический импорт.

Ленивая загрузка - это принцип, который должен быть известен большинству frontend разработчиков. Однако, этот механизм обманчиво прост, и его освоение является гораздо более комплексной задачей, чем кажется многим. Если уже используете Lazy Loading, у вас все равно могут быть серьезные пробелы в знаниях. Но даже если вы считаете, что знаете про ленивую загрузку абсолютно все, освежить память не будет лишним.

В этой статье мы рассмотрим основы ленивой загрузки: что это такое и почему это важно;
как мы можем использовать ленивую загрузку в наших проектах; а также какие части кода следует загружать лениво.

Наряду с развитием искусственного интеллекта, облачные вычисления названы основополагающей технологией будущего. Наверное, многие слышали, как важны и ценны знания Docker и Kubernetes в современном мире ИТ. Но как подступиться к этим технологиям, если ранее с ними вы не сталкивались?

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

Всем привет! Сегодня я возвращаюсь с новой порцией TypeScript- и React-магии. Вместе разберем полиморфизм в React, а именно — паттерн as. Зачем он нужен, как его прикрутить без багов и почему это сделает ваши компоненты в разы круче. Как обычно — всё под катом.

Привет! Меня зовут Алексей Гомелевский, я frontend-разработчик в Garage Eight. Моя команда занимается улучшением взаимодействия пользователей с продуктом, и недавно мы решили реализовать комментарии. В этой статье расскажу, как выбирали между решением из коробки и собственной разработкой, с какими сложностями столкнулись и как на базе комментариев создали чаты. 

ElevenLabs выложила в открытый доступ проект Eleven Shopping - голосового агента, который превращает процесс выбора товаров и оформления заказа в диалог с ИИ. В основе - стек Next.js + React + TypeScript + Tailwind CSS и подключение к Shopify Storefront API через протокол MCP.

Большинство наших «проектов мечты» умирают не потому, что идея плохая, а потому что мы останавливаемся на уровне «ну вот, фронт есть, бэк вроде тоже, как-нибудь допилю оплаты и выложу». Не допиливаем. Потому что платежи, вебхуки, витрина, SEO, публикации — это уже не «интересный код», а «организационная скука».

Проект как раз про то, чтобы скучное сделать готовым и многоразовым. Мы один раз собираем связку: AI → Django/DRF → ЮKassa → деплой → Web Stories → SEO, а дальше в неё можно подставлять вашу идею — не только Mermaid. Mermaid здесь как манекен: на нём удобно показывать, куда вешать оплату, куда прикручивать экспорт, где пускать трафик.

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

Последняя часть по созданию своего starter-kit.

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

Мне часто доводится вести странные споры с фанатами фреймворков о том, действительно ли <div> «столь же хорош», как и <button>.

Спойлер: нет. И давайте выясним, почему.

Технически это называется «неконсистентный». А по-человечески — боль. Делюсь рабочим, хоть и неидеальным, способом её лечения.

Сколько раз вы меняли поле в API, обновляли тип на бэкенде, а потом вспоминали, что надо поправить ещё и фронтенд? А если есть мобилка? А если схемы валидации тоже дублируются? Я устал от этого и создал шаблон монорепозитория, где TypeScript типы, Zod схемы и константы живут в одном месте и используются везде.

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

Делали ли вы электронную визу в Индию? А, может, в Южную Корею? Или подавались на лотерею Green Card в США? Если да, то вы точно знаете, что для заявки на все эти документы надо прикрепить фотографию определённого размера с целым набором требований...

А такое ну просто необходимо автоматизировать!

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

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

Подробности под катом!

Понедельник, утро, открываешь проект, а авторизация на dev-стенде снова сломана. Или же надо поторопиться с релизом фичи, а бэк еще не готов, и разрабатывать нужно параллельно, и тут без моков не обойтись. Ну или классика: в командировке лежит интернет, и вся работа встала колом. Знакомо?

Что тут можно поделать? Можно подождать, пока починят стенд. Можно залезть в код и что-нибудь там нахардкодить, переполнив его ненужной логикой моков. Можно поставить Postman, Insomnia или другие популярные решения. Но у каждого подхода есть подводные камни: простои и сорванные дедлайны, забытые хардкоды в продакшене, необходимость согласований с инфобезом (особенно если вы работаете в банке) и зависимость от внешних серверов.

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

Да, представимся. Мы — Александр Битько и Дмитрий Панфилов, фронтенд-разработчики в ПСБ. Сегодня расскажем, как превратили мокирование запросов из головной боли в простую и понятную работу.

Продолжаю рассказывать, как я в одного делаю проект - сайт, радио и медиаплатформу для своей музыки. В первой части был фронт и админка, теперь - как я встроил мастеринг аудио через Python сервис, чтобы не бегать по разным сайтам и не возиться с Audacity. Ну и немного про вайбкодинг - куда ж без него.

Да, я его действительно ненавижу. Мне кажется, что команда React'а презирает разработчиков, и я презираю их в ответ. Все их решения направлены на то, чтобы сделать разработку сложнее, медленнее и непредсказуемее. На сегодняшний день они даже умудрились сломать работу JavaScript. Уму непостижимо, почему им это сходит с рук.

Добро пожаловать в ещё одну шпаргалку по React! Но подождите, это не то, что вы подумали — не просто набор случайных примеров кода и банальных объяснений, как в других шпаргалках.

Обещаю, это будет по-настоящему полезно. Мы вместе разберёмся, как работает ReactJS, и как реализованы все его крутые фичи «за кулисами», с помощью интерактивных демо, которые я специально подготовил для вас. Это поможет вам реально понять, как всё устроено, и применять знания на практике.

Миграция с одного фреймворка на другой, например, с Angular на React, — задача, с которой сталкиваются многие команды. Причины могут быть разными: устаревший стек, проблемы с поддержкой, нехватка специалистов на рынке или потребность в более современных инструментах. Так или иначе, в какой-то момент становится очевидно: продолжать развивать проект на старом фреймворке становится дороже и рискованнее, чем перенести его на новый. 

Меня зовут Александр Марченко. Я руководитель команды Frontend-разработки в ОК. В этой статье я расскажу о особенностях и способах миграции Angular приложения на React, а также поделюсь своим опытом.

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

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

React стал символом этой модели. Благодаря Fiber и Concurrent Mode он действительно стал быстрее, но его архитектура по‑прежнему опирается на дерево компонентов и диффинг виртуального DOM. Даже с умным планировщиком React всё ещё «пересчитывает дерево», а не конкретные зависимости данных.

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

В этой статье мы разберём, чем «сигнальная реактивность» отличается от компонентной, и на реальных примерах из Solid.js и Angular Signals посмотрим, где именно проходит граница между «умным диффом» и «fine‑grained реактивностью».

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

Давайте по-честному. Искать работу в IT - это боль. Это не похоже на то, что нам обещали: интеллектуальные задачи, интересные проекты, уважение. Вместо этого мы получили бесконечный скроллинг hh.ru, вымученные сопроводительные письма и звенящую тишину в ответ.

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