В принципе, вариантов создания веб-приложения на C++ много, но чтобы устраивало для очень быстрого создания прототипов - нет ни одного.

Критерии, от важных к не очень:
1. Form Designer - быстрый и простой построитель форм для GUI, который можно отдать дизайнерам интерфейсов и пусть его мучают, а в это время писать логику - это очень важно для быстрого создания прототипов
2. Свободное размещение виджетов - куда хочу, туда и ставлю
3. Относительное размещение виджетов - при разных разрешениях экрана виджеты будут растянуты/сжаты или смещены в зависимости от настроек
4. Написание обработчика событий по 1 клику - кликнул по одному из событий любого виджета/компонента и ты перемещен в уже созданную функцию обработчика на C++ и пишешь её тело
5. Может запускаться и как web-сервер/служба, и как обычное desktop-приложение

Какие дизайнеры и библиотеки существуют:
a) BuilderC++ UniGui: есть все 5 критериев
b) BuilderC++ IntraWeb: есть 1-4
c) WtDesigner: есть только 1
d) Wt: есть только 4
e) Qt + QtWebKit Bridge: (приложение Qt как браузер, весь фронт-енд на HTML/CSS/JS) есть только 5
f) Qt + QtWebChannel (WebKit/WebEngine/WebSockets): нет ничего
g) cppcms: нет ничего
h) cgicc: нет ничего
i) plane cgi: нет ничего + гемор для самостоятельного распарсивания POST/GET запросов
j) boost-asio: нет ничего + гемор для самостоятельного распарсивания HTTP а в них ещё и POST/GET запросов


Вариант-1. В принципе можно было бы использовать BuilderC++ UniGui, но:
- проблема-1: в случае успеха прототипа - нельзя запустить на хостинге под Linux
- проблема-2: в случае успеха прототипа - нельзя встраивать виджеты UniGui в собственный HTML (вроде бы) - iframe исключаем
- проблема-3: старый компилятор Clang 3.3 (только c++11, без 14/17)

Вариант-2. Можно WtDesigner или вручную Wt, но:
- проблема-1: не удовлетворяет самому важному критерию 1 - нет адекватного дизайнера виджетов, и придется под каждый вариант прототипа верстать HTML/CSS/JS
- плюс-1: любой компилятор и любая операционка Win/Linux/Mac/Android...
- плюс-2: можно встраивать Wt-виджеты в любые места в собственном HTML
* https://github.com/emweb/wt/tree/master/examples/feature/widgetset
https://www.webtoolkit.eu/wt/blog/2010/12/17/widgetset_mode_and_cross_origin_requests
HTML: <div id="widget_name">:
C++: chat.emit(widget_name, 'login', 'koen');
* https://www.webtoolkit.eu/widgets/layout/html-templates
HTML: <p> ${save-button} ${cancel-button} </p>
C++: t->bindWidget("save-button", new Wt::WPushButton("Save"));


Есть ли ещё более подходящие варианты, чтобы избавиться от долгой разработки UI-интерфейса для web-приложения на C++?

Простой способ есть. На Builder C++ UniGui я за 30 минут делаю прототип по функционалу равный тому, что вдвоем верстальщик + PHP-шник делают за 8 рабочих часов, т.е. раз в 15 быстрее.
Проблема в том что он не работает под Linux. Вот есть тоже самое но под линукс?

lockedВася УткинПростой способ есть. На Builder C++ UniGui я за 30 минут делаю прототип по функционалу равный тому, что вдвоем верстальщик + PHP-шник делают за 8 рабочих часов, т.е. раз в 15 быстрее.
Проблема в том что он не работает под Linux. Вот есть тоже самое но под линукс?
Между прототипом и продакшеном она и есть - 15кратная разница
Ага, только ты ошибся в 20 раз - про продакшен вообще речи ещё не шло, там вдвоем верстальщик + PHP-шник справляются за месяц, т.е. в 300 раз разница.

maytonЯ-бы в эту формулу добавил еще и стоимость поддержки. Допустим прототип и студенты 2-го курса
"остреливают" не йух срать. А вот дальше? Сколько стоит доработка фич если заказчик захочет
интеграцию с веб-сервисами, авторизацию в этих ваших фейсбуках и твиттерах и фулл текст серч.
Без бития себя в грудь. А просто по чесноку. Кто будет пилить интеграцию? Вы лично будете пилить
или бросите бедного заказчика у разбитого корыта?
Прототип это то, что выкинут и перепишут заново после того, как он покажет положительный результат на тестовых пользователях, поэтому поддерживать его смысла нет.
Хотя бы чтобы такая возможность в принципе была, чтобы кастомные фичи коих не более 5% в прототипе - долго пилили те самые HTML/JS-щики.
В UniGu такая возможность есть - интегрировать любой кастомный HTML/JS i: http://digital-flame.ru/2016/02/10/unigui-tinymce-dobavlyaem-moshhnyiy-tekstovyiy-redaktor/
Все это реализуется за минуты: http://prime.fmsoft.net/demo/desktop/mdemo.dll

alexy_blackтаки прочитал тему, хотя хочу спать :)

либо я чего-то не понял, но по мне - в wt есть все с 2-5, нет только гуя для гуя.
Имеется ввиду 2 и 3 - свободное и относительное размещение виджетов именно используя гуй для гуя , да в первом сообщении я это забыл указать.
Т.е. например, в гуях WtDesigner или Dreamweaver вроде и можно создать гуй, но ты не можешь просто взять кнопку и кинуть её в любое место, сначала надо на создавать <div>-ов, потом пошаманить с CSS, и только потом плюхнуть кнопку и потом ещё ковыряться с кроссбраузерностью.
Кроме того, 5 в Wt разве есть, т.е. я могу запустить приложение написанное в Wt и откроется обычная Windows-форма со 100% идентичным интерфейсом? Или вы имели ввиду запустить Wt-приложение, и пока оно работает открыть localhost в браузере? В UniGui работают оба варианта.

