Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

「静态」才是理想状态

  我经常说前端涉及的面很广,甚至抢了一些后端的活。那是因为我们都被「单页应用」给绑架了。现在随便一个新开的前端项目似乎都会是单页应用。而且自从 History API 出现之后,前端路由就非常火。反正我是非常讨厌前端路由的,因为这些东西破坏了 Web 最初的设计理念。
  在我对 Web 这个概念的理解中,Web 是 HTTP 的衍生物。可 HTTP 又是什么?它是以 URL 为单位来传输资源的。HTTP 的 GET、PUT、DELETE 这些最基本的方法本来就是用来操作资源级的对象的。
  单页应用本身并没有什么问题。当我访问一个 URL,这个 URL 就是一个复杂的前端应用,在上面的所有操作都不需要跳页面,这是可以接受的。早期的单页应用就是某个 URL 下有个复杂的应用而已。后来人们为了保存操作过程中的状态,使用了 hash,这也是可以接受的。但是此时很多人都觉得 URL 中带一个 hash 太丑了。再后来,History API 普及起来,由于这套 API 可以给页面切换时加上一些炫酷的效果,所以很多人把本来不属于单页应用的东西使用 History API 给强行搞成单页了。
  但是这带来了令一个问题。History API 改的直接是 URL,当浏览器刷新后 URL 会被发到后端,如果没有对应的资源就会 404。于是前端开发人员就「自作聪明」地把所有请求都响应同一个入口文件,由前端来解析 URL,拉开了前端路由时代的序幕。
  我觉得,从这里开始 Web 就走向了一个错误的方向。资源的概念被抹杀,所谓「统一资源定位符」已经残废。这意味着前端项目不能再静态化,不能再让 HTTP 和文件系统直接关联起来。
  History API 的前端路由解决了什么问题么?当然有,它解决了 hash URL 太难看的问题(简直醉了)!它又造成了什么问题呢?它破坏了 HTTP 和文件系统的关联性,让前端项目对后端路由产生了强依赖。最直观的例子就是本来 nginx 配置里只要指定 root 就可以的,现在要写 location 了。本来可以完全丢给 CDN 的东西现在需要自己的服务器来部署。本来可以在客户端共享缓存的页面,由于 URL 不同无法使用缓存。
  为了解决一个 URL 难看的问题带来了一些列问题显然太不值的了。所以前端项目最好的状态不该是基于 History API 的前端路由(即使要搞前端路由也应该使用 hash)。最理想的前端项目应该是一个 python -m SimpleHTTPServer 就能跑起来的纯静态项目。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^