Pull to refresh

Comments 55

Ни разу не слышал о том, что Flutter быстрее React Native от тех, кто использует оба инструмента. Они обычно говорят, что интерфейсы написанные и на том и на этом «тупят» одинаково.

Доверия графикам никакого.

На графиках там вообще числодробилку тестировали. И совершенно неудивительно, что React Native там тормозить будет нешуточно.
У меня ситуация противоположная: все, кто использовал RN и Flutter в разработке говорят, что Flutter действительно превосходит RN в производительности. И нет, речь не про петпроекты и хеллоуворлд.
Не может такого быть, что флаттер больше тупит. Так может сказать тот, кто им с ним не работал. «Тупит» он только в дебаг режиме из-за поддержки hot reload. В релизе все летает.
О, это ещё не верх громких заявлений! Мне тут один адепт Флаттер доказывал, что производительность приложения под iOS на флаттер и на Свифт одинаковая.

В чем противоречие? Если флаттер гоняет 60fps в интерфейсе?

Это дебаг или релиз запущен? Какая версия сборки? Нужна ссылка на тикет с демо проектом и видео. Ответ от разработчиков должен быть, по крайней мере я на подобное получал ответы.
Подобного не может быть в массе так как на флаттере уже работает довольно много приложений.
Ну вообще как минимум в теории ничего не мешает этого добиться, так как что тот что другой компилируются в нативный для платформы бинарь.
Ну дык у флаттера, в принципе, оверхеда не должно быть никакого, у них нативный код получается и своя графическая подсистема (фактичестки, работает примерно как игрушки, которые сами рисуют весь свой UI), а не как React Native, транзит команд из JS на родные системные UI компоненты.
оверхед есть, когда ты что-то хочешь сделать например, с нативом. Вывести что-то нативное внутри проекта используя PlatformViews. Но тут это очевидно.
О как, почему то был уверен что вы только 1с да ms dynamics занимаетесь.
У тайпскрипта кстати есть еще один минус. Даже если забыть что он в js транспайлится — и на этапе написания с js либами взаимодействовать приходится, а оттуда может динамика проползти.

Либо такая статика в некоторых биндинг ах, что лучше бы динамика была в некоторых местах.

Объясните непосвящённому, что плохого в том, что TS транспайлится в JS? Типы и интерфейсы нам нужны при разработке, а что там движок читает нам разницы никакой нет. Или я не прав?
Ну во первых в изначальном комментарии я уже упомянул про интероп с js из которого динамика пролезет рано или поздно, во вторых результаты статически типизированного языка проще джитить или оптимизировать на этапе aot компиляции, так что потенциал для оптимизации производительности заложен более высокий.
Я месяцев 8 как на Flutter, радует, что технология живая и развивается прямо на глазах. Практика использования еще не устаканилась как следует, и иногда даже весело смотреть на простыни кода. Но это детские болезни разработчиков, пройдет.
Dart, я бы сказал, даже несколько перегружен синтаксическим сахаром, что радует когда ты уже освоился, но на входе бодрит.
Dart, я бы сказал, даже несколько перегружен синтаксическим сахаром, что радует когда ты уже освоился, но на входе бодрит.

Ну вот после Котлина не сказал бы, даже кое-чего не хватает.
прям с языка сняли
А какие там вкусности есть, которых нет в Dart?
Я с Котлином не знаком еще.
Уточните, что имеете ввиду.
вы последний раз комментировали тут что-то в 24 июля 2015 в 17:04 :-)
Да, давно не программил. В менеджмент был утащен :)

А вот как выглядит "Hello World!" на Kivy:


from kivymd.app import MDApp
from kivymd.uix.label import MDLabel

class MainApp(MDApp):
    def build(self):
        return MDLabel(text="Hello, World", halign="center")

MainApp().run()

Помнится, фреймворк Kivy жутко ругали, что он имеет свой собственный движок для отрисовки UI и выглядит одинаково на всех платформах. Но когда новым инструментам потребовался пиар, этот минус быстро превратили в плюс, мол, это же круто — собственный движок для отрисовки UI, единый вид на всех платформах!

выглядит одинаково на всех платформах.

Так приложения на Flutter могут и не одинаково выглядеть, они могут и мимикрировать вполне неплохо под системный UI. В каком-то докладе от гугла по переключателю в меню приложение на лету меняло свой UI из Material Design в iOS-стиль, как бы он ни назывался.

Я из iOS элементов в официальном демонстрационном приложении Flutter видел только несколько кнопок и пару диалогов. Больше там ничего нет.

