我为什么是DC黑─Why I disagree with Douglas Crockford

参加完了QCon北京大会，最有收获的是两场演讲：邓草原对Scala和Erlang的比较，以及Jim Webber对Rest的阐述。当中还抽空去w3ctech听了Raymond的意大利人讲IE9和爱民兄讲架构，以及参加了充满招聘启事的奇遇推油会。晚上还和老庄、雪愚、一丁以及西乔的老公一边啃羊肉，一边畅谈，可以说北京之行非常充实。

不过我这里要说的是QCon的压轴场，人称JS大神的DC（Douglas Crockford）。然而我就是那个不识趣的提问者。我承认，俺一直就是个DC黑。我之所以会来QCon，很大程度上就是为了瞻仰DC。假如DC下次还去D2，我一定会继续前去围观。

先说一下我对DC的提问。我的问题是，据说DC说过，如果浏览器支持C#，他会把Yahoo用C#重写，这是不是真滴。DC思索了一下说no（到底是教主，知道我这个问题就是陷阱。其实DC应该是说过这个话的，不过就是开玩笑的意味吧。），但如果浏览器真的支持C#，他也不知道是否会这样做（教主露怯了）。然后我继续问，如果你认为C#确实不错，那为什么JavaScript不应该有C#所具有的语言特性，特别是class和module/namespace？老头就解释了一通，意思无非是JavaScript不需要这些也能工作的很好，如果需要的话，可以模拟出来。我又补充问到，问题是既然其他语言都有module/namespace特性，而且几乎每个JS库/框架都实现了自己的module/namespace管理方式（此处我有夸大其辞，其实真正具有像样的module/namespace的主流框架只有YUI和Dojo），为什么不让标准做这个事情？老头的回答就让我震精了，他说大家都做的事情未必是正确的。我只能说：我无话可说了。

散场后我又找DC聊了几句，但是DC似乎对我很不耐烦，老是打断我的话（靠，不就是你英文说的比我利索吗），就说如果你认为module/namespace很重要，你应该提出use case的证明，提出你的proposal给委员会。这令我很怒，这不是标准委员会应该做的事情吗？再说module的提案明明就有，还不止一个。

简单说，俺被DC藐视了。下来之后，在场的许多朋友应该听到我跟大家聊天时大声骂DC是大忽悠，出了演讲厅后，我还把所有哭脸（QCon发给参会者评定演讲的小贴纸）都贴给他了。

说他是大忽悠确实是激愤之语（不过这个说法不是出自我，而是出自国内另一位非常有名的JavaScript高手），把哭脸都贴给他也纯属搞笑。但是经过这次当面PK，我确实更坚定了DC黑的立场。

Module/Namespace/Package机制的缺失，我认为是JavaScript发展的最大阻碍之一。Name conflict大概是每个JS开发者都遇到过的，更不要说同时使用几个JS库的问题，比如同时JQuery和Prototype（还有许多其他库）对于$符号的争夺。进一步，在大规模Web应用开发时，模块之间的依赖和加载问题也是每个JS讨论会上最常见的议题之一。

结果是，许多JS框架都会实现一套自己的module/namespace机制。这其中当然也包括DC创建的YUI。反复造轮子这也就罢了，更大的问题在于，这些轮子互相都是不兼容的。结果就造成了JS社区的分化和内耗。你要么用YUI，你要么用Dojo，你要么用MooTools，你要么用Ext……

