SPA
JavaScript 并非问题所在
我们耗费了十年时间,通过劫持路由、手动同步状态、用 JavaScript 重建表单和转场效果来模拟原生应用体验,从而“重建”了浏览器。如今浏览器已迎头赶上,是时候停止这些“黑科技”,重新在 Web 上构建应用了——但要以正确的方式。
选择“单页面应用”(SPA)技术栈通常并非出于性能考量,而是为了可用性。作为前 iOS 开发者,苹果每年发布的《人机界面指南》深刻影响了交互设计理念——其核心原则之一便是视图转场效果:用户点击某行时,新屏幕平滑滑入视图。这帮助用户保持方向感,理解当前所处位置及如何返回。
早期的 Web 无法实现这种体验。整页刷新意味着新屏幕突兀出现,用户需自行脑补上下文关联。因此开发者开始“改造”浏览器,发明了 SPA。初衷并非热爱 JavaScript,而是为了满足用户期望——追赶苹果的体验标准。
浏览器能力进化
如今浏览器与网络基础设施已实现突破: ✅ 视图转场:原生支持平滑过渡
✅ 流式渲染:动态内容分块加载
✅ 边缘计算:就近处理用户请求
✅ 统一标准:主流浏览器高度兼容
不再需要为每个特性寻找 Polyfill 方案,Web 平台已足够强大。
RedwoodSDK 的解决方案
我们选择彻底拥抱服务端路由与渲染,避免在浏览器内模拟浏览器行为(劫持路由/手动同步状态/JS 重建表单)。核心策略:
// src/client.tsx
import { initClient, initClientNavigation } from "rwsdk/client";
// 初始化客户端导航拦截(监听锚点点击)
initClientNavigation();
// 启动客户端框架
initClient();
实现原理:
拦截锚点点击事件 → 以 React Server Component (RSC) 流式获取目标页 → 通过 React Hydration 无缝更新 DOM
效果媲美客户端应用,同时保留 Web 原生请求-响应模型(Cookies/重定向/标准错误码)。
关键结论
- 无功能牺牲:延续经典 Web 开发模式(URL/表单)
- 渐进增强:按需启用客户端导航(特定路由平滑转场)
- 精准定位:
- SPA 仍适用于零延迟/离线/重交互场景
- 90% 的通用场景由服务端方案覆盖
历史背景
SPA 诞生于 2000 年代初:
- 1999 年
XMLHttpRequest
实现异步数据获取 - 2004/2005 年 Gmail 与 Google Maps 验证技术潜力
- Backbone/React 等框架解决 SPA 复杂度问题
核心驱动力始终是与原生应用竞争用户体验。
总结
核心理念
我们终于可以停止与浏览器对抗,不再重复实现其原生能力。RedwoodSDK 基于三项原则构建:
原生优先
直接利用浏览器原生特性(如 View Transitions API),而非通过 JavaScript 重新实现转场逻辑。服务端驱动
默认采用服务端渲染,仅在必要时启用客户端增强:// 示例:启用特定路由的客户端转场 appRouter.route('/dashboard', { clientTransition: true })
渐进增强
基础功能保障所有用户可用,高级体验随设备能力动态加载。
范式转变
传统 SPA 方案 | RedwoodSDK 方案 |
---|---|
劫持路由 | 原生路由系统 |
手动状态同步 | 自动 Cookie/Header 同步 |
JS 重建表单验证 | 原生 <form> 行为 |
技术价值
核心洞见:JavaScript 从来不是瓶颈,问题在于试图用 JavaScript 重建浏览器已有能力。RedwoodSDK 通过回归 Web 本质,释放了现代浏览器的完整潜力。
https://redwoodjs.com/docs/client-navigation
(感谢 Barrett, Simon & MJ 的早期反馈)
RedwoodSDK 定位:
专为 Cloudflare 设计的 React 框架,通过 Vite 插件提供:
- SSR (服务端渲染)
- React Server Components
- Server Functions
- 实时功能
核心优势:
⚡ 基于标准的路由系统(支持中间件/拦截器)
⚡ 深度集成 Cloudflare 生态(Workers/D1/R2/Queues/AI)
⚡ Miniflare 实现本地生产环境模拟
https://github.com/redwoodjs | https://discord.gg/redwoodjs | https://redwoodjs.com/docs