首先，JavaScript是一个单线程的脚本语言。所以就是说在一行代码执行的过程中，必然不会存在同时执行的另一行代码，就像使用alert()以后进行疯狂console.log，如果没有关闭弹框，控制台是不会显示出一条log信息的。亦或者有些代码执行了大量计算，比方说在前端暴力破解密码之类的鬼操作，这就会导致后续代码一直在等待，页面处于假死状态，因为前边的代码并没有执行完。

第三篇，有关koa生态中比较重要的一个中间件：koa-router 第一篇：koa源码阅读-0第二篇：koa源码阅读-1-koa与koa-compose koa-router是什么首先，因为koa是一个管理中间件的平台，而注册一个中间件使用use来执行。无论是什么请求，都会将所有的中间件执行一遍（如果没有中途结束的话）所以，这就会让开发者很困扰，如果我们要做路由该怎么写逻辑？

接上次挖的坑，对koa2.x相关的源码进行分析 第一篇。不得不说，koa是一个很轻量、很优雅的http框架，尤其是在2.x以后移除了co的引入，使其代码变得更为清晰。 express和koa同为一批人进行开发，与express相比，koa显得非常的迷你。因为express是一个大而全的http框架，内置了类似router之类的中间件进行处理。而在koa中，则将类似功能的中间件全部摘了出来，早期koa里边是内置了koa-compose的，而现在也是将其分了出来。koa只保留一个简单的中间件的整合，http请求的处理，作为一个功能性的中间件框架来存在，自身仅有少量的逻辑。koa-compose则是作为整合中间件最为关键的一个工具、洋葱模型的具体实现，所以要将两者放在一起来看。

Node.js也是写了两三年的时间了，刚开始学习Node的时候，hello world就是创建一个HttpServer，后来在工作中也是经历过Express、Koa1.x、Koa2.x以及最近还在研究的结合着TypeScript的routing-controllers（驱动依然是Express与Koa）。用的比较多的还是Koa版本，也是对它的洋葱模型比较感兴趣，所以最近抽出时间来阅读其源码，正好近期可能会对一个Express项目进行重构，将其重构为koa2.x版本的，所以，阅读其源码对于重构也是一种有效的帮助。

TypeScript可以理解为是JavaScript的一个超集，也就是说涵盖了所有JavaScript的功能，并在之上有着自己独特的语法。最近的一个新项目开始了TS的踩坑之旅，现分享一些可以借鉴的套路给大家。

最近新开了一个Node项目，采用TypeScript来开发，在数据库及路由管理方面用了不少的装饰器，发觉这的确是一个好东西。装饰器是一个还处于草案中的特性，目前木有直接支持该语法的环境，但是可以通过 babel 之类的进行转换为旧语法来实现效果，所以在TypeScript中，可以放心的使用@Decorator。

纯原生的组件化、模块化的一次小小的尝试，用到了如下几个新特性：shadown-DOM 对HTML标签结构的一个封装，真正意义上的组件，能保证 shadow-DOM 中的DOM元素不会被外界影响，内部也不会影响到外部的行为，变成了一个独立的模块。custom-elements 可以在浏览器中注册自定义的标签来使用，类似这样的效果<my-tag></my-tag>，标签内容基于两种形式：1. 普通子元素 2. shadow-DOMcustom-events 使用各种自定义事件辅助完成组件之间的通讯ES-module 为浏览器原生支持的模块化的一种方案，直接在浏览器里使用import和export这类语法，以 module 的方式来引入 js 文件。几个算是比较新的事物，聚集在一起确实可以做点儿好玩的东西出来。

这里安利两款我认为开发中能够极大的提高生产力的工具，Charles 和 Postman。 P.S. Charles(查尔斯)。。不要再读查理斯了，金刚狼中被老铁扎心的博士就叫 Charles

其实浏览器原生模块相关的支持也已经出了一两年了（我第一次知道这个事情实在2016年下半年的时候）可以抛开webpack直接使用import之类的语法但因为算是一个比较新的东西，所以现在基本只能自己闹着玩 :p但这并不能成为不去了解它的借口，还是要体验一下的。

这两天针对一个Node项目进行了一波代码层面的优化，从响应时间上看，是一次很显著的提升。一个纯粹给客户端提供接口的服务，没有涉及到页面渲染相关。 背景首先这个项目是一个几年前的项目了，期间一直在新增需求，导致代码逻辑变得也比较复杂，接口响应时长也在跟着上涨。之前有过一次针对服务器环境方面的优化（node版本升级），确实性能提升不少，但是本着“青春在于作死”的理念，这次就从代码层面再进行一次优化。