你做了一个功能。如果本身可以不依赖任何框架直接用JS原生方法，但是你发现你必须为每个框架或插件体系单独包装和发布适合他们的版本。如果你的功能比较复杂希望有一些基础库的支撑，事情就更麻烦了，因为就是一些最简单的基础设施，各个框架或库的接口也是不一样的。本来这也没什么，因为像其他语言一样，我们可以让它们优胜劣汰。但是JS的情况不一样。因为除了引用一个一个脚本文件，JS缺乏语言级别的模块和命名空间支持，使得用户切换某个模块这件事情变得“不同寻常”。导入模块本来应该是trivial的事情，现在却成了高级特性。这实际上阻碍了JS库和组件在较细粒度上的竞争和发展，JS框架和库的切换成了强迫开发者做出非此即彼的选择。这反过来也说明了为什么所有JS高手都热衷于造轮子，因为几乎不可能有一个框架或库的所有部分能让开发者完全满意（最常见的抱怨是有许多功能我并不需要）。然而，除了极少数顶尖天才如JResig，没有通用框架和库领域的后来者能做到更好。

但是本来JS高手可以专注在一个领域。比如小胖做Grid，比如Army做语法高亮。但是悲剧的是，对于许多开发者来说，他的选择范围已经被划定在一款框架内部了。比如jQuery社区的开发者，他对于没有进入jQuery插件体系的第三方库就基本上兴趣缺缺。其他框架也一样，你看到一个其他框架下的优秀组件，你要么等着开发者移植到你所用的框架，要么你转投他的阵营。也有些人意识到这些问题而发展了无侵入式模块和命名空间管理框架（如金大为的JSI），但是受到各种因素的限制，短时期内很难成为主流选择。

总之，缺乏语言级别的module/namespace/package机制，其恶果就是既没有足够的标准库，也很难像其他语言一样通过丛林法则发展出事实标准库。目前唯一的例外是从Prototype开始，jQuery发扬光大的$，但是能起到这样决定性作用的核心API是极少数。核心功能以外的JS库、组件的生态体系也受到了限制，组件的流行不是首先取决于哪个组件质量高，而是看它所依赖的框架是否流行，以及在其上其他组件是否丰富。本来不应该是这样的！

当然，对于module/namespace的必要性，以及在语言特性的优先级上可以有不同观点。DC对JS的许多看法是有不少人赞同的，包括称其为大忽悠的某JS高手，包括我以前也认为，希望有class之类的特性，是你用不来JS，而不是JS不够好。但是我现在的观点有所变化，因为我不再仅仅从一个JS高手（俺就不谦虚一下了）的眼光看，而是会从更普遍的JS开发者的立场看，会从更普遍的应用开发者的立场看，会去参考其他工业语言的经验，会去思考整个web开发的未来。不是说因此我的观点就肯定正确，但是有一点是肯定的，当你看到更多，想到更多，就不会听到DC说什么“大家都做的事情未必是正确的”这样貌似永远正确的话而鼓掌。

此外，我最最不满DC的一点，就是他毫无理由的拒斥module/namespace的态度和以提交提案来搪塞我。你做为标准委员会的一员，理应倾听开发者的声音。而考虑怎样的module/namespace的实现是合适的，也是标准委员会的职责，至少不应该以提交proposal为借口拒绝别人的意见。


下面再说说DC的其他“忽悠”。

DC老是在说安全。有推友发推：这个比喻是Linus大神用来形容吹嘘OpenBSD安全性的开发者的 RT @kevinxw: 这个比喻…… RT @acumon 如果Linus大神也在场，会不会认为一直在强调安全问题的Crockford大神也像只自慰的猴子…… #QCon

这个比喻当然有点恶毒啦，但是我确实认为安全问题没有DC说的那么夸张。的确，Object capability是好的，应该走向这个方向，但是现有的Same original policy其实也能meet绝大部分需求。所谓的安全漏洞的前提是你要跨域，或者非信任的内容来源。

90%的Web应用在现有的安全机制下已经可以运作，XSS攻击的风险来自于非受控的第三方内容来源。比如Mashup，比如Widget平台，比如由用户生成内容，比如webmail。但是有风险不等于不安全。一个简单的道理是，Yahoo! mail没有Gmail安全不是HTML或DOM或JS的错，而是Yahoo自己做得不够好。

