SPA | 锤子前端

《React Router v8 发布：最"无聊"的一次大版本升级》

Sun, 21 Jun 2026 08:48:50 GMT

《React Router v8 发布：最"无聊"的一次大版本升级》

标签：#前端 #React_Router #Remix #Vite #React19 #SPA_SSR #框架升级

总结：
React Router v8 正式发布，主打"最无聊的大版本升级"理念。v7 引入的 Framework Mode 已成熟，v8 在此基础上将多个 future flags 转正为默认行为，带来 40+ 项改进，包括中间件增强、路由模块拆分、类型安全的 href、Link 遮罩等。破坏性变更极少，升级路径平滑。团队同时宣布采用年度大版本发布节奏，并正式将 React Router v6 和 Remix v2 标记为生命周期结束（EOL）。

文章要点：
1. 升级超省心：v8 的破坏性变更极少，大部分改动在 v7 中就能提前完成，团队的目标是"让大版本升级尽可能无聊"
2. 基线要求更新：最低支持 Node 22.22+、React 19.2.7+、Vite 7+，且改为纯 ESM 发布，tsconfig 目标更新至 ES2022
3. Future Flags 转正：v8 移除了多个 future flags，其对应功能现在默认启用，比如中间件、透传请求、Vite Environment API 支持等
4. Remix 走向新方向：Remix v0.x-2.x 的功能已合并回 React Router，Remix 3 将转型为真正的全栈零依赖 JS 框架，与 React Router 并行发展
5. 年度发布节奏：从 v8 开始采用每年一次大版本发布，让升级更可预测、更稳定
6. v6/v7 生命周期：v6 和 Remix v2 正式 EOL，不再接收安全更新；v7 继续接收安全补丁

URL：
https://remix.run/blog/react-router-v8

remix.run

React Router v8

React Router v8 is available now.

《为什么我放弃Next.js和RSC，回归传统SPA与独立后端》

Mon, 01 Jun 2026 00:06:54 GMT

《为什么我放弃Next.js和RSC，回归传统SPA与独立后端》

标签：#前端 #Web开发 #React #NextJS #React_Server_Components #SPA #架构设计 #安全 #TanStack #Hono

总结：

作者回顾了自己从Next.js忠实用户到拥抱App Router/RSC，最终回归传统SPA+独立后端的完整历程。文章深入分析了RSC架构带来的心智负担、序列化开销和安全风险，结合2025-2026年多起严重CVE漏洞，论证了将渲染框架与安全边界解耦的必要性，并分享了当前基于React Router+Vite+Hono的简洁技术栈。

文章要点：

1. Next.js的黄金时代：Pages Router时期心智模型清晰，服务端/客户端边界一目了然，文件路由简单易懂，部署零成本
2. App Router带来的混乱：Server/Client Component区分成为负担，"use client"指令传染性强，开发/构建/生产环境缓存行为不一致，服务端客户端边界变得不可见
3. 安全漏洞敲响警钟：2025年CVE-2025-29927中间件绕过(CVSS 9.1)、2025年底RSC核心包10分满分漏洞CVE-2025-55182、2026年初多起Server Function DoS漏洞，攻击面集中在服务端渲染和反序列化环节
4. TanStack并非避风港：2026年5月TanStack遭遇供应链攻击，42个包被投毒，说明换框架不能免疫风险，减少依赖面才是关键
5. 序列化是根本原因：RSC的"无缝"本质是分布式系统的序列化问题，函数、类实例、错误栈都无法透明穿越边界，反序列化不可信输入成为高危攻击面
6. 当前架构选择：React Router框架模式+Vite纯SPA（仅营销页预渲染）+ Hono独立后端，API通过显式HTTP调用，无RSC负载，无服务端序列化
7. 安全设计原则：认证授权在API层强制执行，前端中间件只做UX跳转，CORS/CSRF/验证码/限流全部在可控的后端实现，与渲染框架彻底解耦
8. 核心收获：架构清晰可指认、无序列化税、前端攻击面趋近于零、后端语言自由选型、依赖更少爆炸半径更小——"无聊"在软件工程里是赞美

URL：https://dev.to/zulikram/why-i-walked-back-from-nextjs-and-rsc-to-a-plain-spa-and-a-separate-backend-4k8p

《利用浏览器Canvas进行数据压缩》

Fri, 27 Feb 2026 02:29:12 GMT

《利用浏览器Canvas进行数据压缩》

标签：#前端 #JavaScript #CanvasAPI #数据压缩 #PNG编码 #浏览器兼容性 #SPA

总结：本文介绍了一种利用浏览器Canvas API将任意数据压缩为PNG图像格式的技术方案。通过将字节数据编码为像素颜色值并生成PNG图像，可以间接调用浏览器内置的压缩算法，实现无需外部依赖的数据压缩。该方法特别适用于需要在旧版浏览器中压缩数据、或需要将SPA状态序列化到URL中的场景，提供了Compression Streams API不可用时的替代方案。

文章要点：
- 背景需求：在静态网站和SPA中，有时需要将状态数据序列化到URL hash中，因此需要前端数据压缩方案；虽然2023年5月后Compression Streams API已普及，但旧版浏览器仍需替代方案
- 核心原理：浏览器内置了优化的压缩库用于HTTP请求和图片处理，通过将数据编码为PNG像素数据，可间接利用浏览器的无损压缩能力
- 技术实现：将Uint8Array数据按RGB通道编码到Canvas像素中（首字节存储最后一像素的有效字节数），Alpha通道固定为255以确保跨浏览器一致性，最终通过toDataURL("image/png")获取base64编码的压缩数据
- 解压流程：异步加载生成的PNG图片，读取像素数据后过滤Alpha通道，根据首字节指示的有效长度提取原始字节数据
- 方案特点：即使考虑PNG格式开销，压缩后的数据通常仍小于原始数据；完全基于浏览器原生API，无需外部库依赖
- 应用场景：旧浏览器兼容性支持、URL状态序列化、纯前端数据压缩需求

文章URL：https://jstrieb.github.io/posts/canvas-compress/

jstrieb.github.io

Using the Browser’s <canvas> for Data Compression

Old browsers don’t have JavaScript compression APIs, so we store data in pixel color channels and export to PNG to compress data.