Комментарии 89
Uno выглядит неплохо для разработки на линукс. Хотя для линукса легче уж GTK или Qt использовать
Все эти чудо технологии надо сравнивать с Delphi7 что бы стыдно было.
Разрабатывал на обоих и уверенно могу сказать, что WinForm сломает об колено Delphi 7.
WinForms годов Delphi7 - не сломает Delphi7 и близко. А WinForms современный даже не дотянется до современного Delphi
.NET Framework 1.0 появился на свет за несколько месяцев до выхода Delphi 7, конечно, по тем временам Delphi уже был колоссом.
Но уже через год Borland втащила .NET Framework в Delphi 8, и дальше в этой среде разработки пошёл какой-то кавардак...
Дальше от дотнета отказались и больше он не использовался. Хотя, в самой среде рудименты дотнета остались.
Тем не менее, vcl все это время развивается, а win forms нет.
Конечно, vcl и win forms давно не популярные в области создания оконных приложений решения, но Делфи развивает и другой фреймворк, но ближе к Avalonia, нежели к wpf.
Да, там потом и от CLX отказались. И VCL то закапывали, то откапывали. Потому так и любят многие стабильный Delphi 7.
Может VCL и развивается, в отличие от winforms, но минус в том, что за VCL надо платить (если не учитывать пробную лицензию на год с ограничениями).
VCL никогда не закапывали, Kilyx был альтернативным проектом, как и версия с .Net. На Delphi 7 сейчас только те, кто не может перевести свой проект на современные версии из-за отсутствия современных версий сторонних пакетов. Все остальные давно использую среду разработки не ниже XE7, а подавляющее большинство использует среды версий от 2018 года и выше. Например, в нашей компании есть и Delphi7 и проект, который не можем просто так перевести. И самая последняя версия Delphi 12 (2024 года) с кучей других проектов посвежее или совсем новых.
Платить нужно за все. Если проект создается для коммерческой разработки. VS тоже не бесплатная среда разработки. А для Delphi и среды разработки RAD Studio, как и для VS существует бесплатная Community версия. Для не коммерческих разработок или с ограниченным доходом.
Я не писал, что многие используют Delphi 7, я написал любят. Ностальгически, и я в их числе.
VCL закопали с приходом Delphi 8, откопали в Delphi 2005.
Для winforms можно использовать не только Visual Studio, но и бесплатные среды, и VSCode, Mono Develop, Sharp Develop, да хоть в блокноте писать без редактора, в winforms это не проблема. А потом собрать через csc.exe. Можно ли для VCL писать хоть на чём-то кроме коммерческого Delphi?
Можно писать на чем угодно, хоть дотнет приложения создавать через блокнот (есть штатный пример создания WPF), однако, компилятор тебе никто не даст бесплатно для коммерческой разработки.
.net sdk идет с компилятором, без требований и ограничений (только на распространение самих компиляторов но не на итоговые продукты, я про версии до 4-ой, которые идут в поставке с ОС), в т.ч. все то же самое и на другие продукты тиа windows scripting host (интерпретатор скриптов javascript/vbscript) или к примеру подсистема скриптов в офисных продуктах.
НО! если ваш код использует библиотеки майкрософта, то на ИХ распространение у вас может не быть прав (отличный пример, не про .net, с нативными приложениями - vcredist, вы можете дать ссылку на скачивание но не держать копию установщика, не получив на это разрешение у компании)
однако, компилятор тебе никто не даст бесплатно для коммерческой разработки
компилятор, рантайм, система сборки и сами UI-фреймворки/SDK у них вообще опенсорсные под MIT-лицензией, разрешающей коммерческую разработку.
Если помните, то многие сторонние конторы, которые делали компоненты для Delphi очень быстро начали переносить их на WinForm и потом именно эта версия становилась флагманской, а VCL стал догоняющим. И это довольно показательно. Самый яркий пример это DevExpress, делавший (и вроде продолжает) прекрасные гриды.
Он их делает и для VCL до сих пор и для него Delphi фреймворка FMX. Помимо DevExpress компоненты делает контора TMS, для обеих фреймворков. Так что нет, WinForms не является основным приоритетом конторы и стабильно пилит для VCL. При чем, по возможностям контролов для VCL и WinForms можно поспорить. Т.к. VCL гибче WinForms.
helloworld приложение:
Delphi 7: ~380 KB, только windows
WinForms .NET Framework 4.0: ~9 KB, windows, а так же linux/MacOS через mono
Не совсем честно сравнивать Winforms, когда у тебя рантайм на 200мб, но не в приложении. Сначала запаковать нужно, чтоб не было зависимостей. В Delphi их нет
Если бы в приложении, собранном Delphi7, не было зависимостей, то оно было бы кроссплатформенным. К сожалению, его бинарник импортирует ряд системных DLL и функций Windows API. Так что там тоже есть свой "рантайм", на который он жёстко завязан (по крайней мере VCL приложения).
Тащить локально зависимости принято у современного ".NET".
Что касается .NET Framework, то он входит в состав Windows ещё с семёрки, так что, можно сказать, тоже является частью ОС, равно как и win api, которые использует бинарник Delphi7.
Может я и ошибаюсь, но мне кажется сравнение вполне честным.
В делфи весь рантайм скомпилирован в бинарник. Естественно есть связь с winapi для создания окна (в vcl и для создания контролов). Цикл обработки сообщений является частью рантайма Делфи.
Win forms "приложение" без статической линковки по сути представляет из себя бинарный (но, не машинный) код класса юзерского решения.
В то время, как Делфи представляет из себя чистый машинный код. То, что дотнет поставляется с ОС это конечно здорово, но ведь ты не будешь сравнивать jar файл с "ехе" от дотнета, если java будет поставляться с ОС. Не говоря уже о том, что для работы дотнет приложения нужна конкретная версия этого дотнета. И почти все установщики приложений на дотнете устанавливают и дотнет нужной версии.
У меня критерий простой: устанавливаем голую винду (только не самую древнюю, которая уже не поддерживается), затем берём бинарник, собранный Delphi7, запускаем. Запускается? Да! Отлично. Теперь берём exe сборку под .NET Framework 4.x, запускаем. Запускается? Да! Без установки дополнительных пакетов, сред исполнения и прочего. Почему нечестно сравнивать такие приложения?
А тот факт, что в exe файле находится MSIL код, а не машинный - так это имеет свои преимущества - среда скомпилирует из него оптимальный машинный код под данную платформу, а затем запустит.
Запускается? Нет. Потому что проект был собран под .net 2.x, .net 3.x, .net 5.x, а в системе стоит из коробки .net 4.x. При этом, проект на Delphi7 запустится как на WinXP, Vista, Win7, Win8, Win10, Win11 и скорее всего на последующих версиях Windows на +10-20 лет вперед. Без пересборки. И без нужды ставить дополнительный рантайм.
А приложения, собранные на Delphi 1, Delphi 2,... Delphi 8 запустятся на современной системе из коробки? Всё-таки, темой обсуждения было сравнение приложений на .NET 4.x версии и Delphi 7 версии.
представляет из себя бинарный (но, не машинный)
дотнет уже давно умеет Native AOT
Ущипните меня, в 2024-ом году мы обсуждаем Delphi7?
Будущее за Linux. Начинать в 2024 проект который будет работать только под Windows - бесперспективно.
Дельфи и Winforms были хороши для своего времени. Мввм паттерн и биндинги там не поддерживаются. Поэтому не стоит их использовать даже для обучения или как первый проект. Научитесь плохому)
Ещё один красный флаг - технологии от Майкрософт. Они каждый год являют миру новый UI фреймворк. Забросят этот маюай прежде чем вы проект закончите.
Моя рекомендация - только Авалония
Пока в линукс-подобных системах не доведут процесс установки ПО до схемы "установка двумя кликами по одному файлу" (утрирую, понятное дело), за будущее Windows как ведущей ОС можно не волноваться. А пока даже в самой дружественной Ubuntu процесс установки deb-пакетов - это рулетка, с высокой вероятностью ведущая в терминал)
Ну, установка пакета из deb файла по факту мало чем отличается от установщик на винде. Про apt молчу, да, надо команду прописать, но уже и гуишка есть, по сути то от Microsoft store мало чем отличается, только вот MSStore почему-то не особо использую.
По поводу дороги в терминал в некоторых случаях: да, бывает, что зависимости не встают, бывает конфликт версий, да, решать через терминал зачастую. НО! Решить можно, в отличии от вины, в которой бывает, что dllка куда ни будь пропадёт. А на моем компе у меня почему то сломалась установка и удаление через msi. То есть я физически не могу поставить нужные мне программы, которые только так поставляются. А уж поверьте, раз я на линуксе сижу половину времени, некоторый опыт в гуглинге и решении проблем с компом имею. Так что этот косяк обоих систем касается
И да, я молчу о самом главном косяке винды - кодироооовки, мне кажется хоть раз в жизни(кроме случаев, когда заранее предупредили), называл пользователя кириллицей, а потом узнавал, что винду надо к чертям сносить, ибо переименовать то можно, но вот с системными папками сложнее
Проблема инсталлеров Линукс конечно есть, но ее научились решать. Сходу можно провести примеры: установщик Steam, установщик Cura. Вполне дружелюбные. Многочисленные пользователи их осилили.
Дельфи и Winforms были хороши для своего времени. Мввм паттерн и биндинги там не поддерживаются.
Да ладно.
this.data = new DataSourceForButton() { StringData = "Lol" };
button1.DataBindings.Add(new Binding("Text", this.data, "StringData", true, DataSourceUpdateMode.OnPropertyChanged));
button1.DataContext = this.data;Привязки к view model в коде выглядят громоздко. Попробуйте то же самое написать на xaml платформах. Получится гораздо элегантнее. Не стоит откапывать winforms, оставьте его в покое )
Годами использовал биндинги в WinForms, а его нет, оказывается :) Работал он не идеально, но работал. Проблема у WinForms была в другом - он на каждый элемент управления создавал окно Windows, из-за чего сложные формы тормозили. Интереса ради как-то сделал форму с большим количеством полей ввода на WinForms и такую же на HTML - HTML-форма в Google Chrome работала гораздо быстрее WinForms.
В-общем, если не нужны изыски отрисовки, то даже "голый" WinForms без специальных стилизованных элементов управления способен решать многие задачи (кроме разве что табличного ввода - он без доработки напильником не работал).
Разве в WinForms каждый контрол - это полноценное окно? Со своим контекстом отрисовки и очередью сообщений? Сомнительно как-то... Потому что получается, что можно создать контрол без пэрента.
В win32 это так было изначально, каждый элемент окна (кнопки, списки,.. - это объект окна HWND (точнее это его хандлер), и работает это очень быстро.
А вот WinForms тормозили по другим причинам, они отвратительно работали с графикой, это прекрасно было видно на слабых машинах без видеоускорителя, не говоря о том что при отрисовке совершается много лишних операций (типа перерисовка) и это почти не решается двойным буфером.
Но если сравнивать с любым другим фреймворком (речь о .net), это образец скорости и эффективности.
p.s. формально, лучший фреймворк по скорости и функционалу - это QT, и на сколько я знаю были попытки интегрировать его в .net, вот бы сравнить производительность, только делать это нужно на самых слабых машинах из возможных.
Прошу прощения, но разрабатывал на C под Win3.1 и там, пу сути, каждый элемент на экране, это окно со своим хендлером. Утилиты, типа spy могли прочитать, скажем, текст из тестового поля окна. И чтобы читать пароли из любого открытого приложения в системе, надо было только найти его хендлер.
UPDATE: Увидел, что вам написали про hwnd
В Delphi изначально MVP, и никто не запрещает реализовать MVVM. И да, биндинги там тоже есть, даже в старом добром VCL. Визуально создаются, кстати. А кроссплатформенный FMX куда эффективнее Avalonia
А кроссплатформенный FMX куда эффективнее Avalonia
И в чем же он эффективнее?
Даже пока не берем во внимание требование писать на полумертвом и мало кому интересном языке с закрытым кодом, никакущим комьюнити и гвоздями приколоченному к одной единственной платной и проприеритарной windows-only ide с ценником свыше 4к евро, платным саппортом (Ж - жадность) и весьма сомнительной конкурентоспособности при этом (хотя имхо вышеперечисленного уже более чем достаточно чтобы даже не смотреть на какие то там возможности gui разработки было уже неинтересно)
Разработка на этом фреймворке гораздо быстрее, за счёт подхода к созданию интерфейсов (моя недавняя статья на Хабре), за счёт полноценного дизайнера, эффективнее за счёт кучи готовых кроссплатформенных решений для работы с камерой, всевозможными датчиками, BT/BLE, общим центром разрешений (прав), возможностью использовать разный графический бэкенд на каждой платформе (существует несколько в каждой), возможностью легко использовать платформенный код для конкретной платформы (winapi, jni, posix...), прямой доступ к другим устройствам. За счёт готовых инструментов публикации, сертификации из среды, прямой или удаленной отладки на всех платформах и т.д.
А со своим "во внимание" можно вообще было не писать. Этот язык далеко не мертвый, это лишь ваше заблуждение.
Разработка на этом фреймворке гораздо быстрее, за счёт подхода к созданию интерфейсов
А в авалонии у вас внезапно нет подхода к созданию интерфейсов?
за счёт полноценного дизайнера
полноценный дизайнер пригоден только для формошлепства в относительно простых хелловорлдах, в сложных интерфейсах основанных на паттернах вроде mvvm пользы от него все равно мало.
решений для работы с камерой, всевозможными датчиками, BT/BLE, общим центром разрешений (прав)
А какое отношение перечисленное имеет к UI-фреймворкам?
возможностью использовать разный графический бэкенд на каждой платформе
(существует несколько в каждой), возможностью легко использовать
платформенный код для конкретной платформы (winapi, jni, posix...)
И в чем эффективность то? Разработчику глубоко пофиг что там под капотом UI-фреймворка до тех пор пока он работает исправно. В авалонии к слову тоже есть варианты
прямой или удаленной отладки на всех платформах
IDE на линуксе даже не запустится, так что по этим параметрам уже позади планеты всей, остальное можно даже не обсуждать. Да и какое отношение перечисленное имеет к UI-фреймворкам?
В общем почти каждое ваше сообщение больше похоже на какие то мантры фанатика ничего не видящего за пределами своего мирка
полноценный дизайнер пригоден только для формошлепства в относительно простых хелловорлдах
Вы сильно заблуждаетесь, потому что не понимаете, о каких возможностях идёт речь. MVVM прекрасно используется с дизайнером с этим фреймворкам. Проект может легко состоять из кучи небольших фрагментов интерфейса, которые дизайнятся отдельно. А ваше представление ограничено тем, что вы считаете, что весь дизайн - это только окно формы и накидывание контролов, но это совершенно не так. Вы вероятно мало компетентны в данном вопросе и как раз именно ваш "мирок" этим ограничен. Как иу большинства тех, кто считает, что "только code only позволяет решать сложные задачи".
А какое отношение перечисленное имеет к UI-фреймворкам?
Такое, что FMX не только графический движок, как и авалония и имеет за собой кроссплатформенный рантайм код, для создания приложений решающих реальные задачи.
IDE на линуксе даже не запустится
Для того, чтобы разрабатывать под Линукс и отлаживать приложения, запущенные именно в Линукс нет необходимости ставить IDE на Линукс. Как и с любыми другими платформами.
Да, IDE не кроссплатформенная, только об этом ли сейчас речь? Нет, не об этом. Однако, среда разработки прекрасно работает, например, в MacOS в виртуальной машине и это регулярно используется разработчиками. VS тоже не является кроссплатформенной IDE, только "позади всех" её что-то не называют. Про обрубок в виде VS Code я промолчу.
какие то мантры фанатика
Так пишут все, кто не имеет аргументации в ответ.
Вы вероятно мало компетентны
не угадали, попробуйте еще раз
Такое, что FMX не только графический движок, как и авалония и имеет за
собой кроссплатформенный рантайм код, для создания приложений решающих
реальные задачи.
Еще раз, авалония это UI-фреймворк, никакого блютуса там нет, не должно быть и никогда не будет. Вы сначала сравниваете кислое с теплым и после этого еще выдаете какие то суждения про компетентность?
Для того, чтобы разрабатывать под Линукс и отлаживать приложения,
запущенные именно в Линукс нет необходимости ставить IDE на Линукс. Как и
с любыми другими платформами.
Конечно, и там где такое возможно это прекрасно, только это не случай с дельфи где вам в любом случае придется работать под виндой (особенно это прекрасно звучит когда винда не является целевой платформой разрабатываемого приложения), а альтернатива только костыли с виртуалками
Так пишут все, кто не имеет аргументации в ответ.
В ответ на что? Вы же ни одного аргумента за fmx против авалонии не привели, за уши притягиваете то блютус то удаленную отладку...
не угадали, попробуйте еще раз
Структура проекта FMX (Делфи в целом).
Файл 1. Файл проекта
Файл 2. Модуль класса формы
Файл 3. Код формы
MVVM решение: Код формы создается и редактируется дизайнером (View) и может иметь связь с модулем класса формы (VM), класс с данными пишем отдельно от всего этого (Model). Связь между VM и View может быть как событийная, так и через биндинги. Связь между (VM и Model) - тоже. Биндинги при этом для VM/View можно создавать дизайнером.
Итого получаем: мы дизайним любой сложности форму, контролы, представления (фреймы), биндим на VM и биндим VM к любой модели данных.
В ответ на что? Вы же ни одного аргумента за fmx против авалонии не привели, за уши притягиваете то блютус то удаленную отладку...
Вот о чем я: https://github.com/AvaloniaUI/Avalonia/discussions/10594
В то время, как FMX предоставляет работу из коробки с этим. Повторюсь ещё раз FMX - это не чисто графический фреймворк, это полноценный кроссплатформенный рантайм, который ускоряет разработку в разы.
это не чисто графический фреймворк
И вы при этом его в трезвом уме и здравой памяти сравниваете с чисто графическим фреймворком в областях за которые графические фреймворки не отвечают? И позиционируете отсутствие блютуса как недостаток графического фреймворка?
Вот о чем я: https://github.com/AvaloniaUI/Avalonia/discussions/10594
Можете пояснить какое отношение имеет блютус к UI-фреймворку. Вы вообще про принцип разделение ответственности слышали или в Delphi-мире по прежнему божественные объекты наше все?
это полноценный кроссплатформенный рантайм
.net это тоже полноценный кроссплатформенный рантайм
блютус? выбирайте наздоровье https://www.nuget.org/packages?q=bluetooth
Вы вообще про принцип разделение ответственности слышали или в Delphi-мире по прежнему божественные объекты наше все?
Это лишь ваши домыслы. Никто не говорит, что "графическая часть пришита к рантайму". Речь тут о том, что FMX имеет масштабный инструментарий, чтобы подобных "выше" проблем не было при разработке приложения. Нужен блютуз - используй, он будет в поставке штатно и работать на всех устройствах.
Вспомните топик "FMX эффективнее Avalonia", потому что не приходится решать подобные проблемы кроссплатформенности.
И сейчас именно вы пытаетесь мне доказать, что я не прав в этом высказывании, когда как использовали только Avalonia, но даже близко не пробовали FMX, а я использовал Avalonia и пробовал его возможности.
Пытаетесь доказать, что MVVM не может быть, когда у тебя дизайнер, хотя это совершенно не так (при чем WPF тоже имеет дизайнер и почему-то там MVVM реализуем. Глупо это не понимать).
И стоит помнить, что вы понятия не имеете, на что способен дизайнер в FMX и насколько сложные можно создавать интерфейсы (с/без MVVM подхода), если его изучить.
И сейчас именно вы пытаетесь мне доказать, что я не прав в этом высказывании
Ваше высказывание имеет примерно столько же смысла сколько например "jre эффективнее чем zlib"
Пытаетесь доказать, что MVVM не может быть, когда у тебя дизайнер,
Скорее наоборот, надобность в дизайнере отпадет. А в случаях когда без корректных данных представление воедино собрать проблематично так и вовсе трата времени. Но вы просто сложных интерфейсов не делали никогда, как доведется столкнуться, сами поймете.
Голословность. Мало того, что я создавал и создаю сложенные интерфейсы, так ещё вы не понимаете, что будь то MVVM или MVC, не имеет значения используешь ты дизайнер или пишешь интерфейс кодом. Дизайнер - это альтернатива создания интерфейса кодом.
Вот когда освоите FMX дизайнер тогда и поговорим о сложности интерфейсов. А сейчас это пустые слова.
так ещё вы не понимаете, что будь то MVVM или MVC, не имеет значения
используешь ты дизайнер или пишешь интерфейс кодом. Дизайнер - это
альтернатива создания интерфейса кодом.
Единственный человек который тут что то не понимает это вы.
При наличии и правильно реализованной дизайн системе wysiwyg подход вам ничего не даст, только замедлит разработку, тк просто не останется действий которые бы было проще и быстрее сделать в дизайнере. Но если вы по старинке там отступы между кнопками настраиваете то конечно для такого низкоквалифицированного и низкокачественного формошлепства это альтернатива. Собственно для чего их и делали. Про динамически генерируемые интерфейсы уже молчу
Этот язык далеко не мертвый, это лишь ваше заблуждение
Ну так найдите с десяток приличных вакансий где требуется Delphi и где бы это не было каким то лютым легаси, и сравните их количество с другими языками.
Ну или как вариант можно и с другой стороны - найдите десяток адекватных разработчиков имеющих большой опыт в данной сфере, и аналогично сравните с другими языками.
Так то если считать язык немертвым если на нем минимум один человек пишет то конечно..
Вы можете поискать и убедиться в этом сами. Ведь, в данном случае именно вы заблуждаетесь, а не я, т.к. именно я больше работают с проектами на Delphi и да, в разных компаниях и да НЕ ЛЕГАСИ проектами. Не говоря уже о том, что на FMX просто напросто нет легаси проектов, т.к. этому фреймворку менее 10 лет (а в качестве полноценно рабочего инструмента не более 5 лет).
Вакансий много, как на Делфи, так и на FMX. В том же СберБанке существует проект СберИнвестПро, работающий именно на FMX и он разработан в течении последних 2 лет. В компании где я работают (и ещё десяток разработчиков), создают новые решения на FMX, возрастом до 3 лет. Десятки и сотни разработчиков из других стран, с которыми я общаюсь в тематических чатах, тоже используют FMX для создания приложений и игр под разные устройства.
Так что нет, искать я это не буду, т.к. с моей стороны идет конфликт интересов. Нужна объективная оценка - ищите. Это не сложно. Недельный вебинар (сессия из 6 вебинаров) по Delphi, к слову прошёл на этой неделе.
Убедился, спасибо
Я не знаю как вы ищите. А с учетом, что вакансий на чисто Delphi в целом в 10 раз меньше, чем на C#, то в отношении внутри языков FMX популярнее, чем Avalonia внутри C#.
А с учетом, что вакансий на чисто Delphi в целом в 10 раз меньше, чем на C#
Ну вот это и значит что язык мертв
Вакансий на HH:
Delphi: 268 (-1) ~100k (35-250)
Pascal: 58 (-4) ~80k (32-230)
Python: 3786 (-61) ~80k (25-200)
C#: 2125 (-39) ~60k (25-275)
C++: 2591 (-51) ~100k (23-300)
Swift: 431 (-9) ~120k (15-300)
Java: 3351 (-79) ~70k (30-250)
Visual Basic: 84 (-2) ~100k (25-200)
Go: 1265 (-24) ~120k (40-350)
Ruby: 144 (-1) ~130k (15-400)
Kotlin: 1044 (-20) ~120k (40-300)
Rust: 118 (-5) ~150k (40-900)
Fortran: 4 (0) ~0k (0-0)
Dart: 129 (+1) ~150k (40-300)
Flutter: 250 (+2) ~110k (20-300)
FireMonkey: 3 (0) ~180k (100-300)
Electron: 52 (-2) ~148k (50-330)
Lazarus: 8 (0) ~80k (32-140)
React Native: 233 (-4) ~110k (40-250)
1С: 6346 (-120) ~60k (25-280)На Rust, Dart ещё меньше вакансий. А на 1С в 3 раза больше, чем на C#.
Простите, пришлось как-то отлаживать приложения на Delphi и это такое себе. Правда, это был 2007 год, но это реально было мучение.
Они каждый год являют миру новый UI фреймворк. Забросят этот маюай прежде чем вы проект закончите.
WinForms и WPF до сих пор поддерживаются и работают на современных системах, хотя им лет больше чем некоторым комментаторам здесь.
Эх, ещё QT не хватает. Было бы с чем кросс платформ сравнить
Ничего лучше tauri пока не нашел. Да не C# ваш. Но это мега крутой фреймворк.
Tsx + Rust.
Жирный плюс по сравнению с тем же Electron в том, что tauri переиспользует уже установленный webview в систему. на windows это edge, на mac это WebKit.. А electron каждый раз пихает в сборку .exe свой движок. За что размер приложения со старта 5 Мб на таури, и 180 Мб у электрона.
Всем советую Tauri!
Хорошии обзор, но имхо крестики-нолики слишком простой пример для сравнения фреймворков, фактически это 9 кнопок и все, это так или иначе по силам любому фреймворку. Вот какая-н таблица с сортировкой и, скажем, комбобоксами в ячейках, и привязанная к данным тысячи хотя бы на три строчек сразу отделяет мух от котлет и показывает с каким фреймворком можно работать, а какой упоминать можно разве что только ради шутки. Две трети сойдут с дистанции еще на этапе разработки. Но конечно такой пример 6 раз для статьи сделать может быть весьма трудоемко
Два примера хватит, один под формы, второй под mvvm, + немного подкрутить индивидуально
Тут уже больше зависит от библиотек, одно дело дефолтный грид, другое девэкспресс.
Наличие сторонних библиотек, степень их убогости и суммы которые за них хотят (и заплатив которые все равно придется потратить на пляски с бубном с воркараундами вокруг бесчисленных багов в них столько же времени сколько на написание собственных контролов) это тоже вполне себе важные критерии для оценки UI-фреймворка.
Было бы неплохо ещё оценить нагрузку в контейнерах, например списки, таблицы и т.п. Желательно около 1000 элементов в них и посмотреть нагрузки, память, скорость прокрутки, есть ли кэш или отложенная загрузка.
Мне к примеру нужен редактор с подсветкой синтаксиса. Есть ли в Avalonia или MAUI такое?
Как я понял, startup time измеряется так:
# Ждем, пока главное окно приложения не станет отзывчивым
while (-not $process.MainWindowHandle)...
Мне кажется, тут довольно скользкий момент. Не понятно, в каком фреймворке как это устроено. В одних оно может стать отзывчивым до момента инициализации и отрисовки, в других - после. Я бы просто добавил вызов Close() в конце конструктора формы, после всех инициализаций, чтобы приложение запускалось, инициализировалось и сразу закрывалось. И измерил бы общее время работы процесса. Просто как вариант...
И жаль, что нет сборки WinForms под .NET Framework 4.x. Они совсем ведь разные фреймворки с .NET
Статья очень вовремя, как раз перехожу с C++ и Windows Forms на C# и WPF. Uno Platform раньше даже не слышал. Спасибо за статью!
По опыту замечу что "простота winforms" крайне обманчива. Как только пытаешься в что-то сложнее крестиков-ноликов, то сложность работы через графический редактор крайне возрастает. XAML в плане организации UI гораздо лучше, хоть и приходиться потратить время на "разобраться".
Также отмечу что WPF поддерживает графическое ускорение, что позволяет с легкостью переваривать 100500 элементов в окне. Для форм такое издевательство нередко превращается в слайдшоу.
Дополнительный минус для winforms, что размеры контролов окна работают в разрезе 16 бит, причем в коде Size или Point имеют 32 битные поля и никаких ошибок в процессе не получаешь. Просто при переполнении, элемент улетает в непонятную часть окна.
И как вишенка на торте, я не завидую тому человеку, которому придеться поддерживать hight dpi на winforms.
С учетом всего этого, я очень скептически отношусь к идеи связываться с winforms, когда есть альтернатива в виде wpf. Особено в плане обучения. XAML всеже больше про разметку через теги, а не работу в графическом редакторе. В итоге приходиться ломать привычные подходы на новые.
P.S. Возможно из плюсов будет тот факт, что в winforms довольно просто нарисовать свой произвольный элемент. Хотя я не особо разбирался насколько это сложно в wpf.
Рисовать на графическом контексте так же просто как и в GDI, только это редко когда нужно ибо проще разместить один раз векторные примитивы, а потом менять их свойства привязками или анимациями
Ещё в пользу wpf и производных я бы добавил возможность использовать разные системы счисления. Например для картографии удобно класть на канву и адресовать элементы сразу в метрах, при этом adorner layer для всплывашек на редактирование использовать пиксельный.
Я сталкивался с проблемой, когда дизайнер нарисовал картинку и нужно было, чтобы точь в точь. Я вынужден был перейти с WinForms на WPF. Там только я смог добиться желаемого, да ещё и с малой кровью.
Поддержку win нужно делить на Win XP/7+ и Win10+ (да xp имеет место жить в кровавом энтерпрайзе)
Avalonia не использует WinUi (!) - там честный кросплатформенный рендеринг на векторах
Спасибо за статью!
Хотелось бы узнать ещё по каждому фреймворку — что по комьюнити, насколько живое/неживое, и есть ли плагины, библиотеки, дополнения к ним, всякие recycleview и т. д., нужны они вообще или нет, насколько сложно сделать сильный кастом-комплект и использовать его как библиотеку к разными проектами.
QT и GTK нужно для полноты сравнения;)
Как-то вот не сталкивался с применением их в шарпе, надо будет вникнуть в тему.
Были пожелания чем-то тяжелым нагрузить тестовое приложение, возможно и эти фреймворки там окажутся, если дело дойдет.
была GtkSharp от Mono, которая не обновлялась с 2016 года и поддерживает только GTK 2. Но есть форк https://github.com/GtkSharp/GtkSharp который работает с GTK 3 и обновляется хотя бы
Самую перспективую платформу с моей тчз забыли - webassembly.
Эцсамое, вы бы для винформ и авалонии NativeAOT включили, благо поддерживают. Скорость запуска несколько поменяется, да и прожорливость тоже.
Сравнение технологий для написания оконных приложений