Как стать автором
Обновить

React Native: очередная «серебряная пуля» для кросплатформенной разработки?

Время на прочтение7 мин
Количество просмотров22K
Всего голосов 41: ↑34 и ↓7+27
Комментарии34

Комментарии 34

А теперь сравните итоговый размер двух проектов этих и их производительность/ресурсоёмкость.
RN не есть серебряная пуля. Тот же NativeScript чуть интересней смотрится и имеет более низкоуровневое взаимодействие. Помимо есть Xamarin. По поводу XML для андроида — пора уже понимать что это прошлый век и стоит перейти на Kotlin + Anko (отличнейшая штука) Кроме того DSL есть и для IOS (либу не помню сейчас)
Kotlin + Anko хорош, но тоже не серебряная пуля. Пойдет для небольших «гуешных» элементов — кастомные вьюхи для диалогов, лейауты с 1-3 элементами. В андроиде сейчас constraint layout наконец-то релизнулась, и, на мой взгляд, обещает быть лучше, чем тот же strory board в xcode. Поэтому тут я за него всеми руками ))
Да, для мелких диалогов типа «если хотите, поставьте этот крыжик» реально удобно.
К сожалению, Xamarin выдаёт очень жирные бинарники. И если на iOS ещё удаётся добиться нативной производительности приложения, то с андроидом хуже, в частности из-за необходимости взаимодействия двух рантаймов. Не подскажете, актуальны ли подобные проблемы для RN и NativeScript?
Как это не серебряная пуля? Если она позволяет единожды написать общий код, а работает быстро, как нативный?
НЛО прилетело и опубликовало эту надпись здесь
Опять Titanium смешали с PhoneGap. Это совсем разные вещи!
Насчет императивного подхода я не совсем понял. В чем проблема юзать тот же Rx, DataBinding, KVO?
Насчет экономии времени есть кто-то кто уже что-то прям серьезное на этом написал и его можно пощупать? (Кроме команды Facebook)

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

А есть полноценный апп (AppStore, Play Market) с реализацией?) Интересно было бы посмотреть чего можно добиться с помощью RN, чтобы решить погружаться в это или нет)

2гис аптеки

Благодарю!
Airbnb и Discord. Discord вообще очень сложное приложение.
Я уже несколько средних по сложности приложений разработал на React Native. Могу сказать, что плаформа готова для серьезной разработки.
https://facebook.github.io/react-native/showcase.html

А Ionic Framework?
Он действительно на столько плох?

Скажу так: заказчики регулярно спрашивают, сколько будет стоит переписывание с Ionic на натив.
Я люблю реакт и постоянно его использую его в работе. И так уж получилось вступить в RN. И вот что скажу: по началу была эйфория, было действительно круто. Но чем дальше в лес — тем толще партизаны. React Native просто омерзительно сырой. В нём огромное количество багов, устаревшая документация, есть проблемы с апгрейдом на новую версию. Сейчас дошло до того, что чистый init проект под ios не компилится из-за ошибок. Для работы с RN в любом случае нужен iOS-разработчик и человек который варится в этой кухне, потому что многие вещи нигде не задокументированы. Технология очень перспективная, но в будущем.
Частично соглашусь, но только частично. Апгрейд — это попаболь, скрипт либо все файлы переписывает, либо ничего не мигрирует. Роутинг проблемный, документация устаревает очень быстро. Но вот то, что вам нужен iOS разраб… Ну вам надо сплеш сверстать и в стор билд залить, разработчик — это оверкилл.
Для апгрейда они сделали git-based инструмент для нормального мержа, чтобы не переписывать ничего полностью, но что-то у меня он сделал почти ничего существенного. В iOS куча своих проблем, которых нет в Android и часто приходится ковыряться в xcode, я не говорю что нужен крутой спец, но нужен кто-то, кто хоть немного разбирается в iOS-разработке.
(не могу отредактировать коммент, дополню)

Например открытие url, пуш уведомления, сертификаты, линковка (хотя автоматическая наконец начала нормально работать) и прочее — это надо сначала разобраться во всей apple-вской кухне. Особую боль вызывает когда вдруг начинают лететь ios ошибки после апгрейда и ты, не ios-разработчик, понятия не имеешь что с ней делать. Вот тогда приходится тратить время и разбираться.
Мне кажется в принципе, чтобы хорошие вещи деллать на RN нужно быть кроссплатформ-нативным разработчиком (то бишь уметь и в Android и в iOS) + знать JS. Это может быть перспективно в случае, если RN станет стандартом кроссплатформ разработки, чего я пока что не наблюдаю, и как следствие появится огромное коммьюнити, а пока честно говоря мне быстрее будет пару нативных приложений создать, чем одно RN, да и работать оно будет получше я так чувствую )
технологии полтора года, подождите. Насчет не наблюдаю: в прошлом году про RN на мебиусе никто не говорил, на этом — два доклала. Убер сказал, что их uberEats использует RN… Ну, вы поняли.
>> Убер сказал, что их uberEats использует RN
как я понял, использует бизнес — апп, а не тот, который юзает пользователь из магазина.
Автору нужно немного аккуратнее приводить примеры технологий, которые он не знает. В Titanium нету WebView и работает он по тому же самому принципу, что и React Native — управление нативными компонентами из js. React Native — это то, чем должен был стать Titanium, но за 7 лет так и не смог. Его убили маркетологи и эффективные менеджеры.

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

Удивлен, что в епаме стали применять React Native :)
Говорят, что у RN одна очередь событий, и в итоге нельзя использовать async вещи которые предоставляет платформа.
Эм, что? Можете пояснить, пожалуйста?
Простите, но в React Native нет DOM.
Можно сколько угодно минусовать, но от этого ни реальный DOM, ни виртуальный там не появится
https://github.com/acdlite/react-fiber-architecture#reconciliation-versus-rendering

Так и чего? Там написано " Virtual dom is a bit misnomer ". Тем не менее нигде не написано, что принцип работы другой, все равно строится дерево компонентов, а при апдейте сравнивается. Так что это подкоп к терминологии.

Согласен с blackPeanut. DOM подразумевает работу с документами (Document Object Model, все-таки), которых просто не существует в мобильной разработке. Вы не представляете документы, используя объектную модель, Вы используете древовидную структуру для представления компонентов экарн(а|ов).

Более того, VDOM, как таковой, является структурой для представления DOM в памяти и не подразумевает никаких «встроеных» алгоритмов (однако, почти все известные VDOM имплементации поставляются вместе с набором алгоритмов типа обхода дерева, вычисления разницы деревьев и пр).

Прошу не считать это «подкопом» к терминологии, скорее небольшой семантической поправкой статье.
Забавно получается:
«Отличная вещь! Только навигация в приложении будет кривая хоть ты тресни!»
В каждой платформе есть проблемы. Когда проблемы не решаются, от платформы отказываются. Когда решаются — используют. Помните, что продукт, написанный неидеально, но выведенный на рынок, всегда лучше идеального, но остающегося неизвестным никому, кроме создателя.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий