前端拼好框

既然你点进了这篇文章, 那么你应该已经注意到了, 这次看起来跟以前有点不太一样了 (就算你使用 RSS阅读器, 那么应该也能发现这一点, 总之绝对跟我乱写代码, 导致出现了某些不可描述的破坏性变更没有什么关系). 没错, 之前说的哪个新的前端现在上线了, 虽然真正的完成度可能连一半都没有, 那么现在来介绍一下吧.

坏了, 图片怎么不会动

速度?

除去外观, 最明显的一点应该就是网站的速度了, 按照常理, 换用了新的技术之后或多或少都能得到性能的提升吧? 但是, 很遗憾, 并没有. 相较于之前的 Next.js + Django(.py, 为什么 JS 库都要加 .js 后缀?) 反而更慢了.

原因也很简单, 就是因为没给 CF (Cloudflare) 交保护费, 原先整个前端都运行在 Cloudflare Workers 上, 前端的所有内容都是直接由 CF 的 CDN 提供的, 而 CF 的 CDN 全球都有, 每个地方的访问速度都很快 (除了个别地区).

但是, 现在的话, 所有请求如果在 CF 那里没有缓存的话, 都需要把请求转发到我的服务器. 但是我的服务器差不多在地球的另一边 (问就是便宜, 也是因为他太慢了, 平时连 ssh 都懒得登), 所以延迟相当的高. 反应到网页上就是网页速度相当的慢了.

那么这个时候就有人要问了, 预加载呢? 预加载当然有, 只不过比较的克制, 大概会提前 0.1s 进行预加载, 杯水车薪. (实际上, 一次请求也就 10kb 左右, 直接全站预加载好像也没什么大问题) 因为是跟踪鼠标的行为来实现的, 所以移动端甚至完全没有这个功能.

说起移动端, 至今有个水合 bug 没修好, 并且只在移动端浏览器上复现, 枯了. 没事, 只要你没有发现他, 这就不算是 bug

结构?

结构在之前的文章里说过了, 就不再复述了, 总体上是四层的结构. (或者说是只有三层?)

需要纠正的一点是, Behaviors 层和 Solid Islands 层其实上是左右结构, 而不是上下结构, 也就是说他们是完全互不干扰的. 因为他们从设计理念上就完全不同, Behaviors 是一个微型命令式行为 "插件" 管理器, 而 Solid 则是一个描述式的独立运行时, 他们从设计理念上就完全不一致.

命令式关注 "怎么做"; 而描述式描述具体要 "做什么", 具体要 "怎么做" 由运行时决定. 像 React.js, HTML/CSS, SQL 都属于描述式. (说起 SQL, 因为现代 ORM 太好用了, 导致我甚至至今不会 SQL, 要我说 SQL 也是世界上最难的编程语言 (那 CSS 呢?)) 直接把这个运行时看成是黑箱就好, 而对于这些黑箱代码, 在不了解的情况下 (如果你了解的话那也就不算是黑箱了), 能不动就不要去动了. 不然可能会出现各种各样的问题, 包括但不限于 DOM 混乱, 内存泄露之类. 并且, Solid.js 作为一个生产级框架, 也是完全有自治能力的, 不需要外部介入.

这也是为什么 React.js 要求所有的组件都不能有副作用了, 因为副作用可能会扰乱运行时的行为, 出现一些意料之外的情况. (想起 C 语言里的未定义行为了, Undefined behavior. 可能会出现各种各样的情况, 最好的情况是当场抛出熟悉的 Segmentation Fault, 最坏的情况嘛, 只能说一切皆有可能了)

说起 C 语言, 写 C 语言写得是真的头大, 原本看着没有 Rust 复杂的生命周期规则, 写起来还是眉清目秀的. 但是写到所有权就头大了. ~~因为想要省点内存, 提前释放了一部分内存, 结果到后面导致双重释放了 (这也是一个未定义行为), 最后让 AI 缕了两圈才捋清 ~~.

毕竟过早优化可是万恶之源

所以我个人还是很看好 Zig 的, 虽然我之前一直把他当成没那么安全的 Rsut 看的, 向下对比 C 语言, Zig 相当透明可控 (C 语言虽然写起来简单, 但是要写出 "正确" 的代码很难); 向上对比 Rust, 在保证一定安全性的同时没有复杂的心智模型. 我记得很久之前说要学学这个来着, 但是到现在都还没有开始, 自制能力堪比一颗成年草履虫. (好像还有 Ruby 来着, 另一个世界线的 Python)

扯远了, 其实说是有四层这么多, 但是这里面其实非常简单, 核心代码只有 500 行 (来源: LLM), 并且几乎全是胶水代码 (这也是文章标题的来源). 如果你想自己上手逝逝的话, 我让 LLM 写了一个 skill, 把项目克隆到本地, 然后用 AI 编程工具打开 把 skill 丢给他, AI 就能帮你搭一个一模一样的出来. SKILL

当然, 因为胶水的原因, 如果你不想使用 Solid.js, 你也可以稍作改动把他换成其他的什么框架, 比如说 React.js. HTMX 也是同理, 用不到他的片段更新功能的话, 可以把他改成 turbo 之类的导航器, 来把页面升级成伪 SPA. 甚至, 如果你不写 Django, 还可以把他迁移到任意使用模板语法来渲染 HTML 的后端, 比如说 Rails, Axum, WordPress 这些, 只需要重写那 100 行 py 文件就行了.

倒是搭建底层基础设施的时候很有意思, 可以随意规划要使用的方式, 用怎样的代码结构来实现他, 顺带还可以做一些性能优化. Python 写多了性能焦虑都写没了. 倒是上层设施挺无趣的, 照着框架, 按照同样的逻辑, 大家都写这一样的代码, 甚至连注释都大差不差, 如果 Vibe 的话. 但是这日复一日的日子什么时候是个头呢? 可能就像是你老板口中的涨薪一样遥遥无期吧.

问题?

但是, 我又要说但是了. 把一堆设计理念完全不同的框架拼接到一起可能会有什么问题呢?

这会导致整体结构相当脆弱, 只靠那 500 行的胶水是不可能做到面面俱到的, 如果不熟悉的话可能会随手把某些地方写炸, 很多地方可能都得需要防御性编程, 并且搭配大量的测试用例 (我到现在都还在给他补测试, 难过).

并且岛屿组件, 也无法解决他的性能问题, 同时还会因为需要的水合 js 加载过晚影响用户体验. Solid.js 也无法像 Qwik 一样做到真正的 "0 水合". (除非你去定制 dom-expressions 渲染引擎)

最后, 看看最不重要的页面性能, 说实话, 没什么好看的, 毕竟首页几乎就是纯 HTML, 代码写得再烂也不会差到哪去.

要说有什么优势的话, 可能就只有这点性能优势了, 用浏览器打开网页, CPU 没有半点波澜. 为什么感觉写了这么久, 还是在写 HTML? 果然, 我是fw

好累, 写完手头这点代码我得去休息几天了, 游戏里见, w