知乎看到一个问题，《为什么都说富文本编辑器是天坑》。里面的答案挺有意思的，各位做web前端的大牛们都有自己的切肤之痛。有兴趣的可以手工复制以下网址查看：

https://www.zhihu.com/question/38699645/answer/108376836

但是这些答案大部分还是停留在碰到的问题上面，而没有去深入总结和思考富文本编辑器背后的需求和实现思路。正好前两年在medium上看到一篇文章，叫《Why ContentEditable is Terrible》，推荐给大家。原文可点击左下角链接查看。

https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480

昨天发生了一件不大不小的事情：有相当多的iOS开发者收到了来自苹果的警告邮件，大意是“你的app有动态修改应用逻辑的行为”。说得更通俗一些，就是能绕过app store的发版审核机制，直接进行更新的app基本都收到了警告。

按理说，这其实是一件于情于理都没什么好争辩的事情，毕竟发版本要经过审核是白纸黑字定下的规则。但是这件事情却掀起了轩然大波，甚至连React-Native和Weex都一瞬间有种人人自危的感觉。这到底是为什么呢？

审核之痛 ​

首先，为什么有这么多人在明知冒险的情况下仍然会选择使用热更新的方式呢？主要的原因还是苹果的版本发布审核太慢，据说7天以上是家常便饭。试想，一个app发出去，发现有一个bug，用户居然需要一周以上的时候才能更新到修复版本，这个在当前中国互联网环境下确实是不太适用的，所以热更新才能大行其道。

当然，也有一部分人完全是动了歪心思，先合法地上架app，然后再修修修改已上架的app行为，偷偷摸摸做些见不得人的事情。

web缺席 ​

既然热更新是如此迫切的需求，那难道就没有更好的方案吗？比如……web？天生就热更新，不好么？

当然好。可是web的性能和体验这么差，大部分情况下属于不得已的情况下才会考虑的方案。所以在移动互联网的崛起中，web基本是缺席的。而且这个现象并没有任何好转的迹象。

问 ​

请问八哥五年内的职业规划是什么？（来自小密圈）

答 ​

这个问题让我犹豫了好久好久啊。因为5年确实很难预料会发生什么。先回顾一下过去的几年职业路径吧。

工作前两年基本在学习，怒补基本功，以及作为一个工程师，在职场上的职责是什么，怎么样去参与项目做事情。

接下来几年有幸开始慢慢主导一些项目的开发工作，慢慢学会了如何以产品思维来思考技术工作，明白技术为产品服务。这期间也有去充当一半产品经理的角色，去参与需求的规划，去关注用户的反馈，去解答用户的疑问。当然期间也在一直在补充前端技术并开始接触新技术和开源社区，对前端的知识体系有了更深刻的认知。

如果说工作到现在学到了什么核心竞争力的话，可能是两个方面。一方面是清楚地知道前端的能力、职责和限制，有什么需求能清楚知道能不能做，以及如何做，代价如何。另一方面则是积累了一些产品研发全流程的经验，知道研发过程各个角色的立场和思维模式，尤其是产品思维。

ES2015（ES6）中新增了几种数据类型，包括Map WeakMap Set WeakSet等。其中Map可以与我们熟悉的对象Object进行对照，他们的功能都是提供一个键值对集合，主要的区别在于Object的key只能是字符串，而Map的key可以是任意类型。关于Map的大致用法可以参考MDN，我在前一篇文章《也谈JavaScript数组去重》中也有提及。

今天要讨论的主角是WeakMap。

按照MDN上的说明

WeakMap 对象是键/值对的集合，且其中的键是弱引用的。其键只能是对象，而值则可以是任意的。

从这段描述来看，我们可以大致推断出，WeakMap与Map的主要区别在于两点：

1. WeakMap对key的引用是弱引用
2. WeakMap的key只能是对象

这两点意味着什么呢？反正我第一眼看到的时候不是拉格良日懵就是三元二次懵的状态。于是围绕WeakMap去查阅了一些资料，渐渐地有了一些更深入的认识，记录成本文。

开年来真的有点忙，好不容易写起来的公众号又好久没拔草了。

最近忙的其中一件事是写一个slides，也就是传说中的PPT。（明明用的是keynote，你才PPT，你全家都PPT！）写的是web前端的一些普及性的介绍。

