聊聊我的第一篇10万+，同时反驳某些评论

摘要： 写个10万+也不容易啊。

元旦的时候，我立了一个Flag，今年要写一篇10万+，现在目标算是完成一半了。

终于有了一篇10万+

知乎后台显示我的回答《如何衡量一个人的 JavaScript 水平？》的阅读量已经超过了10万，具体截止2019年5月20号是115172。

阅读量已经超过10万了，为什么只是完成了一半呢？因为这篇博客其实是我翻译的，原文在Web Archive上能够找到：10 JavaScript concepts every Node.js programmer must master。而且，这篇博客是我2年前写的：10个JavaScript难点。不是原创，也不是今年写的，当然只能算是完成了一半。

虽然只是翻译，但是基本上等于”重写”了一遍，因为我翻译博客都是意译而非直译，这是为了保证可读性。中文和英文的写作套路完全不一样，英语喜欢用各种定语从句，强行直译的话读起来会非常莫名其妙。感兴趣的话，不妨对照原文和我的翻译看看。

刷知乎的时候，看到了这个问题：如何衡量一个人的 JavaScript 水平？，就想起了自己2年前的博客，内容刚好合适，于是随手转发了一下。我对于这篇翻译的博客还是挺满意的，所以一直记得它，所以猜到它应该会比较受欢迎，后来发现它受欢迎的程度远远超过了我的想象。

感谢知乎的推荐算法

正如韩寒在《三重门》的后记写的：我是金子，我要闪光的。好的内容也是会闪光的，只是需要时间和机会。在各个内容平台中，知乎的推荐算法更加友好，可以将内容推荐给很多感兴趣的人，这对于每个坚持创作的人都是一个很好的机会。根据知乎提供的热门内容传播分析报告，一些大V的点赞加速我的答案的传播，在此感谢大家的支持。

作为一个内容平台，推荐算法还是非常重要的。不少用户已经养成了通过推荐获取信息的习惯，比如我每天都刷很多次微信的看一看，确实能发现不少感兴趣的内容。但是，一些内容平台的推荐功能很弱甚至于没有，这里我就不点名了。创作者发布博客之后，会发现除了前几天访问量还可以，以后就非常少了，未来的流量只能依赖于搜索引擎。这样的话，对于读者、作者以及平台都是一种损失。今日头条的成功，简单来说，其实就是推荐算法的成功。

我的博客

这几年，我一直坚持原创或者翻译博客，大概每周写一篇，现在已经写了接近17万字，阅读量超过1万的其实也不少了，但是写技术博客要想突破10万+是一件很难事情，因为中国也就那么几百万开发者。技术相对于各种热点来说，非常的枯燥，其实我也很少看，除非特别感兴趣。有时候确实感兴趣，也不过是收藏到Pocket里面，然后就没有然后了。

既然没什么人看，有时候还得被键盘侠喷，那为什么还要写呢？这个问题我也问过其他一些写技术博客的作者，因为发现他们的公众号也没什么人看，但是他们依然在坚持写作。

其实，这个问题的答案很简单，写技术博客是一种非常好的学习方式。当我们写一篇技术博客的时候，需要对某个技术点非常熟悉，有时候还需要一些自己的思考，而写作的过程中总会发现一些自己不太清楚的地方，需要进一步了解。这样，但你写完一篇博客之后，你对这个知识点已经相当熟悉了，我们的知识体系就通过一篇篇博客完善起来了。

如果大家觉得我的博客还有点意思，不妨看一下我这几篇博客，算是我自己还比较满意的：

反驳某些评论

每一个创作者应该都知道，认真地写一篇博客或者翻译一篇博客都不是一件简单的事情，一般需要花好几个小时时间。对于我来说，每一篇博客都是牺牲周末的休息时间完成的。但是，对于某些键盘侠来说，一句话就可以把人给怼得非常无语。写几十个字的评论，显然要比写一篇上千字的博客要简单很多。

我写了这么多博客，被怼了无数次也习惯了，很多时候不太想看评论。自己费劲写的博客被莫名其妙地怼了，自然影响心情。当然我还是会去看评论的，因为大部分评论是比较友善，且有所收获的，有时确实能够帮助我修改一些错误。

当朋友告诉我，有人实名反对我的10万+，这虽然是意料之中的事情，但是也非常扫兴了。

这位兄弟比较较真，甚至有点かわいい，不过我也是个较真的人，这里来反驳一下这位兄弟的观点，当然对事不对人。

他总结的观点我是完全赞同的：“代码是用来解决问题的，不是用来秀技巧的，越花巧的代码维护的代价越高。如果有一百种解决问题的方法，请使用最简单的一种。”

但是，他说的东西和我的回答基本上是牛头不对马嘴，不知道他在反对我什么东西。我的回答只不过是介绍了10个JavaScript知识点，又没有说非得用这些特性去写代码，谁没事写个立即执行函数啊？

拿闭包来说，大家知道它是怎么回事，看到闭包代码的时候能够理解，需要的时候知道怎么写，面试的时候能够答出来就行了。当然，我们没有必要没事写什么闭包给自己添乱，这是不言自明的道理，不知道有啥好说的。

再举个例子，JavaScrip异步编程有3种方式：回调函数、Promise以及Async/Await，我一直在“鼓吹”大家使用Async/Await，因为简单太多了。但是，这就意味着我们不需要理解回调函数以及Promise了吗？Promise是Async/Await的基础，没有它，哪里来的什么Async/Await？至于回调函数，事件监听的时候还是得用吧？

打个比方，我写了一篇介绍汇编语言知识点的博客，如果有人说”什么年代了你还用什么汇编呢？当然得用Java啊“，这是不是有点搞笑？日常工作中，99%的开发者确实不需要用汇编，但是大部分开发者最好学习一下汇编，为什么呢？因为学会了汇编，往下层可以帮助你理解计算机组成原理，往上层可以帮助你理解编译原理。这些知识对于一个优秀的工程师都是必要的知识。

还有一点需要说明，并不是我介绍的知识点没有用，应该只是现在的你用不到而已，写上层的业务代码当然无需这些奇怪的特性。但是当你写一些稍微底层的代码，比如开发一个Fundebug前端BUG监控插件或者录屏插件时，什么立即执行函数，闭包，prototype，apply都是要用到的。

本来想逐条反驳，所谓来而不往非礼也。不过还是算了，他翻来覆去也就一句话，这个特性不能用，那个特性不能用，也没有什么好反驳的。这些特性确实有些陈旧了，大多数时候也没有必要用，但是正如评论区有人说过，这些特性“best to know”，至于用不用那是另一回事。我给大家介绍一下这些特性，没有劝大家用这些特性，兄弟犯不着这么激动。

彩蛋

我的回答最重要的是最后1个，前面的知识点可以理解为铺垫。我也是花了点时间想清楚然后再写清楚的，不妨作为面试题，正如我所说的，能够读懂最后1个，JS水平不会太差。

关于Fundebug

Fundebug专注于JavaScript、微信小程序、支付宝小程序线上应用实时BUG监控。自从2016年双十一正式上线，Fundebug累计处理了80亿+错误事件。欢迎大家免费试用！

版权声明

转载时请注明作者 Fundebug以及本文地址：
https://blog.fundebug.com/2019/05/20/the-first-blog-over-100-thousand-pv/

您的用户遇到BUG了吗？

体验Demo 免费使用