ECMAScript proposal: iterator helpers

Очередной пост в блоге Dr. Axel Rauschmayer. На тот раз про новый пропозал - хелперы для работы с итераторами.

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

А затем автор переходит к новому API.

take(n) знаком всем, кто погружался в ФП - метод сгенерирует новый итератор, который отдаст только N элементов от исходного итератора. Что-то типа slice, но с учетом основного смысла итераторов

Из стандартных методов массива были перенесены: filter, map, forEach, reduce, flatMap, some, every, find

Также добавлены методы from и toArray, что позволяет прыгать между представления iterator = array = iterator.

Если вы работаете с генераторами или итераторами - рекомендую прочесть подробно.

https://2ality.com/2022/12/iterator-helpers.html

#link #development #javascript #iterators #axelRauschmayer

Cypress V12 Is A Big Deal | Better world by better software

Вышел 12 релиз Cypress. В нем применили CQS и разделили команды на 2 вида - query и command. Query только лишь запрашивают данные, command - что-то делает.

Это позволяет Cypress в случае падения асерта делать ретрай начиная от последней команды. Собственно статья подробно рассказывает, как работают подобные ретраи.

https://glebbahmutov.com/blog/cypress-v12/

#development #cypress #release

Еще один тул для автоматических рефакторингов. Выглядит воодушевляюще

codeque.co

Крутой тул, давно искал что-то такое. Регексп ищет по символам, а эта штука учитывает контекст из AST. Еще и eslint плагин есть.

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

Кстати, для автоматизированного рефакторинга по AST посмотрите на putout.

Codux | Visual IDE for React

Визуальная IDE для React.

IDE позволяет накидывать UI в GUI, ну типа как в Figma, и при этом на выход даёт React code.

Выглядит интересно

https://www.codux.com/

#link #development #react #ide

Дайджест за 19 декабря - 23 декабря

GitHub - tjkandala/baahu: 🐘 (fast) state machine-based UI framework
UI Framework основанный на стейт машинах. Про то, что UI хорошо проектируется через стейт машины не говорил только ленивый. Но готовых инструментов не так много. baahu исправляет это, предоставляя API, в котором state machine и компонент очень тесно переплетены.

Выглядит интересно

Announcing SvelteKit 1.0
Вышел SevelteKit 1.0. Я из новости не до конца понял, что там нового вышло, но то, что они зарелизили первую стабильную версию - уже достойно внимания.

Весь блог-пост посвящен краткому знакомству со SvelteKit - что это такое, для кого, для чего, какие основные фичи есть, ссылка на гайд по миграции из бетки в 1.0.0

ECMAScript proposal: iterator helpers
Очередной пост в блоге Dr. Axel Rauschmayer. На тот раз про новый пропозал - хелперы для работы с итераторами.

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

Cypress V12 Is A Big Deal | Better world by better software
Вышел 12 релиз Cypress. В нем применили CQS и разделили команды на 2 вида - query и command. Query только лишь запрашивают данные, command - что-то делает.

Это позволяет Cypress в случае падения асерта делать ретрай начиная от последней команды. Собственно статья подробно рассказывает, как работают подобные ретраи.

Codux | Visual IDE for React
Визуальная IDE для React.

IDE позволяет накидывать UI в GUI, ну типа как в Figma, и при этом на выход даёт React code.

Репост от artalog про codequo - тул для автоматических рефакторингов
——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Tao of Node - Design, Architecture & Best Practices | Alex Kondov - Software Engineer

Тао of Node - opinionated список бест практиксов для разработы сервисов на node.js.

Большинство практик действительно несут объективную пользу. Остальные являются скорее выбором автора среди альтернатив (поэтому список и opinionated).

Некоторые практики описаны достаточно подробно (с примерами кода), некоторые слишком утрировано. В целом получается скорее обзор на практики.

Практики разделены на 4 группы.