在写的过程中，发现越写越悲观，写到最后竟然隐隐觉得web要完。当然，这是一件政治极其不正确的事情，所以也不敢到处乱发，只能当成呓语在公众号写一写，给为数不多的朋友诉一诉这其中的一些想法。

标准的危机 ​

曾经有几年，大家是非常热衷于web标准的。但是如果问一问现在来面试的朋友，估计应该没有多少人还在意web标准这件事情。大家会关注 Angular / React / Vue ，会关注 AR / VR ，但是真的没有人关注web标准。

那我们关注一下可好？

唉，算了。反正大概的感觉就是真正需要成为标准的东西一直拖拖拉拉，比如像 web components 至今没有定稿，导致至今没有一个像样的组件方案。最后靠框架来填补这块空白。而像 web bluetooth / web usb / web vr 这类的东西倒是层出不穷。

除了标准本身外，厂商的跟进也是个大问题。一方面厂商对标准越来越不上心，爱理不理，另一方面，又为了各自的利益，先做非标准实现，再回头去影响标准。

总而言之，标准现在就是一锅粥。

问 ​

什么阶段考虑进入创业公司？

答 ​

其实我并没有认真的思考过这个问题。职业发展是一个涉及到很多方面的问题，包括职业方向上的规划、薪资水平、工作环境、团队氛围等很多方面。

因为标的公司是创业公司，一般来说，从薪资、工作环境上不会有明显优势，因此个人觉得主要考虑点在于个人成长和团队氛围上。

来自知乎问题小程序上线后市场反应如何

尘归尘，土归土。正在回归正常。

小程序一直在强调自己线下场景的定位，奈何开发者、媒体总是不信邪，非要赌小程序会有流量红利，会给自己带来线上流量。甚至在微信明确说微信中没有入口，没有应用商店之后，仍然有一大波人围着不愿散去。

现在打脸了吧。线上流量红利真的一点没给。于是这波围观的人一哄而散，甚至还会留下一堆唱衰的评价，“你看，我就说这玩意没鸟用吧”，殊不知，正是自己的期望过高导致现在的巨大落差。

回归到小程序自己的定位来说，其实非常明确，就是线下场景。具体的微信公开课Pro上已经详细阐述过，这里就不复制了，有兴趣的自己找。

来自知乎问题微信小程序为什么不用HTML5、CSS，自己搞了个WXML、WXSS，很多框架用不了，好处一点不知道？

引子 ​

假设我们把问题稍微改一下哈：

iOS应用为什么不用HTML5、CSS，自己搞了个OC / swift / autolayout / storyboard，很多框架用不了，好处一点不知道，以前项目根本没法移植，而且我们习惯的jquery、auicss、图标等完全用不了，也没见OC / swift / autolayout / storyboard有什么好处，完全理解不了。。。

嗯。我只是改一下题目，不回答。可自行思考。

用web做小程序的可能性和限制 ​

为什么没有人问上面改过的问题，而小程序就有人问呢？只是因为小程序和web长得很像，所以就觉得要用web来做吗？那长得像的话是不是就能直接用web做呢？

答案是，大部分是可以的。比如文本、图片、输入框等等，都可以。

但是，也有一部分小程序的功能是web完全不具备的，例如扫码、获取设备信息、获取罗盘信息、等等。

此外，还有一小部分是web做起来很困难的。比如上面有人提到的地图、fixed的文本输入、视频相关、sticky定位等。

除了能力上的限制以外，还有相当一部分是来自于性能上的限制，也即虽然很多东西用web确实可以做，但是性能是很差的。

JavaScript的数组去重是一个老生常谈的话题了。随便搜一搜就能找到非常多不同版本的解法。

昨天在微博上看到一篇文章，也写数组去重，主要推崇的方法是将利用数组元素当作对象key来去重。我在微博转发了“用对象key去重不是个好办法…”然后作者问什么才是推荐的方法。

细想一下，这样一个看似简单的需求，如果要做到完备，涉及的知识和需要注意的地方着实不少，于是诞生此文。

定义重复（相等） ​

要去重，首先得定义，什么叫作“重复”，即具体到代码而言，两个数据在什么情况下可以算是相等的。这并不是一个很容易的问题。

对于原始值而言，我们很容易想到1和1是相等的，'1'和'1'也是相等的。那么，1和'1'是相等的么？

如果这个问题还好说，只要回答“是”或者“不是”即可。那么下面这些情况就没那么容易了。