为了更好的帮助外部合作渠道开发游戏的营销活动，我们开发了一款 JS SDK。该 SDK 采用 webpack4 编译打包，用于支持移动端 H5 活动快速开发，随着业务拓展，端游活动的开发也需要支持，但由于一些用户 PC 系统版本较低，部分端游 webview 又采用默认 IE 内核、以及用户使用 IE 浏览器参与活动等原因、导致这些用户无法参与到活动中来，从而影响活动效果，那么，该如何完美的适配 IE 内核呢？

对于现在的前端项目而言，编译发布几乎是必需操作，有的编译只需要几秒钟，快如闪电，有的却需要10分钟，甚至更多，慢如蜗牛。特别是线上热修复时，分秒必争，响应速度直接影响了用户体验，用户不会有耐心等那么长时间，让你慢慢编译；如果涉及到支付操作，产品损失更是以秒计，每提前哪怕一秒钟发布，在腾讯海量用户面前，都能挽回不小的损失。不仅如此，编译效率的提升，带来的最直观收益就是，开发效率与开发体验双重提升。

那么，到底是什么拖慢了webpack打包效率，我们又能做哪些提升呢？

我曾经耗费巨大的精力，试图在计算机的使用效率上找到一条优化的捷径，一直以来都收效甚微。直到遇上 alfred，它强大的工作流机制，彻底解决了输入输出的痛点，极大的减少了程序之间的切换成本和重复按键成本，这才让我明白，原来计算机可以这么玩。

神奇的魔法帽，alfred 初印象。

本文首发于《程序员》杂志2017年第9、10、11期，下面的版本又经过进一步的修订。

导读

对于开发而言，搜索是日常工作，为了提升搜索的效率，以便更快的查询信息，我试着同时搜索4个网站，分别是百度、Google、维基、Bing。一个可行的做法就是网页中嵌入4个iframe，通过js拼接前面4个搜索引擎的Search URL并依次在iframe中加载。这个构思丝毫没有问题，简单粗暴。然而就是这么简单的功能，也无法实现。由于Google网站在HTML的response header中添加了X-Frame-Options字段以防止网页被Frame（这项设置常被用来防止Click Cheats），因此我无法将Google Search加入到iframe中来。那么，我会放弃Google吗？

本文首发于CSDN网站，下面的版本又经过进一步的修订。

导读

我一直信奉简洁至上的原则，桌面窗口的数量越少，我的心情就越放松，开发的效率也就越高。反之，杂乱的桌面，暴涨的Chrome tab数量，或是无数的终端窗口，它们会逐步侵占我的注意力，分散我的思维，最终令我难以专注。因此桌面上我很少放文件，使用Chrome时常点 OneTab 回收标签页，切进终端时使用tmux管理窗口。

那么，有没有可能开机后不需要任何操作，本地的十几种web开发服务就自动运行？当然我不希望连续弹出十几个窗口或是tab，我需要的是静默无感知的启用服务，然后还能快速地进入到现场进行操作，web服务运行时不占据终端窗口，关闭iTem2后操作现场不会被销毁。诸如此类，tmux都能实现，除了这些，tmux还能做得更多更好。

到目前为止，tmux帮助我两年有余，它带给我许多惊喜。独乐不如众乐，愿你也能一同享受tmux带来的快乐。

本文首发于CSDN网站，下面的版本又经过进一步的修订。

导读

6月又是项目吃紧的时候，一大波需求袭来，猝不及防。

度过了漫长而煎熬的6月，是时候总结一波。最近移动端的一款产品原计划是引入第三方的签名插件，该插件依赖复杂，若干个js使用document.write顺序加载，插件源码是ES5的，甚至说是ES3都不为过。为了能够顺利嵌入我们的VUE项目，我阅读了两天插件的源码（demo及文档不全，囧），然后花了一天多点的时间使用ES6引用它。鉴于单页应用中，任何非全局资源都不该提前加载的指导性原则，为了做到动态加载，我甚至还专门写了一个simple的vue组件iload.js去顺序加载这些资源并执行回调。一切看似很完美，结果发现demo引用的一个压缩的js中居然写死了插件相关DOM节点的id和style，此刻我的内心几乎是崩溃的。这样的一个插件我怕是无力引入了吧。

本文首发于CSDN网站，下面的版本又经过进一步的修订。

全文共13k+字，系统讲解了JavaScript数组的各种特性和API。

数组是一种非常重要的数据类型，它语法简单、灵活、高效。 在多数编程语言中，数组都充当着至关重要的角色，以至于很难想象没有数组的编程语言会是什么模样。特别是JavaScript，它天生的灵活性，又进一步发挥了数组的特长，丰富了数组的使用场景。可以毫不夸张地说，不深入地了解数组，不足以写JavaScript。

截止ES7规范，数组共包含33个标准的API方法和一个非标准的API方法，使用场景和使用方案纷繁复杂，其中有不少浅坑、深坑、甚至神坑。下面将从Array构造器及ES6新特性开始，逐步帮助你掌握数组。

本文首发于CSDN网站，下面的版本又经过进一步的修订。

开发环境页面热更新早已是主流，我们不光要吃着火锅唱着歌，享受热更新高效率的快感，更要深入下去探求其原理。

要知道，触类则旁通，常见的需求如赛事网页推送比赛结果、网页实时展示投票或点赞数据、在线评论或弹幕、在线聊天室等，都需要借助热更新功能，才能达到实时的端对端的极致体验。

刚好，最近解决webpack-hot-middleware热更新延迟问题的过程中，我深入接触了EventSource技术。遂本文由此开篇，进一步讲解webpack-hot-middleware，browser-sync背后的技术。

缓存一直是前端优化的主战场, 利用好缓存就成功了一半. 本篇从http请求和响应的头域入手, 让你对浏览器缓存有个整体的概念. 最终你会发现强缓存, 协商缓存 和 启发式缓存是如此的简单.

导读

我不知道拖延症是有多严重, 反正去年3月开的题, 直到今年4月才开始写.(请尽情吐槽吧)

开始写本篇文字时, 我一直不是很明白任务队列的机制, 故想写篇文章弄懂它. 于是我尝试以Promise为核心, 逐步展开, 最终分析process.nextTick , promise.then , setTimeout , setImmediate 它们的异步机制.

导读

Promise问世已久, 其科普类文章亦不计其数. 遂本篇初衷不为科普, 只为能够温故而知新.

比如说, catch能捕获所有的错误吗? 为什么有些时候会抛出”Uncaught (in promise) …”? Promise.resolve 和 Promise.reject 处理Promise对象时又有什么不一样的地方?