SolidJS 的 SSR 框架 SolidStart 可以在公司项目使用吗？

据说正在重构底层。原本他们用 nitro 包了一个 vinxi ，tanstack start 也用的这个。现在 vite v6 的 environment api 解决了大部分 vinxi 解决的问题，于是开始去 vinxi 了。tanstack start 比较活跃，支持 react 和 solid ，已经完成了； solidstart 就比较慢了，作者本身还在搞 solid v2

@subframe75361 #1 目前为止 TanStack Start 还没去掉 vinxi 吧？

建议不要趟这个浑水，全是些不稳定的东西，独立开发者用用不一定会踩到 corner case ，上生产就不一样了。

而且我对国内上 SSR 的收益是怀疑的，因为不管是 Next 还是 Nuxt ，性能都差的一笔... 同样的并发量需要的配置比后端服务还多。

我建议 OP 可以把前端拆分一下，需要 SSR 的场景改为用 SSG ，编译出插槽模板，起一个简单的 node 服务，返回之前对插槽做字符串替换就行了。

@CHTuring https://x.com/schanuelmiller/status/1932550284787511609

不适合上生产，没有大型的项目背书，我自己整过，各种问题不断。

solid 全链条没有稳定值得上生产的产品，我对我这句话负责。

@songray "起一个简单的 node 服务，返回之前对插槽做字符串替换就行了。" 这种在有用户认证的情况下不好做哇？比如千人千面的 UI 就还是得 SSR 或者客户端 ajax, 需要用到 cookie.

@songray #3 不是,自己起个简单的 node 就能上生产环境了吗

@jesse9527 恰恰相反啊，这样才能做认证。
前端编译出模板，然后要么后端直接用模板引擎做替换，要么起一个 node 做 BFF 去替换，不管怎么样认证都是通过后端服务直接完成的。

反而是 SSR 的话不好做，因为你得 All in SSR ，让 Next/Nuxt 接入后端的鉴权服务。或者把 SSR 当 BFF 做，但是这样会拉低整个服务的并发能力。

还有千人千面的 UI 也不是通过 SSR 完成的... 我不知道国外是什么样，国内对前端来说，就只是 App/H5 的活动卡片不一样，点击之后跳另一个 H5 而已，至于展示什么活动卡片和 H5 ，也是后端根据大数据决定的。这方面你直接看抖音和拼多多就行了。

@gorvey BFF 都多少年的东西了... 稳定性比 SSR 好太多了

@songray 那感觉涉及到认证的还是麻烦，不管是 Next SSR 或者 Node 做 BFF 然后接入认证。
一般来说纯后端他只管数据库的接口，模板渲染、BFF 这里的鉴权都需要前端自己搞。

@jesse9527 所以我说国内根本不玩这套东西（ SSR ），也就是独立开发者搞搞。
国内互联网公司全是 App/小程序引擎/H5 连环套，中大厂可能接个 BFF 做特殊处理，但大多数就是客户端渲染 h5 。

研究这玩意没啥意义，面试都不问的🤣

我再提一点，就是浏览器插件导致的水合问题，这玩意现在没有，未来也不可能有解决方案。

@songray 确实，只有大点的公司才搞这些，小公司都是 csr

我写了几年 solidjs webapp ，总体非常满意，不过对 ssr 看都不看一眼。除了以内容为中心的应用，一般的 app 我想不通上 ssr 的必要性在哪，复杂性上升性能下降。

而且象楼上所说的，solid 基本功能很稳，但复杂的东西可能有坑。之前 Suspense 好几年都有问题我从来不用，虽然现在表面看似乎修好了。router 有个问题，我现在 2 年了都还没升最新版，因为一升就出问题但找不出问题所在，我想搞个最小化复现提 bug 都没搞出来。

同意上面的说法，SSR 所带来的收益与付出成本不成正比。
比如认证部分，你只能使用基于 cookie 的认证方案，才能保证 C/S 两端的状态一致。
然后视图渲染部分，nodejs 下性能就是很差，没办法，各种缓存方案都是治标不治本，而且还要额外处理缓存问题。
我也就新项目尝尝鲜，并发上不去导致客户吐槽多的话，马上切回 CSR 。

建议不要没事找事