不关哈希什么事儿（It's About The Hashbangs）
原文：http://danwebb.net/2011/5/28/it-is-about-the-hashbangs
几个月前，在Twitter和博客上有许多关于通过哈希路由方式解析传统Url的讨论。也有许多有趣的MVC框架解决此类问题。这个问题讨论的如此多以致让我有点神经质。但当这种讨论刚开始在互联网蔓延时我也想说两句，可以肯定的是通过堆砌哈希的方式是不可取的，我也很难一条条的列出其中的原因。
正如大家对又长又臭的带参数和哈希Url的反感一样，我也是其中一员。我的同事Ben Cherry已经在一篇博客中论述的很彻底，相比pushState而言堆哈希（hashBang）的方式只是一种临时的解决方案。正如他所言“不关哈希什么事儿”。
参考 那篇博客
经过多次思考和分析现在WebAPP中出现的问题（因堆哈希的方式），我觉得堆哈希的这种方式对Web而言是有破坏性的。即便作为一种降级的实现方式或者临时的解决方案，这种实现方式也不是很合适。
下面我来解释一下
- Urls很重要。Web如此强大缘于其海量信息。网页中的任何一块内容都可以引用其他的内容。我们的信息不再是孤立的一些点，他们是连系在一起的。Web作为这样的分享平台再合适不过。内容信息的连系靠的是Url。这使得Url是Web中最重要的组成之一。如果你在搞一个WebAPP，我猜想你推崇的是它的内容。倘若真是如此，那你应该更加关注这些内容里的连接。WebAPP要优于桌面App的一个点是直接的可访问的内容链接，可以肯定的是不是UI。
- Urls是长久存在的。Web有海量的信息，这些内容被索引、存档，最终可以通过Url来访问。发布在网络上的Url不经常修改。当你准备修改你的链接时，你应该考虑到有人可能链接到了你当前的地址。
- 高富帅的URl一般不发生变化。Tim Berners-Lee写了一篇经典的文章阐述了其不修改的原因。当修改Url时你隔断了与Web其他世界的联系，此时你的WebAPP也变成了一个简单的数据存储。你的内容已经变得失去大部分意义。然而实际应用中可能由于数据过期被删除，更换域名，重新组织网站结构等原因要修改Url。幸运的是，Http给了你处理这样情况的优雅的方式。如果内容被删除，我们可以告诉用户410错误。如果资源被移到别处，我们可以给用户提示301或者302错误。Http给我们提供这样的功能。可是，随着网络的发展，对资源的访问不仅仅只是浏览器的问题，搜索引擎和其他的一些爬虫程序也要访问这些资源。
参考 博客
- 资源需要被嗅探到。当你已经通过堆哈希的方式（即#的方式）来组织资源。#之后的内容指向特定的内容，这部分内容是不随Http发送至服务器端的，对服务器而言这部分是不可见的。服务器要考虑的是接受请求并返回一个状态码为200的回复。这个时候服务器端诸如410的状态码将不再起作用。（由于哈希以后的内容对服务器不可见，但同时它又指向一部分内容）。服务器解决不了，就交给了客户端来解决，js可以检测到Url的哈希部分，并显示相关内容，如果内容不存在则显示“内容没找到”的提示。后续的动作可能是将你带到WebAPP某个内部位置或者直接外链到其他地址。这里面最重要的区别是，当JS运行环境和文档对象模型（DOM）还没建立时，这些东西都是未知的。爬虫程序有时可以在JS运行时抓取想要的东西。即便如此，也没人能够理解“这是一个重定向”或者“内容没有找到”的提示（具体可以了解爬虫在此种情况下的实现机制）。这些爬虫程序搜索后的结果是人们正常浏览网页时不可探测的内容。Google提供一篇如何让你的Ajax程序被爬虫嗅探到，但这个过程是比较痛苦的。
- 一旦使用堆哈希的方式，你无法后退到传统Url页面（不带hash的url）。这是一个比较让人纠结的问题。Ben的博客已经告诉我们使用pushState可以后退到传统的Url页面。之前我已经讨论过了，url是长久的，可以被索引和存档的。我们不想让我们的内容丢掉任何有价值的链接。如果你已经通过堆哈希的方式来定位资源，而在访问他们的时候你又不想破坏链接，你可以借助JS，但是这活不是一时的，你可以今后都要陷入其中了。
- 可能还要糟。对于Web APP而言现在从堆哈希的方式向pushState的方式转变可能已经显得有点晚，pushState速度得被浏览器所接受，正如Kyle Neath上周在酒吧和我说的那样。pushState或许是FireBug出现后最好的革新。正如github已经实现的那样，pushState可以回退到正常的Url页面（不含一堆hash）。如果使用堆哈希的方式来索引内容，对于那些已经引用你的某些内容的用户（如已经将网址存入书签），你可能需要花更多的精力来支持他们。
参考 Kyle Neath
