Комментарии 34
Извините, но живут же как-то фронтендщики со всеми этими миллионами библиотек. Далеко не все их них зависят от Node.js и нативных модулей. Не пробовали ли полифиллы для Buffer и Stream?
Да, я как раз таки один из таких фронтендщиков. Полифиллы пробовал, не удалось прикрутить их к билд-системе React Native.
Более того, это не повод критиковать React Native в противовес Cordova.
Я не говорю что React Native хуже/лучше Cordova, я лишь рассказал что к моему проекту лучше подошла Cordova
Разве мобильный splash-screen — это не просто показать один компонент, а через пару секунд другой?
Чуть-чуть сложней. Т.к. в этот момент js еще не выполняется, то код отрисовки splash screen должен выполнить java машина. Если я не прав, поправьте.
Нужно было реализовать splash screen и первой мыслью был компонент, который показывается первым. Как показала практика, это сомнительное решение. После этого я нашел такой пакет, который решил эту проблему для меня.
Так ли хорошо микроскоп?
Микроскоп довольно новая технология, которая с первого взгляда кажется серебряной пулей для многих начинающих забивателей гвоздей. И так по порядку, я — закручивальщик шурупов широкого профиля, опыта забивания гвоздей до этого не было. Опробовать микроскоп я решил для забивания гвоздя сотки в березу растущую у нас во дворе. Береза красивая, высокая и зеленая. На этом вступительная часть закончена, перейдем собственно к забиванию.
Подготовка у забиванию гвоздей микроскопом почти такая же как и при закручивании шурупов шуруповертом. Главное правильно покрутить управляющие элементы, крутятся они примерно так же, так что больших проблем нет, хотя есть нюансы. Логика забивания гвоздя заключалась в одном простом действии — нанесении одного сильного удара по гвоздю микроскопом. Пару раз я промахнулся и по гвоздю не попал, пару раз попал, но гвоздь погнулся, в итоге взял камень лежащий рядом и загнал гвоздь в дерево по самую шляпку.
По моему мнению, микроскоп не годится в текущем его состоянии для забивания гвоздей. Основные факторы — плохо лежит в руке и недостаточно тяжелый. По итогу если вам нужно закрутить шуруп используйте шуруповерт, если хотите срубить дерево то тут подойдет топор. С топором дерево удалось повалить за 30 минут.
Спасибо за комментарий. Расскажите, в каком проекте вы бы использовали React Native? Потому как я не увидел его ниши
В вашем случае действительно не было никаких предпосылок использовать React Native. Писали вы только для Android, а большая часть функционала приложения состояла из сложных вычислений.
Вы привели хорошие аргументы. Правильный ли я делаю вывод: выбирая React Native автоматически надо знать Android или iOS чтобы написать что чуть более сложное чем hello-world?
Вам бы помог пакет react-native-crypto, который является клоном вами упомянутого crypto-browserify, но с поддержкой нативного рандома.
Думается, что нет серебрянной пули и не будет. На каждой платформе есть специфика, работая например с Cordova мы тоже писали нативные компоненты и биндинги для каждой платформы. Поэтому в серьезной разработке всегда прйдется владеть базовыми знанями программирования для каждой целевой ОС под которую будет приложение.
RN выбирают чтобы свести к минимуму дублирование кода для нескольких ОС, например сторы.
Главный плюс данной технологии в том, что React Native позволяет многим front-end разработчикам вылезти из своей привычной среды (браузеры, node.js и т.д.) и поучаствовать в разработки мобильных приложений, расширить границы своих знаний и узнать больше о том, как работают мобильные платформы, без необходимости нырять с головой в ObjectiveC/Swift/Java.
Что касательно самого фреймворка, то React Native справляется со своей задачей очень хорошо, если подойти к этому делу с умом, терпением и главное желанием добиться результата.
И отдельно:
Если же такой библиотеки нет или ее производительность вас не устраивает, то необходимо написать native компонент для платформы под которую вы разрабатываете.
Другое дело кордова, там-то всё очень производительно. Или нативные компоненты пишутся намного проще. Или вы не с кордовой сравниваете? А с чем тогда? Есть технология, для которой не выполняется утверждение выше?
И да, на андройде нет сплеш-скринов. На ios их тоже можно только статично вставить в проекте, прогать их нельзя вне зависимости от фреймворка.
Прошу прощения, но статья ни о чем.
Я рассматривал React Native с точки зрения фронтенд программиста, который знает javascript но не знает мобильной разработки.
Сейчас откажусь от RN, пересяду на джаву/свифт и все браузерные либы заработают, да?
Для Джавы и Свифта и так есть библиотеки там бразуреные не нужны. Для RN очень мало собственных библиотек, а старые js библиотеки не работают
И да, на андройде нет сплеш-скринов.
Если их нет, то почему же есть бибилиотека для них? react-native-splash-screen
Прошу прощения, но статья ни о чем.
В статье поднимается вопрос о нише React Native.
Для Джавы и Свифта и так есть библиотеки там бразуреные не нужны. Для RN очень мало собственных библиотек, а старые js библиотеки не работают.
Во-первых, для RN библиотек не так уж мало. Несомненно, меньше чем для кордовы, но тем не менее не мало. Не так уж легко столкнуться с задачей, под которую нет библиотеки. Во-вторых, не работают только некоторые библиотеки. Например, важный moment.js работает без проблем.
Если их нет, то почему же есть бибилиотека для них? react-native-splash-screen
Я понял, вы имеете в виду вторичный сплеш, который показывается уже после загрузки приложения. Я думал, что вы про такой как на ios. Что ж, библиотека таки есть. Да, там нужно прописывать строки в нативный код, но это цена за то, что его можно менять. Не уверен, что в кордове можно взять и встроить нативный элемент в страницу. Что приводит в вопросу о нише: никто не сомневается, что вебвью-приложения выглядят так себе, но использовать js хочется — вот и ниша (это не упомяная о реализации компонентного подхода в реакте, который многим очень нравится). Если же цель сделать попроще, то действительно можно завернуть любой сайт в кордову за вечер.
Я рассматривал React Native с точки зрения фронтенд программиста, который знает javascript но не знает мобильной разработки.
Я как раз недавно был точно в такой же ситуации, и наоборот был поражен тем, насколько легко оказалось сделать приложение, не выглядящее как вебвью, совершенно не вникая в джаву, андроид и вообще ничего кроме js.
Просто оставлю здесь https://github.com/jondot/awesome-react-native
Вот
А по делу — РН не подходит ни для одного мало-мальски серьезного проекта.
И шага толком не сделали, а уже выводы на хабре.
Опыта разработки мобильных приложений нет, но есть 5 лет опыта разработки высоконагруженных проектов на node.js, asp.net mvc.
- Опыт временем не меряют.
- Не бывает "высоконагруженных проектов" на node.js / asp.net, просто масштабируется простой процессора в разных вариациях. Без упоминания слов: "профилирование", "аффинитет" и "большие страницы" — не один проект нельзя назвать высоконагруженным.
- Ну да, конечно "автор ниасилил, реакт сырой, потому что… автор ниасилил". Ок, смысл в целом понятен.
Если нет опыта с нативной мобильной разработкой — нет смысла лениво надеятся что всё поедет с полпинка.
Все серьёзные конторы (SoundCloud, Facebook, AirBnB) давно пишут нативные компоненты под себя, и сами их же и поддерживают. А надеятся на посредственные поделки с гитхаба слишком наивно.
Как это весело наблюдать когда одни матерят Cordova и говорят ехать в сторону React-Native, другие матерят React-Native и призывают менять религию на Cordova… а конструктивности и конкретики в обоих случаях как-то вот совсем не наблюдается.
Изначально стоит определить для каких целей ее использовать и смотреть насколько это удобно.
В то же время на Реакте уже написано довольно много приложений, опенсорсных и не очень. Facebook использует в своем приложении собственный фреймворк весьма успешно. Есть неплохое комьюнити, определенный набор стабильных библиотек. Никто не запрещает вам писать собственные js библиотеки или обертки под нативные компоненты, это не сложно.
Занимаюсь разработкой на React Native около года (на ClojureScript). За это время успел поучаствовать в нескольких проектах, несколько из них вышли в продакшн. Могу с уверенностью сказать что фреймворк уже сейчас пригоден для написания серьезных приложений, достаточно вникнуть в тонкости использования и несколько раз споткнуться об подводные камни :)
Добрый день.
Я уже больше года разрабатываю Open Source React Native проект в качестве 20-процентного рабочего проекта.
Есть ли проблемы с React Native? Да, конечно. Но не совсем те, с которыми столкнулись Вы:
Из-за молодости фреймворка, с обновлениями часто выходят Breaking changes, и обновление версии react-native может занять целый день. В 2016 году обновления выходили раз в 2 недели, и простое поддержание актуальной версии занимало порядка 10-20% времени. К счастью, теперь они перешли на месячный релизный цикл, и этот процесс должен упроститься.
Сырость библиотек – тут вы правы, часто приходилось допиливать чужие библиотеки, фиксить баги и т.д. Такова цена Open Source, но этим он и силён. Из-за пункта 1, сторонние библиотеки часто ломаются с выходом новой версии RN.
Кроссплатформенность – мне удалось поддержать обе платформы на одной кодовой базе, но цена этому – отсутствие "Material Design" фич на андроиде. Да и в общем, на андроиде чаще что-то работало не так, как нужно, и это требует отдельных усилий – поддерживать обе платформы.
- Continuous Integration – довольно больших усилий стоила настройка этого процесса, потому что, по умолчанию, всё настроено на сборку на локальной машине разработчика. Помнится, даже ENV-параметры нельзя было прокинуть, не знаю как сейчас.
Пожалуй, это всё, что с ходу вспомнилось.
Думаю автор статьи в первую очередь испытал сильное разочарование в слоганах которые часто сопровождают хвалебные статьи про RN. Кажется что еще чуть-чуть и любой верстальщик сможет кодить мобильные приложения.
Мне кажется что первая проблема RN это люди хватающиеся за мобильную разработку с нуля.Не знакомые с процессом нативной разработки. Если опыт нативной разработки имеется то и покопаться в коде компонента не страшно и часто намного понятнее что и где сломалось при переходе на новую версию.
Спасибо за статью!
Хочу поделиться моим опытом:
Во первых, не обязательно использовать чистый React Native, можно сильно упростить себе жизнь просто работая с Exponent SDK, к примеру.
Во-вторых, не все фреймворки одиноково полезны, то есть не всегда плагины для фреймворков выполняют заявленный функционал, что приводит следующему выводу — всегда призодится углубляться во внутренний кода React Native, чтобы понять как сделать даже самую простую анимацию, к примеру. Просто взять и использовать «из коробки» практически ничего нельзя, однако это не должно отражаться на отношении к фреймворку.
Если у вас негативный опыт использованиия, то скорее всего он не оправдал ваших ожиданий. А фреймворк сам по себе замечательный, исклюичтельно положительно отношусь к транспилерам и кросскомпиляции, это действительно спасает.
Попробуйте Exponent SDK, он будет немного более удобным.
Так ли хорош React Native?