UFO just landed and posted this here

А причем тут "из какого года"? Последнее обновление официального демонстрационного приложения — 7 февраля 2020 года. В разделе "Cupertino" (виджеты для iOS) всего пара-тройка iOS контролов и текстовых полей. Возможно, разработчики не посчитали нужным включать все, но я говорю о том, что вижу в официальном демо приложении.

Увидел название статьи и почему то знал что увижу ваш комментарий. Вы постоянно разводите холивары на тему что "Kivy лучше Flutter". В чём смысл? Ну не пользуется ваш фреймворк популярностью, может причина в нём, а не в других более популярных фреймворках?

Пока не было вашего комментария, никто и не думал о "холиварах". А если уже на то пошло, то специфика данной статьи располагает (Flutter VS React Native). Реакт Нативщики негодуют, вот и вы подскочили… Особо радуют знания "специалистов" по Flutter, которые даже не в курсе, есть ли в этом фреймворке поддержка адаптации UI к особенностям платформы и все-таки натив или не натив. Но вы, видимо, как большой специалист, сейчас нас просветите...

UFO just landed and posted this here

Я и написал — пара-тройка. Если быть точным — 11. А если отбросить элементы "Переключатель", который ничем не отличается от того же на Android, "Navigation bar", который на самом деле просто обычный список (не понятно, зачем его включили в раздел Cupertino), "Кнопки" (две), которые оказываются на самом деле просто RaisedButton и FlatButton из Android, "Activity indicator", который просто обычный спиннер, страшнючие текстовые поля (два), которые нормальный человек никогда не будет использовать в своем приложении, "Pull to refresh", который идентичен элементу в Android (опять же, не понятно, зачем его включали в раздел Cupertino), — то можете сами посчитать, сколько там виджетов для iOS. Я написал то, что увидел в официальном демо приложении от 2020 года. Ну и кто здесь врет?

UFO just landed and posted this here

Нет. Просто, видя ваш настрой, когда вы обвинили меня "во все лжи", и когда я привел вам аргументированные доказательства, вы, заявляя, что не будете скачивать оффициальное демо приложение и смотреть, где я вас обманул, все-таки согласны с моим мнением, что НИКАКОЙ поддержки iOS виджетов во Flutter нет!?

UFO just landed and posted this here

Можете привести доказательства моей неправаты?

Если ты — адепт фреймворка, который никому не нужен, то умей предоставить аргументированные доказательства моим комментариям!

Пишем на Flutter полтора года. В целом — довольны, получилось очень не плохо. Но есть минусы.
МИНУСЫ:
1. Сырой API. Могут поменять спецификацию «На лету».
2. Не работают некоторые нативные вещи, которые должны работать из коробки. Например, до сих пор есть глюки в текстовых полях на некоторых моделях телефонов (задваивается текст). Решается костылями. А очень неприятно решать костылями то, что ожидаемо должно правильно работать из коробки.
3. Нет НОРМАЛЬНОГО WYSIWYG-редактора (проект зефир скорее мертв чем жив).
4. Виджеты. Пришлось писать на нативе. В итоге довольно сложная архитектура, т.к. виджет должен работать в паре с основным приложением, а поднимать дартовское приложение в фоне для виджета — это сразу большой расход памяти (напомню, у виджетов например на айфонах есть ограничение в 24 мегабайта). Выкрутиться можно, но архитектура получается довольно дремучая.
ПЛЮСЫ:
Мне понравился и язык, и типизация, и портабельность и скорость работы. Мы делали десктоп и PWA-версию на React (не Native, но все же...) и мобильную разработку на Dart. (Не сочтите за рекламу, потыкать можно тут singularity-app.com). Код мобильной версии получился в разы проще (в основном конечно не из-за языка, а, из-за того, что не нужно было делать типовые десктопные штуки, типа обработку хоткеев и всякие прелести, типа CMD+Z). Плюс паттерн BLOc, который проповедуют в мире Flutter, в итоге дает более понятный код и меньше слоев абстракции, чем Redux (тут очень спорно и холиварно, и все зависит от задачи, но в нашем случае это оказалось так; впрочем никто не мешает его использовать MOBx но в больших приложениях есть риск утонуть в отладке обзерверов).
Итог такой, что лично я доволен Flutter. А минусы — везде есть )

А язык в сравнении с ES5/ES6/ESNext/TS? Сами сейчас рассматриваем альтернативы.

