Комментарии 101
А как у Native с играми? Слышал, что что-то больше змейки там тоже не стоит делать.
Так как основная идея RN это использовать JS для написания приложения, то от нее и будем отталкиваться.
Все исполняется в JS потоке и через мост дергаются OEM виджеты — то однозначно будет лагать.
Но если использовать движки и/или либы для написания игр — то опять вопрос к передаче данных между JS потоком и движком.
А если убрать JS поток — то это уже и не React Native вовсе.
ReactNative это не про игры, это по большей части про UI.
Если хотите кросс-платформенные игры, то лучше уж искать подходящий вам кросс-платформенный игровой движок.
P.S. Лично я в принципе советую держаться подальше от ReactNative – из плюсов в нём только то, что это React и вы его скорее всего уже знаете. В остальном это боль, страдания и ощущение, что RN это огромных размеров костыль (сугубо личное мнение, никому не навязываю)
из плюсов в нём только то, что это React и вы его скорее всего уже знаете
ИМХО знания React.js одинаково полезны и для начала работы с RN и для Flutter.
Я вот в свое время RN попробовал тоже потому что "ну я же уже знаю React". И был удивлен, что как-то не очень эти знания мне помогли. На Flutter пересесть было примерно также, а учитывая большее удобство самого инструмента, куда лучшую интеграцию с Android Studio и т.п., то наверное даже легче.
Так что и этого плюса нет :)
После React Native было просто перейти на Flutter. Тоже декларативно. Dart похож на JS (один поток, EventLoop, Async/Await).
Я подразумевал под "уже знаете", что при знании react порог вхождения уже не "с нуля". В остальном да, чуть шаг в сторону от "отрисовать данные с сервера на экране" начинаеются пляски с бубнами.
Ну, мой поинт, что при выборе RN vs Flutter нюанс знания React-а не стоит воспринимать как жирный плюс в пользу RN, так как даже с учетом этого плюса, начать использовать Flutter, весьма вероятно, окажется проще, чем RN.
Это для тех, кто стоит перед таким выбором, читая этот коммент :)
Я с вашей точкой зрения согласен. Щупал flutter(сам я фронтендер, до промышленной разработки на flutter если и дойду, то не знаю когда), мне понравилось. Коллега android-разработчик попробовал flutter, он тоже в восторге.
нюанс знания React-а не стоит воспринимать как жирный плюс
А я и не говорил, что он жирный. Скорее "плюсик". И то для определенных ситуаций
Скажите, имея поверхностные знания js (совсем поверхностные) и нулевой опыт в мобильной разработке и фронтенде, но имея хорошие зания и опыт в C и относительно неплохое понимание C++, с чего проще начать, с RN или Flutter? На сколько высок порог вхождения совсем издалека?
Мне сложно ответить, т.к. с C не работал вообще.
Но по моим ощущениям с вашими вводными лучше начать с flutter.
В RN порог вхождения низкий(весьма относительно низкий) если знать js и React. Но мне, имея опыт и в js и в React, RN не понравился от слова совсем.
Мне кажется что знанием C порог вхождения во flutter вам будет проще преодолеть(но это скорее по моим субъективным ощущениям)
Понял что следующий крупный проект точно не хотелось бы делать на RN, а обещания про светлое будущее без бриджа — когда они еще сбудуться. И проблемы с качеством просто достали.
Ну и точно сложность — как перейти меняя стек, тем более с позиции техлида.
В итоге в рамках самообучения я сейчас для себя переделываю куски текущего проекта на Flutter, радуюсь насколько все лучше и стабильнее.
Особенно впечатляет уровень контроля над UI, который является следствием архитектуры flutter. То что у scrollTo у какого-нибудь scrollView можно задать и easing, и duration — просто восторг.
Подскажите плиз, что вы подразумевали под термином "Кросс-платформа"?
Приложение на React Native запускается на Android и iOS.
В светлом будущем еще и в вебе :)
Вопрос из 22 года :) про десктопы. Точнее про вэб для декстопа.
Насколько Флаттер сегодня подходит для фронтэнда? Является ли он аналогом фреймворков "большой тройки" и в какой мере?
У флаттера для веба весьма ограниченный юзкейс – по крайней мере, пока. Он не для "сайтов", он для "приложений". Упрощенно говоря, если у вас не PWA, то Flutter for Web вам, скорее всего, не подойдет.
Если PWA это это приложение, работающее в браузере и каждый раз загружаемое с сервера, то меня это вполне устроит :)
Также очень удобно когда у QA в каком-то инструменте есть все feature-branches для тестирования, не надо ничего пересобирать или публиковать в сторах.
Как такое сделать с Flutter мне пока даже непонятно :)
Также мы перешли просто на ejected expo в какой-то момент, но все равно expo — это позволяло снизить количество геморроя при обновлении версий.
Кому-то он пригождается, мне наоборот нет — так как в каждом проекте была хотя бы одна либа с нативной частью или свой нативный код.
К субъективным минусами я бы еще отнёс "кашу виджетов" Бороться в ней легко, производя рефакторинг выкидывая куски-переростки в отдельный виджет. По началу было не очень а потом привык. Flutter мне зашел очень даже.
Поправьте, если где-то не в том направлении думаю.
Представим, есть человек с некоторым багажом знаний программирования только-только приходит в мобильную разработку. Вот он самостоятельно учит принципы вёрстки, бизнес-логику и создаёт первый серьезный рабочий прототип, который не стыдно показать случайному человеку. А дальше как быть? Как юный мобил-девелопер на флаттере может попасть в некий более-менее крупный проект (которых ещё нет), чтобы изучить внутреннюю кухню девелопинга, пайплайны, разделение труда и все такое прочее.
Напрашивается вывод: учить реакт и идти пилить приложухи на нем, т.к. на реакте проекты точно найдутся.
А как устроиться на работу с Флаттером? Я недавно лениво листал хеху и там все как-то грустно, всем хочется рн с Флаттером сверху зачем-то.
Но разработка это же не «выучил одно — вечно работаю». Знания в целом пригождятся.
Если описанный разработчик взялся за React Native, то он должен хорошо знать JavaScript и React.js. В первую очередь он JavaScript разработчик.
Если говорить о JS, я бы на таких вводных пошел сперва в Web или React Native. А потом можно во Flutter.
Тем более что после RN верстка во Flutter, его асинхронная работа и EventLoop даются очень легко, что-то вообще 1 в 1.
Я думаю следующий шаг — это взять какой-то заказ на проект посерьезнее, чтобы сделать не то что «придумалось», а что-то в соответсвии с требованиями.
Ну и всегда можно продолжать учить Flutter и искать крупный проект на нем.
Эх, еще бы аналоги sealed классов, прямо в тот же момент забросил бы читать статейки про натив и пошел активно флаттер осваивать).
Ну вы это и так знаете.)
Если вы хотите серьезно заниматься мобильной разработкой, то не советую "забросил бы читать статейки про натив". По моему глубокому убеждению, внедрение любого кросс-платформенного фреймворка людьми, не имеющими опыта в нативной разработке, чревато неприятными последствиями.
Наиболее оптимальный вариант: хороший опыт нативной разработки под одну платформу, и хотя бы базовый уровень нативной разработки под другую.
Просто если бы взялся за флаттер тратить по паре часов в день свободного времени как раньше на продолжение изучения натива никак бы не вышло. Потому и написал в такой манере.
Посмотрите в сторону Kotlin Multiplatform, раз вы уже в Котлине.
Пишете насчёт производительности.
Я так понял, чем свежее и мощнее девайс, тем лучше. Приложения написанные на этой платформе, всегда подтормаживают?
А какого типа приложения пишут на RN и Flutter?
А какого типа приложения пишут на RN и Flutter?
Для Flutter можно посмотреть тут
По идее, RN подходит для тонкого клиента, но на деле даже тут без гарантий. Но часто слышал что кроме как для прототипа он не подходит.
Flutter также подходит для этих же целей. Но может больше. Потому что он производительный и вывозит приложения с множеством экранов.
Мой личный рецепт когда использовать RN:
— Нет выхода.
— В арсенале только JS.
— Нужно просто и быстро. Немного экранов.
Flutter:
— Общий UI на 2 платформы.
— Нужно быстро верстать.
— Тяжелые вычисления — отдать в изолят, либо в натив через каналы (это делается проще чем в RN).
В итоге в течении часа перевел все приложение на Flutter и допилил.
Для меня это был момент, после которого я даже думать не хочу о возврате на React Native.
Не работал еще с Flutter — есть вопрос по сборке.
Мой последний RN проект собирался более получаса для iOS из-за множества зависимостей, доставшихся по наследству. Во Flutter есть преимущества в этом? Или та же пляска с Xcode и кучей галочек?
Еще в минусы Flutter можно отнести бардак при работе с темами. Там часть документированного функционала тупо не работает: при смене темы часть её параметров не применяются к компонентам и приходится костылями вручную выставлять.
Addon: Хотя, 8 дней назад закрыли таск в рамках которого обещали пофиксить: https://github.com/flutter/flutter/issues/54776 Огонь! :)
В React Native только JIT-компиляция
Должен сказать что React Native не использует jit на iOS. Вот пруф (https://reactnative.dev/docs/javascript-environment)
Note that on iOS, JavaScriptCore does not use JIT due to the absence of writable executable memory in iOS apps.То есть это значит что на iOS реактовский diff большого дерева компонентов будет тормозить потому что js будет интерпретироваться а не компилироваться в более оптимизированную версию как на android. Даже cordova будет быстрее потому что она использует webview со встроенным safari-движком а это единственное приложение которому iOS разрешает jit, соотвественно реакт c кордовой будет быстрее чем с react native
Реакт нейтив потихоньку развивается, раньше даже кнопки готовой в нем не было.
А какая в C++ ТРУЪ безопасность? В самом языке ни чего такого нет.
К тому же может и еще какую инфу дополнительную дарт сохраняет.
Потому даже на C++ существуют обфускаторы кода, обфускаторы машинного когда, шифровальщики и прочее, прочее, прочее.
Но большинство этих утилит, мне кажется, без проблем применятся и к скомпилированному в машинный код Dart.
— ощущение какой-то хрупкости, особенно при сборке на Андроид, постоянные падения, необходимость постоянно чистить кэши…
— очень большое влияние на приложение рекомендуемого компоненты для организации роутинга React Navigation, плюс он жрет память как не в себя и не очень охотно ее высвобождает, альтернативный роутер есть, но его я не пробовал — текущий очень тесно интегрирован в приложение и заменить его не просто.
Это основное.
Флаттер пробовал. Но он как-то не впечатлил. Весь этот коллбекхелл из виджетов напоминает мне React без JSX. Много есть желающих писать на нем? Я ни одного не видел. Да, можно их делать и все такое и писать свой код на этом будет вполне ок. Но я врагу не пожелаю попасть на поддержку написанного кем-то другим проекта. А ведь год-полтора и все вот эти проекты, на которых сейчас люди учатся и хвалят Флаттер перейдут к другим разработчикам. И им не позавидуешь.
Нужно отметить что Dart еще как язык заметно проще JavaScript.
Например:
var obj = {
name: 'Иван',
age: 21
}
obj = new Proxy(obj, {
get(target, prop) {
if(prop in target) return target[prop]
if(!prop.includes('_')) return '';
return prop.split('_').map(p => target[p]).join(', ')
}
})
console.log(obj.name) // Иван
console.log(obj.name_age) // Иван, 21
console.log(obj.age_name) // 21, Иван
console.log(obj.name_age_name) // // Иван, 21, Иван
Ну навскидку как-то так:
class Proxy {
var _data;
dynamic Function(dynamic, String) _handler;
Proxy(this._data, this._handler);
@override
dynamic noSuchMethod(Invocation invocation) {
return _handler(_data, invocation.memberName.toString().split('\"')[1]);
}
}
void main() {
dynamic obj = {
'name': 'Иван',
'age': 21,
};
obj = Proxy(obj, (dynamic data, String prop) {
if (data.containsKey(prop)) return data[prop];
if (!prop.contains('_')) return '';
return prop.split('_').map((p) => data[p]).join(', ');
});
print(obj.name);
print(obj.name_age);
print(obj.age_name);
print(obj.name_age_name);
}В JS, правда, еще можно на ходу лепить функции через new Function, но в проде никогда этим не пользовался. Как и динамической сменой прототипа через __proto__.
В JS, правда, еще можно на ходу лепить функции через new Function, но в проде никогда этим не пользовался
Dart тоже позволяет подобное https://dart.dev/guides/language/language-tour#functions-as-first-class-objects
но в проде никогда этим не пользовался
А классной штукой, приведенной выше, пользовались?)
По ссылке передача функции через параметры.
Я имел ввиду это:
var f = new Function('a', 'b', 'console.log(a * b)');
f(2, 5)
А вот call и apply в проде использовал, но редко. Но, в качестве исключения, часто юзал такую конструкцию:
Object.prototype.toString.call
По ссылке передача функции через параметры.
Я имел в виду это (чуть ниже написано):
var loudify = (msg) => '!!! ${msg.toUpperCase()} !!!';
assert(loudify('hello') == '!!! HELLO !!!');
Как показывает практика, более популярной становится технология, основанная на устоявшихся универсальных и привычных стандартах. Flutter в этом плане — вещь в себе, и вакансий мало.
Ну Dart хоть и известен меньше, но его создатель не какая-то компания новичок и работа над ним ведется активная.
Насколько мне известно, внутренняя версия RN Facebook отличается от той что open-source.
Также крупные компании форкают RN и поддерживают свою версию.
А Airbnb вообще отказалась от React Native.
Airbnb плюсую. RN годится только для простых приложений (в т.ч. макетов) с учетом того, что в определенный момент развития (если еще будет такое) целесообразно будет выпустить нативные версии и развивать их. Для сложных приложений, которые развиваются быстро, все равно надо будет кодить нативно (JS разработчики и кодить не смогут быстро (или вообще не смогут), и не будут знать многих нюансов платформ), так как RN сообщество развивает только некоторые отдельные библиотеки — остальные устаревают и выпадают из зависимостей (на последнем RN проекте при обновлении версии RN даже пришлось форкать некоторые либы и переписывать).
Как корпоративное звено, могу ответить просто — RN очень легко «продать» (получить спонсорство, финансирование). То есть я могу легко собрать пять статей, где его расхваливают, рассказать про одно приложение на две платформы силами только дешевой JS разработки, большое стабильное сообщество со звездами у репозиториев, множество библиотек, универсальные автотесты, примеры от многих компаний. Все это под соусом позитива (хотя в каждом пункте есть нюансы, которые уничтожат возможность развития продукта на каком-то этапе).
Flutter на данный момент я не могу «продать», не хватает материала для убеждения, статей, где кто-то брызжа слюной доказывает (аналогия с RN), что он космос.
Вот и все.
И я бы не сказал что эти компании маленькие или ноунеймы.
Если Flutter закроет потребности которые не сможет React Native.
Или нужно говорить юзерам «Миритесь с проблемами, зато у нас React Native»?
На RN можно допилить нативно, — но это уже трата дополнительных ресурсов. А мы, вроде как, хотели сэкономить. На Flutter тоже иногда приходится лезть в нативную часть, но куда реже.
Перейти на новый экран, сделать сетевой запрос, обработать JSON ответа на пару сотню Кб, перерендерить пару десятков вложенных View — вот типичные задачи для ниши приложений, для которых используются эти фреймворки.
Если вы их используете для создания игр, real time machine learning, 3d графики и пр., то вы просто используете неподходящий инструмент.
Второе. У меня за плечами разработка большого приложения (порядка 30 экранов) с команде из 3 разработчиков, которое работает на базе RN и при этом занимало и занимает топовые позиции в каталоге App Store. Мне кажется, это подтверждает аргумент, что можно делать крутые приложения на RN, которые нравятся пользователям.
Откуда утверждение про 99%? А если будут, тогда что? На Swift переписывать?
Если все же есть такая потребность, но у RN неплохая документация, как написать подключить к RN произвольный нативный модуль. Этим тоже мы нередко занимались, подключая внутренние нативные модули нашей компании.
Если ли же в вашем приложении процентное соотношение другое, то, конечно, стоит присмотреться к другим вариантам.
Советую еще посмотреть это видео.
Почему я ушёл с React Native и перешёл во Flutter: Часть 1