Комментарии 12
Сдается, под "разделяемостью" тут подразумевается shared, то, что по-русски называется "общий".
Разделение это просто кривая калька с английского. Shared. Там это слово означает что-то общее. Например, shared kitchen в коммуналке, которую никто не называет "разделяемой".
В отдельных случаях общее можно "разделить", например, судьбу или ответственность. Непонятно, почему кто-то решил "разделять" общий код (что-то, особенно материальное, обычно "делят" и "разделяют" как раз на индивидуальные части), но термин прижился.
Несколько раз пытался подойти к Реакт Нейтиву с разных сторон и... это боль и страдания. И не столько в самой разработке, а больше в инициализации проекта и последующем билде. И это не только мое мнение, как начинающего криворукого вайтишника, разрабы, шарящие в вебовском Реакте, тоже не в восторге от его кроссплатформехнной версии. Единственное, что я понял, что тратить время новичку на РН не стоит, если только в кармане не лежит уже оффер от компании, которая готова взять его на эту позицию. Есть другая, более продуманная кроссплатформенная технология, о которой думаю многие знают. А Реакт Нейтиву можно сказать спасибо за проделанный путь... Но, как говорил Илон Маск "это классная ракета, но пора двигаться дальше".
Другая это флаттер? Если да то там есть один большой ньюанс - dart, который нигде кроме флаттера не используется. Знание РН хотя бы позволит потом без особых усилий пересесть на реакт
На флаттере и десктопные приложения пишут, и вебе он пусть пока ещё корявенько, но применяется. И бэк на дарте уже пытаются делать. Синтаксис Дарта похож на Тайпскрипт. Вообще, платформа развивается и для джаваскриптера Флаттер гораздо ближе по духу, чем тот же Котлин. IMHO
Побеждает разработка кроссплатформенного приложения: это гораздо более быстрый процесс, ведь более 70% кода нужно написать только один раз и можно совместно использовать несколькими платформами.
Ага, пока рандомные баги из-за внедрения пары дополнительных абстракций не съедят выигранное время обратно. Но, наверное, зависит от задачи. Если это веб-сайтик завернутый в RN, без особо нативных фич, может и норм.
Здесь также выгодна разработка кроссплатформенного приложения: требуется гораздо меньше ресурсов для написания кода и меньше разработчиков (достаточно айтишников с опытом работы только с одним фреймворком).
Одним фреймворком (RN) который оборачивает 5 языков: objective-c, ruby (чертовы pods), java, groovy (Gradle, ага. Ну или Котлин), ну и, собственно ts + js (dart для флаттера, c# для xamarin)
Ну и обратно к вашему пункту, пока вы можете найти готовые биндинги для нужного для вас функционала на RN, то меньше. А они не всегда бывают, часто устарели и поддерживаются / используются тремя разработчиками в хобби проектах. А иначе вам нужно сперва написать биндинги, а потом их использование. К багам, к слову, это тоже относится.
Конечно, ни один из типов приложений не может гарантировать вам абсолютное отсутствие багов. В кроссплатформе то, что нормально работает на одной платформе, может не функционировать на другой. Однако в кроссплатформенных приложениях бо́льшая часть кода является разделяемой, что помогает избегать ошибок типизации, которые могут привести к некорректному поведению программы. Кроме того, меньше кода – меньше ошибок.
Опять же, вы можете быть завязаны на 3rd party библиотеку, в которой багу не правят годами, и остаетесь перед выбором -- форкать, переделывать, писать самому, в итоге появляется нужда в своем человеке, который может писать нативные части, в общем... Проходили.
Кросс-платформенные приложения хорошо работают если вы делаете веб-страницу, но в виде приложения по какой-то причине (не знаю, решили сделать mobile-first). Но тогда у меня всегда вопрос: а вам точно нужно нативное приложение или не мучать пользователя и сайта с хорошей адаптивной версткой хватит?
Как только начинаются совсем нативные фишки, по крайней мере у RN, начинаются значительные проблемы с необходимостью сперва делать нативную часть, а потом пробросывать её.
Flutter!
PokemonGo это кроссплатформа на юнити. Еще и достаточно отвратная... Как оно оказалось в одном предложение с правильным управлением нагрузки вызывает недоумение.
Можно подвести итоги:
1. Если у вас MVP, либо есть определенная сумма денег - используйте кроссплатформу, а именно Flutter (либо KMM года через 2-3);
2. Если серьезное приложение, то только натив.
Кроссплатформа не всегда (почти никогда) закрывает все потребности разработки. Есть моменты, когда придется писать нативно (даже в кроссплатформе). Не говоря уже о UI
React Native vs нативные языки программирования: что выбрать бизнесу?