React Native *

Итак, 5 ноября команда JFrog опубликовала предупреждение об уязвимости CVE-2025-11953 в инструментах командной строки проекта React Native Community CLI. React Native — это платформа которую используют тысячи разработчиков для создания мобильных приложений, которые мы видим в App Store или Google Play. А React Native Community CLI через командную строку предоставляет инструменты для разработки и сборки этих приложений, куда как раз и входил злополучный пакет.

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

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

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

Отпуск, целых две недели, без программирования.
К вечеру первого дня уже не знал чем себя занять. Работать мне запретили.. гады.
Как ещё может отдыхать программист? Делать новый pet-project.

Надеюсь на картинке не я...

Команда JavaScript for Devs подготовила перевод статьи о том, почему веб-команды застревают на орбите фреймворков и забывают о возможностях самой платформы. Автор убеждён: браузеры развиваются быстрее, чем экосистемы вокруг них, а зависимость от React и других инструментов тормозит инновации. Пора снова смотреть на веб как на платформу, а не как на “внутренность” фреймворка.

Лето уже давно позади, зима на носу, а значит — самое время начинать подготовку к следующему лету. Для многих это означает одно: попытку выбраться из состояния «тюленя» хотя бы в состояние «тюленя, который слегка похудел».

Чтобы совместить полезное с полезным, заодно соберём небольшое приложение — простой трекер веса и тренировок — и посмотрим, как на практике работает мультиплатформенная разработка на React с Expo. Спойлер: почти то же самое, что и обычная разработка на React — и, похоже, именно она окончательно забивает гвоздь в гроб Dart/Flutter и прочих попыток конкурентов сделать вид, что React — это страшный сон, который можно забыть.

Команда JavaScript for Devs подготовила перевод статьи Пола Кинлана о том, почему новые веб-фреймворки сегодня оказываются «мёртвыми при рождении». Автор утверждает: сочетание сетевых эффектов, экосистемы React и обучения LLM формирует замкнутый цикл, в котором альтернативы просто не успевают набрать критическую массу.

Ну как, вы уже обновили свои приложения для поддержки новых требований Google? Если нет, то эта статья будет вам особенно полезна =) Напомню, что с 1 ноября 2025 года приложения, таргетирующиеся Android 15 и выше, должны поддерживать 16-килобайтные страницы памяти.

Как вы помните по предыдущим статьям, я работаю в МойОфис в команде разработки мобильной версии высоконагруженного корпоративного мессенджера Squadus (бэкенд на Node.js, NestJS и Meteor, а веб-интерфейс на React). Мы уже успешно перестроились на новые стандарты Google, и поэтому могу компетентно рассказать, что именно требуется, как адаптировать под это React Native-приложение и что делать, если используемая библиотека ещё не успела обновиться.

Десять лет в бюджетных организациях из них три года работы с ГОЗ показали: сложность не в законах, а в инструментах. Собрал консалтинговую платформу с нуля на React 18 + TypeScript + Vite. Полный CI/CD через GitHub Actions, мониторинг на Sentry, Lighthouse > 90. Делюсь стеком, архитектурой и выводами — как в одиночку запустить production-ready продукт в сложной B2G-нише.

Привет, Хабр! На связи снова Саша Мищенко, тимлид платформенной команды в Профи.ру. И сегодня я хочу поделиться нашей поучительной историей переезда с нативного кода на React Native.

Если кратко, то было интересно и иногда даже страшно...

Привет, Хабр! Меня зовут Георгий, и я тимлид команды платформы в компании Купер. Мы специализируемся на разработке IT-приложений для маркетинга и бизнеса, включая кроссплатформенные мобильные решения на базе React Native. В этой статье я хочу поделиться опытом работы с пуш-уведомлениями. Расскажу, с чего мы начинали, какие проблемы встретили и к чему пришли на текущий момент. Все примеры возьму из свежего проекта, исходники которого доступны на GitHub — ссылку оставлю в конце.

Привет, на связи снова я – React-разработчик Дмитрий. Сегодня отвлечемся от теории и разберем конкретный случай и какое решение для него использовалось.

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

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

Собственно, выглядит компонент загрузки файла вот так:

Команда JavaScript for Devs подготовила перевод кейса Shopify о миграции их крупнейших приложений на новую архитектуру React Native. Результат впечатляет: еженедельные релизы не остановились, стабильность сохранилась, а производительность выросла.

Команда JavaScript for Devs подготовила перевод статьи о том, как доминирование React сдерживает развитие фронтенда. Автор утверждает: выбор React «по умолчанию» тормозит инновации, мешает развитию альтернативных фреймворков и превращает всю экосистему в монокультуру.

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

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

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

Поэтому компании все чаще обращаются за кастомными решениями. Но у самих разработчиков могут возникнуть вопросы: 

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

Недавно нам нужно было добавить чат в админку одного из проектов. Забавно, но решения вроде Jivo или LiveChat мы даже не рассматривали. Так были уверены, что сможем без проблем собрать кастомный чат прямо внутри Admiral.

Эксперимент завершился удачно и теперь мы хотим поделиться его результатами. В этой статье мы предлагаем вам готовый туториал по интеграции сложной функциональности на примере real-time чата.

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

Если хотите перестать выглядеть полными профанами и дать юзерам что-то, что не падает при первом же обрыве связи — welcome to local-first apps. Здесь всё про то, чтобы сделать локальную базу, а синхронизация — это такая себе приятная бонусная функция, а не священный грааль.

Если ты в 2025 году ты всё ещё руками собираешь авторизацию на Laravel для своей админки — у меня для тебя плохие новости. Ты либо получаешь удовольствие от страданий, либо просто не знаешь про Admiral. А хорошие новости заключается в том, что это open source фреймворк, который не позволяет не сойти с ума копипаста и рутинной хрени. Вместо этого он делает всё за тебя (что? да!). Ты просто поставишь, настроишь пару штук — и вуаля: авторизация, фронт, работающий бекенд.

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

Всем привет! Меня зовут Дмитрий, и я руководитель фронтенд-разработки в компании Интелси.

Сегодня хочу рассказать о принципе единственной ответственности (Single Responsibility Principle) — первом из пяти принципов SOLID, сформулированных Робертом Мартином в его книге "Agile Software Development: Principles, Patterns, and Practices". Суть этого принципа звучит так: «Класс должен иметь только одну причину для изменения» (A class should have only one reason to change).

Как мы в Купере переписали CodePush для React Native. Быстрее, легче, удобнее

Всем привет! Меня зовут Евгений Прокопьев, я разработчик на React Native с 9-летним стажем. В этой статье расскажу, как мы в Купере написали собственный CodePush, который совсем не похож на продукт Microsoft.

React Native не справился. Flutter — как глоток свежего воздуха.

Рассказываем, как наша команда переписала большое приложение (60+ экранов, оффлайн режим, карта, камера) на Flutter, с чем пришлось повозиться и почему теперь не жалеем.