Общие. Например, валидируйте запросы, разделяйте приложение на слои, обрабатывайте ошибки. Они практически все хороши и являются бест практисами в разработке в целом, даже не привязываясь к nodejs)

Далее идут инструменты. Тут советы уже весьма opinionated, но в целом все равно хороши

Затем идет блок про тестирование, который, достаточно короткий, но на мой взгляд, содержит очень правильные рекомендации по тестированию nodejs - вкладываться в test coverage, тестировать интеграционными тестами, бизнес-логику покрывать юнит-тестами.

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

Могу рекомендовать к прочтению тем, кто окунается в nodejs разработку. Опытные разрабы также могут просмотреть список, но большую часть они скорее всего уже знают

https://alexkondov.com/tao-of-node/

#development #nodejs #bestPractices #recommended

React Bricks: React CMS with Visual editing for Next.js, Gatsby, Remix

React Bricks - CMS для Next.js, Gatsby, Remix.

Какую проблему решает React Bricks? Допустим, у вас есть создатели контента, которые не являются разработчиками. Они делают, например, лендинги или статьи в блог. Сейчас вам нужно решать, какой удобный инструмент им дать и как с ним интегрироваться. Вы, скорее всего, увеличите технологический стек, возможно завендорлочитесь на каокй-то инструмент, и не будете иметь достаточно контроля над ним.

React Bricks предоставляет подключаемое в Next.js, Gatsby, Remix, решение, которое позволяет описывать такой контент (статьи, лендинги) неразработчикам. Это готовая CMS, в которой уже есть базовые блоки для контента (кнопки, ссылки, тексты, картинки). Но также вы, как разработчик, можете добавлять туда кастомные блоки, реализовав их React.

В итоге вы получаете CMS, которую полностью контролируете и можете легко расширять на текущем технологическом стеке.

https://reactbricks.com/

#development #react #CMS

Avoid These Common Pitfalls Of React useState

Статья про самые распространенные проблемы при использовании useState в react. В статье каждой проблеме приводится подробное описание в структуре:
- Пример кода
- Почему это проблема
- Как исправить

Сами проблемы:
- Лишнее или избыточное состояние (Redundant State)
- Дублирующее состояние (Duplicate State)
- Обновление состояния через useEffect (Updating State Via useEffect)
- Подписка на изменения состояния через useEffect (Listening To State Changes Via useEffect)
- Конфликтующие состояния (Contradicting State)
- Состояние с глубокой вложенностью (Deeply Nested State)

https://profy.dev/article/react-usestate-pitfalls

#development #react #reactHooks

Bun v0.3.0

Вышел Bun 0.3.0.

Пока что Bun достаточно быстро развивается и приносит новые интересные фичи.

В релизе 0.3.0 было уделено много внимания перформансу и потреблению памяти. Теперь Bun под нагрузкой кушает в разы меньше памяти (30МБ против 146МБ в 0.2.2). Также, по их собственным бенчмаркам, аналогичный код в Node.js и Deno кушает 71 и 91 МБ соответственно. Предлагаю и дальше относится к бенчмаркам Bun как к маркетинговой истории, но отмечаю, что работу по уменьшению потребления памяти они все же проделали.

Также в релизе:
- улучшено форматирование console.log
- енкодирование текста ускорено в 3 раза
- добавлены еще фичи для совместимости с node.js
- Bun автоматически устанавливает пакет из npm при вызове import. Пакеты устанавливаются в глобальный кеш, пост инсталл скрипты не запускаются
- Появился FileSystemRouter. Т.е. теперь можно описывать роутинг к хендлерам на уровне путей в файловой системы. Как, например, в next.js. Собственно там и есть такой параметр style: "nextjs"
- Также появилась возможность считывать ввод консоли через async итератор. Выглядит это весьма интересно

for await (const line of console) {
  console.log("Received:", line);
}

https://bun.sh/blog/bun-v0.3.0

#development #bun

A Gentler, Better Way to Change Minds

