如何参与到elf+js项目中(via Franky Yang)
在获得Franky的允许后，我决定把他的来信和我的回复发在这里，也希望有更多开发者朋友能和我们一起交流，谢谢Franky！
Franky Yang
2011年12月27日 11:28 发送至 我, elfjslib
你好！
我是在新浪微博上看到有人推荐你的项目，刚才花了一个小时浏览了博客、文档、从git上clone了代码并且浏览了目录，感觉很兴奋，我相信这是一个伟大的开始，我希望能够加入其中。
我现在在……（此处省略Franky的自我介绍），看到jQuery版本号不断增加，体积不断增大时，也有这种想法。所以你的工程让我眼前一亮。还有全中文的博客以及文档，更是感觉很舒适。这样的一个JS库，对国人来说是很大的便利，从某种精神意义上讲，我也非常想把这件事能不断的被推动、深化下去，希望我自己能在这个过程中尽一份力。
做为一个JS新手，我也希望在前期能够更多的得到你的指导，也许我还无法独立完成大型模块的开发，但是去完成一些定义明确的小模块还是没有问题的。希望能够由易到难，在你的指导下能得到更大的进步。
对elf+js项目，我还不大清楚它的插件机制是怎样的，对于那句“如果把elf看做是使用方便瑞士军刀的话，那么jslib就是核心工具包中真正的一刀一斧”我还不是很清楚具体的含义，而且文档中也只有对API的介绍，未涉及扩展机制相关的内容，所以我猜这部分功能是否还不具备？我觉得对于现代的JS框架来说，一个扩展机制是很重要的，也是更多人参与的一个切入点。
如果扩展出插件机制，我觉得同时支持jQuery和jQuery UI的插件应该不难吧，这有利于市场表现。
此外，我想可以重点考虑对移动设备的支持，独立出一个对应的版本，库文件十来K大小，各方面都有一定优化。
require库可以做到按需加载，如果方便引入，应该能够进一步提升加载页面速度。
mytharcher的回复：
Hi，Franky
非常感谢你的来信！很惊讶发布后这么快就能有人主动关注。
作为一个平常只是敝帚自珍的coder来说，听到有人愿意加入一起努力也感到异常的兴奋，甚至我自己都还没准备好如何让大家来一起参与，而既然放在来了github，我觉得fork一下应该是目前我想到最好的合作方式。或者我们可以就JS library的理解先进行一些沟通，看看我们各自对这个产品的期待是什么样的。
作为elf+js的作者，可以先分享一下我的想法和初衷。我认为elf+js目前是且仅是一个JavaScript Library，正如C/Java的工具库一样，提供的是很多通用的功能。所以我将jslib比喻为一个工具箱，里面每一把工具（类或函数）都可以解决一个普遍性的问题，例如js.dom.ClassName类专门处理DOM元素的classname增删改，js.net.Ajax专门处理异步请求等。这其实和dojo/yui等框架的部分思路是很相似的，不知道你是否了解过百度的Tangram项目，jslib的作用和目的与之更接近。而你应该可以从我对这些工具类的命名上可以看出，我更希望这些工具的代码组织方式是类似Java类库的一种严谨结构，而这样的结构本身就是一个天然插件池，增加一个类就像你可以随时买一把新的工具回来放在工具箱里，而不影响其他任何地方，只要这个工具真的有用而且好用。所以对于jslib来说不需要提及插件这个概念，如果一定需要，应该也是对jQuery使用的一种基于DOM封装的习惯性理解，这个部分可以详细看看目前js.dom.*包下很多以INode*开头接口实体的处理方式，基本和jQuery的思想一样，是在对Node集合类的prototype上增加处理方法。如果只是需要对DOM进行类似jQuery书写风格的插件设计，那么照这个方式进行扩展就可以了。
从上面这些点来看，jslib是一个比jQuery概念大一些的东西，也是我对他称之为“库”的一个理解。而大家其实在多数比较简单的网页应用中都喜欢挥舞着瑞士军刀一样的jQuery一路点下去$('xx').xxx().xxx()...的开发方式，的确这样的写法非常的amazing，让人容易上瘾，所以我根据开发者的这个喜好又设计了与tangram死板的函数库不同的elf。他对jslib中丰富的功能进行了易用性的封装，让你可以像写jQuery一样去开发。于是使用elf时你也可以写：elf('#test').css('width', '100px').on('click', fn)...，这也对应上了elf+js项目的题记——体验愉悦的JavaScript开发！so，elf是一个利用了JavaScript语言特性来让jslib用起来更简单，而不需要和java一样死板的东西，你也可以说elf只是一个壳，所有真实的功能其实都在jslib里。
至于你提到UI，由于我个人做过很多有复杂UI交互的界面系统，所以对UI的理解可能相对于经常使用jQuery UI的开发者来说，更倾向于类似Ext/dojo的体系化框架的处理方式。这种情况下，有一个更加整体全面的框架引擎规划会比只是零散的按需求出现来处理的UI元素会更有生命力。当然我不否认的确有很多简单零散的需求，但是一把武器肯定不能解决全部类型的敌人，正如我划分了jslib和elf一样，如果以后考虑开发UI体系，我也会把这当成两类事情来做。其中框架引擎化的UI体系我已经在考虑中，或许就沿袭elf的命名叫eui什么的。而简易化的零散组件体系还暂时没有考虑，或许到要用到的时候会去具体做一些思考。
对于移动来说，几乎全部代码也是天然支持的，就算要把代码应用到后端比如nodejs的环境，除js.dom.*和js.net.Ajax等特殊的依赖浏览器环境的功能以外，大多数包和类也应该是可用的，虽然我具体没有进行过后端环境的测试，但作为一个可以灵活扩展的库，我还是有信心让他也可以适应后端环境的。
你说到的require库按照CommonJS的思想来说，其实也是个不错的东西。但对目前的jslib体积（压缩后47k，gzip后16k）来说，有点杀鸡用牛刀的感觉。加入require的按需加载反而还要增加不少代码，这个问题就像网站只有100个用户而在初期就考虑要解决100w级的数据量一样，所以我们可以等到jslib长大以后再具体进行考虑:-P，毕竟现在一张图片就远远超过一个js库的大小了，而且今后的网络条件也应该会越来越好。
说了这么多，其实最需要思考的就是我们对设计一个js库产品的初衷和期待，这本是我自己一个人工作之余研究的一点小成果，还没想到是否以后可以走向工业化，所以会有这样的思考。既然已经放到了台前，那么也让我听听你的理解和思考，以及对elf+js的期待吧！
最后再次感谢你给elfjslib邮件组的第一封来信，以及你所有的建议，这是给我对elf+js继续努力莫大的鼓励！另外如果可以的话，我恳请允许我将来信的内容发布到elf+js的博客上（可以隐去来信的一些敏感信息），以便和更多开发者一起交流进步。
谢谢！
mytharcher