最近一直在扯SharedWorker相关的话题，从一些零碎的浏览器BUG到完整的操作封装。搞到这么麻烦，也许这时就会有人困惑了，SharedWorker到底有什么用？虽然之前的文章举的都是跨选项卡通信的例子，那只是为了说明问题罢了，SharedWorker绝不仅限于那点用途！
如今，Web即时通信已经越来越流行。淘宝做了即时通信、微博也做了即时通信，甚至贴吧都做了即时通信。还有数不清的Web应用都用上了Web的即时通信技术。不过无论是谁无论用什么样的代码实现，Web即时通信从传输层上看来无外乎都是靠长连接来实现。但在没有SharedWorker之前，页面之间的通信，或者浏览器选项卡之间的通信是非常困难的（可以通过localStorage或Cookie之类的公共存储区域来模拟实现，但成本比较高），所以就传统Web来看，每个页面几乎都是独立工作的。但页面之间存在很多重复的工作，如果每个页面都重新做的话势必造成大量的资源浪费。比如淘宝几乎在所有页面上都嵌入了Web版阿里旺旺即时通信模块。由于是即时通信的，所以前端程序与服务器总是保持一个长连接。但如果用户同时打开一大堆淘宝页面，那么每个页面都要与服务器建立一个长连接来保持自己的数据即时更新，这样无论是对客户端还是对服务器都造成了巨大的资源浪费。
SharedWorker最重要的用途就是从多个页面中提取公共模块。 比如把即时通信模块放在SharedWorker中实现，页面上只保留一个展示层的代码。这样页面本身就不需要直接与服务器建立长连接，而把这个工作交给了SharedWorker。当服务器数据有更新时先由SharedWorker处理，然后再把收到的数据从SharedWorker发送到所有相关的页面。这样无论用户同时打开多少个页面，也不会产生冗余的长连接。
解决Web即时通信的长连接冗余问题就是SharedWorker的一个应用场景，但不是它的全部。普通的Worker会在宿主页面关闭后被销毁，而 SharedWorker是在所有连接断开后才销毁 。这意味着，SharedWorker的寿命永远比一般页面长，它是比一般页面更尊贵的存在，一般页面要听命于它！换言之，它可以管理所有连接向它的页面，成为一个程序可控的页面资源管理器，协调各个页面之间的资源调度。听起来是不是越来越玄乎了？
说起来还有更玄乎的呢！从HTML5时代开始，单页应用的概念渐渐被人认可，但是为什么要单页呢！？因为单页应用下，整个应用中的所有资源都可以由同一个程序来管理嘛。人们希望一个程序可以管理所有的资源，而这点现在我们已经可以通过SharedWorker在多页面的场景中实现了。比如我们可以写出一个程序，当用户在A页面做某些操作时B页面做出某些响应（百度音乐就有类似的功能，但它是通过服务器中转实现的，效率低，成本高）。也就是说，整个浏览器下所有访问我域名的选项卡都已经是同一个程序在管理了，浏览器已经成了我的后花园，想怎么折腾就怎么折腾。我觉得将来“单页应用”的概念会出现狭义和广义之分，狭义就指现在的单页应用，而广义的会变成基于SharedWorker的“单页应用”。
以上说的这些，也许是我的梦做太大了。总之，SharedWorker是我最看好的几个API之一。从我刚知道Chrome支持它开始就一直等着其它浏览器的支持，如今Firefox29开始也已经支持。剩下个IE，它如果不想自己死掉的话，将来也一定会支持上的。