@Eyakubovskiy
ИТишник, гик, 1Сник

На чем писать веб приложения с GUI как в desktop app?

Доброго дня.
Подскажите пожалуйста на чем можно писать веб решения с подходом как при разработке десктопных приложений?
Я привык к подходу, что легко накидываешь интерфейс в конструкторе (окна, кнопки, таблицы, поля, прогрессбары), а потом в модулях описываешь логику. Но я отдаю себе отчет, что все переходит в веб. И десктопные приложения уже сейчас отмирают. Хотелось бы перейти в вэб с сохранением десктопного подхода.
Знаю, что в С# есть xaml для веб (xbap кажется), но платформа проприетарная и мне это не нравится. На Java вроде тоже что-то такое есть, но не могу найти как оно называется (буду благодарен если напомните). Ну и тоже сложности у нее по настройке серверной части. Пару лет назад смотрел - были сложности с подбором хостера (нужна установленная платформа на сервере).
Соответственно, прошу подсказать по возможным вариантам инструментов. На текущем этапе не хочу углубляться в JS, CSS и пр. Хочу тупо функциональности и быстроты разработки фронтэнда.
Насколько jQuery упрощает разработку интерфеса в сравнении с тем если писать самому все с нуля?
О задаче - есть идея написать свое приложение для работы с задачами в рамках своего видения. Что-то типа todoist. Хочу сделать это минимально напрягаясь)
Есть опыт разработки в 1С, С#, калькулятор на Java писал))) на php другу примитивный сервис по учету бонусов писал. SQL запросы не проблема.
Заранее большое спасибо!
  • Вопрос задан
  • 5911 просмотров
Пригласить эксперта
Ответы на вопрос 8
@dplsoft
вставлю свои 5 копеек. сумбурно, не все совсем все по теме буду излагать (но там будет ответ на вопрос .. вроде как) но надо понимать область применимости того, что хочет тов. Евгений .

Его желание "писать в веб так как десктоп" - мне очень даже понятно, и именно поэтому я фактически сделал свой фреймворк ( не на джаваскрипте, что вы, джава+вебсокеты, и совсем немного js). Но его область применения - тяжелый интерпрайз и интранет.

т.е. писать приложения с веб-интерфейсом, используя подходы и концепции "как для дексктопа" - это иногда просто необходимо (сейчас веб интерфейс в браузере - это уже практически стандартное требование для корпоративных систем)... НО совсем нельзя, ни в каком случае нельзя так делать если вы собираетесь писать массовый веб-сайт "в паблик".

ну и наоборот: современный модно-молодежный подход с тяжелым js, рест-сервисами , микросервисы, stateless-подход и тп - это хорошо ровно до тех пор пока у вас не начинается тяжелая бизнес логика, сложный арм какого либо оператора или необходимость быстрой его адаптации.

и так. имхо, есть 2 направления, сложно совместимых идеологически друг с другом. ( 90% "веб разработчиков" скажут, что есть только одно... но и фиг с ними - они не знают, а я излагаю свое имхо-мнение системного архитектора, чей стаж в it зачастую больше, чем весь возраст упомянутых чуть ранее "веб разработчиков" ))).

и так. "массовый веб" и "тяжелый интерпрайз" :

1. массовый веб.

тонны хомячков, тысячи примитивных запросов, простая логика (бизнес логика). на это заточено 120% современных веб-фреймворков, которые соревнуются между собой в синтакс-засахаренности, да функционально-фиче пригодности. микросервисы, stateless, rest-сервисы, json-туда-обратно - "... о как.. всем прияно...." и т.д. 90% последователей этих технологий не понимают даже основ проблем разработки больших систем на языках с динамической типизацией, готовы топить за самый модный в этом сезоне фреймворк, давить статистикой новых проектов на гихабе.... но да и фиг с ними, ... достаточно того, что те-же "хедлайнеры" - node.js - вдуплили эти проблемы и таки послали js подальше... тьфу - перешли на typeScript ( ибо статическая типизация - этт не закостенелость стариков, а вынужденная мера, совсем "не от хорошей жизни")... но тысячи хомячков любящих js ведь не могут ошибаться... и потому плодят мирриады js-фреймворков, каждый из которых применим в 2х случаях из 100. и отслеживают топ 10 попутярных в этом квартале языков программирования... ну ла ладно.

