Hello World
Spiga

分类:前端表现

由eval生成的代码效率真的很差吗?

2012-08-15 21:29 by 老赵, 16060 visits
摘要:昨晚跟一位Node.js专家讲解了我的Wind.js类库。之前那位仁兄对Jscex(Wind.js的前身)的看法是“就是不喜欢”,也在微博上对Jscex冷嘲热讽,于是我私信他说建议看一下文档了解一下Jscex。昨天我们的争论主要围绕在eval的使用上,他认为更好的做法是像CoffeeScript那样使用一个额外的进程监听改变,这样更方便。我说CoffeeScript这么做是因为它没有像Wind.js那样借助eval实现完全动态的运行时转化,且生产环境中不会出现eval。最后他坚持认为“eval就是有性能问题”,因此开发时也不应该使用,否则Wind.js为什么要提供预编译器?虽然最后不欢而散,不过我忽然也打算验证一下eval生成的代码效率到底会差到什么样的地步,于是便有了这次实验。 阅读全文

专访Jscex作者老赵(上):缘由、思路及发展

2012-07-28 22:01 by 老赵, 5457 visits
摘要:Jscex是很有特点的一个JavaScript异步编程类库,最近作者不但发布了其眼中的里程碑版(v0.6.5),还在“我们的开源项目”系列活动和阿里技术嘉年华上连续露脸,获得广泛关注。InfoQ专诚对Jscex的作者老赵做了正式的书面采访。在采访的上篇,老赵着重阐述对于Jscex类库设计的思考和心得。注:本文首发于InfoQ,出于阅读体验等方面考虑,现在重新发于博客。 阅读全文

Jscex与Promise/A那些事

2012-06-25 19:13 by 老赵, 5745 visits
摘要:任何异步编程的类库要做的第一件事往往便是统一异步编程的模型,例如Jscex的异步模块自带一个类似于.NET中的异步任务模型。围绕统一的模型,开发人员便可以尽情地提供各种扩展,例如Jscex异步增强模块中的whenAll或whenAny一样。换句话说,假如要混用两种异步编程模型,往往需要将其中一种适配至另外一种,因此异步增强模块中也提供了fromCallback及fromStandard辅助,能够轻易地将最简单的(也是Node.js里使用的)两种异步函数接口绑定为异步任务。那么Promise/A呢?它也是种目前运用十分广泛的异步编程模型,Jscex对它有什么特别的支持吗?当然有,但方式有所不同,更为直接。 阅读全文

使用Node.js编写Shell脚本,暨Jscex 0.6.5版本发布

2012-06-19 00:12 by 老赵, 5776 visits
摘要:昨天不得不花时间做了点保护博客阅读体验的事情,但其实这篇才是我真正想写的。上个星期在香港出差,晚上的活动大都是喝酒,回到酒店便借着些许酒劲改进Jscex。如今虽然Jscex的开发工作并没有详细的时间计划,但我正在使用GitHub的Issues页面记录需要制作的任务点,因此每天都是朝着目标逐步前进的。按照计划,Jscex的0.6.5的主要目标是对Jscex的模块机制进行改进,统一辅助方法,并使用Node.js重新编写发布脚本。这些工作的目的都是为接下来的0.7.0版本作准备,它将会是Jscex在项目功能与质量,以及专业性上有重大突破的版本。 阅读全文

Jscex单元测试:喝着咖啡品着茶

2012-06-13 00:47 by 老赵, 8493 visits
摘要:这段时间在香港出差,跟高帅富们一起工作。高帅富的办公室免费供应咖啡,放在壶里随你倒。茶叶也一样,立顿普洱茉莉自取。于是乎我每天也会喝一两杯提提神,尤其是午饭后,感觉还不错。技术人员似乎都挺热衷于这些饮料,也喜欢拿饮料来为项目取名,这方面最让人想到的例子估计就是Java了。这几天我为Jscex整理代码,准备发布其0.6.5版本,并为0.7.0做准备。这方面的主要工作之一便是为Jscex补充尽可能完整的单元测试。写完单元测试之后,我会感到自己是一个非常专业的程序员,突然就有了强烈的码农自豪感和自尊心。 阅读全文

