所有复杂的权限 access control 框架, 都会慢慢演化成折腾 DSL ...
那么问题来了, 为啥不直接用程序逻辑实现?

@ArtYeung
一楼是正解, 你先能把自己的流量搞起来再说. 做这种项目, 技术不是关键.

作为非前端外行，我觉得不行...

各种 UI component lib 都不支持 3...

visual studio 应该主要是写 MS windows 下的东西方便
好多年没用了. 请现在还在用 visual studio 的出来说说

@myCupOfTea @yaphets666 @Feiox 所以 vue 就是好 +-_-

作为后端, 问个问题: vue 3 的脚手架是不是可以省掉折腾 Webpack，Babel

@Chaox
跟中间路由设备应该无关...
应该是端到端的 HTTP encoding/decoding prefer 纯文本, 规定这样更 reliable

作为外行(后端), 看了眼, 不负责的归类下:
出活接地气类: Vue, Bulma
自由高逼格类: React, Tailwind

@awanganddong 楼里各种五花八门的回答，你们是在认证帮楼主么?
我认证问楼主个问题，现在 JS web 前端可以直接用 TCP/UDP socket 和后端通信了 ??
我记得以前是不能的. 如果不能，这个问题本身就不成立. 只能用 WebSocket (over TCP), 不需要你管理 socket ports.

@fiveelementgid
为了兼容性，还是用 bash 吧，免得换到别的设备上适应不过来 +1
用 bash 有个潜在的使用场景，就是去 Linus server 上用 terminal, 那里没有 zsh
没必要搞 zsh. Mac 的默认 bash 很容易从 zsh 换回 bash

@wbfsa 支持! 以前研究过一下 web 3D, Babylon.js 比 three.js 功能丰富多了

@xchaoinfo
为了简单可靠，还是 gunicorn 吧, 出活快, 容易维护.
为了性能... 就不要折腾 Python, 换 Go 吧.

@sunny352787 你说的有一定道理。我就是觉得 client (Go<->C<->Unity) 绕的弯有点长.

@sunny352787 主要考虑客户端嵌进去 Go 是不是方便，如果客户端嵌进去 Go 非常自然原生，那就好。但是 Unity 好像是支持原生嵌进去 C/C++, 不是 Go，所以你看你其实把复杂度移入了 client (Go<->C<->Unity)，而 client 一般限制更多，困难更大，不知道这样搞是不是以后潜在问题也更多.

@sunny352787 为什么不把 client-server 公用的代码用 C 写, 然后 client 端用 Unity C#调用 C, server 端用 cgo 调用 C ?