现有的安全机制的问题在于安全控制的粒度太粗，你要么选择信任，要么选择不信任。这当然不够好，但是不够好不等于不安全。所以DC对于所谓安全的说辞，已经接近了FUD，令我不由想到了以所谓“安全”胁迫用户的360。

DC表达了对HTML5的不满，引起许多人的共鸣。然而他所谓安全在我看来，优先级根本不可能高到要让HTML 5停下脚步的程度。至于他说HTML5铁板一块太大，确实如此。但是我们看到标准已经在进行模块化。而且他没有说的，大家也没有去想的是，HTML5为什么会是以这样一种形式出现。过去Web标准是由许多标准组合而成，模块化程度非常之高，但是这并不能确保标准的成功。DC在那里几次提到Kill IE6，引起大家的鼓掌，但是喊口号就能Kill IE6吗？想想看，谁才能真正kill掉IE6？如果想明白这一点，就知道DC反对HTML5是如何不合逻辑。HTML5的延误只能让IE6活得更长。


言犹未尽，不过现在我要登机回上海了，希望今天CSDN组织的DC见面会（他老人家演讲主题和QCon是一样的）不要成为DC粉丝会。大师不是靠膜拜出来的。只有平等交流才是真正的技术会议。

评论

15 楼 hyj1254 2012-11-01  

不要让DC觉得你和他说话就是为了证实他是大忽悠。

14 楼 lzlhero 2010-04-30  

本想这篇回篇应该提前5天出现的，但于 JavaEye 网站的发贴限制，我只能等到今天给你回复了！

Douglas 的意思其实特别简单，首先引入新的 JavaScript 语法特性不是特别有必要，因为我们可以通过现有的机制模拟实现，成本也不是很高。

对于 HTML5 与安全性问题，Douglas 特别纠结的原因，我理解其本意是引入的特性越多，会为 XSS 攻击提供更多的机会，造成更多的问题。而他认为现如今首要的问题是，完善现有的 HTML4 安全性问题，之后再推进新的 HTML5 或更高的规范。好比是，“屁股还没有擦干净，光想着向前冲，是冲不了多远的”。

由于 ECMAScript3 标准被大家长期使用着，新推出的语言特性，比如 JavaScript2.0，好像关心的人不是太多，这应该是一个事实造成标准的问题。对于任何一种不为某个公司控制的语言，新特性的推进显然没有在原有基础上打补丁效果来得的明显。假设 Firefox 增强了语言特性，而 IE9 没有提供，大家也不会普遍地采用的。

而对于一个委员会成员来说，一段时间只能推进一个提案，他当然选择他觉得最重要的事情去做，因为他是 Yahoo! 的员工。他工作中碰到的什么问题最多，最让他头痛，他就会朝那个方向去思考问题，我觉得也无可厚非。

另外，看看他的 Blog 就可以知道，他写了不少关于 XSS 的内容及提案。但是想让浏览器厂商买商业网站的帐，不是那么容易的，并不是所有的浏览器厂商都像 Chrome 或 Firefox 那么 Open！

13 楼 Tin 2010-04-30  

hax 写道

@Tin 你的回复很好，我会专门写一篇更“激进”的blog来答复你，呵呵。

哈哈，期待你的见解。

12 楼 caii 2010-04-27  

Module/Namespace/Package机制的缺失 
不需要！！

11 楼 szcjlssx 2010-04-27  

要KILL 掉IE6，就要KILL 掉大部分的中国用户！！！
中国就是个神奇的国度！在哪方面都是这样！！！

10 楼 handy 2010-04-27  

太激进。。

9 楼 hax 2010-04-27  

@Tin 你的回复很好，我会专门写一篇更“激进”的blog来答复你，呵呵。

8 楼 Tin 2010-04-27  