Jscex预编译器及其DocPad插件

2012-06-04 22:34 by 老赵, 2659 visits
摘要:需求本身会是最好的动力。上个周末除了忙于构建Jscex主站以外,我还重新整理了Jscex的预编译器——或者说是AOT编译器。Jscex自带一个JIT编译器,配合eval可以在开发时避免额外的编译过程,这也可以说是Jscex的亮点之一。不过对于线上环境,一般都还是建议进行预编译,也就是将Jscex方法定义直接替换为目标代码。这么做的好处主要是为了降低部署时的脚本体积(摆脱对编译器的依赖所有代码加起来不到4KB),或是让异常情况下的错误定位变得容易(主要面向Node.js生产环境)。此外,为了便于编写文档,我还为DocPad开发了一个插件,用于对Jscex脚本进行预编译。 阅读全文

Jscex疯狂周末

2012-06-03 23:39 by 老赵, 4242 visits
摘要:这是个Jscex疯狂周末。从周五下班开始直到现在,我可谓一心扑在Jscex上——当然,早茶还是要的,健身房还是去的,买菜做饭拖地也是必不可少,但剩余时间基本都贡献给Jscex了。这段时间里,我研究了一些静态站点生成机制,并最后决定使用DocPad编写Jscex的文档站。然后便是捣鼓各种页面,重新编写快速入门示例等等。自然,还要它部署到GitHub Pages上,并启用jscex.info域名,还因为GoDaddy的域名服务器总是被墙,又把DNS解析交给了DNSPod。现在Jscex主站看上去是不是像样多了? 阅读全文

受禁锢的异步编程思维

2011-12-19 21:49 by 老赵, 7939 visits
摘要:最近一直在努力推广,补充了很多中文文档和示例,因此博客上都已经有两篇文章有了“上”而没有“下”,即使最复杂的图示也已经绘制完毕。在推广Jscex的过程中,我发现有个比较明显的问题是,许多使用JavaScript的程序员已经习惯旧有的操作方式,甚至推崇一些据说很漂亮“模式”。但其实跟许多GoF模式是在修补OO语言的不足类似,很多异步模式都只是因为JavaScript语言特性不足而设计出来的“权宜之计”。我们在传统JavaScript编程环境下并没有其他选择,单纯地认为这是“美”,说实话只不过是一种安慰罢了。 阅读全文

基于Node.js、Express和Jscex开发的ToDo网站示例

2011-07-15 14:33 by 老赵, 16957 visits
摘要:Jscex的主要使用场景是“JavaScript异步编程”,并不限制是跑在浏览器还是服务器端。最近Node.js很火热,也刚发布了原生的Windows版,不少同学也用它来做一些网站这样的小程序。目前用Node.js开发网站最著名的框架是Express,使用起来也是比较容易的。前段时间看到CNodeJS社区的一篇文章,某同学将一个Python写的ToDo列表网站移植到了Node.js上,我为了推广Jscex,就fork了这个项目,将其修改为基于Jscex的版本,大伙儿可以来比较一下。当然这个网站过于简单,我也正在寻找更合适的项目。 阅读全文

JavaScript:假如default不是switch的最后一项

2011-05-24 11:33 by 老赵, 7798 visits
摘要:话说大家对于switch语句应该再熟悉不过了,各种类C语言都不例外,JavaScript自然也是如此。switch的逻辑很简单,根据switch内容的值执行对应的case项,否则执行default项即可。但是不同的语言在具体一些细节上面的处理却是不同的。例如在JavaScript里,每个case项都可以没有break,于是语句便会顺延到下个case或是default里面去——但某些语言设计者认为这种特性容易造成代码理解上的偏差,因此比如在C#里便要求每个非空的case都要有个break。那么再来一个细节问题:如果default之后还有case,那么会出现什么样的情况?如果default里没有break呢? 阅读全文

