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

Лучший ответ:
вставлю свои 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% этих арм и ас работают в наглухо изолированных от интернеса сетях.

Худший ответ:
В вебе все равно не будет GUI именно как на десктопе по той простой причине, что переход в веб - это не только смена платформы, но и смена парадигмы. От standalone программы к клиент-серверной архитектуре. Которая диктует свою логику построения интерфейса, в том числе.
Впрочем, парадигма супер-формочки для мышевозов пережила смерть Вижуал Барсика и Дельфей и вовсю прет в новый век веба, почти не меняя своей убогой сущности...