Всё-таки интересно, с чем идёт сравнение? Например, React приложение писали на ES5/ TypeScript/ReasonML? Это всё-таки большая разница)

прикольное приложение, Хаос менеджмент, залип на сайт — очень круто :)

ReactNative зло которое должно умереть. Особую боль составляет его дебаг и попытка обновить любой проект сложнее hello world.


Вообще проше JS закопать, чем решить все его проблемы

Мы пишем приложение на react-native уже более 1.5 года.
Оно весьма крупное (eComm + eCare) и всё у нас, в общем-то, хорошо. В том числе и с дебагом. Особенно приятно с hot-reload в версии >0.61 и тайм-тревеллом.
Нерешаемых проблем не обнаружили, композиция компонент в реакт очень хорошо работает.
Довольно легко подключаются сторонние либы. Мы подключили проприетарную нативную либу по распознаванию лиц и документов с потока видео из камеры и это не заняло у нас много времени. Работает хорошо и на андроид и на айос.

Из проблем, столкнулись лишь с долгим временем запуска андроид приложений (на айос вполне нормально), т.к. для этого требуется запускать движок JS. Пробовали различные ухищрения, но они давали не очень существенный прирост. Сейчас смотрим в сторону Hermes, по заверениям, он может дать прирост х2

И да, у react-native есть потрясающая фича — обновление приложения «на лету», даже не надо обновлять само приложение в магазинах (play market, ios store).
Т.к. приложение запускает index.bundle.js, то его можно подгрузить с интернета во время запуска и пофиксить багу, без обновления основного приложения.

Очень приятная плюшка, а flutter так может? )
Очень приятная плюшка, а flutter так может? )

Он ближе к нативу. Но можно динамически строить интерфейс по каким-то конфигам из вне.
Нужно было тут по-быстрому написать Android приложение, ну там REST-сервисы и всё такое. На нативном не было времени вникать, Flutter в принципе получше, но тоже не сильно меньше по времени занимал. В итоге набрёл на проект NativeScript в варианте в Angular и о чудо, через день уже приложение вполне себе нормально работало. Если есть представление в Angular, то очень рекомендую, хоть он там немного урезанный, но даже удивительно как они его вполне органично положили в качестве обвязки для нативных компонентов Андроида/iOS. Кстати, протестировал на довольно старом устройстве с Aндроидом 5, так вот, простое приложение на Flutter буквально поле ввода и кнопка — на нём вполне существенно тормозило при вводе — буквы появлялись очень медленно и иногда происходили пропуски нажатий, при этом аналогичное приложение на NativeScript вообще без вопросов работало.

И отдельно хочется отметить различные варианты разработки. Ребята очень заморочились и разрабатывать можно: как обычным способом, запуская на устройстве/эмуляторе, так и используя специальное приложение NativeScript Playground, которое после сканирования QR из консоли (!) отображает разрабатываемое приложение с динамическим обновлением при изменении. Ну и совсем для ленивых — запуск в этом же вспомогательном приложении по QR коду вообще из браузера.

В общем, советую попробовать: play.nativescript.org
почему не использовали PWA?
в твиттере мобайландерхуд писали, что флаттер меньше крешится чем РН
как и любая кроссплатформа флаттер является решением в пользу бедных.

первый же вопрос — как решение работает с разными жестами и системами навигациями на ведре,
второй — как быстро апп-ку можно будет адаптировать под ipad.
Ждем когда RN переведут на движки рендеринга. Тогда и посмотрим что лучше. Dart перегружен чрезмерно, и при всем этом почти полностью повторяет архитектуру JavaScript, за исключением наличия «правильного ООП». Если абстрагироваться от формы то он напоминает JS 10 летней давности. Мы уже во всю используем await, а Dart юзает Future. Я к тому, что сейчас JS становится все дружелюбнее, а Dart нет. TypeScript привычен и более гибок в настройке глубины типизации.
Ээээ… Вот строка кода. Dart:
dataModel = await dataController.getModel(myParam);
Dart перегружен чрезмерно

мне всегда казалось он построен был так, как должен был js. Разве нет?

Мы уже во всю используем await, а Dart юзает Future.

Future это же аналог промисов, только попроще, разве нет? В итоге одна фигня — есть либы, что axios у js что duo на дарте.

dart.dev/codelabs/async-await

А в выборе дарта для флаттера вместо TypeScript я тоже вижу сугубо личную обиду кого-то из мейнтейнеров, недооценили вы нас, так получайте сполна))
Sign up to leave a comment.

Articles