А какие были недостатки у нее кроме завязки на Windows и отсутствия наследования в VB 5 и 6?
Пардон, у меня нескромный вопрос: ты этим вообще пользовался? Любой, кто пытался этим пользоваться, и тем более сам на этом пытался писать что-то работоспособное, проклял эту технологию. Главным образом потому, что что-то работоспособное чаще не получается, чем получается. Причем, сначала получается, а потом перестает работать. Или работает где-то в одном месте, но не работает в другом.
По факту никакой OLE/COM/ActiveX не отменили необходимости в тщательной притирке. То есть, если компонент разрабатывался специально для MS Word, то он будет работать в MS Word — больше нигде он работать не будет или будет, но очень плохо. В том же офисе по итогу пришли к тому, что проще открыть контейнер во внешнем приложении, а при встройке показывать простую картинку.
В данном случае я ничего не имею против библиотек типов, IDL, RPC, и прочих низкоуровневых фич, которые сами по себе не позволяют ничего никуда встраивать, а лишь облегчают взаимодействие с кодом на другом языке.
Скорее ты убедился, что Delphi — кусок дерьма, в который превратился некогда купленный проект Blue Label Software Pascal => Compas Pascal => PolyPascal, над которым Borland только слепила IDE Turbo Pascal. Это не считая того, что безупречную (для того времени) архитектуру самого языка разработал Вирт, который с этой движухи не получил совсем ничего.
Отсылка к Вирту тут не очень. Turbo Pascal практически сразу довольно далеко ушел от классического виртовского. Сначала прихватив фичи от Modula-2, потом подцепив ООП, не считая разных более мелких фишек.
Так или иначе Borland начинал и процветал как фирма, выпускавшая инструменты программирования для программистов, выигрывывшие относительно низким порогом вхождения и легкостью использования.
Всякому овощу свое время. Для MS-DOS и клонов IDE Turbo Pascal (позднее Borland Pascal) было наверное лучшим инструментов для программирования. Еще и Turbo Debuger был вещь. Turbo C тоже очень хорош, для любителей Си. Недаром столько всего было на них написано тогда.
И кстати, продавался чуть ли не по демпинговым ценам в сравнении с другими компиляторами.
Delphi 1 - стала почти такой же сверхудобной вещью для Win 3.x, Visual Basic на ее фоне довольно убог был, еще и код компилировал не нативный, требовал всякие vbXXrun.dll для исполнения. Хотя конечно суровые программисты юзали компиляторы от MS и их SDK с редакторами ресурсов.
Delphi 2 уже такого успеха не имела, но для Win95 в те годы тоже очень и очень приятная вещь. Однако для WinNT уже имела и недостатки. В частности с unicode все плохо было, но в то время это не так замечалось.
А вот дальше Borland кем-то не тем себя возомнила. Решили (заимев кучку субд тогда), что они теперь будут офигенным Ынтерпрайзом и грести деньги лопатой. Ребренднулись в Inprise, выпустили поделку под названием Delphi 3 (тогда же примерно и еще более поделку, если не сказать г-нище C++ Builder).
В язык продолжили добавлять фичи, но VCL стал окаменевать. Но в принципе Delphi 6,7 для своего времени (самое начало нулевых) тоже очень ничего могли показаться. Вершина эволюции и последние продукты настоящей Borland.
Ну а дальше понеслись по кочкам. Delphi 8 стала странной попыткой запрыгнуть в .NET, в результате ни то се вышло. Kylix как попытка скрестить ежа и ужа, хотя где-то даже получилось неплохо. Потом череда продаж и перепродаж и к настоящему времени не совсем понятны мотивы тех, кто с нуля пишет под Delphi.
Turbo Pascal практически сразу довольно далеко ушел от классического виртовского. Сначала прихватив фичи от Modula-2, потом подцепив ООП, не считая разных более мелких фишек
Ололо, а Модулу кто разработал?
Так или иначе Borland начинал и процветал как фирма, выпускавшая инструменты программирования для программистов, выигрывывшие относительно низким порогом вхождения и легкостью использования
Ну, и какие инструменты с низким порогом и легкостью от борланда ты можешь вспомнить?
Delphi 2 уже такого успеха не имела, но для Win95 в те годы тоже очень и очень приятная вещь. Однако для WinNT уже имела и недостатки. В частности с unicode все плохо было, но в то время это не так замечалось
Да, им понадобилось 10 лет на исправление проблемы — как раз то самое время, когда они игрались в тырпрайз. При том, что они ни в какие паскалевы строки не упирались — они создали свою собственную AnsiString.
Ты можешь заметить, что все проблемы у них начались ровно когда они отошли от 16-битного турбо паскаля. То есть, Borland был хронически неспособен выдать какое-то работоспособное решение, это изначально было сборище манагеров, которые совершенно случайно оказались у востребованного и перспективного продукта, который имел все шансы получить околомонопольное положение на рынке, но по итогу... ну вы понимаете, почему я так не люблю манагеров.
Модула - отдельный язык Вирта. В Турбо Паскаль в основном только отдельные фичи добавили: концепцию модулей, да и то не совсем в том виде. Кстати, Турбо Модула тоже была у борланда.
Ну, и какие инструменты с низким порогом и легкостью от борланда ты можешь вспомнить?
Турбо-языки, BP, BC++ досовский, Delphi 1,2.
Ты можешь заметить, что все проблемы у них начались ровно когда они отошли от 16-битного турбо паскаля.
Скорее от 16-ти битной винды. С 32 битами (да и 64-мя) на уровне языка особых проблем как раз не возникло. В этом смысле код даже проще, чем в C/C++ было перенести, если низкоуровневых системных вещей не использовал. А вот VCL, который вырос из досовского турбовижн - да, его надо было начать переписывать еще параллельно с написанием Delphi 1,2 и версии к 3-й - 4-й выкатить более новую и правильную библиотеку.
То есть, Borland был хронически неспособен выдать какое-то работоспособное решение, это изначально было сборище манагеров, которые совершенно случайно оказались у востребованного и перспективного продукта, который имел все шансы получить околомонопольное положение на рынке, но по итогу... ну вы понимаете, почему я так не люблю манагеров.
Хз, с высоты времени тоже проще судить, но все же именно энтерпрайизация в середине 90-х боком вышла. Вместо решения проблем продукта, которые уже тогда можно было увидеть, из него захотели сделать корпоративное нечто. До этого TP-Dephi были «народными» продуктами.
1995 год примерно. Линукс на десктопе был... в противозачаточном состоянии :) этот твой гтк подсказать когда появился или сам догадаешься? В 97м им еще не пахло, о серьезном использовании речи соответственно не шло.
Qt?
Ага, свободная лицензия когда появилась? Да и тогда и N лет позже лицензию тогда надо было покупать, чтоб пользоваться без головной боли ;) т.к. фри эдишон был глюкодромом.
Опять вести из манямирка? :) обжект паскаль куда у тебя стерся из «истории»? Хайлзберг, не не слышал, который и развивал из своего же турбопаскаля через обжект в дельфи со всеми остановками, пока «группа совладельцев» борланда не подсела на тяжелые наркотики? Язык по итогу надмножество того что «придумал Вирт», который уже упарывался модулами и оберонами, а «учебный язык» забросил еще в 80х.
Ага, свободная лицензия когда появилась? Да и тогда и N лет позже лицензию тогда надо было покупать, чтоб пользоваться без головной боли ;) т.к. фри эдишон был глюкодромом.
Человек, использовавший когда-то в конце мохнатых 90-ых ломаный пиратский Delphi, жалуется что Qt тогда был несвободным, лол.
А вот VCL, который вырос из досовского турбовижн - да, его надо было начать переписывать еще параллельно с написанием Delphi 1,2 и версии к 3-й - 4-й выкатить более новую и правильную библиотеку.
Как минимум либы на VB.NET можно будет делать, даже если прямой интеграции с MAUI не будет. Кстати, Avalonia тоже уже немного может для мобил, и развивается в этом направлении
Этим вообще кто-то пользуется? Ну типа и на делфи кто-то пишет, и даже для мобилок, но только для поддержки наследия, новые проекты на этом никто писать не будет. Аналогично, число проектов изначально созданных на Mono исчезающе мало.
По поводу BC++ я не копенгаген, но судя по популярности оного — по поводу качеств этого инструмента можно поспорить. Всё остальное — это модификации турбопаскаля, до Delphi 2, исключая оный.
Ага, свободная лицензия когда появилась? Да и тогда и N лет позже лицензию тогда надо было покупать, чтоб пользоваться без головной боли ;) т.к. фри эдишон был глюкодромом
Опять вести из манямирка? :) обжект паскаль куда у тебя стерся из «истории»? Хайлзберг, не не слышал, который и развивал из своего же турбопаскаля через обжект в дельфи
Обжект паскаль разработан в Яббле. А в кусок дерьма он уже превратился в борланде.
Какие недостатки у MAUI по сравнению с другими вашими вариантами?
Ты путаешь production-ready инструмент с перспективной разработкой. Например, Mono до сих пор не поддерживает всех фич .NET. И так будет всегда, MS прежде всего поддерживает винду, и потом уже всё остальное. А почему не стоит завязываться на «перспективное решение», даже от MS, можно увидеть на примере UWP, который стал наследием сразу после рождения, потому что его целевые платформы умерли (win/win mobile).
позволяющая получить максимум продуктивности от их кнопкодавста.
Ох, ЛОЛ, продуктивность от кнопкодавства.
Потому что там и так нужно поддерживать отдельно своих и отдельно паблик - это разные формы, разные сущности, разные ответы на вопросы даже в случае веб+веб.
Для фротнэндера - это форма+форма. Ему похер, чем она там занимается, сказали красить кнопку - он красит. А реюзом кода работы всегда меньше. Это у вас так принято, что форму пилит специалист по предм.области между делом, а нормальные разработчики так не делают. Формошлёп-фронтэднер должен сидеть, шлёпать формы и делать это как господь. Так он эффективен. Аналитик, который делает это хер пойми как - нет.
Так не все, почитай про XAF RAD насколько он кастомизируемый, сохраняя при этом ООП расширяемость для программистов. И отзывы реальных пользователей про ускорение формошлепства для типовых учетных систем до 50 раз.
Кого почитать? Маркитологов devexpress?
Идеальные разработчики по методе DevOps CI/CD словить шифровальщик не могут?
Могут, только ничего такого не произойдёт. Откатят на версию взад и всё.
Так значит проблема в разработчиках дизайнеров
Это не проблема. Проблема решается за деньги, а столько кейсов просто нереально покрыть. Ты еще бы за визуальный яп начал тут толкать, как метапрог, ыыы.
Но как я уже упоминал десктопное приложение можно деплоить точно также через веб страничку с noVNC
А еще можно на фокспро автоматизацию делать. Базарю.
Кроме того ничто не мешает обычному десктопному приложению использовать HTTP(S) для связи со своим сервером приложений и даже не поверишь, автоматически обновлять свою версию при запуске
А еще ничего не мешает аж целый недобраузер со своим сприптоязыком. Только зачем это делать, когда можно не делать.
Вот именно, что ваши веб фреймворки меняются как ежегодно линяющая шерсть на теле мартышки
css меняется ежегодно с ног на голову, ага?
Зачем мне постоянно бегать за современными модными веб (и не только) технологиями
Те веб стандарты, которые работали 10 лет назад также и работают. Ничего не меняется, представляешь?
А предъява, что что-то там вокруг стабильного css с dom крутится - странная. Народ делает, пробует, изобретает что-то, то, что хуже дохнет, что удачнее остаётся - это хорошо и правильно. Не, ну кому-то нравится, когда 2.5 конторы 20 лет пишут одну и туже говнину и медленно стагнируют.
Все эти заявления, что вот, там что-то новое появляется, какой ужос, выглядят как дедовское бздение, когда чел уже слишком старый для всего, что уже не успеет никогда усвоить.
Почему же формочка с абс. координатами - это говнина? Наверное, потому что там всё так же и нельзя менять её размер без того, чтобы она не превратилась в тыкву. А чтобы она не превращалась, представь себе, придумали целый цсс со всяким, правда формошлепов туда не позвали и они как-то сами со своими великами, которые иногда работают, иногда не работают, но всё равно то их велики, а то цсс, который знает каждая макака.
Тебе же не надо объяснять, почему даже работающий велик является говниной?
Это всё хорошо и весело, пока покрывает кейсы. Только твои кейсы вываливаюся за рамки, начинается траханье. Так у всех. Но где-то что-то можно с этим быстро сделать, а где-то проще поднять лапки вверх и сказать насяльнику, что сделать ничо нельзя.
Если хочешь действительно богатый user experience - надо садиться и делать руками. Навароченные штампованные формочки с гридами её не обеспечивают совершенно никак. Вся эта дрочня с графиками, свистелками, перделками и мигалками - это не то, что надо. Минимальные удобства можно сделать хоть на vcl, хоть в сраном досе. Надо понимать юзера, его предметную область и делать то, что ему нужно, а не «ололо, мы такие можные, щас херах-херак, поставим модные формочки и всё будет свистеть и пердеть». Это так не работает. Дальше, если юи спецы действительно спецы, они сидят и проектируют под типовые кейсы, под особенности работы. И в этом месте юи становится слишком кастомный для формошлепства, для того, как всё это связано с бд, да и просто сама разработка всего не такого как везде становится просто неподъёмной. Инструмент, который может делать элементы динамически без описания всего заранее и траханья с ооп улетает вперед с отрывом.
Лично я любитель WinForms, которым уже 20+ лет.
WinForms компоненты до сих пор активно развиваются компаниями типа DevExpress, ходят слухи, что даже не без спонсорства тех, о ком упоминать нельзя.
WinForms работают в WINE, что меня вполне устраивает как кроссплатформенность.
Могут, только ничего такого не произойдёт. Откатят на версию взад и всё.
Если репа VCS окажется зашифрованной шифровальщиком?
Это не проблема. Проблема решается за деньги, а столько кейсов просто нереально покрыть.
Можно делать дизайнеры, специфичные для отдельных компонентов, чем DevExpress и занимается.
А еще можно на фокспро автоматизацию делать. Базарю.
И где тут связь? Фокспро использует неэффективную СУБД по нынешним меркам, хотя если брать последние вендовые версии, то наверно можно цепляться и к внешним СУБД? Фоксовики очень жалели, что Microsoft убила их замечательный FoxPRO.
А например похожие XBASE технологии с диалектом Clipper все же развиваются до сих пор, причем с .NET под капотом:
IMHO FoxPRO поинтереснее, чем MS Access и для прототипов по моей noVNC был бы идеальным решением.
А еще ничего не мешает аж целый недобраузер со своим сприптоязыком. Только зачем это делать, когда можно не делать.
Ты сравниваешь несравнимое, обновление по HTTP - это очень просто, а свой браузер - очень сложно, разница в трудоемкости - тысячи раз.
css меняется ежегодно с ног на голову, ага?
Меняются фреймворки: Aurelia, Vue, etc.
У вас там такой зоопарк, что Африка позавидует.
Те веб стандарты, которые работали 10 лет назад также и работают. Ничего не меняется, представляешь?
Да что вы говорите? И их достаточно для современных сайтов? Зачем уж так-то, лучше пообсуждать это с фронтендерами, чем им не нравятся сайты из 90х.
Не, ну кому-то нравится, когда 2.5 конторы 20 лет пишут одну и туже говнину и медленно стагнируют.
Есть конторы, которые делают свои immutable (ну почти) надстройки над постоянно меняющимися современными технологиями.
Все эти заявления, что вот, там что-то новое появляется, какой ужос, выглядят как дедовское бздение, когда чел уже слишком старый для всего, что уже не успеет никогда усвоить.
Опять про неосиляторство :) История systemD повторяется. Почему я умею пользоваться systemD, но редко когда мне это хочется?
И потом зачем Full Stack веб разрабу изучать все варианты ваших свистоперделок, когда есть готовые унифицированные компоненты для Blazor и ASP.NET ?
Если хочешь действительно богатый user experience - надо садиться и делать руками.
Я не исключаю таких фрагментов, но это как про оптимизацию скорости выполнения кода, достаточно оптимизировать только 10% для получения уже очень хорошего эффекта, нет смысла оптимизировать весь код.
Почему же формочка с абс. координатами - это говнина?
Почему мои веб формочки сами приспосабливались к размеру экрана еще 20 лет назад? Наверно потому что я задавал некоторые параметры HTML в процентах от ширины экрана.
Да при поверхностном взгляде кажется что нужное, потом начинаешь присматриваться и оказывается, что вон у того компонента по делу работает полторы функции, у другого еще полторы и так далее.
Зависит конечно, но если брать в среднем по разным предметным областям (офисная автоматизация, сайтеги, про которые тут упоминали), а не чистые числодробилки, 3D, компиляторы и т.п.
Ну в среднем по больнице, включая гнойное и морг, температура 36.6. Можно столкнуться с говнокодом, можно столкнутся с какими-то «особенностями». Мне приходилось переписывать как чужой код так и свой собственный.
WinForms работают в WINE, что меня вполне устраивает как кроссплатформенность
А всех остальных не устраивает, потому что вайн работает заметно хуже любого натива. Wine применяют только когда деваться некуда, а не как штатное решение. Еще раз: ты путаешь перспективные и малоподдерживаемые технологии с production-ready.
Ну если какие-то там компоненты, и приделывали какой-нибудь ffmpeg к сервису или что-то типа того. А так - кто будет специально засовывать свой пхп/жс говнокод в бинарник? Ну да, с другой стороны есть жависты, дотнетчики, гошники.
Ну так это комбайная разработка. Тебе надо 4 функции, берешь с одного комбайна 0.5, со второго 2.5, с третьего 0.5 и подпираешь костылём. Юниксвей? Солид? Фу, херня для лохов. Ну а всё писать это долго.
Если репа VCS окажется зашифрованной шифровальщиком?
Сервер репы взломали хакиры вместе с тачками всех разрабов? А потом разбомбили оба датацентра.
Можно делать дизайнеры, специфичные для отдельных компонентов
Для каждого возникающего единичного кейса.
И где тут связь?
Можно через жопу гланы удалять, так понятнее?
IMHO FoxPRO поинтереснее, чем MS Access
Борьба была равна...
Ты сравниваешь несравнимое, обновление по HTTP - это очень просто, а свой браузер - очень сложно, разница в трудоемкости - тысячи раз.
Так не обязательно реализовывать целый сложный браузер. Можно же реализовать несколько простых кусочков. Ну будет у тебя свой простой глючный недобраузер, ну что такого.
Меняются фреймворки: Aurelia, Vue, etc
Обожемой, КАКОЙ УЖОС!! Было n фреймворков стало n+1. КАК ДАЛЬЩЕ ЖИТЬ-ТО С ЭТИМ?? КТО-ТО ПРИДУМАЛ НОВЫЙ ФРЕЙМВОРК И ПИШЕТ НА НЁМ, ПОНИМАЕТЕ??? А некоторые вообще топят за purejs.
Да что вы говорите? И их достаточно для современных сайтов? Зачем уж так-то, лучше пообсуждать это с фронтендерами, чем им не нравятся сайты из 90х.
Между 90-ыми и 2010-и 20 лет разницы, если что. Как бы на этом же лоре за эти 10 лет ничего особо не поменялось.
И потом зачем Full Stack веб разрабу изучать все варианты ваших свистоперделок
Свистоперделки не наши. Старые веб разрабы как писали на этом своём каком-нибудь вуе, которому 100 лет в обед, так и пишут. Так юзали свои набитые цсс стили так и юзают.
Я не исключаю таких фрагментов, но это как про оптимизацию скорости выполнения кода
Причём тут скорость выполнения кода? Юзер не сможет реагировать быстрее. Ему без разницы отрабатывает оно за 100мс или за 20мс. Юзеру надо, чтобы он видел то, что ему надо видеть, чтобы было понятно, чтобы было удобно и под рукой. А оно для каждого кейса своё и может быть весьма извратно. И твои маками-работодатели из девэкпресс не будут прыгать под каждый единичный кейс разрабатывать конструктор и компонент, которым будет пользоваться 1.5 юзера. Это так не работает. Конструктор должен покрывать как можно больше кейсов сразу. Иначе макак не хватит во всей интустрии, чтобы затыкать каждую дырку.
Может быть, если там был бы опенсорц в который все активно бы контрибутили, фиксили баги и т.п., можно было бы еще как-то что-то напилить чопиков под кучу кейсов и пытаться этим затыкать, но хер там плавал. За все эти годы даже вебшики не выработали какую-то единую систему компонентов, забили хер, просто пляшут со своими великами вокруг dom и css, да им норм, потому что браузер даёт им хорошую базу, под которую они могут быстро сваять что нужно. И всё уходит именно в это направление, а «компоненты как в дельфи» остаются пердунам, которые в другое не смогли. На вебчике, кстати, тоже пытались ваять ext.js, но он почему-то остался там же, где пердуны со своим формочками.
По твоему в веб приложениях достичь большей продуктивности пользователя проще, чем в desktop приложениях?
Кнопкодавство - это не про продуктивность, а юзеру по большому похер, где нажимать кнопки. Формочку в вебе покрась, он ничего и не заметит.
А с точки зрения кодеров я уже все сказал. Что-то кастомное на вебчие делать проще на порядки. А продуктивность юзера, чтобы он действительно продуктивно работал, а не делал каждый день okay или крыл разрабов матом, нужен кастомный ui, а не попытки запихивания штампованных компонентов под кейс на отвяжись.
Может долго, а может и нет. Я описывал вариант, когда поиск компонент становится культом, причем культом доходящим до: «я не могу это сделать, потому что компонент для работы с nnnn никто не сделал». Ещё бывает вариант, есть стандартный компонент, но не хватает какой-то мелочи и вместо того что бы создать свой на основе существующего с допиливанием нужного, начинаем искать какой-то более другой. Или сценарий хуже, мы когда-то сделали на основе компонента c1, в нем нет функционала который вам требуется, будем всё перепиливать на компонент c2, но это займет дофейхуа времени. Мозг не включают, что можно было бы не особо напрягаясь и c1 допилить.
Сервер репы взломали хакиры вместе с тачками всех разрабов?
Как будто, что-то из ряда вон выходящее. И потом, много ли тачек разраба у дельфийных компонентописателей, с которых началось это обсуждение? И ведь проприетарщики (компонентопейсатели тоже) нередко поднимают свои приватные VCS. Сервер с VCS менее подвержен шифрованию шифровальщиками, чем рабочие станции разработчиков?
А потом разбомбили оба датацентра.
Новости смотришь?
Можно через жопу гланы удалять, так понятнее?
Нет, у тебя абстракции ушли слишком далеко за рамки обсуждаемой темы.
Ты сравниваешь несравнимое, обновление по HTTP - это очень просто, а свой браузер - очень сложно, разница в трудоемкости - тысячи раз.
Так не обязательно реализовывать целый сложный браузер. Можно же реализовать несколько простых кусочков. Ну будет у тебя свой простой глючный недобраузер, ну что такого.
Вообще не понимаю, на кой xxx ты притащил в обсуждение сущность браузера? Речь о простейшей операции HTTP GET, которая легко делается через аналог wget, curl, etc. Причем тут браузеры?
Это как сравнивать команду cp (копирование) с файловым браузером типа Dolphin. Если нужно скопировать пару файлов, то зачем разрабатывать свой Dolphin? С гландами все нормально (в твоей терминологии, заметь)?
Меняются фреймворки: Aurelia, Vue, etc
Обожемой, КАКОЙ УЖОС!! Было n фреймворков стало n+1. КАК ДАЛЬЩЕ ЖИТЬ-ТО С ЭТИМ?? КТО-ТО ПРИДУМАЛ НОВЫЙ ФРЕЙМВОРК И ПИШЕТ НА НЁМ, ПОНИМАЕТЕ??? А некоторые вообще топят за purejs.
А нахера все это нужно, постоянно играть в догонялки с развитием веб фреймворков? Больше нечем заняться чтоли? Тем более когда есть унифицированные компоненты ASP.NET и Blazor, и даже более высокоуровневые абстракции над ними типа XAF, которые при желании все же могут кастомизироваться до твоего любимого уровня кодирования на JS фреймворках, только обычно это никому не надо, достаточно объектной модели компонентов.
Кнопкодавство - это не про продуктивность, а юзеру по большому похер, где нажимать кнопки. Формочку в вебе покрась, он ничего и не заметит. А с точки зрения кодеров я уже все сказал. Что-то кастомное на вебчие делать проще на порядки. А продуктивность юзера, чтобы он действительно продуктивно работал, а не делал каждый день okay или крыл разрабов матом, нужен кастомный ui, а не попытки запихивания штампованных компонентов под кейс на отвяжись.
Сколько видел гридов для веб и для десктопа, десктопные от того же вендора по функциональности почти всегда были на голову выше, в них легче было реализовать наиболее оптимальную работу пользователя с минимальным количеством нажатия кнопок и с максимально быстрым отзывом программы.
Причём тут скорость выполнения кода? Юзер не сможет реагировать быстрее. Ему без разницы отрабатывает оно за 100мс или за 20мс. Юзеру надо, чтобы он видел то, что ему надо видеть, чтобы было понятно, чтобы было удобно и под рукой. А оно для каждого кейса своё и может быть весьма извратно.
Вообще-то я подразумевал нечто похожее на закон Парето:
Применительно к данному случаю имелось ввиду, что небольшая кастомизация готовых ASP.NET и/или Blazor компонентов, с высокой долей вероятности решит обозначенные тобой проблемы, и при этом ненужно будет зарываться в изучение твоих любимых современных JS веб фреймворков, чтобы все приложение делать только на них. Достаточно изучить чуть-чуть, чтобы кастомизировать уже существующие компоненты.
Скорость кстати тоже имеет значение, потому что в случае с десктопным приложением после обновления оно обычно уже полностью на компе пользователя или терминального сервера и при наличии асинхронности как у DevExpress оно вообще не тупит в отличии от веб, которые постоянно пытаются что-то подгружать с сервера и иногда подтупливают.
И твои маками-работодатели из девэкпресс не будут прыгать под каждый единичный кейс разрабатывать конструктор и компонент, которым будет пользоваться 1.5 юзера. Это так не работает. Конструктор должен покрывать как можно больше кейсов сразу. Иначе макак не хватит во всей интустрии, чтобы затыкать каждую дырку.
Приведи пример того, что нельзя сделать на компонентах DevExpress для ASP.NET и Blazor? Из обычного офисно бизнесового репертуара, а не какой-нибудь там веб CAD или 3D модели.