脚本装载时一个似乎应该有所重视的问题。

今天无意间打开了一个CSDN上的个人blog，发现窗口无法拖动，Firefox的标签页也无法切换。

查看代码：

<script type="text/javascript">Include("Csdn.Blog.UserOnline");</script>
<script type="text/javascript">Include("Csdn.Blog.ShowmeDataDeal");</script>

看到Include函数，马上可以想到，它很可能使用了动态包含脚本的设计。

//http://blog.csdn.net/scripts/jsframework.js
window.Include=function(namespace, path)
{
  .....
};
S.load=function(namespace, path)
{
  ......
}

仔细阅读这两个函数代码，发现它是通过XMLHttpRequest对象同步装载脚本资源的（对IE，它采用userdata缓存优化）。而这必将导致一种完全阻塞问题（这种问题我在仍外一篇blog上描述过：http://jindw.iteye.com/blog/66702）。

说到阻塞问题，我想大家可能会以为只是一种下载延迟，其实不然。
下载延迟不是完全阻塞，浏览器依然可以响应用户事件。而同步XHR请求阻塞是一种完全的阻塞。
浏览器在脚本运行与事件响应共用同一个线程（我的猜测）。任何脚本尚在运行时（包括被同步XHR请求阻塞的时间），浏览器将无法响应任何用户事件（无法拖放窗口、切换标签、重画页面等等，就像程序死了一样）。与普通的下载延迟造成的阻塞，感觉明显不同。

我对这个问题可以说深有体会，起初，在构建JSI1的项目站点时。因为网站放在sourceforge上，访问数度不是一般的慢，几个简单的例子，浏览器就要完全阻塞好几妙钟。正是厌恶这种完全阻塞的现象，我才开发了JSI2。

事实上，现在的一堆堆js框架中，采用XHR同步装载资源的有不少，JSVM、dojo、a9engine、hax的pies；其中JSVM，dojo都提供打包工具，将可能装载的脚本打包到启动文件中，所以也可以避免XHR同步请求。不过这样也就失去了部分动态装载的意义了。

总之，我非常讨厌这种完全阻塞现象，认为这个严重影响用户体验。
可能也有些主观因素把，希望听听大家的看法。

csdn浏览器杀手。
最新版本的yui也提供了loader，不过它好像是通过动态加<script/>标签来实现的。
东西太多，看起来好累。搂主如果感兴趣的话，可以去研究下。

原来如此,我每次都是冒着浏览器崩溃的风险去打开csdn的.

发挥css+html的威力  和提供更好的机制来配合浏览器 应该双管齐下，我认为重点还是在前面部分，所以我很欣赏ext。

yui-ext倒是准备研究一下：）
忙着找工作，推后推后。


以前用ie的时候访问csdn也老是浏览器崩溃，我想那应该是别的原因吧。

同步xhr请求导致浏览器短时间停止响应，虽然很让人讨厌，不过我没找到任何证据说明它将导致浏览器崩溃。

偏题了吧：）
我在这里想说的只是一种xhr同步请求导致的浏览器短时间停止响应的问题。

这个问题经常是很容易忽视的，因为我们本地测试的时候，根本发现不了问题；本地测试不必考虑网络传输的时间，所以，阻塞的时间基本察觉不到，但是，当网络不够快的时候，这种问题就很让人头疼了。

这个链接体验一下：http://jsintegration.sourceforge.net/example/code-block.html

我说的崩溃，其实就是指的浏览器僵死，不管是IE还是firefox，一个标签僵死，其它标签都动不得，20秒钟是我的心里极限，如果还是不能操作，我就认为浏览器已经down了。

观点很明确啊，就是开发人员不管这个问题，留个你们来研究了 呵呵

啊，说了半天，你是说不关心这个问题啊：（

刚体验过，最后只能在任务管理器中杀死浏览器。

再次打开浏览器就好一些了。不过虽然响应码全是304，仍然有点停顿的感觉。

很喜欢JSI这种做法。不过我太懒了，现在还是采用引入full.js，web服务器设置expired和gzip优化一下。JSI对我这个门外汉的吸引力还是让不同JS类库和平共处这个亮点。