Web 技术研究所

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

单页应用与 manifest

  最近在尝试 manifest,但发现在单页应用上加 manifest 似乎没卵用。我们可以用 History API 来修改地址栏的 URL,可是新的 URL 一旦重新加载又会从服务器拉取一遍,先前页面的 manifest 就被无视了。如果单页应用的入口总是不同的 URL,那 manifest 还有用么?
  现在想想,单页的 Web 应用好像被 History API 这个神奇的东西给侵略了。单页应用应该和 URL 长什么样没有关系,最初的单页应用全都是在一个 URL 上的,之后的操作都是页面渲染的变化,并没有修改到 URL。后来人们通过 URL hash 修改不会跳转页面的特性,使用 hash 来保持页面的状态,以便一个单页应用的链接被分享后依然可以定位到具体的数据上。后来 History API 逐渐被浏览器所支持,于是大家都纷纷改用 History API 来实现单页,让程序看起来不再像单页应用。
  我之前也纠结过「URL 到底干嘛用的?」,然而事实证明,目前的用户已经不再对 URL 是什么敏感,即使 URL 再难看也不会有人注意到。就像淘宝的 URL 里一坨奇奇怪怪的参数,我每次分享一个淘宝链接时都觉得它脏,恨不得手动把多余的参数全部删除掉。但实际上也就我们这样的开发者会在意这些,一般用户哪会管 URL 长什么样?
  既然 URL 无所谓脏不脏,甚至根本没人看,那么我们为什么还要用 History API 来实现单页应用呢?使用 URL hash 来实现单页不是更容易命中缓存?使页面加载速度变得更快么?
  其实 History API 除了解决 URL 难看的问题外,还解决了 SEO 的问题。实际上很多搜索引擎对 URL hash 都是无视的,这也是人们更喜欢用 History API 的原因。在使用 History API 时大家不仅会实现前端路由,后端可能还有一套同构的渲染机制,又或者是使用一些 prerender 之类的黑科技来让搜索引擎抓取到真实内容。
  既然如此,我们为何不试试将 History API 和 URL hash 一起使用呢?所有页面上的链接都写成普通 URL 的形式,然后页面程序总是将当前页面 URL 通过 History API 转换成 URL hash 的形式。这既解决了超链接的 SEO 的问题,同时即使用户把页面链接分享出去也是 URL hash 的版本,点击进来的用户同样可以命中缓存。
网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^