关于JS文件合并的一些衍生想法

对于图片的请求合并是否可行也许还有很多地方需要商讨，比如存储方式，硬盘占用等。但是，网页不光有图片，还有其它资源。对于一些文本类型的资源，比如CSS和JS，合并的做法目前是非常普遍的。但只是简单地把他们放到同一个文件中加载是不是不太好呢？
　　图片的加载无论是否合并，只要是一张完整的图片它就是加载多少显示多少的。在加载过程中，用户可以看到已经加载了的部分。但是JS和CSS就不同，他们需要完全加载后才开始解析，如果像图片那样单纯的合并起来，所有脚本的执行都会因单次加载时间变长而被延后。
　　很多Web程序的结构都是层层依赖的，必须在所有依赖程序都加载完成后整个程序才能正常工作。那么，JS文件的合并加载，对它的执行就完全没有影响。但我的程序并没有使用依赖模型，而是使用了预加载技术。不需要等待所有依赖程序的加载，可以让重要的程序先运行，比如对页面的一些全局操作初始化；次要的后运行，比如对一些子功能的事件绑定。这种情况下直接把JS文件合并加载就会失去预加载技术原本的优势。
　　JS文件合并也可以使用图片加载的思路。把加载过程视为一个数据流，只要加载的数据足够形成一个合并前的JS文件就先执行，直到所有的文件都被执行一次。这么一来，预加载技术的优势就不会受到影响。但这在实现上并不容易，因为数据流的使用是受很多方面牵制的。比如跨域、浏览器兼容性、等，这在之前的问中有提到过。这确实是个问题！如果要兼容低版本IE，这个方法可能会得不偿失。不考虑低版本IE的情况，现有的API已经足以满足需求了。使用任何一种浏览器提供的服务器推送技术，把需要加载的JS文件作为推送的对象来传输。这么一来，整个加载过程就变为单连接、多请求，实现了类似SPDY的工作。
　　当然，这目前也只是个想法，过段时间我可能会试试看。