2008-05-11
全文显示

测试一下你属于哪种人

抄自http://www.terrainformatica.com/index.php/?p=32 What will following JavaScript function return? function test() { try { return "I am optimist"; } finally { return "I am pessimist"; } } Try to answer as this is a good chance to measure your attitude
2008-05-07
全文显示

JS之父再谈JS历史（一）

译自Brendan Eich的Blog上Popularity一文。【】内为我的注。 Popularity 关于流行 It seems (according to one guru, but coming from this source, it's a left-handed compliment) that JavaScript is finally popular. 貌似（根据一位精神导师的说法【中译】）JavaScript最终流行了（尽管从原文来看这种赞美乃是言不由衷）。 To me, a nerd from a tender age, this is something betw ...
2008-04-10
全文显示

JS解析测试代码片段

前一日与jindw聊天，谈到了正在研究的JS代码转换。譬如JSA所作的，其实就是一种代码转换。 PIES为了实现namespace（package）的管理，对JavaScript源代码也进行了处理。为了保证效率，所以想方设法只做了最最简单的预处理，也就是对代码段加头加尾，这样只是简单的字符串串接，对于效率是没有影响的。 但是最近在考虑是否有可能支持一些JS2（ES4）的特性，譬如支持let。这就必然需要将let转换为ES3所支持的某种结构（简单的说，在let语句开始的时候，把let的scope之外的同名变量先压栈，然后到了let的scope之外再恢复出来）。 总之这里就涉及到一种代码的t ...
2007-09-25
全文显示

JS优化原则

关键字: JScript Performance Optimize
JS优化已经讨论了很多了，最近又看到aimingoo的一篇。大体上，aimingoo的说法都是非常正确的。 除了像aimingoo做个案研究外，这里我想从更一般的角度总结在浏览器编程中JS优化的几个原则。 首先，与其他语言不同，JS的效率很大程度是取决于JS engine的效率。除了引擎实现的优劣外，引擎自己也会为一些特殊的代码模式采取一些优化的策略。例如FF、Opera和Safari的JS引擎，都对字符串的拼接运算（+）做了特别优化。显然，要获得最大效率，就必须要了解引擎的脾气，尽量迎合引擎的口味。所以对于不同的引擎，所作的优化极有可能是背道而驰的。 而如果做跨浏览器的web编程，则最 ...
2007-09-24
全文显示

window.eval 及相关方法总结

关键字: eval execScript Script.exec
前面有帖子说到在函数里如何能在全局空间上eval。 虽然此种需求在绝大多数情况下是不合理的，但是仍有极少数情况可能确实有需要。 JScript有execScript方法可以用来执行脚本。其第一个参数为代码字符串，第二个参数为脚本语言，可以选择jscript或者vbscript。 而在其他脚本引擎中，SpiderMonkey保留了JS最早时候的在对象上的eval方法。也就是在任何对象上，都可以eval，执行时，会把该对象加入scope chain。 例如 {x:1}.eval('x')会返回1，而(o={x:2}).eval('var x = 10')后o.x会等于10。 ...
2007-09-10
全文显示

鸡肋的E4X

关键字: E4X
前两天，Aimingoo问我如何能捕获E4X对象的事件（如修改了一个属性），我这两天稍做了研究，发现： 还真没办法！ 问题在于E4X的模型，与现有JavaScript和DOM模型根本是不同的！ 所以E4X的xml对象上，根本没有addEventListener之类的方法。而E4X的操作也不是基于对象上的方法的，有直接的运算符（例如+=可以用来追加元素），所以甚至也不可能使用暴力AOP（例如改写Element.setAttribute方法）。 理论上说，貌似E4X的xml对象有domNode()方法（我没有核对过规范ECMA357——连不上，难道ecma网站被功夫王河蟹了？），可以获得对 ...
2007-08-18
全文显示

改写函数实际上违背了FP的无副作用的精神

在上一篇帖子中，我讨论了Peter提出的Lazy Function Definition Pattern，我指出了这个pattern并不能带来性能的提升，而所使用的closure也有可能造成内存泄漏。 当然内存泄露在任何closure中都可能存在。因此仅仅从不必要的使用closure加大了内存泄漏的风险这一点来说，说服力可能并不强。而且，在之后的回复中，FCKEditor的FredCK给出了一个不使用closure的改进方案。 但是我仍然觉得哪里不妥。 经过一些思考，我终于意识到关键的坏味道，其实就在于对函数变量的重新赋值。 我们知道纯FP是不带有副作用的，因此不可能允许函数名称与实际 ...
2007-08-17
全文显示

JavaScript的Closure陷阱

有这样一种新的JS pattern：Lazy Function Definition Pattern，realazy同志的翻译在此：http://realazy.org/blog/2007/08/16/lazy-function-definition-pattern/ 大体上，这个pattern就是在函数的第一次运行时重新定义自身，代码示意如下： var f = function () { ... // calculation if (condition == 1) { f = function () {...} } else if (condition == ...
2007-07-23
全文显示

关于JScript 5.6及其之前（IE6）引擎的创建对象的性能问题

关键字: jscript gc
这个问题很早就知道，即在对象数量达到一定程度的时候（例如50000），创建新对象的速度明显下降。过去在和aimingoo共事的时候（2006年的某个时候），我花时间研究了一下。 当时我首先猜测是否是在一个closure里，因为当前[[scope]]下可访问的变量太多造成的，即我怀疑是jscript的name resolve的问题，但实际写了一些测试用例证明这个猜测是错误的。任何时候，只要存在大量对象，不管在当前创建新对象的function里是否能访问到已经存在对象，性能都十分低下。 不知怎的，我开始怀疑是否是垃圾回收的问题。于是我尝试在创建对象的循环里插入了CollectGarbage的强 ...
2007-07-20
全文显示

ECMAScript规范可能存在缺陷

关键字: javascript
原讨论帖地址是http://www.javaeye.com/topic/101506 首先，这一个帖子中，Lich_Ray按照ECMA规范来推导，这个尝试是好的，但是ECMAScript的规范是出了名的佶屈聱牙，所以不幸的，Lich_Ray同志也未幸免。。。 Lich_Ray 写道看来我就此开个 JavaScript 专栏一心和你们讨论这些问题算了。这帖子居然还有一群人跟在后面打“良好”“精华”，无语了… 火是要发的，问题也是要解决的。下面讲正经的。不仅仅讲给 keshin 一个人听，大家都来看下吧。我们开始从 === 运算符谈起。 请翻到 ECMA-262 e4 的 11.9.4 ...
hax
搜索本博客
存档
最新评论