В любом случае, обязательно потребуются базовые знания JavaScript/HTML/CSS (без этого, ну никак), а дальше уже JavaScript MVC-фреймворк какой-нибудь(для удобства разработки SPA). Приложение, по сути, будет толстым web-клиентом, т.е. весь код отображения и взаимодействия с пользователем будет на JavaScript/HTML/CSS, а к серверной части будут лишь обращения, навроде: "запиши эту строку в БД", "отыщи значение в БД по такому ключу", "передай мне jpg/pdf/etc файл такой-то". Никаких указателей в JavaScript нет, а если бы и были, то как ссылаться на область памяти на сервере?! Если это что-то на WebGL, то все текстуры нужно будет сперва подгружать в браузер с сервера как внешние ресурсы. Непосредственно видимый интерфейс конструируется на HTML/CSS вручную (WYSIWYG инструментов навроде Glade или QtDesigner/QtCreator по факту нет, если не считать таковыми продукты от Adobe сомнительной полезности). Окошки и виджеты создаём/компонуем или вручную на HTML/CSS или есть куча библиотек и CSS-фреймворков с готовыми виджетами (навроде Bootstrap). Упаковка всего этого добра идет как правило декларативно на HTML. 1000 записей в браузер засунуть можно, но надо ли? Для таких случаев ленивую подгрузку используют, по мере обращения пользователя.
Кроме того на GTK/QT вроде как были проекты по созданию html-backend'ов т.е. обычное приложение, написанное полностью на С++/GTK/QT транслируется специальным бекендом-сервером в веб как просто слоёный набор картинок (некое подобие RDP/VNC протокола, только для браузера) - тогда JavaScript/HTML/CSS вообще знать не обязательно, но по моему все эти проекты так и загнулись.