Во-первых веб-интерфейс позволяет в будущем переходить на другие системы. В России вообще-то уже давно продвигается переход на линукс. И это одна из его продающих фич.
Во-вторых веб-интерфейсом одной из систем, которую я писал, внезапно начали пользоваться на андроидном планшете. До этого там была система на дельфи, с ней это было невозможно. А тут админы прокинули VPN, я чуток подправил стили и готово, стоит товарищ в поле и имеет моментальный доступ к информации, для которой раньше ему нужно было звонить в центр и спрашивать у дежурного.
В-третьих я не согласен с утверждением, что десктоп разработка дешевле. Десктоп разработка остановилась в 90-х и с тех пор ничего по сути нового не появлялось. В вебе разработка уже сейчас более продвинута.
В-четвёртых веб решает проблему обновления, такое понятие, как клиент старой версии исчезает в принципе, а это целый пласт проблем техподдержки. Если ты когда-нибудь поддерживал такое приложение, ты бы это ценил.
У десктопа есть два преимущества. Первое это доступ ко всем функциям ОС. Например если тебе нужно достучаться до крипто-токена в USB-порту, проблем 0. Из браузера это просто невозможно. Второе это оффлайн-режим. Но в принципе по обоим фронтам веб-приложения наступают, поэтому если закладываться на будущее, эти преимущества уже не столь очевидны.
Собственно весь крах десктоп-разработки иллюстрирует Electron. Всё больше современных приложений выходит для него. А это ведь и есть веб-приложение, сбандленное с браузером. Не хотят программисты писать на ваших дельфи и винформах, им куда проще на JavaScript писать. Даже такое, казалось бы, сугубо десктопное приложение, как дискорд, написано на веб-технологиях, что не мешает иметь ему офигенный звук, хитрые фильтры обработки, даже стрим можно пустить одним кликом.
S>Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
Я буду спорить. Дестктоп вполне себе используется, разработки на нем заказываются. Не говоря уж о всяких нативных мобильных приложениях, которых куча, но это особая песня.
S>Основным аргументом выбора веб-интерфейса при разработке ПО, при этом, является аргумент "пофигу на ОС, хоть Вин, хоть Линь, хоть Мак". Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
Кстати, если про конкретно РФ — сейчас за счет движухи с импортозамещением растет доля разработок на всяких линуксах, в т.ч. под AstraLinux.
И еще одна ремарка — считать распространенность той или иной платформы в корпоративе по количеству пользователей не очень корректно. Количество пользователей вовсе не означает масштабность задачи или сложность системы. Бывает достаточно серьезное ПО для достаточно масштабных задач, у которого конечных пользователей — несколько человек.
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
Опять же, за веб топят не все. Есть те, которым веб реально лучше подходит. Есть те, кто ведется на хайп и хочет веб чисто потому, что "стильно, модно, молодежно". И есть те, которым веб нафиг не уперся.
vsb>В-третьих я не согласен с утверждением, что десктоп разработка дешевле. Десктоп разработка остановилась в 90-х и с тех пор ничего по сути нового не появлялось. В вебе разработка уже сейчас более продвинута.
...
vsb>...Не хотят программисты писать на ваших дельфи и винформах, им куда проще на JavaScript писать. Даже такое, казалось бы, сугубо десктопное приложение, как дискорд, написано на веб-технологиях, что не мешает иметь ему офигенный звук, хитрые фильтры обработки, даже стрим можно пустить одним кликом.
Десктоп вполне может выйти дешевле. Если рассматривать не абстрактную разработку, а разработку под конкретнтые хотелки заказчика.
Примерно так. Пусть заказчик хочет, чтобы для него разработали какую-то систему под его специфическую задачу для его специфической предметной области. Пусть, для определенности, он не ограничен какой-то корпоративной политикой в выборе технологий и сам решает, на чем заказать разработку.
(Тут особо отметим специфику именно заказного софта, а не софта для массового рынка. Это значит, что для заказчика не так важно, чтобы софт был симпатичным, привлекательным, формировал позитивный имидж компании и т.п. Заказчику важнее, чтобы софт был заточен именно под его хотелки.)
И тут возникают варианты, что выбрать.
Например, разработчик Вася, которому "куда проще на JavaScript писать", может быстро слабать веб-приложуху на популярном веб-фреймворке. Но, блин, оказывается, что вот тут она работает криво, вот эту хотелку заказчика на этом фреймворке реализовать не получается. А в IE6 это вообще не работатет (да-да, у заказчика у одного некоторых пользоваетелй IE6, и поменять проблематично. Это в случае софта для массового сегмента можно сказать "вот эти пользователи со старыми и экзотическими браузерами пусть идут лесом", а в случее заказного софта придется под имеющиеся системные требования подстраиваться. Вспомним, напримре, что в США до сих пор поддерживаются системы, писаные на Коболе)
Вот есть другой разработчик Петя, которые в веб-технологиях очень-очень крут. Он знает, как на вебе в точности реализовать все-все хотелки заказчика, и даже чтобы под IE6 работало. Но, блин, этого Петю еще поди найди — он один такой на тысячу менее квалифицированных разработчиков. И возьмет за разработку Петя очень дорого.
А есть третий разработчик Митя, который предлагает десктопное приложение. Его десктопные средства разработки позволяют спокойно обработать напильником приложение под все хотелки заказчика. И при этом ему не требуется быть таким уж виртуозом, и денег за разработку он берет не так много.
Вот в этом варианте десктопное приложение — для заказчика весьма выгодный вариант
Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
Основным аргументом выбора веб-интерфейса при разработке ПО, при этом, является аргумент "пофигу на ОС, хоть Вин, хоть Линь, хоть Мак". Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
Здравствуйте, gandjustas, Вы писали:
G>>>2) В вебе есть ссылки, которые приходят на почту.
vsb>>Ну ссылки в приложение вроде все операционные системы умеют. G>Только в вебе тебе не надо ничего дополнительно программировать чтобы ссылки работали. Изначальная архитектура веб-приложения делает возможной адресацию с помощью ссылок. В декстопе это надо программировать.
Получаешь ссылку, парсишь параметры, выполняешь код. По-моему одинаково везде. Никакой магии в вебе нет, точно так же надо программировать.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sfsoft, Вы писали:
G>6) В ебе самый мощный layout-движок из всех существующих.
Настолько мощный, что почти в любом веб-приложении что-нибудь на что-нибудь накладывается
Если серьезно, спорное утверждение. В WPF\UWP можно получить любую раскладку переопределив пару методов. Практически полный аналог flex layout мы писали очень давно и заняло это пару дней.
В html приложениях обычно адская смесь из css flex, css grid и абсолютного позиционирования, и любой глобальный css стиль может случайно все порушить.
А если нужно что-то не стандартное, то я вообще не знаю, как это нужно делать. Нет не только способа переопределить раскладку, но даже события на resize элемента.
Здравствуйте, sfsoft, Вы писали:
S>Здравствуйте, Kolesiki, Вы писали:
K>>Чушь какая... никакого даже "де-факто" нет. Как были WPF'ы с WinForms'ами, так и остались.
S>Хм, я верю, что WinForms, WPF и VCL остались во многих местах. Я даже знаю эти многие места. Но речь шла о новых приложениях. S>Есть примеры разработки именно нового софта на WinForms, WPF и VCL, а не на каком-нибудь Angular'е?
Примеры конечно есть. Мы вот недавно начали пилить один проект, связанный с подготовкой текстовых документов.
Что характерно, хотели на электроне делать, но оказалось, что нормального редактора richtext для веба пока нету, в демках-то они конечно круто выглядят, а на практике со всеми компонентами куча проблем вылезла.
В итоге выбрали WPF. Конкуренты, которые на пару лет раньше сделали, вообще на WinForms все написали.
Вопрос в том, сколько таких примеров? Потому что, была бы возможность дешево сделать кросс-платформенное решение, выбрали бы кросс-платформу.
Здравствуйте, vsb, Вы писали:
vsb>Microsoft Teams уже не корпоративное приложение? Slack, Trello, это только из того, что я видел.
Teams и Trello не видел.
Шлак — лютое говно, добровольно я им пользоваться не хочу.
Скайп туда же.
Здравствуйте, CreatorCray, Вы писали:
vsb>>Microsoft Teams уже не корпоративное приложение? Slack, Trello, это только из того, что я видел. CC>Teams и Trello не видел. CC>Шлак — лютое говно, добровольно я им пользоваться не хочу. CC>Скайп туда же.
Я не хочу пользоваться ни одним приложением, написанным не нативным способом (WinAPI/Gtk/Cocoa/Cocoa Touch/Java для соотв. латформ). Но кто меня спрашивает Раз пишут, значит все остальные считают по-другому.
Здравствуйте, sfsoft, Вы писали:
C>>Ой, ну не надо. Достаточно вспомнить все WinForms-приложения, которые не умеют масштабироваться. S>Это проблема не WinForms, а проблема кривых рук.
Так и неправильные веб-приложения — проблема кривых рук. На WinForms реально нетривиально делать масштабирующиеся формы, кроме самых простейших.
Здравствуйте, sfsoft, Вы писали:
S>Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
S>Основным аргументом выбора веб-интерфейса при разработке ПО, при этом, является аргумент "пофигу на ОС, хоть Вин, хоть Линь, хоть Мак". Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
А ссылку можно про то, что у 99% корпоративных пользователей — десктопные приложения, а не web?
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
Скорости разработки в десктоп приложениях по сравнению с веб — нет (у меня опыт разработки GUI от WinAPI, ATL/WTL, MFC, Qt, WinForms до Plain js, AngularJS, Angular 2+, React)/
По скорости разработки, тоже ни каких тормозов в вебе нет. Ну если только не работа с 3D моделями, хотя, есть примеры и таких веб проектов без торомозов. В общем все зависит от радиуса кривизны рук разработчика.
Давно заметил, что те, кто стал веб разработчиком — без опыта написания кода под ОС, без понимания как работает обработка сообщений в ОС, как работает память, сеть на системном уровне, у тех больше косяков в плане производительности кода, т.к. они не будут особо заморачиваться над тем как работает V8, как выполняется js код.
Здравствуйте, vsb, Вы писали:
vsb>Тот же React — ничего подобного раньше не было, это абсолютная инновация.
Реактивность на десктопе была когда еще веб не родился, а идея изменения хтмл при помощи компараторов — она сугубо HTML специфична.
vsb>>>Без понятия, не пользуюсь. Советую писать HTML руками. Дизайнеры только мешают. S>> Вот именно. Какая же в этом простота? vsb>А что сложного?
Ну вот честно, верстка HTML на порядок сложнее верстки WPF, не говоря уж о пристрелке пикселей времен MFC, VCL и винформсов.
Но я так понимаю, что в России стек для крупных enterprise-приложений в миллионы строк кода выбирается на основе того, что работает на кассовом аппарате. Да?
Здравствуйте, sfsoft, Вы писали:
S>Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
S>Основным аргументом выбора веб-интерфейса при разработке ПО, при этом, является аргумент "пофигу на ОС, хоть Вин, хоть Линь, хоть Мак". Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
Кто-нибудь наверно уже об этом сказал. Но всё равно хотелось бы добавить, что веб-интерфейс всегда говно. Нет вообще примеров более-менее сложного удобного веб-интерфейса. Человечество зашло в тупик.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Серверный код на JavaScript?!? Развесистую корпоративную бизнес-логику?!? Серьёзно?!? НС>Ты правда никогда не слышал про node.js?
С одной стороны понятны аргументы и за и против, но с другой, когда у меня
а) Банк 10 месяцев не менял код, поэтому работать можно было только с IE6, всё остальное валилось с ошибками ангуляра
б) Когда бухгалтерская система (:--(((() уже 2 года имеет кнопки наезжающие друг на друга
в) мейл.ру стал более глюкавый и тормозной, но зато с новомодными ангулярами или реактами, фиг знает
г) когда я пришёл на собеседование в самую крупную контору в мире по бронированию всего на свете и мы 2 часа пытались запустить тестовое задание (vue.js на маке), но так и не запустили.
....
и когда таких примеров просто тонны, то немного странно слышать про крутышку веб.
Здравствуйте, Serginio1, Вы писали: S> А при чем тут stateless? Блазор как раз и хранит состояние как на клиенте так и на сервере
Пробовал blazor server, состояние сохраняется только для простых св-в(int, string, Date, bool)
состояние св-в ссылочного типа сбрасываются в ноль при изменении. Есть какой-то велосипед с атрибутами, но это совсем не то, что десктопе.
Blazor client не проверял, врать не буду.
K>*Хранение данных и бэкапы. В десктоп приложениях много всего хранится локально. В Web все хранится на сервере,
Вы слыхали про многослойные приложения типа CSLA?
K>может обезопасить от различных наездов с изыманием всех компьютеров сотрудников. Чтобы изъять сервер его надо еще найти, а он может быть вообще в облаке.
Если прийдут изымать, то значит будут УЖЕ знать не хуже вас самих, где и что находится.
В облако доступ у некоторых спецслужб такой же как у вас самих.
И вообще к чему весь этот флейм Desktop vs Web, когда можно просто взять и купить DevExpress UNIVERSAL и разрабатывать XAF приложения, у которых возможны варианты автоматического "рендеринга" модели в WinForms, WebForms и Blazor.
WinForms можно запустить как на венде, так и на линупсе в WINE. Не знаю, работает ли WINE+DotNet на макаковых випбуках.
Blazor, понятно, что работает везде, где есть DotNet core, переписывать ничего не надо, переключаете target GUI, и оно само рендерит, как надо.
Здравствуйте, sfsoft, Вы писали:
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
1) Веб не надо устанавливать и обновлять, это происходит автоматически.
2) В вебе есть ссылки, которые приходят на почту.
3) Веб-приложение не требует доработки чтобы работать внезапно на маке.
4) В вебе гораздо проще сделать аутентификацию, причем такую как удобно пользователю. Внтури корп сети интегрированная windows, а при удаленной работе — adfs со вторым фактором.
6) В ебе самый мощный layout-движок из всех существующих.
5) Веб-страницу можно гененрировать динамически и печатать.
То что десктоп требует меньше ресурсов — заблуждение. Реализация на десктопе всего, что написано вышеЮ хотя бы на том же уровне как в браузере, делает десктоп приложение бесконечно дорогим.
vsb>В-третьих я не согласен с утверждением, что десктоп разработка дешевле. Десктоп разработка остановилась в 90-х и с тех пор ничего по сути нового не появлялось. В вебе разработка уже сейчас более продвинута.
Неужто WPF в 90 был?
Кстати какой HTML дизайнер лучше выбрать?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, sfsoft, Вы писали:
S>Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
Чушь какая... никакого даже "де-факто" нет. Как были WPF'ы с WinForms'ами, так и остались.
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
Ну так кто выступает — задроты-жабоскриптники! Поналяпают свои веб-морды, смотреть тошно, юзать ещё противнее.
Я пока что не встречался с такими в реальной работе — может, их уже отправили на лечение? Встречаю только на форумах.
Здравствуйте, sfsoft, Вы писали:
S>Основным аргументом выбора веб-интерфейса при разработке ПО, при этом, является аргумент "пофигу на ОС, хоть Вин, хоть Линь, хоть Мак". Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
Никогда не слышал этот аргумент как основной. А я застал начало перехода наших крупных корпоративных заказчиков в веб. Году так в 2003-2004 мы еще начинали им десктоп приложения, а дальше постепенно практически все новые стали веб-приложениями. Причем разрабатывались тогда зачастую с жесткой привязкой к IE6 потому что "де-факто стандарт и стоит на всех рабочих места".
Основными аргументами с которыми я встречался всегда были:
1. простота обновления самой системы (техподдержке надо обновить только сервера системы и все. и не надо накатывать обновления на десятки тысяч рабочих мест, половина из которых в филиалах, которые полунезависимые юрлица со своей локальной техподдержкой и на которых может быть какая-то более другая версия виндов, чем в других филиалах)
2. упрощение администрирования рабочих мест: не требуется доп.софта кроме одного браузера для всех приложений. Мечта техсаппорта — чтобы рабочие места по одной бизнес-группе пользователей развертывались из одного образа или одним набором скриптов и не требовали никаких изменений, если пользователю потребовался доступ в еще одну бизнес-систему. Чем меньше разнообразного софта на машинах пользователей, тем проще техподдержке.
S> Кстати какой HTML дизайнер лучше выбрать?
vsb>Без понятия, не пользуюсь. Советую писать HTML руками. Дизайнеры только мешают.
vsb>Быстрей пишешь, меньше цена
Такой вот плюрализм мнений в голове отдельно взятого разработчика...
Здравствуйте, klopodav, Вы писали:
K>Но почему-то такая фигня происходит: в веб-интерфейсе разных приложений косяки GUI, мешающие жить, почему-то встречаются значительно чаще, чем в десктопных приложениях (даже если рассматривать не наколенные поделки, а серьезные и популярные приложения).
Проблема в том, что ты в 99% случаев в вебе видишь наколенные поделки, а на десктопе серьезные приложения.
K>А это наводит на мысль, что либо в веб-технологиях что-то развито еще недостаточно хорошо, либо оно развито хорошо, но слишком сложно для массового использования. (либо развито хорошо и существует простая методика использования, но эта методика хранится как сакральное знание только для избранных)
Это наводит на масль что в вебе настолько просто клепать приложения и доставлять их до пользователя, что пользователи довольно часто натыкаются на сырое говно.
С таким уровнем десктопное приложение просто не попало бы на твой комп.
G>>>6) В ебе самый мощный layout-движок из всех существующих. ЕА>>Настолько мощный, что почти в любом веб-приложении что-нибудь на что-нибудь накладывается G>Не понял о чем речь. G>Если ты в CSS не можешь, то накладывается, да.
То что я не умею это еще полбеды (я-то реально html не умею, никогда ничего сложнее лендинга не делал).
Но вот почему у приложений с огромной аудиторией (типа гугл аналитикс или панелей управления AppStore\Windows Store), я часто косяки в раскладке вижу?
Такие, которые на WPF даже новички не делают, ну типа выпадающая менюшка оказалась перекрыта чем-нибудь и в нее попасть нельзя.
Гугл, Аппле и Микрософт не могут css?
ЕА>>Нет не только способа переопределить раскладку, но даже события на resize элемента. G>В таких терминах я бы не стал заниматься layout_ом вообще.
А в каких надо?
Ну предположим хочу, чтоб элементы в паренте радиально расставились, радиус автоматически выбрался максимальный с учетом размеров, а угол задавался для каждого элемента.
Как на html правильно делать?
В WPF будет наследник панельки с переопределенным MeasureOverride\RenderOverride и DependencyProperty для задания угла, вся раскладка пройдет на том же проходе, что и раскладка стандартных панелей, повторно ничего дергать не надо.
Здравствуйте, klopodav, Вы писали:
K>Но почему-то такая фигня происходит: в веб-интерфейсе разных приложений косяки GUI, мешающие жить, почему-то встречаются значительно чаще, чем в десктопных приложениях (даже если рассматривать не наколенные поделки, а серьезные и популярные приложения).
Ой, ну не надо. Достаточно вспомнить все WinForms-приложения, которые не умеют масштабироваться.
Здравствуйте, sfsoft, Вы писали:
vsb>>Можно писать серверный код на JavaScript, если это такая уж проблема. S>Серверный код на JavaScript?!? Развесистую корпоративную бизнес-логику?!? Серьёзно?!?
Да, вполне популярный сейчас выбор.
vsb>>Ну и миллион языков, которые преобразуются в JavaScript, например можно писать серверный и клиентский код на Kotlin. S>То есть ты считаешь нормальной ситуацию, когда статически типизируемый язык (к тому же компилируемый, а не интерпретируемый) нужно преобразовывать в JavaScript? Ничего не кажется странным?
Нет. Чем это принципиально отличается от компиляции в байт-код .NET? Особенно учитывая WebAssembly?
Здравствуйте, Ilya81, Вы писали:
S>>Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно. I>Android, iOS. Или есть примеры web-приложений, которыми наверняка кроме как на desktop'е никто пользоваться не будет?
Ну, в корпоративе таких в избытке. Приложение, веб, которое делается с расчетом чисто на работу в нем определенных ролей пользователей, которые точно работают с настольного рабочего места — вполне обычный случай.
Но, как я писал выше, для корпоратива для выбора веба как основы приложений есть гораздо больше причин чем одна только возможность кросплатформенности пользователей.
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Последние несколько месяцев стало сильно лучше.
Вот вообще не вижу разницы. Глазом — незаметно. Временами он вроде бы норм-норм, а временами — тупит так, что хочется пристрелить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали:
НС>>Они сложны, сложнее браузера современногов понимании. Просто все привыкли. S> Смотря для каких задач. Для браузера даже нет нормальных дизайнеров.
А они там не особо то нужны. Дизайнер WPF есть нормальный, но многие им не пользуются.
Другое дело когда нужна пристелка пикселей. Тут без дизайнера тяжко.
Здравствуйте, sfsoft, Вы писали:
S>Серверный код на JavaScript?!? Развесистую корпоративную бизнес-логику?!? Серьёзно?!?
Ты правда никогда не слышал про node.js?
vsb>>Ну и миллион языков, которые преобразуются в JavaScript, например можно писать серверный и клиентский код на Kotlin. S>То есть ты считаешь нормальной ситуацию, когда статически типизируемый язык (к тому же компилируемый, а не интерпретируемый) нужно преобразовывать в JavaScript? Ничего не кажется странным?
Здравствуйте, vsb, Вы писали:
vsb>Идея React не в реактивности, а в декларативности.
Почему он тогда называется не Declaract?
vsb> Интерфейс описывается декларативно.
Пфф. Этой идее миллион лет в обед.
vsb> А фреймворк вызывает функции рендеринга автоматически, при вычислении состояния, причём только у нужных компонентов.
Это и есть реактивность.
vsb> Такого я не видел никогда, хотя видел немало GUI-фреймворков.
В WPF этого добра полно, а он на 7 лет старше.
НС>>Ну вот честно, верстка HTML на порядок сложнее верстки WPF, не говоря уж о пристрелке пикселей времен MFC, VCL и винформсов. vsb>Не знаю, вопрос привычки.
Нет, это вполне объективно и измеряемо. Формы вполне успешно плодили люди, день назад впервые увидевшие инструмент. А верстке на HTML надо учиться много месяцев, и ты все равно будешь испытывать временами трудности.
vsb> Не видел ничего сложного в HTML вёрстке.
Конечно. К примеру, сделать растягивающийся по вертикали div — просто и интуитивно понятно, да?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>На прошлой работе вполне себе система работала на постгри и сиквеле. В самой системе был язык на основе SQL, транслирующийся в оба диалекта, разрабы осилили.
Здравствуйте, sfsoft, Вы писали:
НС>>Ага, значит таки исключения есть. S>Если ставить вопрос именно так, то нет, там исключений нет. Там какой-то треш, который JavaScript разработчики считают корпоративом.
В вашем понимании "корпоратив" — это то, что пишется для полуподвальной конторы на VisualBasic.NET путём перетаскивания контролов на форму?
Здравствуйте, Cyberax, Вы писали:
C>Я работал с принтером чеков где-то в 2005-м году, там был простой, но немного кривой протокол по RS-232. Наобум взял случайный фискальный накопитель: https://www.sampokkm.ru/fiscalniy-nakopitel-fn-1/ — в описании тот же RS-232.
При чем тут фискальный накопитель? И зачем с ним связываться напрямую? Надеешься счетчики какие скрутить что ли? Так это не корпоративный софт, а совсем-совсем другая ниша.
C>Так что через WebUSB будет очевидный интерфейс — подключаем ФН через USB-RS232 адаптер и всё. Адаптеры RS-232 в USB — это вообще стандартный пример в WebUSB. Дальше остаётся только реализовать протокол общения, что очевидно может делаеться на любом Тюринг-полном языке.
Вот только отладка может занять столько же времени, сколько рисование 100500 форм с обращение к БД в том самом корпоративном софте. Как к слову, там с временными задержками в том самом WebUSB. По этой причине никто напрямую (за малыми исключениями) через RS с ФР не общается, в комплекте всегда имеется библиотеки для разных ОС и языков.
C>Да, и если таки вдруг оказывается, что протокол общения ну никак не реализуется в JS из-за того, что он существует только в виде DLL-ки на VisualBasic 6, то всегда можно просто выделить её в специальный нативный модуль в NodeJS.
Угу, а на клиентском компе не забыть запустить службу/демон.
Здравствуйте, Kerk, Вы писали:
S>>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость? K>Кто-нибудь наверно уже об этом сказал. Но всё равно хотелось бы добавить, что веб-интерфейс всегда говно. Нет вообще примеров более-менее сложного удобного веб-интерфейса. Человечество зашло в тупик.
Salesforce, Slack, Github, ...
Здравствуйте, sfsoft, Вы писали:
S>Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах).
у 99% пользователей чего?
в среднем это не так.
у разных продуктов разные пользователи.
S>И в обозримом будущем альтернатив не видно.
во-первых, уже и так есть OSX, который больше 1% даже у нас в стране, а в странах развитого капитализма так и гораздо больше, не всегда можно пренебречь.
в некоторых областях деятельности бывает так, что чаще можно встретить макбук, нежели ноут на винде.
во-вторых, есть еще андроид. в магазинах, например, из него делают торговые терминалы.
или, например, складские работники могут работать с планшетами на андроиде.
Здравствуйте, LuciferSaratov, Вы писали:
LS>у 99% пользователей чего?
Пользователей в любом офисе любого бизнес-центра (я сейчас не про дизайнерские конторы, а про то, чем у нас вся страна занимается, т.е. продажами). Или в магазинах, ибо большинство торгового оборудования работает только под Windows, как и большинство клиент-банков, кстати, ибо драйверов для ЭЦП под все версии Linux никто не будет писать.
Здравствуйте, vsb, Вы писали:
vsb>Во-первых веб-интерфейс позволяет в будущем переходить на другие системы.
Это из разряда "наше ПО поддерживает работу с разными СУБД". А по факту ни с одной СУБД нормально работать не может. Разрабы не осилили SQL.
vsb>В России вообще-то уже давно продвигается переход на линукс.
Из Казахстана это лучше видно? На Хабре неделю назад пробегала статья про госконтракт на закупку Windows. На 80 млн.рублей. Такой вот Linux.
Поэтому слова есть, а продвижения нет. Разве что на серверах. Но тема не о них.
vsb>Во-вторых веб-интерфейсом одной из систем, которую я писал, внезапно начали пользоваться на андроидном планшете. До этого там была система на дельфи, с ней это было невозможно. А тут админы прокинули VPN, я чуток подправил стили и готово, стоит товарищ в поле и имеет моментальный доступ к информации, для которой раньше ему нужно было звонить в центр и спрашивать у дежурного.
На Delphi так тоже можно. Нативный Андроид клиент вполне рабочий. И для iOS заодно, из тех же самых исходников.
Да, не очень красиво будет, но это корпоратив, тут обычно "ехать", а не "шашечки".
vsb>В-третьих я не согласен с утверждением, что десктоп разработка дешевле. Десктоп разработка остановилась в 90-х и с тех пор ничего по сути нового не появлялось. В вебе разработка уже сейчас более продвинута.
И как это заявление коррелирует с ценой?
vsb>В-четвёртых веб решает проблему обновления, такое понятие, как клиент старой версии исчезает в принципе, а это целый пласт проблем техподдержки. Если ты когда-нибудь поддерживал такое приложение, ты бы это ценил.
Когда-нибудь — это последние 20 лет. Не вижу ни одной проблемы.
vsb>У десктопа есть два преимущества. Первое это доступ ко всем функциям ОС. Например если тебе нужно достучаться до крипто-токена в USB-порту, проблем 0. Из браузера это просто невозможно. Второе это оффлайн-режим. Но в принципе по обоим фронтам веб-приложения наступают, поэтому если закладываться на будущее, эти преимущества уже не столь очевидны.
Начали за здравие, а кончили за упокой
vsb>Собственно весь крах десктоп-разработки иллюстрирует Electron. Всё больше современных приложений выходит для него. А это ведь и есть веб-приложение, сбандленное с браузером.
Electron не демонстрирует ничего, кроме тормозов. Ни одного корпоративного приложения на нем нем нет и не будет.
Здравствуйте, sfsoft, Вы писали:
vsb>>Во-первых веб-интерфейс позволяет в будущем переходить на другие системы.
S>Это из разряда "наше ПО поддерживает работу с разными СУБД". А по факту ни с одной СУБД нормально работать не может. Разрабы не осилили SQL.
Ой, вот не надо. Больная тема. Уже давно поддерживаю систему, в которой разрабы осилили SQL. Да так осилили, что до сих пор с Oracle 9i мигрировать не могут, не то, что на какой-нибудь человеческий постгрес, а даже на 10g.
vsb>>В России вообще-то уже давно продвигается переход на линукс.
S>Из Казахстана это лучше видно?
Новости читаем. С людьми общаемся.
S>На Хабре неделю назад пробегала статья про госконтракт на закупку Windows. На 80 млн.рублей. Такой вот Linux.
А про госконтракты на закупку Linux почему не пишешь? Ручаешься, что таковых нет?
S>Поэтому слова есть, а продвижения нет. Разве что на серверах. Но тема не о них.
У меня другая информация. Продвижение медленно, с треском, но идёт. Скоро только кошки родятся.
vsb>>Во-вторых веб-интерфейсом одной из систем, которую я писал, внезапно начали пользоваться на андроидном планшете. До этого там была система на дельфи, с ней это было невозможно. А тут админы прокинули VPN, я чуток подправил стили и готово, стоит товарищ в поле и имеет моментальный доступ к информации, для которой раньше ему нужно было звонить в центр и спрашивать у дежурного.
S>На Delphi так тоже можно. Нативный Андроид клиент вполне рабочий. И для iOS заодно, из тех же самых исходников.
Ахаха. Ну-ну. То гомно даже щас собирается примерно на семи разных виртуалках, т.к. каждая DLL требует несовместимых компонентов (которые уже давно из интернета исчезли, только и лежат в архивах и не дай бог потеряются). Его на Windows 7 "портировали" 2 года. При этом любой сайт, как бы он плохо ни был написал, в андроидном браузере работать будет.
S>Да, не очень красиво будет, но это корпоратив, тут обычно "ехать", а не "шашечки".
Если сейчас сесть и делать на современной Delphi, ну может чего и выйдет, не пробовал. Ладно, тут сравнение может не совсем корректное.
vsb>>В-третьих я не согласен с утверждением, что десктоп разработка дешевле. Десктоп разработка остановилась в 90-х и с тех пор ничего по сути нового не появлялось. В вебе разработка уже сейчас более продвинута.
S>И как это заявление коррелирует с ценой?
Быстрей пишешь, меньше цена
vsb>>В-четвёртых веб решает проблему обновления, такое понятие, как клиент старой версии исчезает в принципе, а это целый пласт проблем техподдержки. Если ты когда-нибудь поддерживал такое приложение, ты бы это ценил.
S>Когда-нибудь — это последние 20 лет. Не вижу ни одной проблемы.
А я вижу. Постоянно старые версии DLL, невообразимые глюки, новую версию заказчик так боится выкатывать, что предпочитает сидеть со старыми багами, если не совсем критичные. При том, что веб после 18 часов перезапустил за 2 минуты и всё. Скоро в живом режиме будем перезапускать, с нулевым даунтаймом. Это ни в какое сравнение не идёт.
vsb>>Собственно весь крах десктоп-разработки иллюстрирует Electron. Всё больше современных приложений выходит для него. А это ведь и есть веб-приложение, сбандленное с браузером.
S>Electron не демонстрирует ничего, кроме тормозов. Ни одного корпоративного приложения на нем нем нет и не будет.
Microsoft Teams уже не корпоративное приложение? Slack, Trello, это только из того, что я видел.
Здравствуйте, klopodav, Вы писали:
S>>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
K>И есть те, которым веб нафиг не уперся.
Дай попробую угадать, в основном это (около)монополисты на рынке с позицией "жрите что дают"?
K>>И есть те, которым веб нафиг не уперся.
D>Дай попробую угадать, в основном это (около)монополисты на рынке с позицией "жрите что дают"?
Не, не угадал.
Подчеркиваю, речь идет вовсе не обязательно о приложении для широкого круга пользователей.
Если контора заказывает разработку софта для автоматизации и информатизации какой-нибудь своей корпоративной деятельноси — то она закажет этот софт так, чтобы ей было удобно. (причем даже еще подчеркиваю: удобно должно быть не только и не столько работать с самим софтом, сколько работать со всей своей внутренней кухней, составной частью которой является заказываемый софт)
А конечный продукт этой конторы — это может быть вовсе не софт, а, например, жратва, или автомобили, или услуги. И вовсе не обязательно это будет по принипу "жрите что дают", это может быть обычная контора с обычным качественным продуктом.
Здравствуйте, klopodav, Вы писали:
K>И тут возникают варианты, что выбрать.
K>Например, разработчик Вася, которому "куда проще на JavaScript писать", может быстро слабать веб-приложуху на популярном веб-фреймворке. Но, блин, оказывается, что вот тут она работает криво, вот эту хотелку заказчика на этом фреймворке реализовать не получается. А в IE6 это вообще не работатет (да-да, у заказчика у одного некоторых пользоваетелй IE6, и поменять проблематично. Это в случае софта для массового сегмента можно сказать "вот эти пользователи со старыми и экзотическими браузерами пусть идут лесом", а в случее заказного софта придется под имеющиеся системные требования подстраиваться. Вспомним, напримре, что в США до сих пор поддерживаются системы, писаные на Коболе)
K>Вот есть другой разработчик Петя, которые в веб-технологиях очень-очень крут. Он знает, как на вебе в точности реализовать все-все хотелки заказчика, и даже чтобы под IE6 работало. Но, блин, этого Петю еще поди найди — он один такой на тысячу менее квалифицированных разработчиков. И возьмет за разработку Петя очень дорого.
K>А есть третий разработчик Митя, который предлагает десктопное приложение. Его десктопные средства разработки позволяют спокойно обработать напильником приложение под все хотелки заказчика. И при этом ему не требуется быть таким уж виртуозом, и денег за разработку он берет не так много.
K>Вот в этом варианте десктопное приложение — для заказчика весьма выгодный вариант
Какая-то сферическая в вакууме фантастическая ситуация в мире розовых пони, где найти хорошего десктопного разработчика легче и дешевле чем нормального веб
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sfsoft, Вы писали:
S>>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость? G>1) Веб не надо устанавливать и обновлять, это происходит автоматически.
Есть ClickOnce
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, gandjustas, Вы писали:
G>>2) В вебе есть ссылки, которые приходят на почту.
vsb>Ну ссылки в приложение вроде все операционные системы умеют.
Только в вебе тебе не надо ничего дополнительно программировать чтобы ссылки работали. Изначальная архитектура веб-приложения делает возможной адресацию с помощью ссылок. В декстопе это надо программировать.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, sfsoft, Вы писали:
S>>>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость? G>>1) Веб не надо устанавливать и обновлять, это происходит автоматически. S> Есть ClickOnce
Есть. Только автообновление clickonce надо программировать, в вебе оно дается автоматически.
Здравствуйте, Serginio1, Вы писали:
vsb>>В-третьих я не согласен с утверждением, что десктоп разработка дешевле. Десктоп разработка остановилась в 90-х и с тех пор ничего по сути нового не появлялось. В вебе разработка уже сейчас более продвинута.
S> Неужто WPF в 90 был?
Его подходы из 90-х. MVC, XML, вот это вот всё.
S> Кстати какой HTML дизайнер лучше выбрать?
Без понятия, не пользуюсь. Советую писать HTML руками. Дизайнеры только мешают.
G>>>1) Веб не надо устанавливать и обновлять, это происходит автоматически. S>> Есть ClickOnce G>Есть. Только автообновление clickonce надо программировать, в вебе оно дается автоматически.
То есть всякие электроны автоматически обновляются?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Serginio1, Вы писали:
vsb>>>В-третьих я не согласен с утверждением, что десктоп разработка дешевле. Десктоп разработка остановилась в 90-х и с тех пор ничего по сути нового не появлялось. В вебе разработка уже сейчас более продвинута.
S>> Неужто WPF в 90 был?
vsb>Его подходы из 90-х. MVC, XML, вот это вот всё.
Ну тогда и HTML оттуда же S>> Кстати какой HTML дизайнер лучше выбрать?
vsb>Без понятия, не пользуюсь. Советую писать HTML руками. Дизайнеры только мешают.
Вот именно. Какая же в этом простота? А учитывая переопределение css и прочее так вообще понять как будет в конечном счете выглядеть страница весьма сложно.
Так, что насчет продвинутости это очень спорно. НТML это анахронизм с кучами костылей и атавизмами.
Многие до сих пор используют Win Forms потому, что все понятно и как проектируешь так в итоге и видишь в конечном итоге.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
vsb>>>>В-третьих я не согласен с утверждением, что десктоп разработка дешевле. Десктоп разработка остановилась в 90-х и с тех пор ничего по сути нового не появлялось. В вебе разработка уже сейчас более продвинута.
S>>> Неужто WPF в 90 был?
vsb>>Его подходы из 90-х. MVC, XML, вот это вот всё. S> Ну тогда и HTML оттуда же
HTML оттуда же (и в этом большая проблема), но он с тех пор сильно развился, а JavaScript современный это уже совсем другой язык. А фреймворки и вовсе придумали небывалые подходы. Тот же React — ничего подобного раньше не было, это абсолютная инновация.
S>>> Кстати какой HTML дизайнер лучше выбрать?
vsb>>Без понятия, не пользуюсь. Советую писать HTML руками. Дизайнеры только мешают. S> Вот именно. Какая же в этом простота?
А что сложного?
S>А учитывая переопределение css и прочее так вообще понять как будет в конечном счете выглядеть страница весьма сложно.
На практике проблем нет. Да и понимать не нужно, правишь код, жмёшь альт-таб и hot reload уже показал все твои изменения.
S>Так, что насчет продвинутости это очень спорно. НТML это анахронизм с кучами костылей и атавизмами.
HTML выгораживать не буду. Речь не о нём, а о сонме технологий. HTML и часть CSS действительно создавались не для приложений, а для документов. Но это не слишком большая проблма на практике.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Serginio1, Вы писали:
vsb>>>>>В-третьих я не согласен с утверждением, что десктоп разработка дешевле. Десктоп разработка остановилась в 90-х и с тех пор ничего по сути нового не появлялось. В вебе разработка уже сейчас более продвинута.
S>>>> Неужто WPF в 90 был?
vsb>>>Его подходы из 90-х. MVC, XML, вот это вот всё. S>> Ну тогда и HTML оттуда же
vsb>HTML оттуда же (и в этом большая проблема), но он с тех пор сильно развился, а JavaScript современный это уже совсем другой язык. А фреймворки и вовсе придумали небывалые подходы. Тот же React — ничего подобного раньше не было, это абсолютная инновация.
Что касается корпоративных приложений, то вполне подойдет и Xamarin.Forms если изыски не нужны.
Вернее для Windows можно использовать WPF, а для остального Xamarin.Forms. При этом вся кодовая база на .Net
vsb>На практике проблем нет. Да и понимать не нужно, правишь код, жмёшь альт-таб и hot reload уже показал все твои изменения.
Я это знаю. Иногда приходится и Xaml руками править и AXML и даже Windows Forms (это вообще жесть), с HTML работал раньше тоже.
И тоже была надежна на ангулар и .Net https://habr.com/ru/post/321898/ S>>Так, что насчет продвинутости это очень спорно. НТML это анахронизм с кучами костылей и атавизмами.
vsb>HTML выгораживать не буду. Речь не о нём, а о сонме технологий. HTML и часть CSS действительно создавались не для приложений, а для документов. Но это не слишком большая проблма на практике.
На самом деле как бы там ни было на мобильных сейчас натив рулит, для десктопов разный зоопарк как натива так и вэб технологий (как электрона так и плагинов).
И при этом все развивается и это хорошо
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали:
vsb>HTML выгораживать не буду. Речь не о нём, а о сонме технологий. HTML и часть CSS действительно создавались не для приложений, а для документов. Но это не слишком большая проблма на практике.
Так в MFC базовый класс кажись так и назывался документ(данные) и представление.
1) У веба проблема в невозможности бесшовного хранения состояния — между гэт и пост запросами никакой взаимосвязи, все руками.
2) вторая проблема — это взаимодействие с системой: доступ к каталогам и файлам, устройствам и т.п.
Хотя частично это и решается через различные интерфейсы.
3) разные языки на фронте и бэке. Хотя есть clojureScript и Fable(F#), но это сложность в использовании.
Есть WASM (F# Bolero, Blazor из того, что я знаю) там тоже проблема работы с состоянием осталась, еще добавились сложность доступа к HttpContext, по сути его нет.
Здравствуйте, Serginio1, Вы писали:
S> Я это знаю. Иногда приходится и Xaml руками править и AXML и даже Windows Forms (это вообще жесть), с HTML работал раньше тоже.
Что же всем WinForms не нравится? Это надежный, не требовательный к ресурсам интерфейс.
Что-то бог сделал не так, что люди постоянно всем недовольны.
Здравствуйте, varenikAA, Вы писали:
vsb>>HTML выгораживать не буду. Речь не о нём, а о сонме технологий. HTML и часть CSS действительно создавались не для приложений, а для документов. Но это не слишком большая проблма на практике.
AA>Так в MFC базовый класс кажись так и назывался документ(данные) и представление. AA>1) У веба проблема в невозможности бесшовного хранения состояния — между гэт и пост запросами никакой взаимосвязи, все руками.
Непонятно, о чём речь. Состояние на сервере хранится в сессии. В браузере тоже есть механизмы для хранения состояния, тот же localStorage. Чего тут ещё можно желать?
AA>3) разные языки на фронте и бэке.
Можно писать серверный код на JavaScript, если это такая уж проблема. Ну и миллион языков, которые преобразуются в JavaScript, например можно писать серверный и клиентский код на Kotlin.
Собственно, если вопрос в том, почему?
ХЗ, ну нравится боссам веб.
Если бы писал свою приложуху, то наверно все-таки без веба.
Опять же, надо все время задавать себе и заказчику вопрос: ЗАЧЕМ?
Если, конечно, еще не устали. Ибо люди почти не меняются.
Иногда добиться вменяемого процесса взаимодействия сложно.
Вот видел пару раз ТЗ: каждая табличка расписана, все аттрибуты имеют тип, размер, обязательность.
Кейсы все прописаны. Есть тестовый контур для развертывания, стенды для тестирования.
Но чаще всего так: надо запилить приложуху, аналитик накидывает в ворде примерно как должно выглядеть приложение.
Потом босс говорит как быстрее веб, десктоп? пользоваться будем из под мака. а у разрабов винда.
вообщем, творческая свобода.
Здравствуйте, vsb, Вы писали:
vsb>Microsoft Teams уже не корпоративное приложение? Slack, Trello, это только из того, что я видел.
Если честно, то вот Skype for Business был хорошо реализован, но рукожопно спроектирован.
А вот Teams — ровно наоборот: то есть спроектирован он нормально, и пользоваться им крайне удобно. А вот реализован он — отвратительно. Не знаю, электрон ли тому виной, но память и CPU он жрёт как не в себя; регулярно тормозит на ровном месте. Тупо переключение в него по alt-tab занимает секунды, а то и вовсе "ой, у нас что-то пошло не так, давайте-ка перезапустимся".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, sfsoft, Вы писали:
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
Десктопная разработка давно уже требует больше ресурсов, чем веб. С современными фреймворками, GraphQL и прочей радостью можно писать интерфейс прямо со слов заказчика. Многие вещи, которые в WinForms делаются через задницу, реализуются элементарно: стилизация, динамическое создание интерфейса на основании данных, шаблоны и т.п.
При этом всём уже эволюционировали мощные инструменты разработки и тестирования. Например, у нас web-интерфейс при каждом коммите автоматически тестируется на все стандартные сценарии работы. С автоматическим обнаружением вещей типа наезжающих друг на друга контролов. В теории такое возможно и для классического WinForms/WPF, но на практике я такого не видел.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, Serginio1, Вы писали:
S>> Я это знаю. Иногда приходится и Xaml руками править и AXML и даже Windows Forms (это вообще жесть), с HTML работал раньше тоже.
AA>Что же всем WinForms не нравится? Это надежный, не требовательный к ресурсам интерфейс. AA>Что-то бог сделал не так, что люди постоянно всем недовольны.
" А мне всегда чего то не хватает, зимою лета, осенью весны"
Не всем Kolesiki нравится, мне тоже. Речь шла о ручном редактировании форм без редактора!
Большинству то как раз WinForms нравится они очень просты.
и солнце б утром не вставало, когда бы не было меня
S>>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость? C>Десктопная разработка давно уже требует больше ресурсов, чем веб. С современными фреймворками, GraphQL и прочей радостью можно писать интерфейс прямо со слов заказчика. Многие вещи, которые в WinForms делаются через задницу, реализуются элементарно: стилизация, динамическое создание интерфейса на основании данных, шаблоны и т.п.
C>При этом всём уже эволюционировали мощные инструменты разработки и тестирования.
Охотно верю, что в веб-технологиях крутые инструменты есть.
Но почему-то такая фигня происходит: в веб-интерфейсе разных приложений косяки GUI, мешающие жить, почему-то встречаются значительно чаще, чем в десктопных приложениях (даже если рассматривать не наколенные поделки, а серьезные и популярные приложения).
А это наводит на мысль, что либо в веб-технологиях что-то развито еще недостаточно хорошо, либо оно развито хорошо, но слишком сложно для массового использования. (либо развито хорошо и существует простая методика использования, но эта методика хранится как сакральное знание только для избранных)
Вот буквально недавно натолкнулся на такой пример:
видишь суслика кнопочки? И я тоже нет. А они есть...
Здравствуйте, Sinclair, Вы писали:
S>Если честно, то вот Skype for Business был хорошо реализован, но рукожопно спроектирован.
Это ж даже не Skype а переименованное abomination по имени Lync.
S>Не знаю, электрон ли тому виной, но память и CPU он жрёт как не в себя
Электрон. Его чтоб более менее работало надо так готовить что проще сразу native написать.
Здравствуйте, gandjustas, Вы писали:
G>6) В ебе самый мощный layout-движок из всех существующих.
Может и мощный, но дебильный. Вот это, например — полный фейл, с которым давно живут, и непонятно, как его можно системно исправить. И такого бреда полно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Kolesiki, Вы писали:
K>Чушь какая... никакого даже "де-факто" нет. Как были WPF'ы с WinForms'ами, так и остались.
Хм, я верю, что WinForms, WPF и VCL остались во многих местах. Я даже знаю эти многие места. Но речь шла о новых приложениях.
Есть примеры разработки именно нового софта на WinForms, WPF и VCL, а не на каком-нибудь Angular'е?
Здравствуйте, ononim, Вы писали:
S>> Неужто WPF в 90 был? O>xul был, те же яйца, но не распиаренные
Суть не в том, что были некие XML или xul, а реализация того, что задекларировано.
Напрмер UWP года 4 догонял WPF хотя оба и на DirectX.
Но 1 работает и под ARM и x86-64, а второй только под x86-64.
Задекларировать можно что угодно и на том же HTML проблема реализовать
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, sfsoft, Вы писали:
G>>6) В ебе самый мощный layout-движок из всех существующих. ЕА>Настолько мощный, что почти в любом веб-приложении что-нибудь на что-нибудь накладывается
Не понял о чем речь.
Если ты в CSS не можешь, то накладывается, да.
ЕА>Если серьезно, спорное утверждение. В WPF\UWP можно получить любую раскладку переопределив пару методов. Практически полный аналог flex layout мы писали очень давно и заняло это пару дней.
Вот так обычно и получается. Вроде как то же самое, но тут пару дней писать, там тоже пару дней писать. Потом еще пару месяцев отлаживать.
А потом WPF пытаешься запустить на удаленном рабочем столе и оно тормозит аццки.
ЕА>В html приложениях обычно адская смесь из css flex, css grid и абсолютного позиционирования, и любой глобальный css стиль может случайно все порушить.
Если не умеешь, то можно и в любом другом движке сломать что-либо. Для тех то не может самостоятельно в CSS есть bootstrap и прочие радости.
ЕА>А если нужно что-то не стандартное, то я вообще не знаю, как это нужно делать.
Вот какбы суть в выделенном. "Не знаю" не означает "нельзя" и даже не означает больших затрат.
ЕА>Нет не только способа переопределить раскладку, но даже события на resize элемента.
В таких терминах я бы не стал заниматься layout_ом вообще.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, gandjustas, Вы писали:
G>>6) В ебе самый мощный layout-движок из всех существующих.
Ops>Может и мощный, но дебильный. Вот это, например — полный фейл, с которым давно живут, и непонятно, как его можно системно исправить. И такого бреда полно.
А зачем его исправлять? Если тебе не нравится как это работает, то это вовсе не означает что оно работает неверно.
Здравствуйте, gandjustas, Вы писали:
G>А зачем его исправлять? Если тебе не нравится как это работает, то это вовсе не означает что оно работает неверно.
То, что работает верно, в соответствии со спецификацией, еще не значит, что спецификация хорошая.
Оно работает не очевидно, это какая-то магия, сбивающая с толку. Что в этом хорошего?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vsb, Вы писали:
vsb>Можно писать серверный код на JavaScript, если это такая уж проблема.
Серверный код на JavaScript?!? Развесистую корпоративную бизнес-логику?!? Серьёзно?!?
vsb>Ну и миллион языков, которые преобразуются в JavaScript, например можно писать серверный и клиентский код на Kotlin.
То есть ты считаешь нормальной ситуацию, когда статически типизируемый язык (к тому же компилируемый, а не интерпретируемый) нужно преобразовывать в JavaScript? Ничего не кажется странным?
Здравствуйте, sfsoft, Вы писали:
S>Есть примеры разработки именно нового софта на WinForms, WPF и VCL, а не на каком-нибудь Angular'е?
Есть. Не так давно довелось. Приложение должно было получать данные по UDP с разных источников и быстро реагировать на изменения в данных.
При этом устанавливается на весьма ограниченное число рабочих мест. Было сделано на WPF.
Там где нужно общение с железом или хотя бы плотно с файлами на рабочем компе пользователя — там десктопные приложения подходят лучше веба. Но для огромного количества корпоративных задач этого не требуется — и веб там процветает.
Здравствуйте, gandjustas, Вы писали:
G>Проблема в том, что ты в 99% случаев в вебе видишь наколенные поделки, а на десктопе серьезные приложения.
А можно ссылку на серьёзные приложения в вебе? Чтобы с кучей форм, таблиц и т.д. В общем как в кровавом энтерпрайзе.
Ну и чтобы это было вменяемо по разработке небольшой командой. Или серьёзный веб это не небольшие команды, да?
Здравствуйте, sfsoft, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Проблема в том, что ты в 99% случаев в вебе видишь наколенные поделки, а на десктопе серьезные приложения.
S>А можно ссылку на серьёзные приложения в вебе? Чтобы с кучей форм, таблиц и т.д. В общем как в кровавом энтерпрайзе. S>Ну и чтобы это было вменяемо по разработке небольшой командой. Или серьёзный веб это не небольшие команды, да?
Ну каждое первое примерно.... Я вот недавно с SAP Ariba познакомился. А еще давно работаю с Dynamics CRM. Там кучи форм и таблиц.
Сколько там людей работало — хз.
В целом в куче форм и таблиц сложного ничего нет. Для веба уже давно есть компоненты, куда только датасорс подходящий подставить надо. У меня вот ОДИН разработчик пилит жутконавороченную формотаблицу с помощью kendoui. Как его делать на десктопе — хз, ведь в отличие от десктопа HTML и CSS всегда "торчит наружу" и его можно поправить.
Здравствуйте, Евгений Акиньшин, Вы писали:
G>>Если ты в CSS не можешь, то накладывается, да.
ЕА>То что я не умею это еще полбеды (я-то реально html не умею, никогда ничего сложнее лендинга не делал). ЕА>Но вот почему у приложений с огромной аудиторией (типа гугл аналитикс или панелей управления AppStore\Windows Store), я часто косяки в раскладке вижу?
Потому что такие приложения делаются студентами. Серьзно.
ЕА>Такие, которые на WPF даже новички не делают, ну типа выпадающая менюшка оказалась перекрыта чем-нибудь и в нее попасть нельзя. ЕА>Гугл, Аппле и Микрософт не могут css?
Не все могут. В этом одновременно и недостаток и преимущество веба. С одной стороны легко делать даже студенту, с другой стороны без достаточной клвалификации полчится говнеццо. Помгают инструменты, типа bootstrap, чтобы не косячить.
ЕА>>>Нет не только способа переопределить раскладку, но даже события на resize элемента. G>>В таких терминах я бы не стал заниматься layout_ом вообще.
ЕА>А в каких надо? ЕА>Ну предположим хочу, чтоб элементы в паренте радиально расставились, радиус автоматически выбрался максимальный с учетом размеров, а угол задавался для каждого элемента. ЕА>Как на html правильно делать?
В данном случае https://www.w3schools.com/jsref/event_onresize.asp
Но это скорее исключение.
Основная задача — сделать так, чтобы окно корректно отображалось при изменении размеров когда в нем самые обычные элементы — картинки, надписи, кнопки, поля ввода итд. Даже с WPF половина начинающих буксует на этом месте. Или например сделать "прилипшую" планку при скролле вниз, если это не стандартный датагрид.
Здравствуйте, Cyberax, Вы писали:
C>Ой, ну не надо. Достаточно вспомнить все WinForms-приложения, которые не умеют масштабироваться.
Это проблема не WinForms, а проблема кривых рук.
У нас, например, не только align с anchors нормально работают, но и DPI до 200% поддерживаются, включая подстановку правильного размера ресурсов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Евгений Акиньшин, Вы писали:
G>>>Если ты в CSS не можешь, то накладывается, да.
ЕА>>То что я не умею это еще полбеды (я-то реально html не умею, никогда ничего сложнее лендинга не делал). ЕА>>Но вот почему у приложений с огромной аудиторией (типа гугл аналитикс или панелей управления AppStore\Windows Store), я часто косяки в раскладке вижу? G>Потому что такие приложения делаются студентами. Серьзно.
У меня иногда впечатление, что детсадовцами
ЕА>>>>Нет не только способа переопределить раскладку, но даже события на resize элемента. G>>>В таких терминах я бы не стал заниматься layout_ом вообще.
ЕА>>А в каких надо? ЕА>>Ну предположим хочу, чтоб элементы в паренте радиально расставились, радиус автоматически выбрался максимальный с учетом размеров, а угол задавался для каждого элемента. ЕА>>Как на html правильно делать? G>В данном случае https://www.w3schools.com/jsref/event_onresize.asp G>Но это скорее исключение.
Ну про это даже я знаю, но работает только на верхнем уровне для body. Есть еще ResizeObserver но он в сафари не работает.
Если захочется например сделать радиальную менюшку в виде независимого, которая сама подгоняет свой вид, когда ее размеры изменились, то придется извращаться.
Собственно,именно это я и хотел сказать — система навороченная, но не расширяемая, в нестандартных ситуациях обкладываешься костылями по самое нихочу.
G>Основная задача — сделать так, чтобы окно корректно отображалось при изменении размеров когда в нем самые обычные элементы — картинки, надписи, кнопки, поля ввода итд. Даже с WPF половина начинающих буксует на этом месте. Или например сделать "прилипшую" планку при скролле вниз, если это не стандартный датагрид.
G>В целом в куче форм и таблиц сложного ничего нет. Для веба уже давно есть компоненты, куда только датасорс подходящий подставить надо. У меня вот ОДИН разработчик пилит жутконавороченную формотаблицу с помощью kendoui. Как его делать на десктопе — хз, ведь в отличие от десктопа HTML и CSS всегда "торчит наружу" и его можно поправить.
Проблема в том, что правишь CSS в одном месте, а вылезет в другом.
Кстати про ксамарин формы Задание стиля приложений Xamarin.Forms с помощью каскадных таблиц стилей (CSS)
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, sfsoft, Вы писали:
G>>Проблема в том, что ты в 99% случаев в вебе видишь наколенные поделки, а на десктопе серьезные приложения. S>А можно ссылку на серьёзные приложения в вебе? Чтобы с кучей форм, таблиц и т.д. В общем как в кровавом энтерпрайзе.
Идём на https://www.salesforce.com/products/ и смотрим.
Здравствуйте, Cyberax, Вы писали:
vsb>>>Ну и миллион языков, которые преобразуются в JavaScript, например можно писать серверный и клиентский код на Kotlin. S>>То есть ты считаешь нормальной ситуацию, когда статически типизируемый язык (к тому же компилируемый, а не интерпретируемый) нужно преобразовывать в JavaScript? Ничего не кажется странным? C>Нет. Чем это принципиально отличается от компиляции в байт-код .NET? Особенно учитывая WebAssembly?
The .NET runtime used by Blazor WebAssembly is doing IL interpretation – there’s no JIT – so this does affect the performance of CPU intensive workloads. For .NET 5 we are looking at adding support for ahead of time (AoT) compilation that we enable precompiling hot paths to WebAssembly as a way to improve runtime performance.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>В целом в куче форм и таблиц сложного ничего нет. Для веба уже давно есть компоненты, куда только датасорс подходящий подставить надо. У меня вот ОДИН разработчик пилит жутконавороченную формотаблицу с помощью kendoui. Как его делать на десктопе — хз, ведь в отличие от десктопа HTML и CSS всегда "торчит наружу" и его можно поправить. S> Проблема в том, что правишь CSS в одном месте, а вылезет в другом.
Значит плохой CSS и непонимание его работы.
S>Кстати про ксамарин формы Задание стиля приложений Xamarin.Forms с помощью каскадных таблиц стилей (CSS)
Это хорошо.
Здравствуйте, klopodav, Вы писали:
K>вот тут она работает криво, вот эту хотелку заказчика на этом фреймворке реализовать не получается. А в IE6 это вообще не работатет
Т.е. там примерно Windows XP, а может даже Windows 98?
K>А есть третий разработчик Митя, который предлагает десктопное приложение. Его десктопные средства разработки позволяют спокойно обработать напильником приложение под все хотелки заказчика.
Не позволят. В 2020-м году разрабатывать софт с обратной совместимостью с XP можно, но не легко и просто, а рыдая и матерясь. А чтоб ещё и под Windows 98 — вообще Адъ и Израиль. Это ж либо плюсы нужны, либо старые версии дельфи.
K>и денег за разработку он берет не так много.
Здравствуйте, sfsoft, Вы писали:
S>Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
Android, iOS. Или есть примеры web-приложений, которыми наверняка кроме как на desktop'е никто пользоваться не будет?
Здравствуйте, varenikAA, Вы писали:
AA>Что же всем WinForms не нравится? Это надежный, не требовательный к ресурсам интерфейс. AA>Что-то бог сделал не так, что люди постоянно всем недовольны.
В котором смысле надёжный? Нетребовательный к ресурсам — ну, если только в плане отсутствия GPU, но это ещё до сих пор актуально? Ну и да, VS2005 не такой тяжёлый, конечно, но если речь о коммерческой разработке, это значимый критерий?
А на счёт, кстати, нетребовательности к ресурсам — точно проиграет MFC. А какие преимущества перед ним. Сложный layout и там, и там придётся задавать в коде, к тому ж на WinForms через задний проход. Получается, недостатки есть, достоинств не вижу.
Здравствуйте, gandjustas, Вы писали:
G>Основная задача — сделать так, чтобы окно корректно отображалось при изменении размеров когда в нем самые обычные элементы — картинки, надписи, кнопки, поля ввода итд. Даже с WPF половина начинающих буксует на этом месте. Или например сделать "прилипшую" планку при скролле вниз, если это не стандартный датагрид.
С последним — в чём сложность? Ведь не обязательно прямо его и пихать внутрь ScrollView? Ну а template в 10 местах использовать — в WPF нет ничего проще, нужный DataContext перекинуть — тоже проблемы не вижу.
А с остальным — тоже не понимаю сложности. Даже если расположение нестандартное, нужно лишь правильно реализовать MeasureOverride. Неужели бывают варианты проще, и где-то какой-то т. с. AI всё правильно разместит?
Здравствуйте, Cyberax, Вы писали:
C>Так и неправильные веб-приложения — проблема кривых рук. На WinForms реально нетривиально делать масштабирующиеся формы, кроме самых простейших.
На WinForms — согласен. На TurboVision ещё сложнее, наверно, было б, только не очень нужно было в текстовом режиме экрана. А когда графический режим для обычных приложений стал ходовым, появились и более подходящие инструменты.
Здравствуйте, sfsoft, Вы писали:
S>Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
S>у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
В корпоративе у 99% пользователей то, что официально принято как разрешённый корпоративный тул. Никто не будет держать разношёрстный sysops-отряд ради прихотей каждого из многих тысяч сотрудников.
Здравствуйте, sfsoft, Вы писали:
S>Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
S>Основным аргументом выбора веб-интерфейса при разработке ПО, при этом, является аргумент "пофигу на ОС, хоть Вин, хоть Линь, хоть Мак". Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
Если в команде есть ui-щики, то скорость разработки уже будет за вебом, потому что задача хорошо паралеллится.
Второе — веб хорошо интегрируется с другими системами, которые сделаны на вебе.
Третье — доступ к системе со сторонних компьютеров — не надо ничего устанавливать и настраивать, сразу все работает.
Четвертое — можно делиться ссылками на отдельные разделы приложения, добавлять в закладки.
Пятое — лучше в плане безопасности и разделения прав доступа — можно на сетевом уровне блокировать доступ к отдельным разделам приложения.
Шестое — так как разработка идет на низкоуровневом языке разметки, больше вольностей в создании компонентов, стили и пр..
Здравствуйте, Явь-Истъ, Вы писали:
ЯИ>Если в команде есть ui-щики, то скорость разработки уже будет за вебом, потому что задача хорошо паралеллится.
Допустим. Но увеличивается в расходах. Как минимум на зарплату верстальщиков/CSS-ников/JavaScript-истов.
ЯИ>Второе — веб хорошо интегрируется с другими системами, которые сделаны на вебе.
Интеграция систем между не имеет никакого отношения веб/не-веб.
Тем более речь шла про приложения, а не про систему. Десктоп-приложения тоже вполне себе умеют использовать веб, как поставщика данных. REST он и для десктопа и для веб одинаковый.
ЯИ>Третье — доступ к системе со сторонних компьютеров — не надо ничего устанавливать и настраивать, сразу все работает.
С каких таких "сторонних" компьютеров в корпоративе?
ЯИ>Четвертое — можно делиться ссылками на отдельные разделы приложения, добавлять в закладки.
Ты уже не первый пишешь, про этот юзкейз. Может и удобно, не знаю. У меня в браузере нет закладок. Перестал ими пользоваться, когда понял, это нисколько не помогает эффективности работы.
ЯИ>Пятое — лучше в плане безопасности и разделения прав доступа — можно на сетевом уровне блокировать доступ к отдельным разделам приложения.
Т.е. мы к приложению еще одну нашлепку приделаем, вместо нормальной системы безопасности. Логично, чё.
ЯИ>Шестое — так как разработка идет на низкоуровневом языке разметки, больше вольностей в создании компонентов, стили и пр..
S>Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
Не сказал бы.
В вебе больше вероятность, что сделают что-нибудь не так, и самые примитивные функции UI будут тормозить и глючить.
Очень большой зоопарк стилей и подходов, кнопки — не кнопки, а картинки, как их увидел дизайнер, гиперссылки под цвет основного текста и без подчеркивания, и прочее, и прочее, а в каждом веб-приложении все это по-своему.
С приходом wpf и на десктопе начали такое делать. Ярко, наляписто и с кучей интерфейсных багов, похоже, все время разработки уходит на верстку xaml.
Вот тут соседняя тема — на чем писать интерфейс для линукса. Или на чем писать кроссплатформенный интерфейс. А когда веб, особо вопросов не возникает.
Обновить деплой на кубере с модулем веб-интерфейса — пара минут. А сколько займет времени обновление дейсктоп проги на сотнях, тысячах компьютерах?
Собственно, когда IBM скооперировался с SUN и выпустил спецификацию J2EE, уже тогда веб интерфейс стал основным. Это было еще в прошлом веке. Это видимо из-за специфики корпоративных систем — они очень часто меняются.
Когда бэк пишется для веба, он генерит json, поэтому с бэком можно взаимодействовать напрямую, вне зависимости от графической оболочки.
Поэтому удел десктопа — это навороченные и редко меняющиеся интерфейсы.
Здравствуйте, Явь-Истъ, Вы писали:
ЯИ>А сколько займет времени обновление дейсктоп проги на сотнях, тысячах компьютерах?
Ровно столько же, а конкретнее столько, сколько займет обновление базы данных и копирование новых исполняемых файлов (для веб-интерфейса всё тоже самое). А дальше при правильно построенной системе обновления файлы с сервера автоматически перекочуют на клиентов при запуске ПО. Не вижу проблем, если честно.
ЯИ>Когда бэк пишется для веба, он генерит json, поэтому с бэком можно взаимодействовать напрямую, вне зависимости от графической оболочки.
Я разве не согласен с тем, что бэк можно вызывать откуда угодно? В том числе и из десктопного приложения. Я нигде не упоминал про клиент-серверную архитектуру.
ЯИ>Поэтому удел десктопа — это навороченные и редко меняющиеся интерфейсы.
Здравствуйте, sfsoft, Вы писали:
S>Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
S>Основным аргументом выбора веб-интерфейса при разработке ПО, при этом, является аргумент "пофигу на ОС, хоть Вин, хоть Линь, хоть Мак". Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
Ну, вообще, веб интерфейс имеет ряд очевидных преимуществ, которые проявляются именно в корпоративной среде:
* Кроссплатформенность. Да, в корпоративном секторе у всех винда. Но винда это не одна система, есть win32 и win64, есть 7, 8, 10, я не говорю про более старые версии. Они конечно все совместимы друг с другом, но всегда могут вылезти мелкие ньюансы.
Не стОит забывать про Mac, это конечно редкость, но единственный Macbook скорее всего будет у самого главного начальника. И он будет искренне не понимать, почему программа, прекрасно работающая на нищебродских офисных компах не открывается на его премиальном vip ноутбуке, уж не заговор ли это, чтобы специально что-то от него скрыть.
Ну и конечно же в самый неожиданный момент вдруг выясяется, что программа просто обязана работать у кого-то на планшете, чтоб он мог показать графики и реальные данные на неформальных переговорах с важными партнерами...
* Обновление. Web гарантирует, что у всех пользователей всегда будет самая последняя версия. Все мучения с поддержкой разных версий, обновлениями для каждого пользователя, и "почему когда я уходил в отпуск все работало, а когда вернулся ничего не работает!!! я ничего не трогал!!!" остаются в прошлом.
*На десктоп программу как правило надо устанавливать, и как правило пользователи сами это сделать не могут. Соответственно, если у пользователя новый комп, или пользователя пересадили на другое место, или он поехал в коммандировку в другой офис или еще что нибудь, десктопное приложение ему должны будут установить админы. А в больших организациях для этого еще какие-нибудь апрувы от кого-нибудь надо получать. Веб приложение он спокойно откроет с любой машины.
*Хранение данных и бэкапы. В десктоп приложениях много всего хранится локально. В Web все хранится на сервере, бэкап сервера проще сделать, ну и в российских реалиях это может обезопасить от различных наездов с изыманием всех компьютеров сотрудников. Чтобы изъять сервер его надо еще найти, а он может быть вообще в облаке.
На телефонах с планшетами тоже она? https://gs.statcounter.com/os-market-share
S> (ключевое слово пользователей, а не разработчиков и не на серверах).
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
Да потому что классический десктоп в целом теряет позиции. В копроративе, к примеру, все более популярны всякие неттопы, а там далеко не всегда винда, да и с локалт=ьными ресурсами не так чтобы, тяжелые приложения не запустишь.
Здравствуйте, klopodav, Вы писали:
K>Вспомним, напримре, что в США до сих пор поддерживаются системы, писаные на Коболе)
Ну ты очень точное направление привел куда движется разработка заказного десктопа, молодец.
K>Вот в этом варианте десктопное приложение — для заказчика весьма выгодный вариант
Для маргинального заказчика. Для Пети может его и хватит, а для фирмы покрупнее уже не наскребешь.
Здравствуйте, sfsoft, Вы писали:
vsb>>Во-первых веб-интерфейс позволяет в будущем переходить на другие системы. S>Это из разряда "наше ПО поддерживает работу с разными СУБД". А по факту ни с одной СУБД нормально работать не может. Разрабы не осилили SQL.
На прошлой работе вполне себе система работала на постгри и сиквеле. В самой системе был язык на основе SQL, транслирующийся в оба диалекта, разрабы осилили.
На текущей новый продукт с самого начала работает на постгри и сиквеле, тесты гоняются на обоих и пока особых проблем нет. В качестве прослойки linq2db, который в 95% случаев осиливает SQL лучше, чем некоторые осилившие SQL разрабы.
vsb>>В России вообще-то уже давно продвигается переход на линукс. S>Из Казахстана это лучше видно?
В РФ тоже. На бюджетном рынке систему под винду протолкнуть очень непросто.
S> На Хабре неделю назад пробегала статья про госконтракт на закупку Windows. На 80 млн.рублей. Такой вот Linux.
Ну так пласт win-only софта огромен, его так просто не перепишешь. Так что в контрактах на винду ничего удивительного нет. Ты лучше поищи заказ на софт windows only.
S>Поэтому слова есть, а продвижения нет.
Ты сколько продуктов для бюджетного сектора сделал, что так уверенно утверждаешь? Или, может, у теба какая статистика на тему есть, сколько нового софта пишется под винду?
vsb>>Собственно весь крах десктоп-разработки иллюстрирует Electron. Всё больше современных приложений выходит для него. А это ведь и есть веб-приложение, сбандленное с браузером. S>Electron не демонстрирует ничего, кроме тормозов. Ни одного корпоративного приложения на нем нем нет и не будет.
Здравствуйте, Sinclair, Вы писали:
S>А вот Teams — ровно наоборот: то есть спроектирован он нормально, и пользоваться им крайне удобно. А вот реализован он — отвратительно. Не знаю, электрон ли тому виной, но память и CPU он жрёт как не в себя; регулярно тормозит на ровном месте. Тупо переключение в него по alt-tab занимает секунды, а то и вовсе "ой, у нас что-то пошло не так, давайте-ка перезапустимся".
Здравствуйте, Ночной Смотрящий, Вы писали:
vsb>>Тот же React — ничего подобного раньше не было, это абсолютная инновация.
НС>Реактивность на десктопе была когда еще веб не родился, а идея изменения хтмл при помощи компараторов — она сугубо HTML специфична.
Идея React не в реактивности, а в декларативности. Интерфейс описывается декларативно. А фреймворк вызывает функции рендеринга автоматически, при вычислении состояния, причём только у нужных компонентов. Такого я не видел никогда, хотя видел немало GUI-фреймворков.
Причём, помимо прочего, эта концепция позволяет реализовать множество очень крутых штук. К примеру redux hot reload: помимо состояния записываются все шаги, которые привели к этому состоянию и при изменении кода они проигрываются с начала, в итоге получается возможность менять код и иметь уже изменённое состояние, в том числе и возможность "путешествия во времени" или простой отладки, если не сразу понятно, откуда взялось такое состояние, это можно посмотреть по шагам. Или, при репорте бага, можно последние шаги включить в отчёт — тоже будет гораздо понятней, почему такое состояние получилось.
НС>Ну вот честно, верстка HTML на порядок сложнее верстки WPF, не говоря уж о пристрелке пикселей времен MFC, VCL и винформсов.
Не знаю, вопрос привычки. Не видел ничего сложного в HTML вёрстке. Не знаю про пристрелку пикселей, это уже какие-то странные желания, а так всё делается. HTML + CSS страдали некоторой проблемой наследственности, поскольку изначально их проектировали под документы, а не под приложения. Но в последние лет 10 эта проблема по сути исчезла, в CSS появились мощные layout-ы, которые позволяют писать всё не хуже, чем в специализированных десктоп-фреймворках.
Помимо прочего хорошая семантическая вёрстка доступна устройствам для слепых, например. Это важно в некоторых отраслях ну и вообще в принципе правильно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
S>> По мне так Blazor интереснее и под него сечас пишутся контролы https://www.telerik.com/blazor-ui
НС>Блейзор это веб, твой аргумент в пользу Электрона.
Угу с родными контролами для андроидами и яблока.
Электрон это JS, а блазор это надеемся в будущем это вэбассембли для использования в Mono .Net. То есть электрон не нужен. Нужен просто браузер
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
S>> Большинству то как раз WinForms нравится они очень просты.
НС>Они сложны, сложнее браузера современногов понимании. Просто все привыкли.
Смотря для каких задач. Для браузера даже нет нормальных дизайнеров. А на WinForms тяп ляп и готово.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали: S> Электрон это JS, а блазор это надеемся в будущем это вэбассембли для использования в Mono .Net. То есть электрон не нужен. Нужен просто браузер
Браузер не обеспечивает такой же уровень безопасности как у настольных приложений.
Это основная проблема. Вторая биг проблем — stateless, которая лшиь частично решается ws.
Ну и третья — взаимодействие с железом. На днях видел опус на хабре, на каждый пк где планируется юзать веб-приложение ставится служба(!!!), чтобы взаимодействовать с железками.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, Serginio1, Вы писали: S>> Электрон это JS, а блазор это надеемся в будущем это вэбассембли для использования в Mono .Net. То есть электрон не нужен. Нужен просто браузер
AA>Браузер не обеспечивает такой же уровень безопасности как у настольных приложений.
Как раз браузер то и работает в песочнице. AA>Это основная проблема. Вторая биг проблем — stateless, которая лшиь частично решается ws.
А при чем тут stateless? Блазор как раз и хранит состояние как на клиенте так и на сервере AA>Ну и третья — взаимодействие с железом. На днях видел опус на хабре, на каждый пк где планируется юзать веб-приложение ставится служба(!!!), чтобы взаимодействовать с железками.
AA>Мне нравится веб, но...
https://medium.com/@echobrain/11-простых-npm-трюков-которые-вас-удивят-d00510587ec
Но работать с .Net намного приятнее чем с Node.js
Поэтому Blazor интересен и как кроссплатформенный гуй ввиде браузера на .Net
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, varenikAA, Вы писали:
AA>1) У веба проблема в невозможности бесшовного хранения состояния — между гэт и пост запросами никакой взаимосвязи, все руками.
Ты в каком году в браузерные технологии заглядывал?
AA>2) вторая проблема — это взаимодействие с системой: доступ к каталогам и файлам, устройствам и т.п.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> а блазор это надеемся в будущем это вэбассембли для использования в Mono .Net. То есть электрон не нужен.
НС>Нужен. Аналог электрона на блазоре уже у МС в разработке.
Спасибо интересно. Мы про Электрон наверное по разному понимаем. И сейчас можно использовать .Net без всяких электронов CEF, ES6, Angular 2, WebPack 2 .Net Core десктопное приложение без серверной части
Там проблемы в том, что разные сборщики мысора и нельзя определить финализаторы для JS классов.
Ну и раздражает огромный node_modules под Hello Word.
Когда собираются выпустить?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, fmiracle, Вы писали:
S>>Основным аргументом выбора веб-интерфейса при разработке ПО, при этом, является аргумент "пофигу на ОС, хоть Вин, хоть Линь, хоть Мак". Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
F>Никогда не слышал этот аргумент как основной.
Я слышал. Только там было не про винь-линь, а про адаптивную верстку и возможность работы на мобилках и планшетах.
Здравствуйте, sfsoft, Вы писали:
S>То есть ты считаешь нормальной ситуацию, когда статически типизируемый язык (к тому же компилируемый, а не интерпретируемый) нужно преобразовывать в JavaScript? Ничего не кажется странным?
Когда куча нормальных языков препроцессируется в С — тебя это не смущает?
Слышал, и что?
Я так понимаю, мы про разный корпоратив. В моём понимании корпоратив, это там, где 500+ форм для ввода/редактирования данных, куча импортов/экспортов из/в разные форматы и работа с железом (те же ККМ, обязательные по 54 ФЗ при работе с физиками). У тебя другое понимание корпоратива? Ну сорян тогда, я не про стартаперов с распильщиками.
Здравствуйте, sfsoft, Вы писали:
S>Я так понимаю, мы про разный корпоратив. В моём понимании корпоратив, это там, где 500+ форм для ввода/редактирования данных, куча импортов/экспортов из/в разные форматы и работа с железом (те же ККМ, обязательные по 54 ФЗ при работе с физиками). У тебя другое понимание корпоратива?
Это абсолютная тривиальная скукотища, которая нынче на React/Angular и Electron делается, не приходя в сознание. Даже работа с железом есть: https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web
Здравствуйте, sfsoft, Вы писали:
S>Я так понимаю, мы про разный корпоратив.
Ага, про истинных шотландцев, я понял.
S> В моём понимании корпоратив, это там, где 500+ форм для ввода/редактирования данных, куча импортов/экспортов из/в разные форматы и работа с железом (те же ККМ, обязательные по 54 ФЗ при работе с физиками). У тебя другое понимание корпоратива? Ну сорян тогда, я не про стартаперов с распильщиками.
Здравствуйте, sfsoft, Вы писали:
S>> Кстати какой HTML дизайнер лучше выбрать?
vsb>>Без понятия, не пользуюсь. Советую писать HTML руками. Дизайнеры только мешают.
vsb>>Быстрей пишешь, меньше цена
S>Такой вот плюрализм мнений в голове отдельно взятого разработчика...
Здравствуйте, sfsoft, Вы писали:
S>По ощущениям именно ты и не ходил. Там, за редким исключением,
Ага, значит таки исключения есть.
S>Ты же, надеюсь, не считаешь вот это кровавым энтерпрайзом?
Нет. Зато это POS-терминал, про который ты упоминал. А совсем уж кровавый написан обычно десятилетия назад, его просто так переписывать никто и не будет.
Впрочем, если тебе непременно много форм, да еще и с российской спецификой — веб версия 1С вполне способна продемонстрировать тебе, как оно выглядит.
Здравствуйте, Cyberax, Вы писали:
C>Но я так понимаю, что в России стек для крупных enterprise-приложений в миллионы строк кода выбирается на основе того, что работает на кассовом аппарате. Да?
Я так понимаю, что ты совершенно не в теме, но мнение имеешь. Да?
Здравствуйте, sfsoft, Вы писали:
C>>Но я так понимаю, что в России стек для крупных enterprise-приложений в миллионы строк кода выбирается на основе того, что работает на кассовом аппарате. Да? S>Я так понимаю, что ты совершенно не в теме, но мнение имеешь. Да?
Как бывший Principal Engineer в гигантской компании, имеющей сотни миллионов строк кода — ну совсем не в теме. Ни разу вообще enterprise-софт не видел.
Здравствуйте, sfsoft, Вы писали:
S>Продолжай, я весь внимание. S>Так как подключить ККМ через WebUSB? Не стесняйся, Principal Engineer.
Я работал с принтером чеков где-то в 2005-м году, там был простой, но немного кривой протокол по RS-232. Наобум взял случайный фискальный накопитель: https://www.sampokkm.ru/fiscalniy-nakopitel-fn-1/ — в описании тот же RS-232.
Так что через WebUSB будет очевидный интерфейс — подключаем ФН через USB-RS232 адаптер и всё. Адаптеры RS-232 в USB — это вообще стандартный пример в WebUSB. Дальше остаётся только реализовать протокол общения, что очевидно может делаеться на любом Тюринг-полном языке.
Да, и если таки вдруг оказывается, что протокол общения ну никак не реализуется в JS из-за того, что он существует только в виде DLL-ки на VisualBasic 6, то всегда можно просто выделить её в специальный нативный модуль в NodeJS.
Здравствуйте, Kerk, Вы писали:
K>Кто-нибудь наверно уже об этом сказал. Но всё равно хотелось бы добавить, что веб-интерфейс всегда говно. Нет вообще примеров более-менее сложного удобного веб-интерфейса. Человечество зашло в тупик.
Здравствуйте, Kerk, Вы писали:
K>Здравствуйте, sfsoft, Вы писали:
S>>Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
S>>Основным аргументом выбора веб-интерфейса при разработке ПО, при этом, является аргумент "пофигу на ОС, хоть Вин, хоть Линь, хоть Мак". Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
S>>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
K>Кто-нибудь наверно уже об этом сказал. Но всё равно хотелось бы добавить, что веб-интерфейс всегда говно. Нет вообще примеров более-менее сложного удобного веб-интерфейса. Человечество зашло в тупик.
Сейчас в пример обычно приводят figma и vscode. Figma мне понравилась.
Здравствуйте, pagid, Вы писали:
P>При чем тут фискальный накопитель? И зачем с ним связываться напрямую? Надеешься счетчики какие скрутить что ли? Так это не корпоративный софт, а совсем-совсем другая ниша.
Я не знаю, но тут говорят, что это непреодолимое препятствие.
P>Вот только отладка может занять столько же времени, сколько рисование 100500 форм с обращение к БД в том самом корпоративном софте. Как к слову, там с временными задержками в том самом WebUSB. По этой причине никто напрямую (за малыми исключениями) через RS с ФР не общается, в комплекте всегда имеется библиотеки для разных ОС и языков.
Я для интереса нашёл стандартный протокол для ФР, и там ничего криминально сложного нет.
C>>Да, и если таки вдруг оказывается, что протокол общения ну никак не реализуется в JS из-за того, что он существует только в виде DLL-ки на VisualBasic 6, то всегда можно просто выделить её в специальный нативный модуль в NodeJS. P>Угу, а на клиентском компе не забыть запустить службу/демон.
Если используется фискальный накопитель, то это уже будет специализированная система. Т.е. или кассовый аппарат, или что-то типа его. В таких условиях запустить отдельную службу внутри Electron-приложения нет проблем.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, pagid, Вы писали:
P>>При чем тут фискальный накопитель? И зачем с ним связываться напрямую? Надеешься счетчики какие скрутить что ли? Так это не корпоративный софт, а совсем-совсем другая ниша. C>Я не знаю, но тут говорят, что это непреодолимое препятствие.
Преодолимое. Но во-первых, доставляющее лишний гемор, во-вторых, ты таки не то посмотрел, интерфейс фискального накопителя интересен только изготовителю кассовых аппаратов, а не разработчику корпоративного или какого другого софта. Последнее не принципиально, у софта с кассовыми аппаратами связь тоже через RS/USB
C>Я для интереса нашёл стандартный протокол для ФР, и там ничего криминально сложного нет.
Нет конечно, ничего сложного, там описание даже в разы короче, чем описание интерфейса прилагаемых библиотек/драйверов, вот только через них всё замечательно работает, а напрямую программировать RS/USB при наличии упомянутых библиотек мало кто возьмется, потому кроме как геморроя ничего не получит.
C>Если используется фискальный накопитель, то это уже будет специализированная система. Т.е. или кассовый аппарат, или что-то типа его. В таких условиях запустить отдельную службу внутри Electron-приложения нет проблем.
Это будет просто комп подключенный к кассовому аппарату (фискальному регистратору), он может быть в специфической комплектации, например, комп у кассира в магазине, или обычный компьютер бухгалтера в оптовой или производственной компании, где налом платит незначительная часть покупателей.
Здравствуйте, Kerk, Вы писали:
K>Хотелось бы добавить, что веб-интерфейс всегда говно. Нет вообще примеров более-менее сложного удобного веб-интерфейса.
Сейчас тебя будут убеждать в обратном. Что ты ничего не понимаешь и интерфейс в веб строится проще, быстрее и пользоваться им удобнее.
Здравствуйте, Cyberax, Вы писали:
C>Я не знаю, но тут говорят, что это непреодолимое препятствие.
То есть твоим ответом на вопрос "Так как подключить ККМ через WebUSB", я так понимаю, является "Нет никаких трудностей реализовать протокол общения между двумя железками по RS232"?
Почему тебя, при таком подходе к разработке, еще из айти не выгнали? Или ты тот самый эффективный менеджер, который умеет бюджеты раздувать из ничего?
Здравствуйте, sfsoft, Вы писали:
S>Никто не будет спорить, что веб-интерфейс сейчас является стандартом де-факто при разработке новых приложений.
S>Основным аргументом выбора веб-интерфейса при разработке ПО, при этом, является аргумент "пофигу на ОС, хоть Вин, хоть Линь, хоть Мак". Но в реальности (я сейчас про РФ, не про весь мир), у 99% процентов пользователей по прежнему стоит Windows (ключевое слово пользователей, а не разработчиков и не на серверах). И в обозримом будущем альтернатив не видно.
S>Так зачем, тогда, все топят за веб, если десктоп разработка требует меньших ресурсов и имеет большую скорость?
Вообще тема неправильная, потому что в бизнесе так: если заказчик что-либо хоча, ему это надо обязательно дать, чтобы он был максимально доволен.
Поэтому спорить с ним в данном случае абсолютно неправильная и бесполезная тактика.
Веб — это открытые стандарты в области разработки интерфейса, набор альтернативных клиентов-броузеров. У многих интернет-продуктов есть толстый мобильный клиент, и тонкий для десктопа. Тонкий клиент покрывает вообще все платформы без исключения, которые хоть как-то используются в виде клиентских. Так как windows mobile сдох, то как минимум на мобильных устройствах винды больше не будет.
Здравствуйте, Явь-Истъ, Вы писали:
ЯИ>если заказчик что-либо хоча, ему это надо обязательно дать, чтобы он был максимально доволен.
Если бы не началась истерия с веб-интерфейсами, то заказчики и знать бы не знали ни про какой веб. Работали бы спокойно на своих десктопах (и в нативных приложениях на телефонах) и горя не знали. Но Google устроил "революцию", поскольку десктоп ему был неподвластен. В результате все равно все работают в Windows, но приложения должны быть в браузере.
Здравствуйте, sfsoft, Вы писали:
C>>Я не знаю, но тут говорят, что это непреодолимое препятствие. S>То есть твоим ответом на вопрос "Так как подключить ККМ через WebUSB", я так понимаю, является "Нет никаких трудностей реализовать протокол общения между двумя железками по RS232"?
Я ответил:
1. Использовать WebUSB для общения через RS-232 и реализовать протокол на JS.
2. Использовать родную библиотеку ФН, подключив её к NodeJS как нативный модуль.
S>Почему тебя, при таком подходе к разработке, еще из айти не выгнали? Или ты тот самый эффективный менеджер, который умеет бюджеты раздувать из ничего?
Нет, я практический специалист, который не считает, что выбор ФН является причиной для выбора всего стека в enterprise-системах.
Здравствуйте, sfsoft, Вы писали:
S>Здравствуйте, Явь-Истъ, Вы писали:
ЯИ>>если заказчик что-либо хоча, ему это надо обязательно дать, чтобы он был максимально доволен.
S>Если бы не началась истерия с веб-интерфейсами, то заказчики и знать бы не знали ни про какой веб. Работали бы спокойно на своих десктопах (и в нативных приложениях на телефонах) и горя не знали. Но Google устроил "революцию", поскольку десктоп ему был неподвластен. В результате все равно все работают в Windows, но приложения должны быть в браузере.
Странная логика. Если у веба нет перед десктопом преимущество, то почему все выбирают веб?
Даже фаулер в далеком 2002 году (18 лет назад однако) в книге PoEAA сказал что если нет особых причин использовать десктоп надо делать веб.
Здравствуйте, Ватакуси, Вы писали:
В>С одной стороны понятны аргументы и за и против, но с другой, когда у меня В>а) Банк 10 месяцев не менял код, поэтому работать можно было только с IE6, всё остальное валилось с ошибками ангуляра В>б) Когда бухгалтерская система (:--(((() уже 2 года имеет кнопки наезжающие друг на друга В>в) мейл.ру стал более глюкавый и тормозной, но зато с новомодными ангулярами или реактами, фиг знает В>г) когда я пришёл на собеседование в самую крупную контору в мире по бронированию всего на свете и мы 2 часа пытались запустить тестовое задание (vue.js на маке), но так и не запустили. В>....
В>и когда таких примеров просто тонны, то немного странно слышать про крутышку веб.
Эти примеры показывают низкий уровень программистов, которые делают веб. С таким уровнем подготовки программистов десктоп программа не добралась бы ни одного из перечисленных пунктов.
Здравствуйте, gandjustas, Вы писали:
G>Даже фаулер в далеком 2002 году (18 лет назад однако) в книге PoEAA сказал что если нет особых причин использовать десктоп надо делать веб.
Хм. Я тоже этот труд читал. Году так в 2005. Можно цитату?
Здравствуйте, gandjustas, Вы писали:
G>3) Веб-приложение не требует доработки чтобы работать внезапно на маке.
Со всем согласен, но вот это: Более-менее серьёзное веб-приложение на маке и прочих iPad, iPhone как раз _внезапно_ обычно и работает. Так, что потом волосы на голове шевелиться начинают. Что не отменяет того факта, что после этапа непрерывного мата, доработка всё-таки выходит существенно дешевле, чем написание отдельного приложения под iOS.
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Slack, Trello, это только из того, что я видел.
Раз пишут, значит все остальные считают по-другому.