тут важно понять, что это разработка сайтов - именно массовых сайтов - и это действительно другая парадигма разработки - лругая чем в десктопе. и от этого, к сожалению или счастью, никуда не деться.
тут не выйдет использовать и половину принципов десктопа.

примеры: вконтактик, форумы, и 99% всех веб сайтов.
типичные технологии: php, одноглазый змей-питон, js, чудо руби, и все прочее и тд....

ps: и да, я ни коем разе не хаю js. я его люблю. но крайне рисковано применять js в объеме большем чем скрипт на 2 страницы. первый же рефакторинг и переаботка кода поломает все нафиг. на определноом объеме кода вы попадете в ситуацию, когда попытка имправить баг будет вность еще больше багов и вы не сможете это остледить.
то, во что сегодня превратили js и технологии на js - это страх и ужас, но да это моё имхо.


2. интерпрайз интранет
...и различные АРМ с веб-интерфейсом в локальной сети и сложной бизнес логикой

характерные признаки: не слишком большое число пользователей (несколько сотен, максимум пара тысяч), сложная логика бизнес процессов и сложная логика работы формы, высокие требования к надежности.
быстро-меняющиеся процессы предприятия, меняюшиеся раждые полгода регламенты, постоянный рефакторинг под давлением постоянно меняющейся обстановки...

примеры: СЭД (системы документооборота), арм различных госструктур, арм различных операторов, и тд.

вот тут как раз все наоборот. одна только попытка использовать stateless подход и тяжелый толстожЁпый js грозит вам переработками такого масштаба, что вам и не снилось. т.е. вы конечно построите первую версию и все у вас будет хорошо... до первого рефакторинга и отработки замечаний заказчика по новой версии регламента, которая была утверждена руководством месяц назад... (ну а вы начинали работу конечно полгода назад, и вот уже вроде как через месяц надо было бы сдаваться)... но внешние условия изменились, и у вас начинаются проблемы, вырисовывается громадный объем работ по рефакторингу. просто потому что крайне сложно сделать машину состояний и сложную логику диалога с веб-клиентом, в ситуации когда вы постоянно терятее состояние процесса на сервере... а вы попытались написать внутренний арм как будто это сайтик ...

вот тут вам очень нужен подход и концепция десктопных приложений. в идеале - что то близкое к терминальным сервисам но типа в веб. и тут важно понять следующее: готовых массовых решений нет.

самое перспективное что я вижу - jsf/primefaces, но увы: он пригоден ровно пока у вас логика и интерфейс укладываются в формат демок на сайте производителя. поверьте мне - на реальном проекте - вы слишком быстро выйдете за границы применимости типовых компонент, вам начнет катастрофически не хватать их возможностей... и в этот момент начнется содом-и-гомора...

за spring мало что скажу, но сколько я видел - он тоже не решает проблем написания сложных-веб-интерфейсов. много вкусного для серверной части, но для общения с вебмордой в конце концов все опять скатывается к rest-сервисам, аякс-json-туда-обратно и тп. - что, повторюсь, при усложнении логики работы вашего арм сильно вдарит вам по самым нежным и мягким местам раскаленной булавой.

в общем вот тут идеи десктопного приложения очень как пригодились бы, но готовых технологий нет.
я вижу перспективу в использовании web-socket, но опять же, промышленных наработок и фреймворков нет.
самое близкое что так умеет - c++/Qt но у них скорее трансляция в веб интерфейса с++ приложения. в 1С аналогично - у вас одинаковый интерфейс "управляемой формы" и в веб и на десктопе.

у нас есть свои домашние заготовки, но, повторюсь, мы пока их не выпускаем на массовый рынок, предлагать не буду. погодите полгодика, и все будет.

---------
в общем я к чему: хотите использовать десктоп в веб? пишите например на qt/c++. у них есть технология трансляции в веб приложения написанного на c++. опять же, на вебсокетах все работает). хотите писать тяжелые арм на джаве для интарнет-интерпрайз-систем - присоединяйтесь к нашему закрытому тестированию (за сим в личку) или ждите публичного анонса. для шарпов ничего не скажу, имхо шарпы только для Unity-гемдева и пригодны(имхо), а как интерпрайз-технология они так и не состоялись.

если хотите писать массовый веб - концепции десктопных приложений вам совершенно не пригодны. вы , банально, слишком много израсходуете ресурсов при относительно малом наплыве пользователей. никто, например, терминальный сервер в публичный веб анонимусам не пускает. разорвут как тузик грелку.

