JavaScript

记一次失败的jQuery优化尝试

我经常抱怨jQuery的DOM操作性能并不优秀,并且经常尝试用一些方法去进行优化,但是越是优化,越是沮丧地发现jQuery其实已经做得很好,从使用者的角度能够进行的优化实在有限(这并不意味着jQuery的性能是优秀的, 反之只能说它是一个相对封闭的库,无法从外部介入进行优化)。这篇文章就记录一次失败的优化经历。 优化思想 这一次优化的思想来自于数据库。在数据库优化的时候,我们常会说将大量的操作放在一个事务中一起提交,能有效提高效率。虽然对数据库不了解的我并不知道其原因,但是“事务”的思想却为我指明了方向(虽然是错的……)。 因此我尝试将“事务”这一概念引入到jQuery中,通过打开和提交事务,从外部对jQuery进行一些优化,其最重要的在于减少each函数的循环次数。 众所周知,jQuery的DOM操作,以get all, set first为标准,其中用于设置DOM属性/样式的操作,

JavaScript

一小段jQuery代码的分析与优化

今天刚回家,QQ群里就看到有人求助优化一段jQuery代码,简单看了一下,发现如果对jQuery这东西只停留在用的层面,而不知其具体实现的话,真的很容易用出问题来。这也是为什么近期我一直不怎么推崇用jQuery,这框架的API设定就有误导人们走上歧途之嫌。 需要优化的代码大致是这样的,也不方便直接把人家的代码复制过来,就大概地表达下意思: $.fn.beautifyTable = function(options) { // 定义默认配置项,再用options覆盖 return this.each(function() { var table = $(this), tbody = table.children('tbody'), tr = tbody.children('tr'), th

JavaScript

jQuery1.5的改进细节

jQuery 1.5 beta1出来了,从学习跟进上来说,这一次已经比较晚了(我竟然不知道1.5什么时候出的alpha,就这么beta了)。 这个1.5版本最大的更新是AJAX的完全重写,提供了更强的可扩展性。但是受制于精力和篇幅,对新的AJAX的分析还是放到下回,本篇先简单介绍一下细节方面的改进。 jQuery._Deferred和jQuery.Deferred 首先不得不说这两个新生事物,因为他们是作为基础设施存在,不把这两个东西讲明白了,有些问题根本没办法解释。 首先,jQuery.Deferred是jQuery._Deferred的增强版,因此对于这个问题,从jQuery._Deferred入手,就能说明一大半的问题。 什么是Deferred?从字面上看,我的第一反应是“

JavaScript

jQuery的.css函数的一个BUG

其实关于jQuery的css函数的BUG在很久以前的一篇博文中就已经有所提到,不过那个已经在1.4.3版本中被修复了,只可惜又引入了一个新的BUG,并且直到jQuery1.4.4都没有修复,昨天看了玉伯的从 isPlainObject 到“完美”代码的实现一文,仔细从各方面考虑了一下,感觉这确实是一个BUG,因此在本篇再提及一下。 这个BUG的解释相当简单,就是一句话: 在IE中,当一个元素已经拥有filter样式时,使用$('#bug').css('opacity', value)会使原有的filter样式失效 问题的重现 重现这个问题,需要以下的HTML片断: <div class=

JavaScript

细说浏览器特性检测(1)-jQuery1.4添加部分

浏览器特性检测即通过探测对象是否拥有某个属性或者函数,或者通过其他的编码探测方式,来决定其是否支持某一功能、特性。其最经典的运用莫过于通用的addEvent函数: function addEvent(element, type, handler) { if (element.attachEvent) { //IE8及以下浏览器 element.attachEvent('on' + type, handler); } else { //W3C标准浏览器 element.addEventListener(type, handler, false); } } 函数可以通过检测attachEvent函数是否存在,以决定使用attachEvent或者addEventListener,这也是最简单的一种特性检测,因而通常在需要时才进行实时的检测。另一种特性检测由于检测的过程较为麻烦,因此会预先完成检测,将检测的结果(