上周末Jscex项目介绍的幻灯片

2011-05-16 13:43 by 老赵, 5489 visits
摘要:上周末,在风景秀丽的浙江大学校园内,举行了NodeParty杭州站的活动。我在活动上结合Node.js项目对Jscex进行了简单介绍,包括其设计目的,设计原则,使用方式,高级模式,组成部分等等。在场的许多朋友也提出了不少问题,我也一一作了解答或是演示。总体感觉还算不错,毕竟是亲手编写的项目,对其各方面还是了然于胸的。在此发布演讲用的幻灯片,希望能给不在现场的同学带来一些帮助。 阅读全文

浅谈Jscex的$await语义及异步任务模型

2011-05-10 22:29 by 老赵, 3059 visits
摘要:从某些程度上说,Jscex的是提供了“新语言”,只不过这种新语言和JavaScript长的一模一样,最多添加了一个$await操作这个语义而已。其他方面,JavaScript的各种语法都可以让Jscex编译,所以它基本可以说是个完备的方案。之前有朋友提出疑问,说$await只能执行单个任务,那么岂不是多个任务之间就出现了先后依赖关系?假如有三个任务:A和B可以并行,但C依赖前两者,ABC如果串行的话,系统的总耗时便不够理想了。其实Jscex并没有这种限制,因为它的任务模型和$await语义简单且具有深厚的理论基础,灵活、丰富而统一。 阅读全文

浅谈Jscex编译结果的优化

2011-05-05 18:45 by 老赵, 2670 visits
摘要:Jscex的核心是一个JavaScript语言到Monadic形式的编译器。从理论上说,这种编译规则十分简单,要写一个能够“正常运行”的编译器很容易。但是“正常运行”不代表足够优化。优化不当,会导致生成的结果中产生太多函数及闭包,对性能产生负面影响。在Jscex的早期原型中,从AST生成最终代码的逻辑比较简单,只做了一些基础优化。后来重构了编译器,减少了不必要的代码。而上周我提交了更新,实现了更复杂而有效的优化策略。如今的Jscex编译器部分应该已经足够稳定,剩下的便是类库方便的发展了。 阅读全文

Jscex编译器更新:已支持嵌套Jscex函数

2011-04-30 00:11 by 老赵, 2322 visits
摘要:Jscex编译器更新了。之前的编译器并不会将一个Jscex函数内部的其他Jscex函数代码一并展开,这导致内嵌的Jscex函数会在外部函数调用时反复编译,性能开销较大;不过更重要问题,可能是AOT编译后的代码无法彻底解除与编译器的依赖。嵌套Jscex函数是否合理是一回事儿,使用者可以不去这么做,但是编译器本身还是该支持的。这也是Jscex编译器改进计划中的重要一步。 阅读全文

SNDACode及Jscex项目中文站

2011-04-27 23:20 by 老赵, 3071 visits
摘要:之前有朋友问我,为什么Jscex只有英文站却没有中文的。其实原因很简单:国际化的项目势必更容易推广,而且国内看的懂英文的同学肯定比懂中文的外国人多嘛。而且我也不希望在一个源码库里维护两种语言的说明,这样对于浏览者也会造成误解——但更不希望维护两个源码库。因此我理想中的情况便是:某个站点可以完整地同步我的源码库,并提供一个供我放置文档的地方。最近我的同事搞了一个SNDACode站点,公开了部分盛大员工的开源项目。虽然远不如GitHub等类似站点来的完备,但恰好能满足我的需求,我自然很乐意将它作为Jscex的中文站点。 阅读全文

Jscex使用BSD授权协议正式发布

2011-04-22 00:15 by 老赵, 3113 visits
摘要:这次打算把Jscex好好搞一下了,其实很少会有技术方面的障碍能“轮到”我们去突破,但我觉得Jscex的确有机会,HTML 5、Node.js各个都是红火的玩意儿。前几天我花了两个晚上用半生不熟的中式英语写了一篇自认为比较完整的说明文字放到了Github上的项目首页上,没想到几个小时后便收到了StratifiedJS(一个与Jscex目标有些类似的项目)作者的邮件,提到了一些关于StratifiedJS的事情。我向他咨询了StratifiedJS的某些细节问题,也向他简单介绍了Jscex的实现原理。如今Jscex已经使用BSD授权协议正式发布(中文站也会在近期推出),再进行一些细节上的优化便要开始作推广了。 阅读全文

