最早 20 年以前，C++就能在后端编写代码，叫 CGI，模板是这样的( http://cppcms.com/wikipp/en/page/cppcms_1x_templates_comm)

<% c++ #include "all_data.h" %>  
 <% template render() %>  
    
<% include menu() %>
  
  <% end template %>  

CGI 和早年 ASP 一样，属于后端模板，数据对大带宽服务器于前端是不可见的。

但这种方法对现代 WEB 有个致命的缺点，就是用户交互的时候，每次都要生成一次 GET 请求，用户无法及时得到反馈，体验很不好。

现在我们有了新的解决方法，就是为每一个 WEB APP 用户，都建立一个专属 WEBSOCKET 通道，由于 WebSocket 自带压缩属性，我们可以通过以下方法，来减低数据量传输，提高实时性，达到用户交互高速访问目的。

1. 服务器端维护一个文件 /数据更新列表，每一个新的资源请求，都经过 hash 查询，老数据和 CSS/JS，直接保存到本地的 localStroage 里。
2. 服务器端维护一个 JSX 类似的虚拟 DOM，每一次更新 DOM 请求，都是经过 DIFF 差分算法，前端只获取树变更后的少部分数据。
3. 每个前端 DOM，都对应一个唯一 ID，是为了快速对局部节点进行更新。(这点比 VUE 好，VUE 列表还必须手动添加 ID)

总的来说，前端就是一个暗盒，页面所有元素，都是服务器端的虚拟 DOM 镜像版本。 然后所有的逻辑代码，区分为敏感逻辑和非敏感逻辑。把非敏感逻辑部分，编译成 emscripten 或 webasm(微信 iOS 小程序不支持 webasm, 只能编译成 emscripten 胶水 JS 版本), 在前端执行。两种逻辑通过 route 自动切换。

GoogleEarth 都能用 C++在前端运行，有什么理由不多尝试一下，前端不同的可能性？

放弃 innerHTML 赋值, 放弃 js 逻辑，全部改用 document.createDocumentFragment，多层封装 C++对象，加入消息反射机制和数据自动绑定，尝试开启 WEB3.0 的新时代。

我印象中有更新的东西，cgi 太老了。

再新也没办法解决实时性交互问题，后端 c++发展到交互新时代，就止步不前，几乎没人用，就因为前后端模型不统一。
操作不了前端 dom 的 c++不是好 c++。

c++ 来开发 web 太浪费了, 招一个 c++3W 起, 可以顶好几个前端了.

可以走更现代一些的 web assembly + JS

Erlang 早就用这一套思路做服务端实时渲染了。。。不过前端用 wasm 的也就近几年才流行，知名的有 C的 OOUI

C++ 开发 WEB 走前后端分离方法比较靠谱。

目前是构想还是原型还是成品？
这种设计的工作量实在是非常巨大，而且是一个富底层设计。
确实 Erlang 的基础天然适合这种设计
总结来说，“前端即后端延伸”，那么天然适合分布式系统的 Erlang 确实看上去是最好的选择。

如果你还没做出来，那么这里有个建议：
你首先得排除富底层设计
像是 WSGI 那样，构造底层协议，API 非常简陋但能低开销完成所有操作
之后再考虑 App 框架，虚拟 DOM 之类的事儿。

楼主，20 多年前已经有人尝试过了，于是发明了 Python

你说的要求 [WT]( https://www.webtoolkit.eu/wt) 能做到

还真是一模一样，WT 也是为每个客户端建立一个私有 websocket，不另外增加 POST/GET 方法，就直接一个通道处理所有事务。
每个客户端命令都二进制打包到服务器处理逻辑，然后即时更新到客户端。
看来互联网最不缺的就是 IDEA，想到的东西，总有前辈实现过。
当然还是有一点小区别的，他没有虚拟 DOM，没有客户端 C++。我这个 IDEA 的先进地方是第三点，让 route 在 webasm 和服务器 C++中自动无缝切换，WT 应该还没做到这一步。
比如[browser] int sum(int a, int b) {return a+b}是编译成前端代码调用，而不是服务器版本。

除此之外，还有一个思路是直接服务端渲染完搜集绘图指令发送到前端，然后在 canvas 里复现结果，这样就完全不用考虑布局差异了，可以做到 100%兼容，除开一部分文本输入的做一些特殊处理，其他的应该都可以做到 canvas 里。
GTK3 的一个显示后端就是直接接入浏览器的。