C# 宇宙第一。
TypeScript 也很不错，我称之为 C#-Lite 。而且 TypeScript 能无缝衔接 JavaScript 生态，生态非常繁荣。

Anders Hejlsberg YYDS

个人感觉在现代前端应用把 html 结构和 css 样式分离就是个错误。
Flutter 、SwiftUI 、WPF 都是直接在 element 上加样式的。

关注点不分离之后开发和维护轻松多了。
目前使用 Utility-first 的 tailwind 、windi 或者 css in js 的 emotion 等库都能轻松做到关注点不分离。

css in js 的写法没有普及令我感到诧异
jsx 作为一种编程语言，自然有与其对应的样式写法，类似这样: https://emotion.sh/docs/css-prop

这个写法明示了样式目标元素在 DOM 中的位置，也不用给维护对应语句提供定位

如果样式与结构分离，所有 css 胡乱堆砌在一起，通过 className 与 element 绑定，就是一座屎山。无数人抱怨 CSS 不可维护，就是找不到应该从哪里入手修改，只能碰运气搜索一下，不久就放弃了，然后在文件末尾新启一行，糊上新的屎

我自己给常用的 200 个网站编写 UserCSS （不是），其中最长的(刚好是本站)有近 700 行，短的也有几十行，如果没有 css in js ，维护这些 CSS 不可想象

这种写法如此自然，以至于我想象不出为什么很少有人这么写，不是本该如此吗

nodejs 的 ORM 都是能在项目启动的时候自动建表的。
比如 TypeORM 把 synchronize 置为 true 。
这种方法是最友好的，但是不太安全。正经生产环境绝不会开 ORM 自动更新表结构。

就我个人的经验来看，nodejs 后端一般是先在本地或者测试服用 ORM 的自动建表功能建完了之后，用 DataGrip 或者手动 dump 把表结构导出成 SQL ，人眼过一遍，再找新的环境跑一遍，再把 SQL 部署到线上。真正对线上生产环境改动的 SQL 都是经过反复测试的。

具体到楼主这个小项目，我建议楼主要么开 ORM 自动更新，要么把运维的活也揽了。

转念一想，其实大家早就看不惯 React 这种函数式的贪婪更新机制。
所以后来的 Vue3 、Svelte 、Solid 都是监听变化按需更新，可以说它们比 React 更 reactive ，性能比 React 好不少，也没有到处 useMemo 、memo 的烦恼。
vue3 是我觉得最舒服的，reactive 对象可以作为全局变量存在于组件之外，这样极大方便了组件间通信。不过话说回来，全局变量还是得小心地用，不然会有内存驻留的风险。

你说的很对，用全局变量再加上 render-optimized 是个不错的方案，valtio 就是这么干的
https://github.com/pmndrs/valtio

powershell

这个软件我经常安装卸载。
每次看到大家都夸它好用就会去安装，安装完了发现它对我来说并没有提升效率就卸载。

alt + space 呼出搜索栏，我用系统自带 win + s 照样呼出搜索栏，而且 UI 上 windows 的搜索栏比 utools 好看不止一个档次。
各种小工具其实也挺好用的，但是大部分我能直接在 windows 商店里找到一样的，UI 上还比 utools 好看不止一个档次，何必让 utools 来做我的应用商店？

归根到底 现在的 Windows 已经足够完善了，并没有哪个方面需要 utools 来补足。

我见过类型体操最 6 的项目：
https://github.com/codemix/ts-sql

这时候就体现出 GraphQL 的好处了，后端还是直接抛从数据库里取出来的对象，前端需要什么按需取就行了

想勾搭设计师的话可以去站酷
https://www.zcool.com.cn/designer

楼主这个情况我觉得可以考虑深入学习 Node.js 。Midway 、Nest 搞起来。

来点新鲜的玩具：

Compose Multiplatform:
https://www.jetbrains.com/zh-cn/lp/compose-mpp/

React Native:
https://microsoft.github.io/react-native-windows/
https://github.com/nodegui/react-nodegui
https://github.com/infinitered/reactotron

Rust:
https://tauri.studio/
https://slint-ui.com/

如果是真的生产级应用还是用点稳定的技术。
写过 C# 再去写 C++ 简直是折磨吧。
目前 C# 比较稳定的桌面框架也就：
https://platform.uno/
https://avaloniaui.net/
坑多不多我自己也没用过也不清楚。不过话说哪个框架没坑呢？办法总部困难多。