alexy_blackдля построения полноценного гуя - только wt, там не такой говнокод получится, как билдере.
А можно пример говнокода из билдера, и чем он хуже, чем в Qt?

alexy_blackтакже, как способ - cppjson (это я вынес из cppcms::json) и набросать rpc. весь гуй строится на dojo, или чем-нибудь в этом духе, на клиенте, сейчас полно фреймворков для этого. функции вызываются на сервере, ответ в виде json. c++ вобще никак не думает об их представлении. rpc есть и в cppcms.
В dojo есть гуй для гуя?
Если нет, то это ещё сложнее, чем Wt. В Wt-виджетах уже встроен весь обмен клиент-сервер и жестко связан видимый элемент на клиенте, и обработчик на сервере, а вот в cppjson+rpc есть возможность перепутать.

alexy_blackна счет rpc на dojo. я делал так - создавал на клиенте класс, все или часть его фукнций вызывали однаименную функцию определенного объекта на сервере и возращали будующий результат, в коде писал типа foo.get_something().then(function(){...}); . делаешь систему один раз, потом просто пишешь методы, также как и на qt например.
дальше интерфейс уже можно собрать как угодно, в том же Dreamweaver
Ну вот собрать интерфейс это как-раз самое геморное занятие.
А чем dojo лучше, чем Wt: функционала больше, он гибче или виджетов больше, чем у Wt?

alexy_blackна счет гавнокода.. пытался когда-нибудь править код, который получается в этих программах? то есть например создаешь создаешь гуй в какомнибудь визуальном редакторе, потом хочешь что-нибудь там подправить... там полнейшее г, куча ненужных дивов и прочего, я такой код не использую :)
я уже много лет не использовал builder, но там вроде был подход абсолютного позиционирования. то есть например ставишь кнопочку на форму, и она там и будет стоять.. сейчас это не модно :) модно layout - они сами расчитывают где будет стоять элемент по геометрическим правилам. это полезно для переводов например..
С 2007 года там точно есть и абсолютное и относительное позиционирование - можно писать под разные разрешения экрана, причем делается это элементарно.

Насчет говнокода.
- Если про Builder C++ VCL-lib, то там div-ов нет, это не HTML, это dfm - формат оконных форм. И ковырятся в ui(Qt C++) ничем не лучше, чем в dfm(Builder C++).
- Если про Builder C++ UniGui-lib, то там в div-ы все превращается, но мне бы в голову не пришло это править. Или интегрируешь самописный HTML/CSS в развернутый на весь экран URL HTMLFrame (UniGui), или если лишних ресурсов совсем дофига - команда из дизайнера, верстальщика, JS-программиста - месяцами пишут полностью уникальный хороший HTML-интерфейс.

alexy_blackи по моему ничего геморного в этом нет, просто делаешь и все. можешь использовать css таблицы или flex, описал контейнеры и готово. если уже представил интерфейс в голове (а лучше на картинке), делов минут на 10.
Т.е., например, за 10 минут вы можете сделать полностью рабочий прототип Web-приложения с функционалом как во вкладке Database -> DBLookupComboBox : http://prime.fmsoft.net/demo/desktop/mdemo.dll
Если база данных с данными уже есть.
- Чтобы пользователь мог менять размеры столбцов.
- Чтобы можно было править данные прямо в таблице и они автоматом сохранялись в базу.
- Чтобы данные в таблице можно было править вводя на клавиатуре или с помощью выпадающего ComboBox - двойной клик прямо на поле таблицы (как в столбцах CustNo или LookupField - помечены цветом)?

alexy_blackВася УткинТ.е., например, за 10 минут вы можете сделать ...
Если база данных с данными уже есть.
- Чтобы пользователь мог менять размеры столбцов.да, остальное - нет, потребуется боьше времени. я говорил об интерфейсе пользователя. то есть чтобы это выглядело примерно так (ну, компоненты конеч-то другие будут), а не работало так же. чтобы это рабтало, нужно повесить обработчики событий, может немного отладить.. это тоже давольно быстро (если это действительно прототип и гавнокодить можно), но не 10 минут вместе с интерфейсом :)

http://webix.com/widget/treetable/ вот например такой компонент можно использовать. на счет "менять размеры столбцов", я не замарачивался на счет этого, поэтому не знаю поддерживает ли dojo такое или нет, но,думаю что поддреживает (webix вроде только если купить). вобще по моему это не нужная функциональность в прототипе.

кстати, в примере у меня почему-то прокрутка не работает - верхняя часть интерфейса обрезана , и до неё не прокрутить. верхнее надпись у меня Style = csDropDown, там выше еще много чего?
Да, это косяк примера, забыли Layout и вертикальный скролл прилепить к основной панеле. Есть примеры с Layout, но всё ещё без скрола: Layout Management -> Accordion Layout и остальные в этой вкладке.
TreeTable кстати тоже есть пример, не знаю только насколько легко он подключается там к БД: TreeView -> UniTreeView Sample

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

Ну а очень примерно, сколько бы у вас заняло создать полностью рабочий прототип с 5 ComboBox-ов и 3 Table (с ComboBox-ами в полях таблицы), час, день, несколько дней?