Абсолютно пустая статья, нет сравнения даже с прямыми конкурентами.
Плюсы:
производительность приложений наравне с нативными решениями;
прямо наравне?
снижение затрат на исправление багов и добавление новой функциональности
Каким образом снижаются затраты на исправление багов? Flutter приносит много своих багов, которые решить даже не получится самостоятельно, необходимо ждать исправления от разработчиков.
Жирный минус в том, что ты пишешь реально на 3-х языках: Dart, Java, Swift, потому как одним Dart не обойтись и надо лезть в натив. В Xamarin сделано удобнее, ты используешь нативные SDK, но использую C#, так код не сваливается в кашу разных языков
Мы столкнулись с проблемой производительности, а также с тем, что работники не хотят выходить на работу в офис. С производительностью проблема была очень проста: люди не хотели лишний раз писать и связываться с командой, когда не понимали тонкостей, а делали, как считали нужным. В большинстве таких случаев это была ошибка. Ни у кого не было хорошего рабочего места, чтобы их не отвлекали домочадцы. И в целом график работы размазывался перекусами и т.д.
Плюс многие договорились на работу по удаленке с другими компаниями и поставили перед фактом ухода, на карантине это очень больно.
И macOS не бесит пользователя, а Windows, например когда начинает хлопотать по хозяйству — бесит.
Очень и очень субъективно. Меня бесит в разы больше и зависаний заметно больше, но опять же это мои субъективные ощущения.
По клавиатуре-бабочке есть статистика ремонтных центров — да, отказов клавиатуры стало больше в разы, но основной причиной ремонта она так и не стала, а вероятность попасть в ремонт у Мака постоянно минимальна, даже когда отпаивается экологически прекрасный припой. Проблемы есть, но раздуты СМИ в сотни раз, на практике — проблем нет.
На практике 6 ноутбуков: 4 с бабочками, 2 с ножницами. Все четыре с бабочками с проблемой нажатия, да нажать можно, но с определенным усилием, иногда дублирование идет. Покупались ноутбуки с бабочками за неимением выбора в свое время. Это за 2-3 года эксплуатации.
Я ясно писал — поддерживает 4 платформы из одного (1) кода. Не с переиспользованием бизнес логики, а из ОДНОГО. Было обещано в .NET 5, теперь обещано в .NET 6. А тот же Flutter — flutter run и оно само спросит где.
Хорошо, сейчас у вас есть 5 проектов, 4-ре из которых вам заглядывать надо только с одной целью поправить настройки названия проекта и версию, а в пятой весь UI и логика. Чем отличается от папок flutter с нативым кодом платформы?
А я что, не пишу про Lens что зацепилась в коммерческом секторе? Хотите понять какой провал — пересмотрите Build где её восхваляли. А ARKit как раз про то — рот Микрософту и Гугол заткнуть, заявленные ими задачи решить, но не как маркетологи врали, а на сколько на данный момент возможно.
Смотрю все презентации и все обязательно восхваляют свои продукты и конечно же рынок будет порван и т.д. и т.п. Так поступают все и Apple, Microsoft, Google не исключения.
3000 баксов за очки простой пользователь никогда не заплатит. Это дело будущего, в частности уменьшения размера устройства, утомляемости оператора и цены.
А ARKit — это игрушка. Да, прикольные игры, да красивая визуализация, но в комерческом секторе, где нужны HoloLens, там нужно смотреть своими глазами, а не через рамки устройства.
Где я говорю, что Xamarin это плохо? Это у Вас оговорочка по Фрейду — сами знаете, что не без проблем. Не будет MAUI в .NET 6 — Микрософт это переживёт, не будет в .NET 8 — уже вопрос.
Не без проблем любая кроссплатформенная среда, да и в целом разработка.
В остальном — многократно пытались привести в порядок Windows — неудачно, пытались найти замену — неудачно (а у Эппл такой проблемы нет)
Вы так говорите как будто MacOS беспроблемная. Давно ли MacOS научилась хотя бы быстро загружаться? А чистить мусор, который накапливается в системе и без стороннего ПО не удалить? А если Macbook расценивать в целом, то придумали клавиатуру бабочку, поняли что отстой и вернули. Сделали непонятную сенсорную панель над клавиатурой. Беспроводную зарядку не осилили. Не смогли даже построить собственное облако, всю информацию с Cloud хранили раньше в Azure и AWS, а сейчас S3 и Google Cloud Platform.
У Xamarin и не надо выигрывать, Xamarin приложение для всех четырёх основных платформ из одного кода пока не обеспечивает
Поддерживает спокойно Windows, MacOS, Android, iOS. Четыре основные платформы и уже давным давно.
пытались устроить революцию с Holo Lens, но Эппл выпустила ARKit. Тут Микрософт с Lens и Гугол с проектом Tango тупо заткнулись и стали делать вид что ничего не было
HoloLens используется в коммерческом секторе и довольно активно строительство, архитектура, научные разработки, проектирование. Только с армией США контракт на 22 млрд долларов. О каком провале идет речь? Кто-то добился большего? ARKit — вообще не про то.
Flutter, конечно, не панацея, но 200000 приложений на нём, если правильно I/O помню, в магазине. В том числе Flutter пользуют солидные люди, или просто, или клиентам натив, они по-лучше любят, а сотрудникам — Flutter. А это удар по Микрософт в самое сердце, в корпоративные связи. Капля точит…
Не знаю сколько приложений на Xamarin, но им пользуется 1.4 миллиона разработчиков. Согласитесь не мало. В основном его использовали в enterprise разработке, а такие клиенты не бегают по технологиям.
Странно говорить, что у Microsoft ничего не получается, когда их продукты очень даже развиваются, что подтверждается прибылью по всем направлениям. Surface можно не считать, они сами говорят, что основная цель их - показать для других вендоров, как надо.
Не понимаю пессимизма по поводу VS 2022. Оно ещё не вышло даже, с чего считать, что будет плохо?
Xamarin был куплен в 16 году и с тех пор стал бесплатным и сделал довольно большой скачок. Kivy уж точно не выигрывает у Xamarin. Xamarin Forms тоже работает, но с нюансами. На native ещё больше проектов, там и жаловаться не на что, производительность не отличается от написанных на java и swift.
Да, такая разработка нужна не всем, она не заменит нативную, но и flutter не панацея и на нем глючные прилки пишут, да и рынок не отжала.
Аналогия с Windows X не совсем уместна, да и работа не пропадет над ней даром, оптимизации перекочуют в основную. MAUI может запускают и долго, но есть объективные причины на это. Честно говоря не помню, чтобы они обещали его в NET 5, вроде была информация про то, что в NET 5 начнутся подготовительные работы по переходу, но не могу это утверждать на 100%.
У нас немного необычный кейс, наверное, для текущих реалий blazor'a. Дело в том, что нам необходимо SEO и еще важна скорость рендера первой страницы. Рендер сервера выполняется шустро, тут все супер, далее 4-5 секунд на инициализацию нам не критичны. Сейчас добиваем механизм восстановления состояния (чтобы это было универсально без дополнительного кода), смотрится довольно перспективно. Лоадеры убирать не очень хочется, все-таки пользователь должен видеть, что что-то происходит.
Где-то на github в одном из обсуждений натыкался на сообщение, что они собираются решить проблему повторной инициализации компонентов в NET Core 6.0.
Интересная у Вас идея, о таком подходе мы даже и не думали.
Сейчас тоже экспериментируем с серверным пререндером. Очень растроились, что решение из коробки делает рендер, но далее заново идет инициализация всех компонентов из-за чего для нас полностью пропадает смысл данного подхода, т.к. у нас идут сразу запросы к api и появляется loader. Сейчас думаем в сторону сохранения json текущего состояния при рендере на сервере.
Мы у себя приняли разделение компонента на два файла — верстку (razor) и код (отдельный c# файл partial). В самом razor у нас остается только конструкции if, foreach и т.д.
Я лично не в курсе, как было сделано в VB, поэтому не могу ничего по этому поводу сказать.
Не забывайте одного, мир на MS не заканчивается. Будьте открыты к новому, думайте своей головой, не бойтесь пробовать.
Можете применить Ваш же совет и открыться для Blazor. Успешно используем Blazor уже сейчас и экономим время на разработке SPA приложений. Скорость получается выше чем на React, код легче читать и понимать для новичков. Это не панацея и не всегда он будет подходить, но в целом продукт отличный, а если осуществлят планы, которые освещали, то будет очень-очень круто. Нужен конкурент Javascript'у.
Что-то с Grid сравнение неправильное. Или я неправильно смысл понимаю. Grid используются в большинстве для компоновки элементов, аналог table в html, с возможностью объединения ячеек. Как это сделать во флаттер?
По статье не увидел каких-либо преимуществ перед xamarin forms, особенно в плане шаблонов.
В xamarin listview уже использовать не стоит, есть более новый и более производительный collectionview.
А какой аналог во flutter relativelayout, absolutelayout, flexlayout?
Какой аналог модальных окон?
Да, раньше списки были действительно проблемой, но с появлением CollectionView списки шустрые и лагов не замечал. (Не успел протестировать на действительно сложных списках, но простые или 1 колонкой работают плавно даже с быстрой прокруткой).
А вот с более медленным стартом приложения придется мириться, но тут у всего кроме натива будут проблемы. Xamarin Forms мы используем в основном для внутренних приложений, там где это будет не так критично. Например, внутренний документооборот, управление складами, курьерские приложения.
Если бездумно пользоваться инструментом, то конечно.
Не вижу причин по которым эти инструменты не подходят, ни в одном приложении не было проблем. Зато к гибкости и скорости разработки жирный плюс.
Попробуйте отобразить список из 500 элементов хотя бы, чтобы не было тормозов при скроллинге, а теперь 1000, несколько тысяч. А теперь множество горизонтальных списков на одном экране, так чтобы каждый из них переиспользовал элементы друг друга (как сделано в гугл плей). Да, вы можете применить ту же технологию, что и в нативе (переиспользование элементов списка, но я думаю это уже довольно сложная задача и не факт, что будет значительно лучше).
Пример с картами — это как раз та ниша, где phoneGap уместен.
Для каждого инструмента своя ниша. Для приложения где оптимизация не важна эта технология вполне подходит, но для серьезного проекта есть куда лучшие варианты (Натив, Xamarin, Flutter, React Native).
Извиняюсь, что пишу про тормоза, но просто это решающий момент, почему разработчикам все еще приходится писать нативно.
Если вы хотите разрабатывать для iOS, то на любом инструменте вам понадобится Mac для сборки (либо облачные сервисы для сборки), iPhone не обязателен. Хотя те же пуши без iPhone не оттестишь, на симулятор они не приходят. Если вы хотите разрабатывать под iOS как-то несерьезно не иметь Mac и iPhone.
А я вот не увидел особо преимуществ перед Xamarin.
На стороне Xamarin огромное количество библиотек, как минимум. Найдите достойные аналоги для того же Autofac, Automapper.
При использовании Native подхода, мы можем оптимизировать рендеринг по-максимуму, не теряя ни капли производительности в сравнении с Java или iOS, причем 100% знаем как это работает, с flutter такое не пройдет.
Изучая SDK Android и iOS мы будем это реально использовать в Xamarin приложениях, соответственно переход от Xamarin на swift, java, kotlin — не проблема, как и обратный подход.
Что плохо — это визуальное накидывание интерфейса на iOS, но мы его и не используем, в команде сториборды — это ад, мы создаем интерфейс программно.
Прототип на Xamarin Forms написать намного быстрее и проще, все-таки XAML — это мощь.
Производительность Xamarin Forms на списках, за что его много хейтили, стала намного лучше сейчас, когда добавили CollectionView и наши клиенты не замечают разницы c приложениями на iOS и Java.
Плюс идет развитие Blazor, значит и SPA приложения можно будет писать на C#. Blazor мы уже опробовали, есть проблемы с производительностью, но мы были вполне довольны используя его для админок.
Плюсы:
прямо наравне?
Каким образом снижаются затраты на исправление багов? Flutter приносит много своих багов, которые решить даже не получится самостоятельно, необходимо ждать исправления от разработчиков.
Жирный минус в том, что ты пишешь реально на 3-х языках: Dart, Java, Swift, потому как одним Dart не обойтись и надо лезть в натив. В Xamarin сделано удобнее, ты используешь нативные SDK, но использую C#, так код не сваливается в кашу разных языков
Мы столкнулись с проблемой производительности, а также с тем, что работники не хотят выходить на работу в офис. С производительностью проблема была очень проста: люди не хотели лишний раз писать и связываться с командой, когда не понимали тонкостей, а делали, как считали нужным. В большинстве таких случаев это была ошибка. Ни у кого не было хорошего рабочего места, чтобы их не отвлекали домочадцы. И в целом график работы размазывался перекусами и т.д.
Плюс многие договорились на работу по удаленке с другими компаниями и поставили перед фактом ухода, на карантине это очень больно.
Очень и очень субъективно. Меня бесит в разы больше и зависаний заметно больше, но опять же это мои субъективные ощущения.
На практике 6 ноутбуков: 4 с бабочками, 2 с ножницами. Все четыре с бабочками с проблемой нажатия, да нажать можно, но с определенным усилием, иногда дублирование идет. Покупались ноутбуки с бабочками за неимением выбора в свое время. Это за 2-3 года эксплуатации.
Хорошо, сейчас у вас есть 5 проектов, 4-ре из которых вам заглядывать надо только с одной целью поправить настройки названия проекта и версию, а в пятой весь UI и логика. Чем отличается от папок flutter с нативым кодом платформы?
Смотрю все презентации и все обязательно восхваляют свои продукты и конечно же рынок будет порван и т.д. и т.п. Так поступают все и Apple, Microsoft, Google не исключения.
3000 баксов за очки простой пользователь никогда не заплатит. Это дело будущего, в частности уменьшения размера устройства, утомляемости оператора и цены.
А ARKit — это игрушка. Да, прикольные игры, да красивая визуализация, но в комерческом секторе, где нужны HoloLens, там нужно смотреть своими глазами, а не через рамки устройства.
Не без проблем любая кроссплатформенная среда, да и в целом разработка.
Вы так говорите как будто MacOS беспроблемная. Давно ли MacOS научилась хотя бы быстро загружаться? А чистить мусор, который накапливается в системе и без стороннего ПО не удалить? А если Macbook расценивать в целом, то придумали клавиатуру бабочку, поняли что отстой и вернули. Сделали непонятную сенсорную панель над клавиатурой. Беспроводную зарядку не осилили. Не смогли даже построить собственное облако, всю информацию с Cloud хранили раньше в Azure и AWS, а сейчас S3 и Google Cloud Platform.
Поддерживает спокойно Windows, MacOS, Android, iOS. Четыре основные платформы и уже давным давно.
HoloLens используется в коммерческом секторе и довольно активно строительство, архитектура, научные разработки, проектирование. Только с армией США контракт на 22 млрд долларов. О каком провале идет речь? Кто-то добился большего? ARKit — вообще не про то.
Не знаю сколько приложений на Xamarin, но им пользуется 1.4 миллиона разработчиков. Согласитесь не мало. В основном его использовали в enterprise разработке, а такие клиенты не бегают по технологиям.
Странно говорить, что у Microsoft ничего не получается, когда их продукты очень даже развиваются, что подтверждается прибылью по всем направлениям. Surface можно не считать, они сами говорят, что основная цель их - показать для других вендоров, как надо.
Не понимаю пессимизма по поводу VS 2022. Оно ещё не вышло даже, с чего считать, что будет плохо?
Xamarin был куплен в 16 году и с тех пор стал бесплатным и сделал довольно большой скачок. Kivy уж точно не выигрывает у Xamarin. Xamarin Forms тоже работает, но с нюансами. На native ещё больше проектов, там и жаловаться не на что, производительность не отличается от написанных на java и swift.
Да, такая разработка нужна не всем, она не заменит нативную, но и flutter не панацея и на нем глючные прилки пишут, да и рынок не отжала.
Аналогия с Windows X не совсем уместна, да и работа не пропадет над ней даром, оптимизации перекочуют в основную. MAUI может запускают и долго, но есть объективные причины на это. Честно говоря не помню, чтобы они обещали его в NET 5, вроде была информация про то, что в NET 5 начнутся подготовительные работы по переходу, но не могу это утверждать на 100%.
Xamarin.Native развивается и развивался всегда, его никогда и не бросали, он живой и никуда не денется, просто он не нужен для всех.
Xamarin Forms тоже вполне себе используется, а его наследник maui выглядит очень многообещающе.
По специфики работаем с приложениями с большим объемом бизнес логики и это настоящее спасение.
А когда он умирал? Вы наверное про xamarin forms имели ввиду. Да и тот новую жизнь сейчас обретает с maui.
Где-то на github в одном из обсуждений натыкался на сообщение, что они собираются решить проблему повторной инициализации компонентов в NET Core 6.0.
Сейчас тоже экспериментируем с серверным пререндером. Очень растроились, что решение из коробки делает рендер, но далее заново идет инициализация всех компонентов из-за чего для нас полностью пропадает смысл данного подхода, т.к. у нас идут сразу запросы к api и появляется loader. Сейчас думаем в сторону сохранения json текущего состояния при рендере на сервере.
Я лично не в курсе, как было сделано в VB, поэтому не могу ничего по этому поводу сказать.
Можете применить Ваш же совет и открыться для Blazor. Успешно используем Blazor уже сейчас и экономим время на разработке SPA приложений. Скорость получается выше чем на React, код легче читать и понимать для новичков. Это не панацея и не всегда он будет подходить, но в целом продукт отличный, а если осуществлят планы, которые освещали, то будет очень-очень круто. Нужен конкурент Javascript'у.
Что-то с Grid сравнение неправильное. Или я неправильно смысл понимаю. Grid используются в большинстве для компоновки элементов, аналог table в html, с возможностью объединения ячеек. Как это сделать во флаттер?
По статье не увидел каких-либо преимуществ перед xamarin forms, особенно в плане шаблонов.
В xamarin listview уже использовать не стоит, есть более новый и более производительный collectionview.
А какой аналог во flutter relativelayout, absolutelayout, flexlayout?
Какой аналог модальных окон?
А вот с более медленным стартом приложения придется мириться, но тут у всего кроме натива будут проблемы. Xamarin Forms мы используем в основном для внутренних приложений, там где это будет не так критично. Например, внутренний документооборот, управление складами, курьерские приложения.
Не вижу причин по которым эти инструменты не подходят, ни в одном приложении не было проблем. Зато к гибкости и скорости разработки жирный плюс.
Пример с картами — это как раз та ниша, где phoneGap уместен.
Для каждого инструмента своя ниша. Для приложения где оптимизация не важна эта технология вполне подходит, но для серьезного проекта есть куда лучшие варианты (Натив, Xamarin, Flutter, React Native).
Извиняюсь, что пишу про тормоза, но просто это решающий момент, почему разработчикам все еще приходится писать нативно.
На стороне Xamarin огромное количество библиотек, как минимум. Найдите достойные аналоги для того же Autofac, Automapper.
При использовании Native подхода, мы можем оптимизировать рендеринг по-максимуму, не теряя ни капли производительности в сравнении с Java или iOS, причем 100% знаем как это работает, с flutter такое не пройдет.
Изучая SDK Android и iOS мы будем это реально использовать в Xamarin приложениях, соответственно переход от Xamarin на swift, java, kotlin — не проблема, как и обратный подход.
Что плохо — это визуальное накидывание интерфейса на iOS, но мы его и не используем, в команде сториборды — это ад, мы создаем интерфейс программно.
Прототип на Xamarin Forms написать намного быстрее и проще, все-таки XAML — это мощь.
Производительность Xamarin Forms на списках, за что его много хейтили, стала намного лучше сейчас, когда добавили CollectionView и наши клиенты не замечают разницы c приложениями на iOS и Java.
Плюс идет развитие Blazor, значит и SPA приложения можно будет писать на C#. Blazor мы уже опробовали, есть проблемы с производительностью, но мы были вполне довольны используя его для админок.