Как изменить мнение человека по какому-то вопросу? Часто случается, что люди расходятся во мнениях и они пытаются изменить мнение опонента по вопросу. Однако тактика переубеждения в споре работает далеко не всегда - как правило все остаются на своём.

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

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

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

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

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

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

Как же все таки подходить к коммуникациям когда мнения расходятся?

1. Не разделяйтесь на "мы" и "они". Это провоцирует разделение, в том числе психологическое. Будьте в одном круге коммуникации чтобы слышать мнения друг друга.
2. Не принимайте возражения персонально. Помните, что возражения к вашему мнения - это не атака лично на вас.
3. Слушайте. Исследования говорят, что слушание более эффективно чем разговор в плане изменения мнения другого человека. Внимательное слушание с задаванием хороших вопросов работает намного эффективнее, чем разговор. Спор же, согласно тем же исследованиям, особо не влияет на мнение других людей по вопросу.

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

https://www.theatlantic.com/family/archive/2022/04/arguing-with-someone-different-values/629495/

#managment #changeManagment #softSkills

Всех с наступающим новым годом 🥳 (а кого то уже с наступившим)

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

Благодаря вашему фидбеку, в канале появились еженедельные дайджесты (иногда у мнея даже появляется мысль, что многим только дайджесты и нужны 😬 но коментарии под постами говорят, что есть достаточно людей, которые читают в риалтайме и даже оставляют комментарии).

Также, благодаря фидбеку, я планирую немного подразобрать все старые ссылки и подкорректировать там тэги и, возможно, сформировать какой-то список must have read по определенным темам.

Планы на новогодние выходные:
- Я постараюсь найти контент для канала. Возможно пойдет аудио или видео контент т.к. теперь будет время посмотреть что-нибудь из беклога докладов\подкастов
- Следующий дайджест выйдет 9го января и будет содержать все новости начиная с последней декабрьской недели
- Возможно выйдет несколько материалов от меня

Спасибо вам еще раз ❤️ и еще раз с новым годом 🎉

Guiding principle: Speed generates quality

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

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

Как это работает?
Статья начинается с притчи про мастера гончарного дела. Он разделил учеников на 2 группы: первая группа оценивается по тому, сколько вещей они произведут, а вторая группа оценивается по качеству того, что они произведут. Когда пришло время оценить работу групп, то оказалась, что первая группа сделала 50 первоклассных горшков, 40 хороших горшков и так далее. Вторая же группа сделала всего 1 первоклассный горшок.

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

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

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

При этом надо отличать "делать быстро всякую ерунду" и "делать быстро маленькими шагами". В фразе "Speed generates quality" cкорость - это прежде всего про маленькие итерации и процесс обучения. А процесс обучения ведет к качеству.

https://jchyip.medium.com/guiding-principle-speed-generates-quality-f0672db3e4bc

#managment #agile #feedbackLoop #quality #recommended

⚛️ Applying Design Patterns in React: Strategy Pattern

Статья про применение шаблонов проектирования в React.

Это хорошая обучающая статья, описывающая, как проблема Shotgun Surgery (хирургия дробовиком?) решается с помощью паттерна Стратегия.

Что такое Shothub Surgery - это когда 1 фича "расплескивается" на кучу файлов, и когда приходит время что-то в ней изменить, необходимо сделать изменения в куче файлов разом.

В статье есть конкретный пример - это карточка цены на продукт (base, pro, premium уровни), в которой ценообразование располагается везде разом. Это нарушает принипы S и O из SOLID.

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

Если нам нужна будет новая стратегия ценообразования и тарифов, нам не потребуется править никакой существующий код, достаточно будет создать новую имплементацию Стратегии.

В общем, хорошая обучающая статья про хорошие практики.

https://dev.to/itshugo/applying-design-patterns-in-react-strategy-pattern-enn

#development #react #designPatterns #recommended

GlitchTip

