TypeScript or Pure JavaScript?

I was really excited when I got to know that Microsoft had released a new language called TypeScript.

Type, which means better intellisense and type safety that serve the purpose of its existence — scalable.

Why is this important?

  1. Type safety.
    Hate bugs? There’s a joke we talk a lot, which is also a truth: “The weirder the bug is, the stupider mistake we might have made.” And the compiler would now worry about some of these things for us, like typo or forgetting to change a property after copying some code.
  2. Tooling.
    When a project grows, the API might become too complex for the developer himself to remember. Visual Studio provides great experience on JavaScript intellisense by actually running the code in background. But on the one hand, it would usually requires a special rewritten-version of intellisense file. On the other hand, it would become very slow when code lines add up. (I wrote a framework called VEJIS which picks up the powerful intellisense feature of Visual Studio, provides support for classes, interfaces, delegates, etc. But it’s a runtime framework and there’s no type safety. Checkout http://vilic.github.io/vejis/)
    TypeScript makes code navigation much easier and most of the time, we won’t even need to navigate because the information we need is there with intellisense.

Searching articles related to TypeScript would result in many that are comparing it to CoffeeScript and Dart. It’s really weird because some (maybe most) of these articles treats TypeScript the same sort of thing as CoffeeScript simply because both of them compile to JavaScript. And I have even seen an opinion saying: “If you want to build a big application I’d recommend going with CoffeeScript as you end up writing less code.”

WHAT? Maybe that buddy haven’t really met something big enough.

CoffeeScript won’t do things better for people like me, who have been writing JavaScript since day one. People like to talk about the “good part” when it comes to CoffeeScript, but… does it really take more effort for one person who starts with JavaScript to remember how to avoid the bad part than learning a syntactically brand new language?

And actually I have never given the “good or bad part” thing much credit.

So back to the topic, TypeScript or pure JavaScript? Ignoring things other than the languages themselves, I go with TypeScript without hesitate. Because it’s a superset of JavaScript, and it provides much more useful features for larger-scale applications. And, the key point, I write relatively large-scale web applications. However, to use TypeScript in productive environment, there would be more to think about.

  1. Poor IDE and editor plugin support.
    There have been several IDEs with TypeScript support integrated. Visual Studio, of course, would be one of them. But the experience coding using Visual Studio can’t even beat the experience on TypeScript Playground. This really bothers me a lot. No automatic-quote/bracket completion, no snippets, strange indent behavior, etc.
    I haven’t tried TypeScript in WebStorm, maybe it would have done better job. Also ReSharper for Visual Studio may improve the experience according to some comments I’ve seen.
    There are also some plugins for Sublime Text, but… you know.
  2. Poor NPM package and cross-project referencing support.
    Actually TypeScript is capable generating definition files so that it should have been friendly to these things. But the reality is not that awesome…
    I have proposed a convention on distributing TypeScript-written NPM package, and hoping it would make things better.

If finally you choose TypeScript, here’s some information and techniques that might help.

  1. Definitions of popular JavaScript libraries.
    I don’t have any crush on open source, but here open source does it right. So far most of the declarations I need for specific JavaScript libraries can be found in DefinitelyTyped, and it’s becoming of better quality and of larger covering.
    You may install the declarations though NuGet on Visual Studio, to make things work after installation, try to refresh the solution tree.
  2. Temporary “best” practice for cross-project referencing in Visual Studio.
    In project properties page TypeScript Build tab, check “Combine JavaScript output into file” (and specify a file name) and “Generate declaration files”.
    Create a “.d.ts” file in parent project and add the declaration file generated by sub project to it as a reference.
    Visual Studio would compile all “.ts” files included in the project into the JavaScript file specified, so make sure other test files are excluded from the project or you may want to create another project for samples and tests.
    When it comes to NPM packages, I haven’t figure out an acceptable way. But following that convention I mentioned earlier in this post, I may try to write an extension for Visual Studio which would pick up declaration files automatically, wrap it up with ambient module name and add the modified declaration file into the project that’s using that module. It would also be useful even if we are using these packages ourselves without publishing it to npmjs.org only. (BTW, symlink would save you hours if you didn’t know.)

I have now a symptom trying to make everything typed, it slows me down starting up coding a project, but speeds my lines up once the skeleton completes. Hope you enjoy writing in TypeScript if you need it.

(BTW it would be great if TypeScript add support for await/async based on Promise.)

关于 "动态" 模板的憧憬

大概是一年多以前还在一淘实习的时候, 萌生了这么个想法, 如果一个模板可以是基数据驱动的, 那能胜任的工作就从现在更多的格式化字符串和其他一些简单的东西变得更加复杂和强大. 当然因为是数据驱动的, 在写这样一个模板时, 也将体会到数据驱动带来的逻辑上的优势. 不过也是因为各种原因, 当时做完第一步的模板解析之后, 就没再继续了. 因为要做好, 略微困难, 而且不像原来做Prever什么的时候, 虽然代码总量大, 但可以分开成很多小块, 今天断开一点, 明天稍微回想下继续写就好.

除此之外, 另外一个数据驱动的小库, Drop(未更新), 倒是做了出来, 虽然还有诸多不完善, 到最后肯定也免不了被重写的命运… 但就实践来看, 这种方式的确是很实用的.

那回归可能会基于Drop(顺便Drop最近的版本是基于VEJIS的)之上的这个模板系统, 之前取名叫Sonne, 以后多半也是这个名字吧. 前些时候了解了下lisp语言, 才发现它和lisp之间还有一点点相似之处. 这里贴一段很久很久以前写的示例.

<!-- comments -->
    <img src="xxx.jpg" />
        {#link {
            {@hash page}
            {@value home}
            {@inner {home}}
            {@class nav-link}
    {#if {
        {@if {#cookies loggedin}}
        {@then <a href="#logout">log out</a>}
        {@else <a href="#login">log in</a>}
    {#async {
        {@type html}
        {@url content.ashx?page={#hash { {@name page} {@default home} }}}
        {@loaded {data}}
    {#async {
        {@type json}
        {@url sidebar.ashx?page={#hash { {@name page} {@default home} }}}

还是大概能看出来吧? 大括号开始, 紧接一个字母的, 是闭包, 在里面可以直接书写文本内容. #号开头的则是组件(当然, 你可以定义自己的组件), 里面的@开头的是属性, 也可以理解成参数. 包括if都是以组件的形式存在的, 所以这种一般性让Sonne具有更强的扩展性. 好吧其实, 还有个原因是我实现起来会相对容易, 不用处理更多的特殊化的语法… 😛

再以#async组件为例, 可以看到url属性对应的字符串中存在另一个组件, 所以实际上, 组件是有 “返回值” 的, 可以是字符串, 也可以是文档片段. 因为是数据驱动, 当数据发生变动的时候, #async组件所管理的文档片段也就随之变化了, 并且因为是组件, 也可以很容易地实现定时更新数据.

当时一直期望这东西能改变Web开发的某个分支, 其实现在也有这个想法, 但也不知道最后能不能做出来… 记得后来看到过某个库, 也有类似的功能, 但印象里并没有Sonne强大,,, 具体哪里没有… 忘记了…

TypeScript 小感

今天在一个Windows Phone的论坛看到微软出了个TypeScript, 瞬间想到高中时期自己构想的InviScript和Prever 2… 不过后来因为种种原因, InviScript只是停留在了构想上, 而Prever 2也在开发初期流产. 不过后来取代InviScript的, 则是VEJIS.

很高兴的是, 自己, 当然也一定是很多当时和我面临同样问题的人的设想, 最后被很好的实现. 其实Google也有一个叫Dart的语言, 不过与和InviScript的相似度赶TypeScript和InviScript的相似度就差太多了… 而且我个人也不喜欢Dart的语法, 感觉抛弃了很多JavaScript的精髓.

TypeScript和InviScript应该说都是JavaScript的超集, 并且相同的, 最终都会编译成JavaScript. 这也是我为什么取名为InviScript的原因. 意为INVIsible SCRIPT. 只在开发过程中存在.

不过同样高兴的是, 我选择了一个对于我个人而言, 更现实的实现, 即VEJIS. 虽然独立开发完InviScript也并非不可能, 但成本显然太过高昂…

VEJIS通过各种各样的函数, 从语法层面加强了JavaScript的功能, 提供了可以媲美甚至超过TypeScript的类/类型/模块工具, 当然因为VEJIS是运行时的脚本库, 代价就是一定的性能损耗. 这也限制了VEJIS的运用场景. 但就目前的实践经验来看, 在正确使用VEJIS的情况下, 这种影响是可以忽略不计的.

现在正在开发VEJIS 0.5, 重写了核心代码, 并提供了更多, 更具扩展性的功能. 甚至是delegate_, 虽然还没有决定是否会最终使用. 不论最终是中间语言形式的TypeScript更容易被接受, 还是运行时的VEJIS, 都一定程度反应了Web开发的趋势. 这点上, 我觉得Franky或许不会永远是对的. 😛


第一次遇到这个问题, 是大概两年前写代码高亮, 从当时的解决方案到现在一共有三代, 嘎嘎. 觉得还是算越来越好的.


//那个时候自己正则还不算很精通, 也没有(?:...)这种习惯, 是以寻找结束引号为入口写出的这个正则. 思路混乱, 也存在错误.
//比如像字面量 "abc\\\"", 则会匹配为 "abc\\\", 而正确的结果应该是 "abc\\\"".
var re = /('('|.*?([^\\]'|\\\\'))|"("|.*?([^\\]"|\\\\")))/g;


//这个匹配其实和第一代思路基本相同, 也是寻找结束引号, 通过给\\添加*解决了第一代的bug.
var re = /(['"])(?:.*?[^\\](?:\\\\)*)?\1/g;


//老实说第三代是昨天晚上出题的时候突然想出来的(后来又修改过), 支持多行字符串字面量, 思路也有了较大的转变, 从匹配结束引号变味了匹配中间内容.
var re = /(['"])(?:\\(?:\r\n|[\s\S])|[^\\\r\n])*?\1/g

这里有一个正则里非常常用的技巧, 姑且称之为 “抢占”, 在诸如/a|./这样的正则里, 越靠前越先匹配, 通过 “抢占” 一些字符, 可以避开很多麻烦. 说起来有些抽象, 在上面这个例子里, /\\[\s\S]/就可以很自然地抢到 \” 这样的转义字符, 所以不必担心转义字符中的 ” 给匹配造成影响. 这是局部的 “抢占”, 还有更大范围的, 比如注释里的字符串或者字符串里的注释, 只要在同一个正则中, 把相关匹配都写入, 则一定是先遇到的优先. 如 /(注释正则)|(字符串正则)/g, 可以先通过这样的方式, 把内容匹配出来, 再进行进一步判断处理.

虽然可能对于多数人来说, 用处不大, 但万一呢? Best wishes~

Visual Studio 2012 for Web JavaScript自动完成体验

从Visual Studio 2005用到2010, 现在又用上了2012. 实际上之前就有体验过, 但并没有测试什么细节, 今天偶然想到, 对自己感兴趣的几个细节进行了测试, 感受是: It’s just AWESOME!

之前喜欢VS的JavaScript自动提示的原因, 是因为它会在某个环境执行你的代码, 并且用真实的结果给以智能提示, 如:


但VS 2010的时候, 类似的功能并不能体现到函数的实参上:

我一直很期待这个功能, 因为如果有它, 在更新自己VEJIS库的intellisense文件之后, 可以实现相当全面的自动提示. 结果, 它真的支持了!

但不仅仅是如此! 另外一个相当棒的功能就是支持异步, 比如异步加载脚本, 还有setTimeout. 先说可能大家不如我关心的setTimeout. 之后在介绍VEJIS的时候会提到前者.

除此之外, 智能提示还对数组的提示进行了优化, 会根据数组中之前出现的数据类型猜测之后出现的类型.

除了这些关于代码执行的提示, VS 2012对于代码注释的提示也有改进, 不过不是说让你写注释更方便, 而是让你写的注释被看得更方便. 并且支持多行, //和/**/都可以. 虽然之前也有<summary>等一些列的注释可以实现这样的功能, 但还是有点繁琐.

那接下来, 我就针对VEJIS谈谈对于VS 2012智能提示特性的进一步应用(这个时候在文件开头添加脚本引用了). 首先是动态加载.  在VEJIS里, require_函数用于动态加载一个脚本文件, 并且该文件会以<script>标签的形式添加到文档中. 例中动态加载的是我面向数据的一个基础库.

接下来是关于函数实参的, 像上面看到的那样, VS 2012可以根据函数被首次调用时传入的参数, 给实参加上提示, 但我们平时书写的时候, 多数时候是先写完函数再去调用. 当然, 在VEJIS下这种境况稍有不同, 因为VEJIS的函数支持重载, 也是需要指定类型的. 这样一来, 稍作修改, 就可以实现如下的功能.

同时, 因为之前说到的对于数组的提示支持, 让我还可以对VEJIS中的params类型进行处理.

又因为对于setTimeout的支持, VEJIS中类的提示也得到了加强, 虽然这个可能解释起来不是那么直观, 毕竟牵涉到其实现了.

强悍吧~ 话说如果是VEJIS老些的版本, 还支持with_, return_这些东西, 分别用于确定this和返回值的类型, 那配合上VS 2012, 就可以实现媲美强类型语言的自动提示了, 所以… 其实我已经动心开发下一个版本, 添加上这些支持. 囧. VS 2012除了这些运行时间的提示优化之外, 还增加了对很多常见对象的支持, 比如XMLHttpRequest.

顺便不得不提的是, Visual Studio 2012 for Web也有Express版, 也就意味着这么强大的工具是免费的! 各位前端同学们也加入VS阵营吧!

Adobe AIR JavaScript跨域获取iframe内容

老实说在想到这个解决方案之前, 超级吓, 因为不解决这个问题, 就意味着项目无法实现预期的功能.

Adobe AIR中跨域的问题貌似主要是因为安全沙箱(security sandbox)不同导致的, 官方提供了两个相关的解决方案, 一个是使用iframe的sandboxRoot和documentRoot属性, 如:


我花了很长很长的时间才理解这两个属性到底指什么, 一方面是因为官方文档说得不够清楚, 我一开始一直以为app:/sandbox/是表示应用沙箱的固定用法, 一方面也是因为相关资料相对较少.

这个方法使得跨域页面中的内容(不包括iframe的src, 但包括iframe加载的内容里的各种东西, 甚至是XMLHttpRequest), 如果其URL在sandboxRoot指定的URL之下, 则并不会请求该URL在互联网上的位置, 而是请求documentRoot所指定的文件目录中的内容. 比如按上面的例子, 如果iframe加载的页面中有一个脚本的URL是http://www.example.com/local/sample.js, 则实际会加载的则是app:/sandbox/sample.js, 这里的documentRoot可以是任意目录.

但是这个方案似乎只能说是加载下文件, 并不能让脚本获取iframe的内容. 另外则有两个bridge(桥), 可以实现脚本的交互. 一个是parentSandboxBridge, 另一个是childSandboxBridge. 这两个bridge都是iframe.contentWindow的属性, 指向一个对象, 这样双方就可以通过这个对象下的属性或者方法进行信息交换了. 但需要补充的是, 不要企图传document这类的对象, 只能传传自己的(非严格界定, 但是大体意思大家应该懂). 官网上也提醒道, 如果要在iframe页面加载过程中让其中的脚本访问parentSandboxBridge, 则要在iframe中的脚本执行前就给iframe绑上parentSandboxBridge. 这时可以使用 “dominitialize” 事件.

这样一来, 跨域交互看起来终于是可行的了. 但是… 我做的是一个采集程序, 对方如果不调用我的bridge, 即使我搭好了又有什么意义呢?

后来才明白前面提到的sandboxRoot和documentRoot的意义. 对于现在多数的网页, 里面一般都会有脚本, 但那天看Google Adwords Keyword Tool的时候差点就伤心了, 从上面往下, 眼看着全是内嵌的脚本… 终于… 发现一个cues.js文件, 可能是GWT相关的信息初始化文件, 其URL是: https://adwords.google.com/cues/cues.js 于是, 将sandboxRoot设置为https://adwords.google.com/cues/, documentRoot设置为app-storage:/, 再把经过更改的cues.js文件放到app-storage:/, 这样一来, 当网页加载完成, 我安排在cues.js里的 “木马” 也就可以执行他的任务了~

如果要替换的JS文件是静态的, 那完全也可以更改后放到app:/目录(只读, 可以用trick写入, 但有兼容问题), 我放到app-storage:/是因为cues.js是动态生成的, 悲催吧…

虽然不能说是一个完美的解决方案, 但至少解决了自己的问题. 不过, 要是真遇上一个页面里没有脚本或者全是内嵌脚本的时候… 就伤了. 有人会问为什么要用那么低级的方式, 不直接发HTTP请求来解决? 老实说我也觉得蛮低级. 但Google Adwords Keyword Tool是用GWT开发的, 里面用来交换数据的格式并非常见的application/x-www-form-urlencoded, 而是text/gwt-rpc, 因为时间紧, 不能保证这是能轻松破解的(同样, 资料极少), 于是退而求其次了.


所以说, 趋势就是趋势, 并不在于谁提出来, 该有的东西自然便会有. 我不知道我们这一代人是否算是见证了DOP的诞生, 但至少在这些年, DOP被用得越来越多了.

说到这个, 首先想提两点. 一个是之前众所周知的变成模式, 面向对象编程(OOP). 对与我来说, 面向对象在我的代码中扮演了相当重要的角色. 它让程序内部的交流变得更加清晰, 提升了程序的可读性, 降低了出现bug的概率. 在有些应用上, 到目前还是不能替代的. 另一个是今后Web编程的发展, 我目测会有几个大方向: 1. 基于Canvas或CSS3的Web游戏. 2. 功能复杂的Web应用程序(如在线办公). 3. 以内容呈现与交互为主的Web页面(如SNS). 只所以想要提这两点, 是为之后将要说到的OOP的局限性, 和DOP的应用范畴做铺垫.

那首先说说, 什么是DOP. 老实说, 我并非是从这个名字开始接触这个概念的, 而是从很多Web页面的改变上开始思考这个问题. 不过很自然地, 使用了同一个词语来描述这样同一个概念. 其实其中有一点YY的成分, 但我想也应该八九不离十.

如果说OOP让人们只用关心如何去调用一个功能, 而不用关心功能的实现的话, 那么DOP则只用人们去关心一个模块/对象所管理的数据, 而不用关心这些数据的改变会对其他模块/对象造成什么影响. 当然, 对自己的影响还是要关心的. 其实细想, 在一些高级编程语言中, 对象的属性就是一种简单地DOP模型. 但显然, 它是局限在某一个对象上的. 然而很多时候, 同一个数据在多个对象上是公用的, 这或许就是DOP和传统OOP一个很大的区别, 也是传统OOP的局限.

但说到这里, 大家可能也会有种想法, 认为DOP也是OOP. 我认为这种想法是正确的, DOP的最佳实践应该对象化/模块化, 只是与直接调用其他对象的方法不同, 通过数据来间接达到目的. 这一点来讲, 倒和面向事件的编程(EOP)有些相似, 但事件是瞬时的, 而数据则是可持续的. 或许DOP约等于OOP+EOP+Data?

近年来, 在很多网站中出现了Hash, 很多MVC框架也支持相应的技术, 极大地方便了复杂的无刷新页面的实现, 这应该算是典型的DOP. 不过如果仅仅是这样, 还只能说是Hash上的数据在和整个页面一个对象交互, 这就有点伤感了. 还好看到一些框架, 并非这样的如果, 比如淘宝的MagixJS似乎就不错. 不过很显然, DOP也有其局限性, 毕竟中间穿插了一个环节, 在效率上或许比不过传统的变成手段. 所以像Web游戏的有些部分则是不便于使用的, 但我想做做UI还是完全能够胜任.

按我的理解, 相对于OOP, DOP能进一步减小复杂程序的思维难度, 提高开发效率, 以及降低bug的概率, 应该是未来Web编程某些方面的趋势, 于是我也有自己的DOP框架计划, 只是准备在DOP的基础上, 增加强大的模板功能, 也许未来, 很多AJAX操作, 都只需要一个简单的模板了.


说明下, 本文仅限于我个人的理解与感受, 如果有错误或者不好的地方, 欢迎指正.

可能对于多数前端工程师来说, 面向过程的编程模式依旧是够用的, 其实很多时候, 我自己写的代码也几乎都只是函数没有类. 但面向过程毕竟有它的局限性. 当完成一些庞大的东西, 或者逻辑复杂, 容易产生混乱的代码时, 面向过程的模式就不容易处理了.

当然, 其实说到底, 还是和代码书写者的状况有关系. 我相信, 一个足够优秀的前端工程师, 即使面向过程, 也能写出清晰, 明了, 正确的程序来. 或者说, 在他的这种面向过程的编程下, 已经埋入了很深的面向对象的思想. (另外, 一定要有new才是面向对象吗? 显然不是, 面向对象只是一种思想, 不拘泥于实现的方法.)

面向对象的编程, 很大的一个好处, 就是把程序员从混乱中解放出来, 让思路更清晰, 把注意力集中在一些需要攻克的技术细节, 而非整个系统复杂的内部交互. 当然, 由此带来的东西就更多了, 比如更高的编程效率, 更少的bug.

但, 如何设计一个程序面向对象的结构呢? 这个我想是面向对象的过程中最关键的一步了. 它直接决定了之后具体实现的难易程度, 这应该也是一个高水平的前端工程师需要具备的能力.

接下来举两个例子, 谈谈两种不同的面向对象编程.

1. Web 游戏

Web 游戏的实现过程中, 处理一些具体算法方面的问题, 整体控制也是个问题. 比如说一个简单的操作, 可能会引起复杂的反应, 这些反应可能是各个方面的, 如画面呈现, 内部变化等等. 当然用面向过程的模式也能解决, 但普通的面向过程或许不那么容易简单地解决. 或者即使解决了, 代码的可读性, 或可维护性或许会不那么好.

这个时候, 用几个对象来分别控制游戏的不同部分, 或者会比较容易实现. 比如, 可以分成score, game, operation, 分别表示游戏的得分, 主体和操作控制, 而game又可以继续细分成foreground, stage, background等等. 这样一来, 思路就顿时清晰了.

这里提到的面向对象, 有一个特点, 就是所有的对象都是单独的实例, 不过很多时候就是这样, 一个类出来就只用一次. 这个时候, 我通常这样写JS:

var object = new function () {
    this.someMethod = function () { };
} ();

2. 多级菜单

作为前端工程师, 这个东西应该多少有接触过. 这个例子有很明显的两个对象, 菜单(包括子菜单)和菜单项目. 用面向对象来实现, 我们就只用关心菜单和菜单项目之间的关系, 只要把这两者的关系思考清楚, 就能很容易地避免一些令人伤心的bug, 或者实现难度问题.

function Menu() {
    this.add = function (item) { };

function Item() {
    this.childMenu = null;

显然, 这里的面向对象, 与之前提到的区别就在于, 我们会用到多个实例, 而且这些实例的数量很多时候是不确定的. 但是只要把握住它们的关系, 就能高效的完成代码, 并且规避一些面向过程容易遇到的bug. 同时, 这种模式可以配合事件编程, 效果更好.

上面提到了面向对象两种看似不同的实践, 但其本质是一样的, 只是一个注重整体的规划, 一个注重功能实现. 配合使用, 我想对整个实现来说, 会有很大的意义. 当然, 或许上面这两个例子还不足以让你感觉到面向对象的优越性, 可能是因为这两个例子还不够复杂, 也没有很大的实现难度. 毕竟合适的才是最好的, 根据需求选择适当的模式, 才是聪明人的选择.

当然, 在实际操作的过程中, 或许并不是那么容易把某些东西抽象出来, 或者可以抽象出来的东西很多, 取舍又是个问题. 这些就需要前端工程师的经验和思考了.


拿一些UI特效为例吧, 比如某个窗口飞入飞出, 我们希望它在飞入的时候做什么, 飞出的时候做什么. 当然随便写写也好, 但可维护性和可扩展性或许就不那么好了. 特别是当这些窗口不止一个两个, 运动也相互独立的时候, 普通的写法就更吃力了. 而且最主要的是, 即使实现了, 也相当容易出bug. 不过最终, 面向对象是核心, 基于事件是翅膀, 没了对象, 事件又能有什么大作为呢?

希望这些想法能对不熟悉或者刚接触面向对象编程的同学有一点参考作用, 也欢迎交流和指正.

Let's "call" around!


自己博客更新频率越来越低了, 很大程度上, 是因为技术上的收获不再有那么多, 另外即使有, 也不是特别容易归纳或者表达亦或者常用的技巧, 所以也没必要写到博客上来. 不过, 还是想写一篇, 说说怎么玩JavaScript.

标题是 <Let’s “call” around!>, 所以什么是call? 既然玩的是JavaScript, call自然不能少. 当然, 本文包含但不仅限于call, call在这里代表的, 应该是一类东西.

那, 什么时候, 我们会使用call或者apply呢? 做个不完全归纳吧.

  • OOP.
  • 函数劫持.
  • this绑定.


其实这个应该算在this绑定里, 但是在OOP中, 又运用得特别多, 于是单做一类. 假设有一个class, MyClass. 那么创建一个实例 var mc = new MyClass(), 在某些时候, 可以做如下替换. var mc = {}; MyClass.call(mc); 当然, 他们并不是等价的, 而且差距还蛮大. 但有些时候, 从功能上讲, 是可以代替一部分的. 不过在这里, 由于建立对象和调用构造函数分成了两部分, 我们就可以在其中增加一些trick. 至于什么trick, 就不多做讨论了.


这个时候用apply可能偏多吧, 毕竟能传递几乎所有的参数, 也方便些. 如之前存在函数fn. 现在要劫持它, 那么就可以 var fnBackup = fn; fn = function () { fnBackup.apply(this, arguments); }; 好吧, 这个仍然牵涉到了this…


于是, 就说说单纯的this绑定咯. 对于Web前端开发来说, 在事件处理上, 一定会很熟悉. 当然对于我, 就更熟悉啦, 嘎嘎嘎. 因为写到的很多东西里, 我都会通过this绑定一些方法什么的, 供函数使用, 比如VEJIS的类有这样的写法:

var C = static_class_(function () {
        xxx: 123
        yyy: 456

匿名函数配合this, 很好用!

OK, 说完了call和apply, 说说callee和caller. callee大家应该很熟悉, 不过caller就… 其实实话, 我也不是很熟, 但是觉得很有意思. 虽然现在还基本没用到过, 以后就说不定咯. 用法请arguments.callee.caller.caller.caller… 自己试试咯.

然后关于正则. 先说match. 在非global情况下, 我习惯这么用.

var result = string.match(regexp) || [];

一个JS里很常见的技巧不是么, 如果我想得到整个匹配的字符串, 那我会这么做. (string.match(regexp) || [”])[0]. 当然, 这个也很简单, 就看有没这个习惯了. 使用这种方式能省不少代码哦.

那说说exec. 这是我最近两年来比较喜欢的方法, 在global模式下非常管用. 我习惯的用法类似:

var groups;
while (groups = regexp.exec(string)) { }

关于instanceof. 这个是JS的一个好东西啊, 这个运算符给了JS这种弱类型语言处理强类型工作的能力. 既然说到它, 就不得不说说继承.

JS中如何实现继承? 其他的方法就不在赘述了, 推荐我比较喜欢的一种:

//更新, 之前的方法有问题, 今天看到TypeScript的做法之后借鉴下.
var Class = function () {};
function __() { this.constructor = Class; }
__.prototype = Base.prototype;
Class.prototype = new __();

var c = new Class();
var o = {};
copy(o, c); //这儿就伪代码了, 把o上面的东西拷贝到c上, 根据需要覆盖或不覆盖.

当然… 这样写有点长, 于是, 请自行封装… 使用VEJIS当然也是可以的, 简单多了:

var Class = class(function () { }).inherit_(Base);

这种写法的优势是什么呢? 相对单纯的prototype继承, 它能够更好地保证成员的独立性, 相对单纯的工厂模式, 它能保证instanceof为true. 代价稍大, 但可以忽略.

关于参数的合法性, 有时候我们的代码是给第三方用的, 同一个方法, 或许我们在内部调用的时候, 需要使用某个参数, 但却不希望第三方使用这个参数, 这个时候怎么办? 有人会说, 约定好就好了. 但显然约定只是自我安慰. 我是一个不喜欢暴露变量的人, 不该暴露的东西绝不暴露, 不该给别人用的东西绝对不能给别人用. 于是推荐的方式是, 在自己可控的闭包内, 创建一个类, 如下:

function Value(value) {
    this.value = value;

然后再验证参数的时候, 使用instanceof就可以了. 因为Value这个类在闭包内, 只要不传出去 (当然, 也不能把它的实例传出去), 就是安全的.

逻辑运算符的妙用. 这个场景不多见, 也只能是抛砖引玉. 场景是这样的, 通过XHR请求到一些脚本, 脚本内容是调用了一个函数, 现在我需要通过eval来得到这个函数的返回值. 特殊之处在于, 如果前面有注释怎么办? 用正则清除掉? 可行, 但是不大好吧… 于是前后加括号? 万一结尾有分号呢? 于是, 最后我采取的方法如下: var value = global.eval(‘(function () { return false || ‘ + script + ‘ })()’);

困了… 睡觉去.

JavaScript 推荐书写规范

自己写JavaScript也有一些年头了, 前些时候看Douglas的JSLint和他推荐的写法, 深有感触, 也见过不少JSer使用了他的规范, 但, 很多地方, 我却不能认同. 当然, 写法什么的, 最终还是看个人, 哪种写法效率更高, 就用哪种. 下面我就对比Douglas的规范, 说说我推荐的写法.

  1. JavaScript文件及引用
    根据需要将JavaScript代码放入单独的*.js文件中, 这些需要一般可能是指: 代码量较大, 代码被多个页面重用, 为了方便维护等. <script>标签因尽量放在<head>中, 并且标注type=”text/javascript”. 对于普通网页, 放在<body>结束之后, 有需要时甚至是<body>之中也是可以接受的. 但对于JavaScript密集的网页及WebApp, 应尽量避免.
  2. 缩进
    空格和Tab都可以接受, 但最好不要混用.
  3. 换行
    代码书写时要尽量保证其可读性, 自然每一行不应该过于长, 但不推荐无语义的换行. 换行应该能表达一个逻辑片段, 分组等意义.
  4. 注释及空行
    根据代码的需要进行注释, 在一个代码片段开始的前一行使用 // 注释该片段的作用, 对于难以理解的单行代码, 使用 // 注释在该行代码之后. 对于一个完整的, 或者相对重要的功能块, 使用 /* */ 在其上方第二行进行注释, 上方第一行留空. 如果结尾不明显, 容易与之后的代码混淆, 也可以在该功能块结束后再使用 /* */ 进行注释. 对于容易理解的代码, 也应该根据功能或者逻辑进行分组, 中间用空行隔开.
  5. 变量的声明和定义
    声明所有变量, 不过类似于 global.abc = 123; (浏览器中为window)这样的语句也是可以接受的. 随时声明变量能够帮助避免很多作用域的问题, 反之, 类似的问题可能会成为极大的困扰. 从个人来讲, 即使你非常清楚变量的作用域, 也应声明变量, 或者使用类似于global.abc = 123; 这样的形式定义全局变量. 当然, 语义化是永远需要注意的, 这点也适用于下面的函数声明.
    根据逻辑的进行声明变量, 有些变量, 比如在一个闭包中会被多个逻辑使用, 或者从意义上应该是独立与其他逻辑的, 应该放在闭包的最上方, 而部分仅仅会在某个逻辑中使用的变量, 则应该在该逻辑开始, 且该变量使用前声明. 如果该逻辑需要的变量较多, 容易与其他变量冲突, 可以考虑将该逻辑放入一个闭包中. 需要注意的是, 有些语句或许并不适合包含声明变量的代码, 比如if.
    另外, 不推荐使用一个var语句声明大量变量, 将变量分组, 并按意义上的先后顺序进行排序或许更好. 如:

    var id;
    var width, height;
    var left, top;

    当需要在声明的同时定义变量时, 通常我的做法是一个var语句只对应一个变量. 同时, 避免使用不必要的全局变量, 但不要担心局部变量和全局变量或闭包中的变量重名, 如果我们已经很清楚各自作用域的范围, 为了避免重名而给变量名添加各种前后缀, 或者缩写变量名的做法, 只会使代码变得更难理解.

  6.  函数声明和定义
    一般使用function语句进行函数声明, 且声明应放在当前闭包的最下方. 一般情况下, 一个函数主要是处理一个逻辑中某一个从意义上简单, 但代码量较大或者重用率较高的功能. 如果将函数声明在前面, 反而会影响我们直观地获知逻辑结构, 让本末倒置. 另一方面, 如果函数名足够语义化, 对于多数功能, 我们甚至可以略过函数体, 直接通过函数名来完成逻辑的阅读.
    对于声明和定义, 推荐使用这样的格式, 注意哪些地方有空格:

    /* 普通声明 */
    function abc() {
    /* 匿名函数赋值 */
    var fn1 = function () { return true; }; //单个语句可以写成一行
    var fn2 = function () {
        if (true)
            return true;
            return false;

    另外, 只有一些非常通用的函数适合作为全局函数(除非当前项目的JavaScript代码量非常少). 其他时候, 需要根据逻辑和意义来确定函数声明的位置. 闭包是JavaScript最美好的东西之一, 一定要善于利用. 它能够让代码具有更明显的结构. 有时需要建立一个立即执行的函数来实现一个闭包, 推荐这样的写法:

    (function () {

  7. 命名
    尽量使用字母(A~Z, a~z)数字(0~9)和下划线(_)命名变量. 一般情况使用类似于myFirstName这样的驼峰状命名规则, 但如果变量的值代表一个类, 则首字母应该大写, 如: MyClass.  一些由于实现必须要求出现在逻辑结构之外的变量, 建议在其前后加双下划线标注. 如:

    var __inc__ = 0;
    function inc() { __inc__++; }

    但多数情况下(当结构相对简单时), 可以使用闭包来避免.
    对于一些有特别意义的全局变量, 比如当一个全局变量能决定是否执行某一个功能块, 以及部分常量, 推荐使用全大写命名, 单词之间使用下划线隔开, 如OPEN_DEBUG.
    另外, 尽量使用英文命名变量, 即使你的英文不够好. 退一万步, 如果使用拼音, 不要过度缩写. 顺便中英文混合虽然可以让人看到很 “快乐”, 但还是不要这样的好 .

  8. 语句
    每一行最多只包含一个语句, 需要分号的地方一定要加上分号. 包括这样的 语句: var fn = function () {}; 因为这实际上是一个赋值语句.
    对于控制结构, 如果只有一条语句, 可以将大括号去掉.
    另外, return是一个特定的语句, 并不是一个函数, 所以一般情况下, 不要在return之后使用(). 当然, 有时你可能会需要()帮你排除换行的歧义. 类似的还有typeof.
    continue有时会很有用, 所以完全没有必要回避. 至于with, 我很少用.
  9. 空格
    合理使用空格能够提高代码的可读性, 具体需要使用的情况如下:
    控制结构中的标示与()之间, ()与后面的语句或者复合语句之间. 如: while (true) {}.
    多数运算符左右应添加空格, 如 var a = 1 + 2; var b = true ? 1 : 0;
    逗号(,), 分号(;)后如果不换行则需要添加一个空格.
  10. 其他建议
    使用 {} 代替 new Object(), [] 代替 new Array();
    在创建一个类型的实例时, 不管构造函数的实参个数是否为0, 都应该加上(), 如new Object()不应写为new Object.
    如果你已经足够熟悉JavaScript了, 那么使用这样的语句也未尝不可:

    var a = true;
    if (a = !a)

    同时, ==和!=在多数情况下都是适用的, 所以没必要处处都使用===和!==.
    除此之外, 我觉得一个漂亮的JavaScript代码一定是充分并正确利用了JavaScript语言特性的, 至于这些特性, 就很难一一描述了. 不过, 如果你真的喜欢JavaScript, 请去感受它.

所以只是个人建议而已, 具体怎么落实, 酌情.