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

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

Попробуйте для сравнения Flutter.
Пока не пробовали и не планируем пока что
Наконец то, кто то написал правдивую статью про то как «круто и удобно» писать приложения на react-native. Еще бы упомянуть как они issues закрывают без решения проблемы.

С чего вдруг она правдивая? Люди не осилили доку почитать.

После того как мы завершили наш третий проект на этом языке, мы решили, что нет.

И в какую сторону посматриваете для четвёртого проекта? Есть уже какие-то планы на этот счёт?

Новые проекты начинаем только нативно на данный момент.
Delphi FMX в помощь. Один код везде работает. FMX уже вылизали большей частью.

Если честно, я в замешательстве. С выходом react-native 0.60 добрая половина вашей статьи устарела. Хотя бы в части линка зависимостей. Да и вообще, лично у меня после прочтения статьи возникло ощущение, что вы называете танк бесполезной боевой единицей только потому, что не умеете им управлять. Я с успехом применяю RN, уже не в первом проекте. Есть конечно и ошибки, и трудности… Но это говорит только о моей компетентности, а не об особенностях механизма.

Но это говорит только о моей компетентности, а не об особенностях механизма.

Если механимз при прочих равных требует особой компетенции, разве это не может так же указывать на надостатки его дизайна, неинтуитивность?

Любой механизм требует определенного уровня компетентности. Даже на детских конструкторах пишут возрастные ограничения. Это не означает, что ребенок, не достигший этого возраста, не может попытаться собрать этот конструктор. Лично для меня RN достаточно хорошо документирован и имеет довольно зрелое комьюнити, если документации не хватило. И потом, RN — это не только android и ios приложения. Это универсальный каркас интеграции React в различные платформы, включая десктопные маки, смарт-тв, "виндовсы". Поднимать тему react-native-web, думаю, даже не стоит. Это тема для отдельной статьи, а не объяснения в комментарии.

Любой механизм требует определенного уровня компетентности.

Вопрос в оправданности таких требований и трудозатратах на поиск решений.

Я с RN не знаком, но категоричность все же удивляет. Неужто технология без изъянов, просто все споткнувшиеся просто не смогли найти очевидных решений? Или все же есть подводные грабли, о которых и пишут?
Грабли конечно есть. Всякие странные ошибки связанные с тем, что где-то случайно не убился какой-то файлик и методы их решения в виде «перезапустить то-то и то-то 3-4 раза, а потом ещё это и перезагрузиться». Другое дело, что постепенно логику этих проблем начинаешь понимать и жить с этим становится вполне возможно.

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

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

Пропорции на единицу полезной работы могут быть разными.

не зная сути оперируете аргументами из серии «а вдруг не получится».

Свой интерес подчеркнул — вы изначально слишком категорично (на мой взгляд) заявили практически следующее: «Технология отличная, просто вы все неосиляторы!»
Думаю, подобное и вы слыхали много раз относительно других инструментов, поэтому специфика RN здесь есть едва ли (=
Если проект продолжительный то обновление к новой версии, та еще задача. В свое время я перепрыгивал с 0.54 и далее, но после этого до 0.60 проапгрейдится не получилось (надо сказать что проект домашний, так что не было возможности тратить недели на поиск решения) мое мнение что RN еще не готов.
У меня самый трудный переход был как раз с 0.59 на 0.60. Остальные (57/58) были лёгкие всегда. Даже 0.60-0.61 без проблем был.
С 0.59 на 0.60 перейти в результате не получилось — потратил час на разбор, а потом просто создал новый проект, скопировал директорию «src» и добавил пакеты. Процесс занял несколько минут.
Вот кстати я на том же решении остановился… Хотя там еще с вендорными либами, использующими нативные функции те бы еще пляски пришлось устраивать…

С моей стороны всё видится иначе. Автор, на мой взгляд, не разобрался во всех прелестях и тонкостях механизма. Написал вроде обзорную, вроде статью… Обмолвился полу-словом об обфускации, не разобравшись даже, что обфускация касается только нативных модулей. То, что автор называет обфускацией для js — это обычная минификация. И если ошибка пишет нечитабельными классами — воспроизведи ее без минификации js. Всё! И вот так практически по каждому тезису автора! На что я в двух словах и обратил внимание, сравнив этот подход с танком. Я категоричен лишь в том, что тему нужно либо раскрывать, либо не брать вовсе. А не хоронить надежды тех разработчиков, которые только собираются попробовать RN

разве это не может так же указывать на надостатки его дизайна, неинтуитивность

Вы только что С++.
До React Native я не дошел, сравнить не могу. Остановился на Xamarin.Forms, и слезать пока не хочется — очень хорошо сделано, как по мне.
Наконец-то кто-то написал всю правду!
Пусть я и не полностью согласен, но очень хорошая статья. Позитивный опыт у всех примерно одинаковый, а вот негативный различается. Всегда интересно про него узнать.

Видимо, мне очень повезло, но у меня точно время разработки на двух платформах на React Native равна примерно 120% от одной платформы. То есть, экономия видна открыто.

Что самое интересное, у меня есть достаточно долгий опыт разработки на Android (Java), iOS (Obj-C) и даже на других платформах, где я всегда старался использовать родную среду.

На React Native у меня были долгие тёрки только в самом начале, так как я не сраз понял с чего вообще начать и как это устроено. Про React я на тот момент знал только название, а фо front-end'е у меня был нулевой опыт (я даже слабо представлят что такое npm и зачем он нужен). Сейчас у меня опыт React Native примерно 3-4 месяца.
Но даже потратив время на понимание процесса общее время на приложение значительно меньше разработки двух нативных. Не говоря о том, что некоторые вещи на RN написать проще и быстрее, чем на нативных платформах.
Изначально я пишу и проверяю на Android так как это первая платформа для запуска, но время от времени проверяю на iOS. Обычно надо только изредка подкрутить стили, редко когда что-то ещё.

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

Я могу ошибаться, но чаще всего фреймворк для создания гибридного мобильного приложения выбирают для того, чтобы не содержать две разных команды. И вот с этой задачей эти фреймворки как раз таки отлично справляются. А недостатки и подводные камни, как уже заметили выше, есть везде.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации