为何重复造轮子
凡事都要有原因，不管重复造轮子这件事好还是坏。
最早想写一个JS库是因为2007年的时候看到jQuery这么NB的写法，当时完全被震撼了，开始萌生把jQ拆开来用的想法。但当时才疏学浅，JS没写过多少，打开jQ的源码以后完全无法理解里面各种精妙的设计，怎么$('#id')就成了一个看似数组但又不是数组，到这就无法理解了。之后就没再进行下去，直到后来在百度erik给大家做技术交流时讲解了JS里prototype的机制后我才有所顿悟。再后来，公司各种开发任务压下来，很长时间里没再仔细分析jQ的代码，只在项目用到的地方，逐渐的剥离出一些常用的东西，比如Event和Ajax等。
而公司对jQ一直是不提倡在各产品线内使用的，原因是当时的jQ还不是很稳定，如果出了问题很难查出原因，特别要用的是压缩过的源码。这样带来的后果就是公司内各个团队都开始积累适合自己产品线的基础库，当然，这件事我也在做。所以几年下来，随着产品线的丰富，产品的功能复杂化，我也积累了很多基础库的代码。
直到2010年初我再次转换产品线负责重构一个系统的前端架构时，这些年积累的一堆代码还算能用，而且对比2009年公司内前端统一推的Tangram，我觉得我这些代码更符合我所认定的一种编码规范（类似Java的组织结构）和使用习惯，所以没有完全放弃去直接使用公司的Tangram。这里并不是说Tangram不好，从很多方面讲Tangram的设计是非常好的，只是不符合我所认同的一种规范，使用起来也很不舒服，更改习惯是困难的。
后来和晓斌商量把这些代码推出来，可以做一个使用起来更舒服的基础库，因为里面现在很多特性是很有价值的，也是其他库所不具备的。于是开始给这个库想名字，我没想出几个合适的来，但晓斌提了几个中的一个elf立马电击到了我，所以就定下了这个名字。
接下来一段时间就先把大部分代码投入到新的产品线中使用，因为觉得还有些缺陷，所以没有对外发布，同时也在不断完善。产品线开发时一直没有顾的上太多，直到系统重构上线后，又腾出一些时间来把elf的组织调整到一个更加规范的结构，才开始着手考虑发布的事情。
今年初开始为发布筹备各方面的东西，再次把整体的代码给erik帮我全部review了一次，他提出一个很好的建议：把基础功能部分和对一个库进行易用性优化的部分拆开。我觉得elf这个名字更适合一个易用性的封装，而基础功能部分我更希望可以是一种标准化的API，于是干脆大言不惭的占用了js.*这个命名空间，所以最后就有了“elf+js”。
简单的说原因就这么几点：
- 想把jQuery拆开用；
- 自己的代码有了积累，不想放弃自己的劳动成果，作为给自己写代码这么些年的一个交代；
- 写代码写自己的库是学习的一个必经过程；
- 还有就是对这些代码的设计有那么点沾沾自喜。
所以，有了这个轮子。