Comments 15
UFO just landed and posted this here
Не совсем понятно зачем использовать ReactNative(RN), если уже есть приложения написанные на native стеке и вы от них не собираетесь отказываться. Использование большого «зоопарка» в технологиях всегда сопряжено с усложнением кода и его поддержкой.
Про использование специфичных возможностей каждой платформы, я бы с вами согласился, если бы кейсы, которые вы описываете, были бы таковыми. Но для работы с оплатами, GPS и файлами есть уже написанные библиотеки (если не хотите заново писать код), которые работают.
Про переход на 64Bit версию Android тоже не совсем верно. Поддержка появилась в версии 0.59 и переход на неё не был сколько-нибудь сложным, в отличии от перехода на версии 0.60+.
В общем я соглашусь с вами в том, что использовать RN, когда уже есть native, не совсем целесообразно. Но не могу согласиться с выводом, что на RN можно писать только простые приложения аля витрина магазина. Можно посмотреть к примеру сюда.
Про использование специфичных возможностей каждой платформы, я бы с вами согласился, если бы кейсы, которые вы описываете, были бы таковыми. Но для работы с оплатами, GPS и файлами есть уже написанные библиотеки (если не хотите заново писать код), которые работают.
Про переход на 64Bit версию Android тоже не совсем верно. Поддержка появилась в версии 0.59 и переход на неё не был сколько-нибудь сложным, в отличии от перехода на версии 0.60+.
В общем я соглашусь с вами в том, что использовать RN, когда уже есть native, не совсем целесообразно. Но не могу согласиться с выводом, что на RN можно писать только простые приложения аля витрина магазина. Можно посмотреть к примеру сюда.
Слежу краем глаза за флаттер чатиком и с выводами статьи в целом согласен. Пока дело касается разработки UI и применения готовых плагинов — вроде проблем особых у людей нет. Как только нужно подправить библиотеку или написать свою, интегрировать с нативным кодом, разобраться с ошибкой в нативной части и подобное — тут у тех кто понадеялся на наличие готовых решений начинаются проблемы.
Спасибо за комментарий!
Абсолютно согласен, что при наличии полностью нативного приложения внедрение кроссплатформенной составляющей добавляет проблем в поддержке.
Да, библиотеки, возможно, есть, но тогда встает вопрос поддержки и кастомизации того, что написано другим разработчиком. А самое главное — скорость обновления библиотек. Если, например, в Google API изменится логика работы с оплатами, а разработчик, который ее поддерживал, не внес изменения, а вы об этом не знаете, так как надеетесь на библиотеку, то можете получить дополнительные проблемы.
У нас была сравнительно старая версия React Native в проекте 0.43, и переход с нее на 0.59 оказался довольно болезненым.
С примерами можно согласиться, но Airbnb в итоге отказался от использования кроссплатформенности, Facebook-приложения, в том числе Instagram, используют свой стэк по сути (React Native все-таки разработка Facebook, было бы странно, если бы они использовали что-то другое). Walmart, по сути, является интернет-магазином.
С остальным спорить не буду: каждый выбирает то, что ему удобнее. Остается вопрос, сколько проблем они готовы решать для того, чтобы использование React Native в их приложениях оправдался. Не могу судить о том, сколько у них уходит усилий на то, чтобы обработать ту или иную особенность платформ. Для меня кейс Airbnb является наиболее показательным.
Абсолютно согласен, что при наличии полностью нативного приложения внедрение кроссплатформенной составляющей добавляет проблем в поддержке.
Да, библиотеки, возможно, есть, но тогда встает вопрос поддержки и кастомизации того, что написано другим разработчиком. А самое главное — скорость обновления библиотек. Если, например, в Google API изменится логика работы с оплатами, а разработчик, который ее поддерживал, не внес изменения, а вы об этом не знаете, так как надеетесь на библиотеку, то можете получить дополнительные проблемы.
У нас была сравнительно старая версия React Native в проекте 0.43, и переход с нее на 0.59 оказался довольно болезненым.
С примерами можно согласиться, но Airbnb в итоге отказался от использования кроссплатформенности, Facebook-приложения, в том числе Instagram, используют свой стэк по сути (React Native все-таки разработка Facebook, было бы странно, если бы они использовали что-то другое). Walmart, по сути, является интернет-магазином.
С остальным спорить не буду: каждый выбирает то, что ему удобнее. Остается вопрос, сколько проблем они готовы решать для того, чтобы использование React Native в их приложениях оправдался. Не могу судить о том, сколько у них уходит усилий на то, чтобы обработать ту или иную особенность платформ. Для меня кейс Airbnb является наиболее показательным.
Для начала, стоит вообще серьёзно засесть за пиво стол и честно глядя друг другу в глаза спросить: а нафига нам эти платформы?! КТО и где будет приносить нам деньги? И насколько приложение вообще будет привлекательно, чтобы за него кто-то вообще платил.
И сразу обнаружится, что 99% приложений вообще не нуждаются ни в каких «кросс-платформенностях». У смузихлёбов это просто бзик, хайп в заднем проходе — «кроссплатформенность». И только потом, профукав время и деньги заказчиков/себя, начинается прозрение.
Забавно, но кроссплатформенность — она не нужна юзерам — она нужна разработчикам! Очень ленивым/жадным разработчикам, которые в 21 веке думают, что можно «экономить на коде». Реальность показывает, что скупой не просто «платит дважды», а вообще вылетает из бизнеса.
«Нэйтив» — это чудовищный «подводный слой» функциональности и поведения, над которым работали годами профессионалы. Таскбар, трэй, меню, уведомления, жесты, тени, шрифты, отточенные контролы… да надо быть глупцом, чтобы думать, что всё это можно прикрыть фúговым листиком жабоскрипта и сверху нафигачить «кроссплатформенных кнопок»! Чудики, ей богу!
И сразу обнаружится, что 99% приложений вообще не нуждаются ни в каких «кросс-платформенностях». У смузихлёбов это просто бзик, хайп в заднем проходе — «кроссплатформенность». И только потом, профукав время и деньги заказчиков/себя, начинается прозрение.
Забавно, но кроссплатформенность — она не нужна юзерам — она нужна разработчикам! Очень ленивым/жадным разработчикам, которые в 21 веке думают, что можно «экономить на коде». Реальность показывает, что скупой не просто «платит дважды», а вообще вылетает из бизнеса.
«Нэйтив» — это чудовищный «подводный слой» функциональности и поведения, над которым работали годами профессионалы. Таскбар, трэй, меню, уведомления, жесты, тени, шрифты, отточенные контролы… да надо быть глупцом, чтобы думать, что всё это можно прикрыть фúговым листиком жабоскрипта и сверху нафигачить «кроссплатформенных кнопок»! Чудики, ей богу!
Справедливости ради, хоть RN я терпеть не могу — он использует нативные UI элементы через мост, а не сам рисует. Тем что вы описали страдает флаттер, дарт в котором компилируется aot в машинный код рисует через skia на канвасе напрямую, используя opengl/metal, как игровые движки.
Я нативщик, но в целом флаттер мне видится лучшей альтернативой чем засилье RN, электронов и подобного.
Я нативщик, но в целом флаттер мне видится лучшей альтернативой чем засилье RN, электронов и подобного.
Этого мало, я же описал ЧТО ИМЕННО в системе (помимо внешнего вида) помогает юзерам:
Любой, кто сидит хотя бы год в своих иОСиках, Вендах и Линупсах, мгновенно просекает, когда «что-то не то». Когда приложение — лишь нашлёпка над очередной «кроссплатформенной муетой», а не родная программа.
По мне, при том обилии девелоперов и уже написанного софта, просто глупо писать очередной «кроссплатформенный редактор» — он будет «наибольшим общим делителем» всех платформ и вот нафиг не нужен! Лучше нативного ты всё равно не напишешь.
Таскбар, трэй, меню, уведомления, жесты, тени, шрифты, отточенные контролы
Любой, кто сидит хотя бы год в своих иОСиках, Вендах и Линупсах, мгновенно просекает, когда «что-то не то». Когда приложение — лишь нашлёпка над очередной «кроссплатформенной муетой», а не родная программа.
По мне, при том обилии девелоперов и уже написанного софта, просто глупо писать очередной «кроссплатформенный редактор» — он будет «наибольшим общим делителем» всех платформ и вот нафиг не нужен! Лучше нативного ты всё равно не напишешь.
Таскбар, трэй, меню, уведомления, жесты, тени, шрифты, отточенные контролы
В том и дело что RN тут исползует эти же компоненты, нативные. Другое дело что у него есть другие проблемы. Во первых они их любят настраивать так что перестают походить на натив. Во вторых RN лагает. В третьих — гайдлайнам следовать тоже не любят.
Опять же, если один черт бизнес будет экономить и разрабатывать кроссплатформу — я бы предпочел видеть у себя на мобилке или на десктопе флаттер, чем электрон, кордову, реакт нейтив и другие веб штуки. А бизнес будет экономить, даже зная о минусах кроссплатформы.
Такая реализация приводит и к минусам.
Пришлось недавно начать пользоваться одним приложением на флаттере (под андроид)(вообще это клиент одного вебсайта):
— навигация совершенно нелогичная (догадаться логически куда системная наэкранная кнопка назад переведет или даже встроенная кнопка назад у приложения — невозможно)
— логин — если через штатные логин-пароль то нет даже попытки имитировать нормальные контролы (в результате не то что автозаполнялка — не работает, даже вставить руками скопированный пароль не выходит).
— авторизация через Facebook — берем открываем вебвью (при том что на устройстве есть приложение Facebook'а и вменяемые приложения — им пользуются).
— пополнение внутреннего счета (там через яндекскассу) — разумеется ТОЖЕ через вебвью а не открытием браузера, и при любой ошибке от яндекс кассы — не прочитать потому что сразу закрывается экран.
Пришлось недавно начать пользоваться одним приложением на флаттере (под андроид)(вообще это клиент одного вебсайта):
— навигация совершенно нелогичная (догадаться логически куда системная наэкранная кнопка назад переведет или даже встроенная кнопка назад у приложения — невозможно)
— логин — если через штатные логин-пароль то нет даже попытки имитировать нормальные контролы (в результате не то что автозаполнялка — не работает, даже вставить руками скопированный пароль не выходит).
— авторизация через Facebook — берем открываем вебвью (при том что на устройстве есть приложение Facebook'а и вменяемые приложения — им пользуются).
— пополнение внутреннего счета (там через яндекскассу) — разумеется ТОЖЕ через вебвью а не открытием браузера, и при любой ошибке от яндекс кассы — не прочитать потому что сразу закрывается экран.
Все так, но история ничему не учит. Swing против SWT, QT или wxWidgets. Желание сэкономить будет порождать обертки вроде RN и SWT и рендеры вроде Flutter и QT с одним и тем же результатом — все это оседает в нишах, тортовые продукты делаются на нативном UI.
Почему мы отказались от React Native? Потому что в нем нет хранимых процедур)
Вы не ответили на этот комментарий под предыдущей статьёй, ну да может он просто потерялся. Может ответите тут. Что думаете насчёт этого?
https://twitter.com/SanSYS/status/1299657221085835264
Как я понял, после перехода на хранимки ваша база позволяла писать в неё любые объекты и выгружать всё содержимое, включая хэши паролей и, возможно, персональные данные. Интересно ваше мнение по этому поводу.
Sign up to leave a comment.
Когда имеет смысл писать кроссплатформенные приложения: появление и исчезновение React Native в Lingualeo