我不能理解一个程序员这么用这么激进的语言去讨论一个技术问题，而且其中的观点在我看来是大大的偏激了的。
web的安全绝对是一个大的问题，它涉及到了js、html。跨域应该由标准解决，而不应该是继续依赖于“奇技淫巧”，你觉得每个初学web编程的人都需要花那么多的力气去解决跨域问题是个可以忍受的事情么？你觉得html5这样支持了客户短数据库的编程模型还可以像以前那样无视js的安全问题么？所以我觉得DC把安全放在一个重要的位置是没错的。
关于namespace和module的问题，我认为先在的情况挺好。每个js库是一种风格的问题，编程风格在团队内应该统一，我认为没有必要让namespace作为让你依赖更多库的一种手段。如果你说的ajax中的很多行为模式作为一种通用的交互隐喻，并被标准的浏览器原生功能取代，这难道不更好？之所以先在有这么多的实现，我觉得问题不光是什么namespace和包依赖的问题，这是一个浏览器中html和css特性缺失的问题！DC说的将标准切分模块化的想法就是面对这个问题的，特性的扩展应该切分开。让标准能够release in time。
DC说如果haxy兄你有非常大的concern可以去提交proposal，我觉得这是非常对的说法。这正是“我可以不同意你的做法”，但是我坚决支持保护你“持有反对意见的权力”。haxy兄非要把你的想法强加给DC，那你真的就是把DC当神看了。他是个人，他有他的想法，他有他的价值观思想体系。像你那样激烈的提问是你没有捍卫DC保有自己意见的权力。这样是非常不理智的。ES发展成这个样子不是DC的错，而是整个委员会的问题，这个你说是吧？
其它问题，继续讨论吧。

7 楼 cloudgamer 2010-04-27  

hax的文章就是有见地

6 楼 orcl_zhang 2010-04-27  

Js库之间的不兼容问题确实很严重。引入namescope机制确实应该是当务之急。现在的现在的rails3在使用其他框架而不使用prototype,同样可以很好的使用一些rails的ajax方法。
盼望有一天出js2,用$可以简写，以及楼主关心的namescope.

5 楼 hax 2010-04-27  

定论也是可以再推翻的，就好像以前的ES4草案一样。而且既然DC可以对HTML5大放厥词，我也可以对ES5说三道四。

过去的package/namespace的设计存在问题，不代表module/namespace的需求本身不应该得到优先满足。实际上，module/namespace的提案从来就没有停歇过，见：http://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v。

BTW，注意以前所讲的namespace是ES4的一个特别设计，和我讲的一般的namespace特性是不同的。

4 楼 dexter_yy 2010-04-27  

……namespace/package/class的问题不是早在奥斯陆和谐会议上就有定论了么：

https://mail.mozilla.org/pipermail/es-discuss/2008-August/003400.html

One of the use-cases for namespaces in ES4 was early binding (use 
namespace intrinsic), both for performance and for programmer 
comprehension -- no chance of runtime name binding disagreeing with 
any earlier binding. But early binding in any dynamic code loading 
scenario like the web requires a prioritization or reservation 
mechanism to avoid early versus late binding conflicts.

Plus, as some JS implementors have noted with concern, multiple open 
namespaces impose runtime cost unless an implementation works 
significantly harder.

For these reasons, namespaces and early binding (like packages before 
them, this past April) must go. This is final, they are not even a 
future possibility. To achieve harmony, we have to focus not only on 
nearer term improvements -- on "what's in" or what could be in --  we 
must also strive to agree on what's out.

Once namespaces and early binding are out, classes can desugar to 
lambda-coding + Object.freeze and friends from ES3.1. There's no need 
for new runtime semantics to model what we talked about in Oslo as a 
harmonized class proposal

3 楼 lordhong 2010-04-27  

  学好英文很重要啊... 起码吵架的时候不会吃亏...

2 楼 felixding 2010-04-26  

hax的确是受了dc的刺激……

1 楼 jindw 2010-04-26  

今年下半年准备吧JSI重新搞搞，和模板集成。让开发更容易一点。