Комментарии 18
Мне кажется, не упомянута 6 причина, которая собственно и отличает данный фреймворк от других: flutter сам отрисовывает виджеты, а не является прослойкой между кодом и системными виджетами. Это приводит к высокой скорости работы и отзывчивости интерфейса. Ну и плюс aot компиляция на двух платформах, если не ошибаюсь.
Не взлетит, ибо дарт.
У React Native все же есть некоторые преимущества, к примеру, переиспользование бизнес-логики(которая обычно в Redux/Mobx) из web-приложения. Плюс есть такие штуки, как React Native для Web, еще больше повышающие процент повторно используемого кода.
Ну и в Flutter отрисовка далека от идеала: текстовые надписи на кнопке в примере Dialogs почему-то пикселизированные, табы «прыгают» на несколько пикселов при нажатии, а мимикрия нативных виджетов под iOS местами заставляет вспоминать приложения на Cordova.
Вообще, сама концепция «в нативном UI есть один фатальный недостаток» не очень хороша: нельзя использовать UI-фреймоврки, работающие с этим самим нативными UI, к примеру обертку для рисования графиков и диаграмм, каждую библиотеку придется переписывать под отрисовку на Skia.
Ну и в Flutter отрисовка далека от идеала: текстовые надписи на кнопке в примере Dialogs почему-то пикселизированные, табы «прыгают» на несколько пикселов при нажатии, а мимикрия нативных виджетов под iOS местами заставляет вспоминать приложения на Cordova.
Вообще, сама концепция «в нативном UI есть один фатальный недостаток» не очень хороша: нельзя использовать UI-фреймоврки, работающие с этим самим нативными UI, к примеру обертку для рисования графиков и диаграмм, каждую библиотеку придется переписывать под отрисовку на Skia.
У React Native все же есть некоторые преимущества, к примеру, переиспользование бизнес-логики(которая обычно в Redux/Mobx) из web-приложения. Плюс есть такие штуки, как React Native для Web, еще больше повышающие процент повторно используемого кода
Мечты, мечты, где ваша сладость…
Существует огромное количество систем, где переиспользование физически невозможно (из-за в корне различных систем на веб-фронте и бэке и в смартфоне). И тем не менее эти предприятия успешно функционируют.
React не является серебряной пулей. Гипотетически, да — грандиозное переиспользование, экономия кучи ресурсов. По факту — так не получается. Почему-то. Возможно, из-за различных сценариев использования браузера и телефона? Или еще из-за чего-то? Не знаю.
Ну так никто и не мешает этим предприятим и дальше поддерживать по полноценной команде разработки для каждой платформы. React Native, Flutter, Weex, Xamarin, Native Script, и подобные технологии — они для тех, кто хотят упростить внесение изменений, унифицировать логику работы клиентов, и уменьшить количество рутины.
Что лучше: написать два клиента API на Retrofit и Alamofire/Moya под Android и iOS соответственно, или написать один раз на TypeScript+axios под Web-платформу, и потом переиспользовать на мобильных? Загрузка и кэширование фото? Анкета пользователя? Навигация по приложению? Обработка push-уведомлений? Формы регистрации с валидацией? Это все рутина, которую мы вынуждены повторять 2-3 раза под разные платформы. Да, сначала будет непривычно, да, придется частично выйти из зоны комфорта удобных и привычных инструментов, да есть баги, но Рим не один день строился, как говорится.
Ну и никто не говорит что это будет работать в 100% случаев использования технологии. В качестве хорошего примера повторного использования кодовой базы можно привести Discord. Сразу скажу, что у мобильных клиентов есть несколько багов в UI, но при этом производительность на уровне нативных приложений. Кроме того, логика общая для iOS, Android и Web. У команды разработки есть неплохая статья, где среди прочего они рассказывают и о минусах React Native, к примеру им пришлось использовать ComponentKit для более плавной прокрутки чата.
Что лучше: написать два клиента API на Retrofit и Alamofire/Moya под Android и iOS соответственно, или написать один раз на TypeScript+axios под Web-платформу, и потом переиспользовать на мобильных? Загрузка и кэширование фото? Анкета пользователя? Навигация по приложению? Обработка push-уведомлений? Формы регистрации с валидацией? Это все рутина, которую мы вынуждены повторять 2-3 раза под разные платформы. Да, сначала будет непривычно, да, придется частично выйти из зоны комфорта удобных и привычных инструментов, да есть баги, но Рим не один день строился, как говорится.
Ну и никто не говорит что это будет работать в 100% случаев использования технологии. В качестве хорошего примера повторного использования кодовой базы можно привести Discord. Сразу скажу, что у мобильных клиентов есть несколько багов в UI, но при этом производительность на уровне нативных приложений. Кроме того, логика общая для iOS, Android и Web. У команды разработки есть неплохая статья, где среди прочего они рассказывают и о минусах React Native, к примеру им пришлось использовать ComponentKit для более плавной прокрутки чата.
React Native, Flutter, Weex, Xamarin, Native Script, и подобные технологии — они для тех, кто хотят упростить внесение изменений, унифицировать логику работы клиентов, и уменьшить количество рутины.
То что вы рассказываете — это красивая теория. В идеальном мире так и должно быть… но мы живем в реальном мире.
Как показывает практика — универсальные системы позволяют создавать худшее решение для каждой целевой платформы.
Да, они универсальны — это плюс. Они хуже для каждой целевой платформы чем нативные приложения — это минус.
Пока никто из перечисленных не показал себя достойным. Ну иначе бы все остальные способы разработки естественным путем вымерли бы.
Что до конкретно Флуттера — я лично проверял. Он — тормоз. На хороших современных смартфонах его можно использовать (если плюнуть на расход заряда аккумулятора). Но и только.
На не самых быстрых устройствах (а дешевые модели по понятным причинам составляют большинство продаж и большинство на руках в использовании) — не пригоден.
Рим не один день строился, как говорится.
Почему страдать должны мои пользователи? Чтобы я потерял интерес моих пользователей к моим продуктам?
В условиях отсутствия бюджета у не понимающего заказчика, которого интересует только цена вопроса, а не качество итогового решения и лояльность пользователей — да, в этих решениях есть смысл.
Почему страдать должны мои пользователи? Чтобы я потерял интерес моих пользователей к моим продуктам?
Тут стоит уточнить, что является причиной «страданий»? К примеру, из опыта работы с React Native могу привести пример: на различных Prestigio, Zopo, и прочих чистокровных китайцах были проблемы с падениями приложения при использовании Google Services. Команда разработки React Native решает эти проблемы, рано или поздно они приблизяться к уровню стабильности работы, достигнутом для приложений под iOS.
Опять-таки, никто не принуждает всех прямо сейчас отказываться от поддержки устаревших Android-устройств, переводить всю разработку на React Native, и потом действительно страдать, утопая в жалобах тех пользоватлей, кому не посчастливилось быть обладателем телефонов-флагманов. Точно такая же история была с Material Design: только через год после анонса библиотеки поддержки стали более-менее годными для использования — а ведь это «родная» технология.
В условиях отсутствия бюджета у не понимающего заказчика, которого интересует только цена вопроса, а не качество итогового решения и лояльность пользователей — да, в этих решениях есть смысл.
Мне, как пользователю Skype Preview совершенно все равно на какой технологии он построен(а там таки React Native). Он работает даже на весьма тормознутом планшете Prestigio, при этом быстрее чем предыдущая «нативная» версия. Напротив, у меня есть множество вопросов к UX: нет поиска по истории, нет групирования контактов, неудобно расположены кнопки, в списке контактов вылазят какие-то левые люди которых «я могу знать». Имеет ли это какое-то отношение к React Native? Нет. Но если команда UI/UX решит эти проблемы(что в случае с Micro$oft маловероятно) — разработчикам нужно будет проделать меньше работы для внедрения обновлений под все платформы.
P.S. Особо дальше спорить на эту тему я смысла не вижу, т.к. я не пытаюсь никого убедить в необходимости использовать ту или иную технологию, и изначальный комментарий в ветке был всего лишь дополнением к сравнению Flutter и React Native.
Не могу с вами согласиться по поводу того что Flutter тормозит на бюджетных устройствах, по крайней мере в текущей версии Галереи что на Google Play — на моем телефоне (Sony Xperia M) на котором оригинальный с момента выпуска (2013) года Android 4.1 — всё работает без каких-либо нареканий по скорости.
На фоне Dart ReactNative это пионерское поделие.
Я попробовал Dart, ReactNative и Xamarin. Последние два это тихий ужас. Годятся только смотрелки картинок делать, да и то с кучей оговорок. Dart же практически идеальный язык, а Flutter это реально будущее которое в ближайшие пару лет оставит без работы кучу любителей пихать свой JS куда попало.
Я попробовал Dart, ReactNative и Xamarin. Последние два это тихий ужас. Годятся только смотрелки картинок делать, да и то с кучей оговорок. Dart же практически идеальный язык, а Flutter это реально будущее которое в ближайшие пару лет оставит без работы кучу любителей пихать свой JS куда попало.
Не первая же попытка сделать нечто подобное мультиплатформенное. Можно еще PhoneGap вспомнить. Можете еще что, с ходу в голову не приходит. Но наверняка есть.
Из всех взлетел только только проект Unity. И то — за счет готовых компонентов для жестко определенного сценария использования.
Из всех взлетел только только проект Unity. И то — за счет готовых компонентов для жестко определенного сценария использования.
Не стоит путать языки и фреймворки. Кроме того, утверждение о «смотрелках картинок» как минимум спорное, под React Native есть много приложений, обладающих гораздо большой функциональностью.
а Flutter это реально будущее которое в ближайшие пару лет оставит без работы кучу любителей пихать свой JS куда попалоКакой вообще смысл так враждебно относиться к языку? Это же просто инструмент, можно писать на том же Dart, как альтернатива есть Kotlin, ну и наиболее популярный вариант — TypeScript. Собственно, разрабатывать проект даже средней сложности на голом JS — это добровольно обеспечивать себя проблемами в будущем.
Когда пробовали Xamarin, использовали Xamarin Forms или Xamarin Classic?
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пять причин проникнуться симпатией к Flutter