AI 有所能有所不能,服务端渲染/Spa 之 GooseForum 又经过一年的迭代感慨(前端兜兜转转的技术选择)

1 天前
 PungentSauce

去年把很早之前开发的论坛项目GooseForum部署发布了之后,又伴随 ai 一起 coding 一年多了。质量也是越来越高。

codex 你真好用

当时帖子 2025 年分享

整个开发目标是单体应用(第一目标基于 go )+sqlite 下的良好运行(第二目标)

以及还可以的 seo(就是这个 seo 和第一目标之间的矛盾搞的页面技术换来换取,如果采用 go 打包可执行文件,那么像 nextjs 之类的使用就肯定不会考虑采纳)

那时候的第一版本没记错应该是采用的纯 css 吧。是从一开始 naiveui 切换走的(用 naiveui 写非管理页面我也是脑洞大开)。后来切换到 tailwindcss + Daisy UI 。 不得不说 ,用 Daisy UI 写管理页面也是脑洞大开,因为这是个纯 ui 组件。 再后来剥离了 Daisy UI 。 前端纯 tailwindcss+ Alpine.js+go 模板渲染 ,管理当时引入了一个 shadcn-admin(react 版本)。大概半年吧。

这套组合说能用也能用,但是确实古板,而且写法不主流,Alpine.js 性能也不是多好,并且还存在闪烁,当时还发帖询问了混合渲染有没有什么好的方案。

万能的 v 友啊,求一个不同语言开发的 web 混合渲染方案(首屏渲染用的不是基于 node 的服务端渲染,但是增量渲染使用 spa )要怎么做。

虽然当时没有改,但是当时讨论研究的几个方案算还是给我留下了深刻印象。也是我最终现在采用的方向。

就是<no-js>标签+payload ,这种情况下 react/vue 其实区别就不大了。并且过程中的管理页面和用户页面的分离也可以合并起来了(改之前是用户页面纯 go 渲染动态部分 Alpine.js ,管理页面纯 spa ,维护起来麻烦)。

并且随着 ai 迭代。稳定的迁移新技术,以及方案的实现都好很多,比如 过程中 payload 部分,没有采用 nertia.js 。 直接 codex 实现 的 go 模板-payload-spa-vue 的串联。

当然虽然 ai 没有让 go 直接实现 nextjs 的全部,但是这个方案再次重构整个网站。过程中质量/可靠性越来越强了。并且作品最终的运行的效果我也是非常满意的。

GooseForum

也欢迎大家相互交流 (`・ω・´)

568 次点击
所在节点    分享创造
0 条回复

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1215706

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX