编译的速度与激情：从 10mins 到 1s

导语：对于大型前端项目而言，构建的稳定性和易用性至关重要，腾讯文档在迭代过程中，复杂的项目结构和编译带来的问题日益增多，极大的增加了新人上手与日常搬砖的开销。恰逢 Webpack5 上线，不如来一次彻底的魔改～

在 《XSS 终结者-CSP 理论与实践》 中，讲述了 CSP 基础语法组成与使用方式。通过一步步的方案制定，最终我们利用 CSP 提供的域名白名单机制，有效地将异常的外联脚本拦在门外。然而在线上环境千千万万，虽然我们限制了外联脚本，但却仍被内联脚本钻了空子。

前言

前段时间看了下开源组件 stryker 的源码，对 Typescript 的解析器产生了兴趣。这个开源组件是用来检查单测质量的，通过识别源码自动更改某些代码内容，然后看单测能否检测出来。Typescript 解析器做的，就是识别源码这一关键步骤。

于是花了些时间学了下 Typescript 解析器，感觉像打开一个新的大门，可以玩很多有趣的事情。

附：stryke (https://github.com/stryker-mutator/stryker/tree/master)

最基础，生成 AST

翻了下 Stryker 的源码，发现应用 Typescript 解析器的关键语句如下：

Web Worker 介绍

众所周知，JavaScript 这门语言的一大特点就是单线程，即同一时间只能同步处理一件事情，这也是这门语言衍生出的 nodeJS 被各后端大佬诟病的很重要的一点。

脚本错误量极致优化-定位压缩且无 SourceMap 文件的脚本错误

”JS 代码压缩后，定位具体出错代码困难！“ 的问题，我们可以通过 SourceMap 快速定位，处理得到源文件的具体错误信息。具体方式可以查看 《脚本错误量极致优化-让脚本错误一目了然》

然而当项目外链第三方资源或公共库时，这种压缩且无提供 SourceMap 的文件出现异常，又该如何更好的定位错误位置呢？

背景

需求预沟通

• 产品：我们需要做一个 IM，和微信一样
• 我：打扰了，走错片场了，你们继续，，，，，，，
• ....
• 我：这个需求虽然不合理，但是我还是接了。。。。。。

TypeScript 中高级应用与最佳实践

当我们讨论 TypeScript 时，我们在讨论什么？

闭包这个概念是前端工程师必须要深刻理解的，但是网上确实有一些文章会让初学者觉得晦涩难懂，而且闭包的文章描述不一。

本文面向初级的程序员，聊一聊我对闭包的理解。当然如果你看到闭包联想不到作用域链与垃圾回收也不妨看一眼。希望读了它之后你不再对闭包蒙圈。

基于 React 的组件化开发方式，为富前端 web 应用提供大量技术实践，社区逐渐形成了稳定的组件规范，本文从 API 层面归纳出 6 种组件类型，分析其优缺点和适用场景，为日常组件开发提供一个方法指南。6 种类型分别为结构型组件、样式型组件、组合型组件、配置型组件、受控型组件、非受控组件。

写在前面

Omi 框架 正式发布了 → omi-transform。

Made css3 transform super easy. Made 60 FPS easy.

作为 Omi 组件化开发特效运动解决方案，让你轻松在 Omi 项目里快速简便支持 CSS3 Transform 设置。css3transform 是经受过海量项目洗礼的，作为移动 Web 特效解决方案，在微信、手 Q 兴趣部落、日迹、QQ 群、QQ 附近等项目中广泛使用，以激进的修改 DOM 属性为代价，带来极为便利的可编程性。

你可以通过 css3transform 官方首页快速了解它。