Jscex项目现状:UglifyJS解析器及AOT编译器

2011-04-15 02:04 by 老赵, 3928 visits
摘要:Jscex项目是我为了简化JavaScript异步的一个类库,支持任意JavaScript(ECMASCript 3)引擎。Jscex小巧而强大,可以极大地改善前端的AJAX及动画等场景的编程体验,同样也可以用在node.js进行服务器开发。从产生Jscex的想法到现在也有几个月的时间了,也一直想设法进行推广。在思考过程也发现了它在实际生产中可能会遇到的问题,于是前两个星期的主要工作,便是针对这些问题进行优化。首先我将Jscex的JavaScript分析器从Narcissus换成了UglifyJS,并基于node.js开发了一个简单的AOT编译器。接下来我也打算写个稍微详细一点的介绍,然后在国外社区看看反响如何。 阅读全文

通过定义常量控制Closure Compiler的行为

2011-04-11 01:12 by 老赵, 2797 visits
摘要:上一篇文章里我提到,在进行Closure Compiler压缩之前可以对代码进行一些预处理,这样可以得到更好的效果。在回复中有朋友提到可以使用一些Annotation(标记),例如加上@export,然后使用--generate_export,便可以保留需要的那些变量名。不过经过实验还是没有得到预期的效果,所以使用标记来“指导”高级压缩行为依旧是一个不太可行的做法。不过有个标记与我的设想一直,那就是使用@define来“定义一个常量”,然后在编译(压缩)时对其进行覆盖。这为一些压缩需求提供一种更直接的控制方式。 阅读全文

使用Google Closure Compiler全力压缩代码

2011-04-07 09:30 by 老赵, 17921 visits
摘要:JavaScript压缩代码的重要性不言而喻,如今的压缩工具也有不少,例如YUI Compressor,Google Closure Compiler,以及现在比较红火的UglifyJS。UglifyJS的出名是由于它代替Closure Compiler成为jQuery项目的压缩工具。根据我的实测,jQuery Core的代码使用UglifyJS压缩后(节省62.5%)的确要比Closure Compiler压缩后(节省57.53%)更小一些。很显然,这是因为UglifyJS的压缩策略比Closure Compiler更“聪明”一些。我这里用了“聪明”而不是“激进”,是因为“激进”带上了一丝负面的意味——就好比Closure Compiler的“高级”优化方式。之前与UglifyJS相比的是Closure Compiler的“简单”优化方式,它们都是“安全”的,而Closure Compiler的“高级”优化几乎100%会破坏您的代码,因此它提出了各种“激进”的手段去“破坏”您的代码,以此达到压缩的目的。这种手段是把双刃剑,如果您能掌控它的压缩规则,则代码便可以压缩至极小。 阅读全文

UglifyJS有个不错的JavaScript解析器

2011-04-01 15:40 by 老赵, 8515 visits
摘要:我一直在为Jscex寻找好用的JavaScript解析器,之前我用的是Narcissus,也写过相关文章。不过可惜的是,Narcissus使用了SpiderMonkey的扩展,因此它并不是用ECMAScript 3实现的,无法在IE 8等浏览器中使用。目前Jscex使用的是NarrativeJS中旧版的Narcissus,但是我并不喜欢它输出的AST结构,使用中也发现高级功能里的一些bug,有些食之无味弃之可惜的感觉,而改写新版Narcissus又必须大动干戈。最近我接触到了UglifyJS,发现它的解析器相当不错,性能也比Narcissus高出许多,在此介绍给大家。 阅读全文
1 2 3 4 5 6 7 8 9 Next >
使用Live Messenger联系我