参加完了 ，最有收获的是两场演讲： 对Scala和Erlang的比较，以及 对Rest的阐述。当中还抽空去 听了 讲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发展的{zd0}阻碍之一。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高手都热衷于造轮子，因为几乎不可能有一个框架或库的所有部分能让开发者xx满意（最常见的抱怨是有许多功能我并不需要）。然而，除了极少数{dj1}天才如JResig，没有通用框架和库领域的后来者能做到更好。
但是本来JS高手可以专注在一个领域。比如小胖做Grid，比如Army做语法高亮。但是悲剧的是，对于许多开发者来说，他的选择范围已经被划定在一款框架内部了。比如jQuery社区的开发者，他对于没有进入jQuery插件体系的第三方库就基本上兴趣缺缺。其他框架也一样，你看到一个其他框架下的优秀组件，你要么等着开发者移植到你所用的框架，要么你转投他的阵营。也有些人意识到这些问题而发展了无侵入式模块和命名空间管理框架（如金大为的JSI），但是受到各种因素的限制，短时期内很难成为主流选择。
总之，缺乏语言级别的module/namespace/package机制，其恶果就是既没有足够的标准库，也很难像其他语言一样通过丛林法则发展出事实标准库。目前{wy}的例外是从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粉丝会。大师不是靠膜拜出来的。只有平等交流才是真正的技术会议。
不过我这里要说的是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发展的{zd0}阻碍之一。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高手都热衷于造轮子，因为几乎不可能有一个框架或库的所有部分能让开发者xx满意（最常见的抱怨是有许多功能我并不需要）。然而，除了极少数{dj1}天才如JResig，没有通用框架和库领域的后来者能做到更好。
但是本来JS高手可以专注在一个领域。比如小胖做Grid，比如Army做语法高亮。但是悲剧的是，对于许多开发者来说，他的选择范围已经被划定在一款框架内部了。比如jQuery社区的开发者，他对于没有进入jQuery插件体系的第三方库就基本上兴趣缺缺。其他框架也一样，你看到一个其他框架下的优秀组件，你要么等着开发者移植到你所用的框架，要么你转投他的阵营。也有些人意识到这些问题而发展了无侵入式模块和命名空间管理框架（如金大为的JSI），但是受到各种因素的限制，短时期内很难成为主流选择。
总之，缺乏语言级别的module/namespace/package机制，其恶果就是既没有足够的标准库，也很难像其他语言一样通过丛林法则发展出事实标准库。目前{wy}的例外是从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粉丝会。大师不是靠膜拜出来的。只有平等交流才是真正的技术会议。