单纯就业的角度来说 Java > Go > PHP > others

不过我觉得是，如果你花三四个月深入学一下门槛比较高的 Rust ，回头只要花一个星期就能掌握 Go 了。
我比较推荐掌握三种语言：

第一类短平快工具型语言：F#、Python 、JavaScript 、matlab 。代码简洁，写起来十分顺畅，适合平常自己写脚本整点小工具。

第二类偏向系统的底层语言：Rust 、C/C++、汇编?。这类语言可能稍微有点难度，但是能帮助理解硬件和操作系统的运行逻辑，非常适合用来提升。

第三类工程型语言：C#、Java 、TypeScript 、Kotlin 。这类语言通常语法比较严格，而且是面向对象的，非常工程化。搭配合适的框架很难能避免产生垃圾代码。这类语言用来讨碗饭吃。

我还是想再谈谈 Go 语言。Go 语言为了追求易学，有意向短平快靠拢，这导致语言过于简陋，是真的简陋：
为了省 throw/try ，靠 return 来传递错误；不健全的类型系统，interface {} 满屏飞。
我感触比较深的 ORM 场景。看看 C# 的 Entity Framework ，兼顾了代码简洁和类型安全。Go 的 ORM 要么只有简洁(gorm)，要么只有类型安全(ent)。说到底还是 Go 语言从根本上设计有问题。
在我有限的认知里，Go 语言是最丑的编程语言了。

相比于 Go 我觉得合适 Rust 更优雅一点。
语言设计上 Rust 完胜 GoLang 。
而且 Rust 是更底层的语言，经常写 Rust 能帮助你理解硬件的运行逻辑。
相比于 C/C++，Rust 的语法更加现代，有健全的包管理和构建工具。

正好最近在做的项目前后端深度使用 GraphQL 。

优点：
1. 强类型文档。GraphQL 本身首先是一门语言，而且是强类型语言，目前社区已有各种语言与 GraphQL 转换的工具。实践中，前端配合自动生成工具和 TypeScript 能确切知道每个 Query 每个变量每个属性的类型，省去了以往 RESTful API 项目中前端手动声明类型的麻烦。使用如果后端使用 TypeGraphQL 或者 NestJS 这类框架，能直接从 TypeSCript 的 Class 生成文档(schema)。

2. 自动聚合。以往 RESTful API 的每个接口的数据都是预先设计好的，前端展示的数据和后端返回的数据有时匹配不上，复杂的业务往往需要一层 BFF 层来做数据聚合。GraphQL 的返回数据是由前端决定的，能有效降低前后端的数据耦合程度，并且减少接口调用次数。

3. 更细致的鉴权。RESTful API 的鉴权颗粒度只停留在路由上，但是 GraphQL 能控制每个字段的访问权限。（讲道理 RESTful 也能，无非实现起来麻烦点）

缺点：
1. 迁移成本高。
2. 生态不完善。如果后端要用 GraphQL 的话目前几乎只能选 Node.js 了。其他语言生态都不完善，缺少 dataloader 、federation 等关键包库。
其他方面我觉得和 RESTful 相比，GraphQL 简直完胜啊

坑：
1. 著名的 N+1 问题。对于后端来说，需要对每一个列表查询进行优化避免 N + 1 。目前流行的解决方案是 dataloader 。
2. 每个前端项目只能有一张 GraphQL schema 。这使得后端必须部署一个网关来整个各个微服务，目前几乎只能用 Apollo Federation 来解决这个问题。
3. Subscriptions 。Apollo 实现了 Subscriptions 功能来帮助服务器主动发送消息。但是实践下来发现这个功能还是比较简陋的，不合适微服务架构和集群部署。

后端后期换 Go 我不是很理解。
在我看来 TypeScript 比 Go 优秀太多了。
Node.js 的生态与 Go 也是不相伯仲。另外看到前端有用 GraphQL ，那么后端用 Node.js 的 TypeORM/prisma + TypeGraphql/Nest.js 基本上是最优解。Node.js 关于 GraphQL 的生态比 Go 要领先一大截。
Go 比 Node.js 唯一优势就是性能，不过这一点只要多堆点机器就能解决了。
如果是要提升自己的话不如练练 Rust 。

语雀