GlitchTip - опенсорсный аналог Sentry. Вплоть до совметимости с API sentry, что позволяет легко перейти с sentry на glitchtip.
В чем основная фича и Sentry и GlitchTip: они предоставляют из себя системы трекинга ошибок приложения. Т.е. вы подключаете систему через SDK к приложению, а затем можете отправлять туда ошибки. Система же умеет:
- Показывать конкретную строчку кода в репозитории, которое привело к ошибке, а также отображать полный стак-трейс
- Показывать действия, которые перед этим делал пользователь. Для веб-приложений обычно собирается инфа о сетевых запросах и действиях пользователя. Также можно настроить кастомные "хлебные крошки", например, выводить исполненные redux события
- Показывать, в каком релизе или коммите впервые появилась данная ошибка

Короче, если использовать с умом, то такие системы очень мощные. Хорошо, что появляются опен-сорсные альтернативы.

https://glitchtip.com/

#development #monitoring #glitchtip

GlitchTip вместо Sentry. Как мы бесплатно настроили мониторинг ошибок

В продолжение предыдущей ссылки: статья на хабре, про то как и почему компания, DevOps из компании Constanta решили взять GlitchTip вместо Sentry.
Статья очень короткая и в целом сводится к следующему:
- GlitchTip не хуже Sentry
- GlitchTip потребляет меньше ресурсрв
- GlitchTip проще деплоить и сопровождать

К сожалению подробностей реального использования не рассказывается. А было бы интересно про это почитать (насколько легко исследовать ошибки, какую держит нагрузку и тд и тп)

https://habr.com/ru/company/constanta/blog/706386/

#development #glitchtip #monitoring

Одна платформа, чтобы править всеми

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

Что описано в статье:

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

Достаточно интересно, что как стандарт для общения в ozon используют GraphQL и grpc. И т.к. это является стандартом в компании, то появляется простор для разного рода оптимизаций. Например, в некоторых языах что-то полезно вшито прямо в бинарник.

Также, платформа предоставляет командам удобный API для создания сервисов и БД. Вы хотите запустить новый микросервис? Выбери язык, потыкайся в настройки и платформа сгенерирует тебе кучу базового кода. Нужна постгря? Нажми еще пару кнопок и будет у тебя свой инстанс БД.

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

Еще в статье много внимания уделено своей реализации service mesh.

В общем, очень объемная и достаточно неплохая статья про роль платформенной команды в большой компании. Есть много вариантов, что может делать платформенная команда и как помогать разработке. И вот Ozon поделился своим опытом использования паттерна "Платформенная Команда".

https://habr.com/ru/company/ozontech/blog/708274/

#development #paas #platformTeam #ozon

Дайджест за 2022-12-26 - 2023-01-06

Tao of Node - Design, Architecture & Best Practices | Alex Kondov - Software Engineer
Тао of Node - opinionated список бест практиксов для разработы сервисов на node.js.

Большинство практик действительно несут объективную пользу. Остальные являются скорее выбором автора среди альтернатив (поэтому список и opinionated).

React Bricks: React CMS with Visual editing for Next.js, Gatsby, Remix
React Bricks - CMS для Next.js, Gatsby, Remix.

Какую проблему решает React Bricks? Допустим, у вас есть создатели контента, которые не являются разработчиками. Они делают, например, лендинги или статьи в блог. Сейчас вам нужно решать, какой удобный инструмент им дать и как с ним интегрироваться. Вы, скорее всего, увеличите технологический стек, возможно завендорлочитесь на каокй-то инструмент, и не будете иметь достаточно контроля над ним.

Avoid These Common Pitfalls Of React useState
Статья про самые распространенные проблемы при использовании useState в react. В статье каждой проблеме приводится подробное описание в структуре:
- Пример кода
- Почему это проблема
- Как исправить

Bun v0.3.0
Вышел Bun 0.3.0.

Пока что Bun достаточно быстро развивается и приносит новые интересные фичи.

