47% users on this site use *nix
- 异步、模拟多线程式的JavaScript，防止界面锁死。例如Google Gears，Firefox3.5 WebWorker异步API。
- 拆分JavaScript文件，即需即载入即运行，避免首次载入的高代价。类似dojo的分包机制。
- 普通的script会阻塞页面的载入直至脚本下载执行完成，采用其它方法可以改变这种情况：XHR Evel, XHR Inject, Script DOM, Script Defer, Script in Iframe, Document.write Script Tag。
- 由于外部script和内联代码异步载入造成的冲突，解决方法1. 在外部编码种硬编码回调，2. 在Window.onload中调用 3. 用timer监控载入情况 4.scripttag.onreadystatechange
- 把异步载入外部脚本的方法编写为可复用的module
- 处理内联脚本，解决方法：1.将内联脚本移至页面尾部 2.异步执行JavaScript回调(setTimeout(0)) 3.使用script defer属性 内联脚本执行会被
- 语言级别上提高JavaScript执行效率的一些手段，Zakas
- Comet的前景和现阶段实现，以及WebSocket
- 优化HTML文件
- 优化图片的utilities和几种格式的特点
- sharding文件到不同的服务器上增加并行下载
- 正确地使用flush提高部分页面的加载速度 影响因素1.是否开启了Output_Buffer，2.是否使用了chunked encoding， 3.是否启用了gzip并在apache228上运行 4. 是否被代理和AV软件影响了 5.是否因为相同的域名的文件下载被block了 6.是否是webkit阈值以下不能渲染
- 慎用iframe，DOM操作代价过高，在html中设置src的iframe会阻塞onload，iframe与style script标签的位置
- 高性能的CSS选择器，避免全局rule，避免div#sele，避免div.sele，避免使用长选择器，避免使用decendant选择器，避免使用tag-child选择器，查看所有child选择器，使用继承
避免div#sele，避免div.sele
—————-
这句不明白是什么意思，避免这样写，难道写成 #sele | .sele 之类的？
@小马 对，直接写就可以，尤其是id的那种情况，避免浏览器去找相应类型的元素
是仅指 divi 这个标签？其它的呢，比如 h2.sele 如何
@小马 哦，对所有tag都一样～
我最新的想法是简化主义，尽可能避免任何hack，像ext那样深dom结构模拟web control或者jquery那样模拟的css selector都不是future promise的。我现在觉得理想的js封装方式是这样的：
1 在onreadystatechange中加载一个bootstrap.js。
2 在这个自启动脚本中判断浏览器类型，根据不同浏览器类型下载具体的代码。在编写js时，可以考虑用语言机制来自动生成，比如gwt那种，然后flash develop里支持的一个语言也可以按照要求编译成js，我现在记不清了
3 尽可能不要hack，不要模拟任何东西，客户端看到的应该是input type=”button”这样的封装好的控件，具体的控件实现可以考虑用flash实现，但调用时看到的只有js的接口
4 异步机制的确很重要，我觉得最好有个全局控制点，不然很难维护
5 dojo那种动态加载方式其实得不偿失，js的模块化不需要那么动态，最好事先分解好，然后压缩，具体的应用还是一次性下载完比较好
用户操纵的如果只是控件级别的api，而不是各种各样的层，那么以后html5普及了，在库的内部替换为html5原生控件就可以了，否则就用flash组件来实现，这样的效率必然是最高的。
层还是用来做它最擅长的事-布局吧
我现在觉得特性的简单性非常重要，如果一个特性可以节省10行代码，但是需要多研究10个小时，或者增加10%的出错概率，那还是不使用这样的特性为好
@axel 嗯，你应该写一篇然后trackback过来～