楼主的女朋友不怕么？....

使用场景：

＃ 标准场景
1. 选中
2. 复制
3. 粘贴到任意一个空白的位置

# 替换场景

1. 选中词汇
2. 复制
3. 选中另外的词汇
4. 粘贴

# 避免未选中场景（mac系统部分浏览器常见问题）
1. 选中词汇
2. 多次复制以确保正确
3. 粘贴到任意空白位置

# 避免未选中场景2

1. 选中词汇
2. 多次复制确保正确
3. 地址框／或者其他的地方当中粘贴确保正确性 避免再次切换过来继续复制
4. 确认没有问题，粘贴。

# 错误选中场景（编辑器里面）

1. 选中错误词汇。
2. 复制
3. 发现选择错误，选择新的词汇，复制
4. 确认没问题，粘贴。

# 遗忘粘贴场景（常用于保存link与错误选中场景类似）

1. 选中
2. 复制
3. 有事情离开，遗忘了粘贴的现有内容
4. 选中另外的link
5. 复制
6. 粘贴


如果将以上场景里面的复制粘贴全部用CC替换掉，并且插上楼主的CC两次清空的逻辑，我觉得要思考的更加多一些。

因为不喜欢复制粘贴还要考虑一下。

https://github.com/trevorlinton/webkit.js 楼主说的是这个？

requirejs 有自己的optimize api，可以将文件合并。当然也可以自己合并。

这个标准记得在chrome里面是被dialog标签替代的。`dir(HTMLDialogElement.prototype)`在最新版本应该是ok的。

http://www.anti-spam.org.cn/sample/209.85.192.181

看到这个觉得这个ip被ban很正常的说....

<dialog>标签？

@kmvan

oz.js ，你没听过不是你的错，dexter.yy 他们的team太低调了，分享极度的少，但是我看过的分享当中豆瓣的干货是最多的，从我个人角度来说至少领先2年。seajs的玉伯和dexter.yy有过一次关于oz.js的讨论。

@qdwang

“真是讽刺”这四个字真是刺耳啊。

摘自[HTML5史上最惨重的失败：Facebook放弃HTML5转投iOS Native](http://www.csdn.net/article/2012-08-24/2809122)
““
其实，html5, nodejs等的失败，最基本的原因是，它们都是反上帝的。
宇宙虽然纷繁复杂，但是基本的物理学原理缺很简单，爱因斯坦晚年曾想把宇宙中4种基本力统一成一种基本力。最近科学家一直在苦苦寻求上帝粒子来统一物质。这就说明，简单，统一才是万事万物的终极目的。
就拿网络游戏来说，现在有些游戏采用全3D, 玩家想怎么玩，想怎么看都行，但是这样的游戏大都半死不活，因为玩家都转得头晕了。相反那些固定视角、甚至是二维的游戏呢, 缺凝聚了一大批忠实玩家。
html5/nodejs就是这样的东西，不该是它做的事，它非要做，不失败上帝都不同意。
另外一个走入歧途的是Web 2.0，web 2.0大量使用所谓ajax技术，所谓“用户体验”，但是却违反了网页里面还有一个“页”字，网页就应该和小说、报纸一样，以阅读为主、方便阅读为主，而不是在那里让用户惊叹你的交互性和体验。网页，就应该是一个电子版的报纸、杂志、小说等，加你妈比的动态性啊。

经过冲动之后，必然会回到本质。web 2.0必将冷却，生存下来的，还将是那些认真做事，做有意义事的人和公司。
””

感觉楼主和上面的这位理念差不多。但是技术好和实用产品有很大的联系么？按照楼主说的用WAP开发即可，回头不是有其他人说豆瓣前端技术差劲么？

CardKit对兼容性的误判算是最致命的 ，其他的从前端技术角度来说 @dexteryy 他们的思路已经相当超前了。如果算2012年11月启动的话，他们的技术可以秒杀国内大部分做移动前端的，因为那年android的各种差劲到极点的浏览器和严重的分化，作为一个不能控制网络环境不能控制runtime的前端来说，没有什么好值得讽刺的。

另外就楼主说的facebook而言，"facebook不是做了移动web端后没办法还是做客户端么，自此以后国外移动web端都比较谨慎。"看到这句就知道当年历史没有好好细细的品味过。摘录上面链接的原话：
“又过半年，Facebook宣布放弃其基于HTML5的iOS App，彻底转为Native，又一次让HTML5 vs Native的话题升温。”

看起来，好像facebook他们有很多大牛，然后大牛说“哎呀，我技术这么高也搞不定”。中国是一个看“脸”的国度，所以当时大部分也开始说“哎呀，搞不定啊搞不定”。

但是老外说：“.... 浏览器里打开Facebook的网页都比应用快3倍。”

不知道楼主看清楚原文和你说的区别没有？别人facebook放弃的是hybrid app，不是移动web端，然后别人不是没办法才去做native客户端，是有hybrid客户端然后改成native。2012年hybrid app的性能很差，部分功能缺失，ios还相对好一点，android的webview还没转到chrome上面。至于说国外移动web端都比较谨慎我倒是完全没有觉得，sencha就在2012年直接反击，在移动端游戏上面2012年的时候DeNA就已经做的非常不错了，不过当年毕竟算是少数。


至于豆瓣产品方面我没具体看过，web前端技术本来就有极限：runtime。但是要“最好不用js load”，就能省下流量，除非楼主不是做移动前端的，否则怎么看怎么像扯淡，websql / indexdb / local storage / application cache 这几个技术可以用来做cache。如果是douban的重度用户，怎么看怎么都省流量，还能解决部分网络环境的差的问题。

重启

MAS 没有这个问题，倒是 daily 版本的出现过。而且有一次明明只用了12MB 硬说我超过了界限不让编辑了，重新安装了一次才 OK。

vm.runInContext 是否可以解决安全问题？

title 的颜色有点...让人有点担心里面的质量...

@ryanking8215
也没必要递归，其实有简单的方法:

var promise = Promise.resolve();
array.forEach(function(){
promise = promise.then(async_task);
});

promise.then(function(){/*done*/});