В обсуждении к посту в канале есть подписчик, который игрался с Bun

A Gentler, Better Way to Change Minds
Как изменить мнение человека по какому-то вопросу? Часто случается, что люди расходятся во мнениях и они пытаются изменить мнение опонента по вопросу. Однако тактика переубеждения в споре работает далеко не всегда - как правило все остаются на своём.

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

Guiding principle: Speed generates quality
Часто мы обсуждаем скорость и качество как противоположное. Типа надо выбрать или качество или скорость, но не оба вместе.

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

⚛️ Applying Design Patterns in React: Strategy Pattern
Статья про применение шаблонов проектирования в React.

Это хорошая обучающая статья, описывающая, как проблема Shotgun Surgery (хирургия дробовиком?) решается с помощью паттерна Стратегия.

В обсуждении есть немного полезных комментариев

GlitchTip
GlitchTip - опенсорсный аналог Sentry. Вплоть до совметимости с API sentry, что позволяет легко перейти с sentry на glitchtip.
В чем основная фича и Sentry и GlitchTip: они предоставляют из себя системы трекинга ошибок приложения. Т.е. вы подключаете систему через SDK к приложению, а затем можете отправлять туда ошибки, где они представлены в удобном для «расследования» виде.

GlitchTip вместо Sentry. Как мы бесплатно настроили мониторинг ошибок

В продолжение предыдущей ссылки: статья на хабре, про то как и почему компания, DevOps из компании Constanta решили взять GlitchTip вместо Sentry.
Статья очень короткая и в целом сводится к следующему:
- GlitchTip не хуже Sentry
- GlitchTip потребляет меньше ресурсрв
- GlitchTip проще деплоить и сопровождать

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


——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Знакомство c Reatom

Статья от автора Reatom про Reatom. Это первая обучающая статья в серии статей про Reatom.

Статья очень короткая, но показывает основы Reatom:
- вокруг чего основная идея (сюрпрайз, атомы и реактивность)
- основное API для создания и изменения атомов

В комментариях засветились свидетели mobx и nin-jin (автор $mol)

Надеемся на продолжение серии статей. Контента в текущей, объективно, мало, чтобы понять что за зверь этот Reatom и стоит ли начать его использовать.

https://habr.com/ru/company/ruvds/blog/708826/

#development #reatom #javascript

Bun v0.4

Продолжаем следить за Bun, у которого вышел релиз 0.4

В этом релизе:
- bunx - аналог npx но в 100 раз быстрее
- флаг --bun позволяющий интерпретировать все вызовы nodejs через shebang (#! /usr/bin/env node) как вызовы Bun. Это делается через создание временного алиаса node = bun
- Добавлены хуки в инструментарий для тестирования

https://bun.sh/blog/bun-v0.4.0

#development #bun

React Native is not the future

Статья от команды разработки приложения Standard Notes про их борьбу с мультиплатформенностью с помощью React Native. Standard Notes - это приложение для ведения заметок. Достаточно хорошее даже.

У них изначально был небольшая команда разработки и три платформы - веб, который контейнизировался в электрон для публикации десктоп приложения, android и ios. В начале разработки, в 2016 году, приложения дла мобилок писали нативные. Но тут встала проблема поддержки трех платформ - сложно поддерживать паритет по фичам (это когда на всех платформах есть одинаковый набор функциональности) и работоспособности, когда у вас 3 разные кодовые базы. В 2017 году они переехали на React Native и это позволило иметь 2 кодовые базы весто трех. Изначально их все устраивало, но дальнейшая практика показала, что достичь паритета по фичам для веба и мобилки оказалось сложно.

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

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

Моё небольшое имхо, если хочется иметь приложение на нескольких платформах то либо:
- Смириться с тем что это будет дорого
- Отказаться от паритета функциональности
- Использовать кроссплатформенные технологии

https://blog.standardnotes.com/40921/react-native-is-not-the-future

#development #reactNative