Количество issues, как и количество stars (где Flutter обошел React.Native) ни о чем не говорят. Потребности бизнеса говорят. Я вижу как бизнес, по крайней мере в Штатах, очень заинтересован во Flutter и часто выбирает Flutter вместо React.Native/Xamarin/etc. Бизнес хочет сэкономить и при этом не наступать на «грабли» кроссплатфоменной мобильной разработки.
Смысл есть только если часть вашего приложения имеет, допустим, сложный UI с анимацией, и вам проще это реализовать на Flutter и интегрировать это на 2 платформы, чем пытаться сделать это нативно 2 раза. Но это довольно редкий кейс, где у вас/в компании уже есть нативные приложения, есть желание/опыт работы с Flutter и т.д.
Dart публично разрабатывается с 2011. Dart как замена JS — провал, начиная с 2015, следуя вашей логике гугл давно должен был закрыть проект.
Гугл не вкладывался в Kotlin до момента пока JetBrains не довели его до стабильного состояния. Да и вообще Kotlin не продукт Гугла, это самостоятельный продукт. Просто «повезло», так сказать.
Flutter не разменная монета. Flutter доказал что как продукт имеет очень существенный преимущества перед конкурентами. И если статья не убеждает в этом, то есть не-Васи, непредвзятые бэкенд разработчики (Phoenix_free), которым зашло.
Есть такой грех за Flutter. Фреймворк не прощает, или прощает меньше, если вы пихаете все подряд в UI тред, например. Любая операция не должна превышать 16 миллисекунд. Работа со списками тоже имеет свои особенности, как и везде. Но если знать некоторые основы, с производительностью не будет проблем. Сейчас я работаю над приложением, в котором просто уйма анимация и списки виджетов с более 500 елементов в нем. Пока критичных проблем с производительность нет.
Про один недостаток я написан, отсутствие дефолтного UI рендера (для кого-то это вовсе не минус). Все опирается на нативные контроллы. Хотя если использовать SkiaSharp, то жить можно.
Другой минус(ы), очень субъективный, который лично мне сложно выразить словами.
Почему, например, Xamarin так и не подвез Catalyst для Mac? Почему с покупкой Xamarin майкрософтом они все больше превращают ex-Xamarin Studio в IDE для работы с .Net Core, чем собственно с Xamarin? Я уже не говорю о том, что Xamarin.Forms за последние несколько лет превратился собственно в синоним Xamarin. Хотя, тут ответ наверное очевиден. Майкрософт всегда был бизнесом, ориентированным на корпоративный сегмент. Я хочу делать красивый UI и удобные приложения а не формочки для страховой компании.
Как минус Xamarin можно также занести отсутствие Hot Reload/Restart. Вроде как они что-то похожее сделали, но это работает только в Forms и даже (поправьте если ошибаюсь) только с iOS… В общем, так же как во Flutter у них не получится сделать просто потому что бессмысленно, все равно в итоге все упирается в нативный UI.
Как я написал в статье, я периодически пользуюсь приложением от Realtor.com, и к моему удивлению я узнал что оно написано на Flutter. Оно наверное больше тяготит к Material Design но у меня и мысли не было, что это не нативное iOS приложение.
Это довольно обширная тема, да и опыта с Flutter у меня пока не так много. Но если выделить главную для меня положительную черту, то это их подход к имплементации фреймворка. Там где можно работать со Skia, работают с ней. Где нет (веб), транслируют в веб элементы. При этом ты действительно работаешь нативно с UI потому как рендер UI концептуально от платформы к платформе не меняется. Ты оперируешь виджетами везде одинаково.
Eсли мы говорим про мобильную разработку, Flutter не скрывает от тебя нативные инструменты разработки. Приложение строится благодаря Xcode и gradle а не msbuild. По сути это и есть нативное приложение просто с одним activity/controller и canvas внутри. Xamarin имеет привычку все скрыть и завернуть в фантик от майкософт, что с одной стороны помогает абстрагироваться от платформ, но с другой причиняет боль если ты хочешь выйти чуть дальше этой песочницы.
Я в основном писал на Xamarin.Native/Classic и с Forms у меня был опыт печальный и очень давно, поэтому как сейчас в Forms дела обстоят я не знаю, но при переходе на Flutter я впервые ощутил, что UI для iOS и Android оказывается можно писать единый. Это наверное главный wow эффект. Это действительно pixel perfect решение и теперь я не знаю как можно вернуться к Xamarin после этого :)
HotReload/Restart вещь. Я знаю что в Forms вроде тоже реализовали это но имплементация точно будет хуже, просто потому что в конечном счете рендер UI в Xamarin ложится на каждую из платформ отдельно и такого функционала просто нет у них (не считая SwiftUI, но в Xamarin это пока не работает)
Everything is widget концепт действительно подкупает. Padding это тоже виджет, например. И это действительно так если ты смотришь на это с точки зрения рэндера дерева виджетов. Вообще все эти концепты widget/element tree, stateless и statefull виджетов, вся эта «реактивность» из коробки подкупают и не позволяют мыслить по другому после этого.
Есть и свои минусы/странности конечно. Например ты не можешь просто взять и узнать размер элемента перед построением всего дерева элементов. Фреймворк просто не работает так. Работа с зависимостями в пакетах (NuGet аналог) тоже далека от идеала. В Xamarin/.NET это реализовано стабильнее, чтоли. Dart и DartVM тоже далеки от идеала. С# как язык на порядок превосходит Dart, по моему мнению. Хотя некоторые концепты очень хорошо вписываются во Frontend разработку. Например в DartVM есть такой концепт как isolate. Каждый isolate это один main thread, побочные IO «трэды», которые дают тебе асинхронность и своя изолированная куча. Все. В этой песочнице ты и работаешь. Нужно что-то параллельно сделать, можно создать другой isolate и общаться с ним посредством сообщений но у меня такой необходимости пока не возникало да и на вряд ли возникнет.
PS: сейчас я разрабатываю одно приложение на Flutter с очень продвинутой анимацией и честно, я просто не был бы в состоянии сделать что-то подобное на Xamarin в каких-то приемлемых сроках. Нативно, скорее всего да если ты супер спец сразу на 2 платформы. На Xamarin.Forms, очень сомневаюсь, возможно если ты используешь SkiaSharp и то не факт. В общем, c Flutter моя продуктивность возросла.
Перешел с Xamarin на Flutter и ни могу не нарадоваться. Единственный раздражающий момент, система типов в Dart. Хочется нормальной строгой, явной типизации.
Xamarin.Forms + Mac OS/Linux и в какой-то степени WPF + Windows. Конечно комбинация Forms + WPF не может считаться полностью кроссплатформенной для десктопов, но определенно есть множество общих знаменателей.
С таким подходом можно и PHP 4.x какой-нибудь считать многопоточным :) (не знаю, возможно в последних PHP есть многопоточность на уровне рантайма)
Спасибо за перевод, всегда интересно прочитать что-то новое.
Но я до сих пор не понимаю, чем корутины в Kotlin/Go концептуально отличаются от async/await/Tasks/TPL/etc, короче от асинхроно/параллельного программирования в C#? Это преподносится как нечто совершенно новое, но, каюсь, я все не могу уловить суть. Может ли кто пояснить как корутины должны реализовываться в C#?
А как же Xamarin.Forms/WPF + XAML?
iOS, Android, Windows, Mac OS, Linux, даже никому не нужные Windows Phone и Tizen.
Я не удивлюсь если в течении полугода они принесут Forms в браузеры через WebAssembly (a.k.a реинкарнация SilverLight)
Год назад, примерно когда я стал интересоваться флаттером, написал на нем игру-клон Flutter.Bird, было довольно интересно и надо сказать легко.
Примеры продакш ready игр на этом движке я не знаю, но знаю одну почти игру, написанную на этом движке и выложенную в сторы, можете поиграться:
apps.apple.com/us/app/darkness-dungeon/id1506675248
play.google.com/store/apps/details?id=com.rafaelbarbosatec.darkness_dungeon
github.com/RafaelBarbosatec/bonfire
Гугл не вкладывался в Kotlin до момента пока JetBrains не довели его до стабильного состояния. Да и вообще Kotlin не продукт Гугла, это самостоятельный продукт. Просто «повезло», так сказать.
Flutter не разменная монета. Flutter доказал что как продукт имеет очень существенный преимущества перед конкурентами. И если статья не убеждает в этом, то есть не-Васи, непредвзятые бэкенд разработчики (Phoenix_free), которым зашло.
Другой минус(ы), очень субъективный, который лично мне сложно выразить словами.
Почему, например, Xamarin так и не подвез Catalyst для Mac? Почему с покупкой Xamarin майкрософтом они все больше превращают ex-Xamarin Studio в IDE для работы с .Net Core, чем собственно с Xamarin? Я уже не говорю о том, что Xamarin.Forms за последние несколько лет превратился собственно в синоним Xamarin. Хотя, тут ответ наверное очевиден. Майкрософт всегда был бизнесом, ориентированным на корпоративный сегмент. Я хочу делать красивый UI и удобные приложения а не формочки для страховой компании.
Как минус Xamarin можно также занести отсутствие Hot Reload/Restart. Вроде как они что-то похожее сделали, но это работает только в Forms и даже (поправьте если ошибаюсь) только с iOS… В общем, так же как во Flutter у них не получится сделать просто потому что бессмысленно, все равно в итоге все упирается в нативный UI.
apps.apple.com/US/app/id336698281?mt=8
play.google.com/store/apps/details?id=com.move.realtor&hl=en_US
Eсли мы говорим про мобильную разработку, Flutter не скрывает от тебя нативные инструменты разработки. Приложение строится благодаря Xcode и gradle а не msbuild. По сути это и есть нативное приложение просто с одним activity/controller и canvas внутри. Xamarin имеет привычку все скрыть и завернуть в фантик от майкософт, что с одной стороны помогает абстрагироваться от платформ, но с другой причиняет боль если ты хочешь выйти чуть дальше этой песочницы.
Я в основном писал на Xamarin.Native/Classic и с Forms у меня был опыт печальный и очень давно, поэтому как сейчас в Forms дела обстоят я не знаю, но при переходе на Flutter я впервые ощутил, что UI для iOS и Android оказывается можно писать единый. Это наверное главный wow эффект. Это действительно pixel perfect решение и теперь я не знаю как можно вернуться к Xamarin после этого :)
HotReload/Restart вещь. Я знаю что в Forms вроде тоже реализовали это но имплементация точно будет хуже, просто потому что в конечном счете рендер UI в Xamarin ложится на каждую из платформ отдельно и такого функционала просто нет у них (не считая SwiftUI, но в Xamarin это пока не работает)
Everything is widget концепт действительно подкупает. Padding это тоже виджет, например. И это действительно так если ты смотришь на это с точки зрения рэндера дерева виджетов. Вообще все эти концепты widget/element tree, stateless и statefull виджетов, вся эта «реактивность» из коробки подкупают и не позволяют мыслить по другому после этого.
Есть и свои минусы/странности конечно. Например ты не можешь просто взять и узнать размер элемента перед построением всего дерева элементов. Фреймворк просто не работает так. Работа с зависимостями в пакетах (NuGet аналог) тоже далека от идеала. В Xamarin/.NET это реализовано стабильнее, чтоли. Dart и DartVM тоже далеки от идеала. С# как язык на порядок превосходит Dart, по моему мнению. Хотя некоторые концепты очень хорошо вписываются во Frontend разработку. Например в DartVM есть такой концепт как isolate. Каждый isolate это один main thread, побочные IO «трэды», которые дают тебе асинхронность и своя изолированная куча. Все. В этой песочнице ты и работаешь. Нужно что-то параллельно сделать, можно создать другой isolate и общаться с ним посредством сообщений но у меня такой необходимости пока не возникало да и на вряд ли возникнет.
PS: сейчас я разрабатываю одно приложение на Flutter с очень продвинутой анимацией и честно, я просто не был бы в состоянии сделать что-то подобное на Xamarin в каких-то приемлемых сроках. Нативно, скорее всего да если ты супер спец сразу на 2 платформы. На Xamarin.Forms, очень сомневаюсь, возможно если ты используешь SkiaSharp и то не факт. В общем, c Flutter моя продуктивность возросла.
То что доктор прописал, спасибо
Я не эксперт, но мне кажется что прикрутить Mac OS как минимум возможно.
Спасибо за перевод, всегда интересно прочитать что-то новое.
Но я до сих пор не понимаю, чем корутины в Kotlin/Go концептуально отличаются от async/await/Tasks/TPL/etc, короче от асинхроно/параллельного программирования в C#? Это преподносится как нечто совершенно новое, но, каюсь, я все не могу уловить суть. Может ли кто пояснить как корутины должны реализовываться в C#?
iOS, Android, Windows, Mac OS, Linux, даже никому не нужные Windows Phone и Tizen.
Я не удивлюсь если в течении полугода они принесут Forms в браузеры через WebAssembly (a.k.a реинкарнация SilverLight)