地址： http://nicedit.com/index.php
实在不能忍受现在的TinyMCE了（其它的就更甭提了），好几百K的主文件（压缩前），上万行代码，Tiny个P啊还。当然我相信TinyMCE之流那么大，肯定有它们的道理，不过实在没心思在那么多代码中间找出到底图个啥。
这些editor重复造了这么多次，其实实现思路已经很明确了。自己写的问题主要是搞业务的往往没有时间处理各种各样的问题，比如浏览器兼容性、BUG，所以用别人的是一定的了。关键是怎么用：我的首要要求是代码必须好看，也就是说写的不算太乱，规模不能大；或者规模很大但规划非常清楚。
顶上推荐的这个，有个感觉是稍显稚嫩，比如看它源码，连个类似于Namespace这样的外围隔离都没有，虽然命名不是那么容易重复，不过嗯还是应该考虑一下的。这个东西和C文件不同，C看起来也没什么隔离手段，甚至比JS更次（JS可以用对象、闭包之类的），但是一个C文件内的东西很容易和其它的隔离开来，真正要管理的仅仅是导出的函数（只能通过命名规范了）；可JS，所有的文件实际上都输出到一个页面，好比一个大文件一般，适当的注意还是必要的。
不过呢，顶上这个胜在代码长度短，配合editor的实现思路，很快就能把所有东西摸清楚，自己修改、扩展、包装一下就好，工作量也不大。需要注意的是，对于包含第三方组件的项目，尽量不去修改它的代码是必要的，这样新版本出来（尤其是解决了BUG之类）的时候好更新。JS做这种工作当然也很容易。
功能上的缺点呢，比较重量级的是没有表格编辑器，这个看着其它的Editor的实现，自己扩展吧如果有需要。其他的，好像没有源代码编辑，这个加上不难。细节上有待磨砺，不过本来各个Editor的风格什么的和自己的业务往往也是不搭界，这些工作最终还是必要的。
另外一个够小的在这里： http://www.leigeber.com/2010/02/javascript-wysiwyg-editor/
我还没有看，估计大同小异吧。
另外我挑选这些东西的一个重要的指标是，绝对不能使用第三方框架，尤其是现在基于jQuery的这么多，一排除一大半。以前似乎在评论里还和别人讨论过关于第三方框架或者库的使用问题。现在我的看法更加明确，所有的这些第三方框架都是毫无用处。JS本身已经足够简单了，我们在这上面也沉浸这么多年了，任何jQuery有的东西都很容易clone一份，按照自己的风格。
理由就是最后这句“按照自己的风格”。任何框架类的第三方组件都会更多的影响你，从如何写代码到思维方式，这个在JS这个肮脏的地方，是完全不需要的。我如何写JS呢？开始的时候瞎写，多打几行字或者少考虑某方面问题，根本形不成障碍。随着项目发展自然而然的，就会归类总结，逐渐的就有序化了。
有一阵子大家对JS如何实现面向对象、应该如何写较真的很多，当时我就没参与，因为感觉没想法。现在看起来，更没想法了。
感觉JS拘泥于某一定式完全没有必要，巧妙一点、愚笨一点，都是那么回事。最终当我们产生现实的需求，如果当初动键盘的时候真的已经会写JS了的话，反过头来再重构一下比什么都简单。我有一个感觉，比如Python也是一个基于字典的语言，不过Python仍然有一种隐约的东西，要求你这样、那样，否则就不舒服，但是JS真TM太随意了，似乎没有任何对使用者的价值观输出。
这不是说JS写的多烂无所谓，我上面提到一个词就是需求。需求有时候很自然的就导致包括明确的接口、整齐的层次和一些其它东西。你可以看到，在这文章较前部分，我对名字的隔离这样的小节都是有一定要求的。我的意思是：JS就是这么一种东西，如果你是一个有心人，你写出的代码、做出的设计，总会是当前最合适的，无论是垃圾代码、还是工整的设计，全部是即符合够用就好、又有的放矢。
而框架和一些使用风格明确的库却总是会破坏这种完美。不过这种说法只是P话，完美仅仅是人的主观印象；所以在这里有必要给完美一个定义：最适合你的目的。库指定的使用风格和框架要求的使用方式所做的破坏，在于让我们无法选用最贴切的方式设计并实现眼前具体的需求。其核心是，我们为自己的目标增加了一个不必要的需求：与某某适配。
这也解释了为什么我个人允许使用类似于这篇文章介绍的组件，却对jQuery之类的东西抱有天然的反感：如果一个东西可以通过包装将其自身隔离，它带来的负担在很大程度上相当于没有。但是一个框架，你如何包装呢？一个主要靠使用风格取胜的库，你包装它的价值又在于哪儿呢？
而使用了框架和这种库的组件..，严格的来说我们当然可以通过包装去忽略框架和库的影响，因为我们要的是组件的功能。但是，由于其所带的框架或者库本身往往存在大量和这个组件无关的冗余，而这些多出来的部分我们并不复用，同时从项目整体来看，其所占比例又引起风格和代码管理上的冲突，这个代价就有点大了。
另一个需要解释的问题是，对于组件，笔者前面提到因为浏览器兼容、BUG等因素，最好用别人的；那为什么到了框架和库，却不考虑这些因素了呢？实际上浏览器兼容问题在我看来从来不像好多人想象的那么难；而且作为一个Web开发者，我个人认为这是一个不但要了解其细节、也要亲身实践的地方。对于BUG，因为库和框架一般提供的是基础功能，所以不存在可见BUG这一保证，应该是由自己亲自做出的，而且也必须有做出这个保证的能力。
正是因为这些理由，拒绝轻易使用第三方基础部件是利大于弊的。对于组件的拿来主义，主要是为了避免就这个组件所关注的具体部分所产生的工作量，而不是要避免基础部分所产生的工作量。对于一个习惯前端的开发人员来说，基础部分的工作量、常识、经验和技巧，不应该、而且（即便采用第三方的部件）最终也会发现不能避免。
那什么时候要使用jQuery一类的东西呢？一个交换有不值得时候，必然有超值的时候。
这个关键就在于，如果你需要更多的交流，你就需要和社区统一风格。交流包括但不限于：输出自己的东西、广泛的输入别人的东西。如果项目的需求（还是需求），导致你需要（而且可以）这里拿一个、那里拿一个，凑起来就好，而jQuery下的衍生物能覆盖你的大部分需求，那又何苦重新造车轮子呢？
写到这里，我相信我的意思已经充分表达明确了。前阵子本来写了两篇文章（不包括这篇），一篇是技术的、一篇是关于经济的。不过进攻性太强，最近事儿不太顺，想了想不能分心去讨论，就算了没发。希望这篇很个人的东西能够对别人有点借鉴意义吧。
P.S. 说实话最近也觉得自己有点闷，能写的东西越来越多，真正写的倒越来越少。不过至少在技术领域的价值观输出，我不会放弃的 :)，至少要对得起花出去的时间嘛。