потому - , уважаемый топик стартер - вы определитесь с тем что вы хотите делать, и поймите, готовы ли вы отказаться от идей десктопной разработки или вы согласны окунуться в нелюбимый многими мир "ынтерпрайза-мать-его". т.е.:

- "массовый веб" (тонны простых маленькиз запросов, сотни тысяч пользователй) - и никаких десктопных концепций не применимо! но зато тысячи идей и подходов, мирриады фреймворков, каждый месяц что-нибудь очередное новое модно-молодежное с тысячами фапающих на это хомячков... бурление масс, так сказать... главное не ходить с этим в интранет...

или

- "тяжелый интранетовский интерпрайз" ( несколько сотен пользователй максимум, сложная логика работы каждого АРМ, тяжелые запросы отрабаиываюшие по десятку минут, запутанные бизнес-сценарии рабрты гуи, фоновые процессы на сервере.... ) - многие десктопные концепции, когда гуи должен рассматриваться так, как будто он локальный - просто жизненно-необходимы. попытки строить эти системы по технологиям из области "массового веб" - ... скажем так ..."чреваты" и в 90% случаев пооучаются либо костыльно убогими, если вообще работают, либо неповоротливыми в разработке и рефакторинге. не смотря на это, готовых решений и концепций всё еще пока практически нет, каждый изъгаляется как может. рынок достаточно закрытый, относительно массового веб : 99% этих арм и ас работают в наглухо изолированных от интернеса сетях.
Ответ написан
@mletov
Подскажите пожалуйста на чем можно писать веб решения с подходом как при разработке десктопных приложений?
Я привык к подходу, что легко накидываешь интерфейс в конструкторе (окна, кнопки, таблицы, поля, прогрессбары), а потом в модулях описываешь логику.


ASP.NET WebForms как раз использует такой подход

Но я вам сразу скажу, что сейчас вакансий по нему нет, разве что legacy поддерживать.
Все новые проекты все равно пишут на ASP.NET MVC или .NET Core.

Идея натянуть десктопные концепции на веб была признана попыткой натянуть сову на глобус.

И вроде бы что-то такое было и в Java, но не уверен.
Ответ написан
@SaintRepublic
Дайте мне какое-нибудь дело, мне скучно!!! ;D
Не особо шарю в веб-е, но знаю, что есть такая платформа у microsoft - silverlight. Тот же Visual Studio, по сути.
C# и xaml и вроде она свободная.
Silverlight is a free plug-in
.
Вот тут есть уроки: ссылка.
Ответ написан
coderisimo
@coderisimo
" Хотелось бы перейти в вэб с сохранением десктопного подхода." звучит как
"Хотелось бы перейти в повара с сохранением подхода электросварщика" ))))))))))))
Минимально напрягаясь далеко не уедешь. Я тоже начинал с C# (для десктопа) , но в вебе все иначе.
Используйте bootstrap для UI. Он отлично подходит для создания простых лаконичных интерфейсов. За пару, тройку дней вполне можно освоить основные понятия. Далее JS.
По идее, можно использовать его минимально, но это тупиковый подход. Так что, как я написал выше - придется напрячься. Впрочем, все на так страшно. Тот же jQuery , если не лезть в дебри - простой и наглядный. Со временем, конечно, в дебри-таки придется лезть. Но для простых вещей указанного инструментария вполне достаточно.

Удачи)
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
GrapesJS для создания шаблона.
GrapesJS is an open-source, multi-purpose, Web Builder Framework which combines different tools and features with the goal to help you (or users of your application) to build HTML templates without any knowledge of coding.
Ответ написан
Комментировать
@NoofSaeidh
Сейчас модно дестоп писать как веб. Как раньше веб и десктоп (таким образом как Вы написали) уже почти никто не пишет.
Ответ написан
Adamos
@Adamos
В вебе все равно не будет GUI именно как на десктопе по той простой причине, что переход в веб - это не только смена платформы, но и смена парадигмы. От standalone программы к клиент-серверной архитектуре. Которая диктует свою логику построения интерфейса, в том числе.
Впрочем, парадигма супер-формочки для мышевозов пережила смерть Вижуал Барсика и Дельфей и вовсю прет в новый век веба, почти не меняя своей убогой сущности...
Ответ написан
@doreonline
Попробуйте spiderbasic
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы