setTimeout(fun, 0)是什么意思？
浏览器线程包括：GUI渲染线程，JavaScript引擎线程，浏览器事件触发线程，定时触发器线程，异步http请求线程。其中，JS引擎线程就是执行JS的主线程，GUI渲染线程跟JS引擎线程是互斥的，不能同时进行，所以当JS陷入死循环的时候，浏览器界面没法进行渲染，而如果渲染消耗了大量资源，JS也没法马上执行。
setTimeout(fun, 0)是一个有趣的现象。这里的知识点是，定时触发器线程和JS主线程是分开的，当执行setTimeout的时候，就是告诉JS主线程，需要被分发到定时触发器线程中去计时等待。线程与线程之间通过消息来通信，当定时触发器线程的某个任务执行完之后，它会把消息发送回主线程，这个消息其实就是回调函数，它把回调函数发回给主线程，但是发回的消息在主线程执行顺序的最末端。所以setTimeout(fun, 0)的效果虽然在时间上看上去是立即执行，但是相对于js程序而已，其实是有一个延时的，起码延时到当前主线程所有任务的最后面。
这好像没有什么用，但是起码在阅读代码的时候不会懵逼。
今天见识到一门新的基于java的语言Kotlin，它有点类似TypeScript，是java的语法糖超集，据阅读到的一些文章看，Kotlin没有对java的实现全部重写。最重要的是，我看到有人指出，Kotlin可以直接编译成JavaScript。也就是说，一门语言，可以根据需要针对不同的应用，进行不同的撰写，然后编译出对应的语言去执行即可。你想在java平台上跑一个应用，用Kotlin写好，编译成java程序，拿去跑就可以了。你想在前端跑，用Kotlin写好，编译成JavaScript拿去跑就好了。我还不知道这种说法，是不是我想象的，一套代码根据需要编译成不同平台版本，但是这确实一点屌。难道现在的新生代语言都是这么玩儿的吗？语言已经突破平台的界限，更拼自己的语法和实现了吗？屌！
sass项目中的modules出口
一个组件的sass里面，不应该直接引用某个第三方vendor来进行继承，因为当sass compile的时候，会把第三方继承过来的code全部编译过来，导致你的组件编译后的css里面有大量第三方vendor的样式。正确的做法是当你要继承的时候，仅引入第三方的module文件，比如：
@import "~bootstrap-sass/.../_colors.scss";
因为一般的sass项目都会将单独的变量、函数等放在单独的文件中，而这些文件里因为没有实际的样式规则代码，所以在编译之后，它们实际上不会产生最终的css样式。
而如果你在写一个sass项目的时候，也应该遵循这种原则，如果你的组件的sass打算给其他组件去继承，也应该提供一个这样的modules的出口，这样别人只需要继承你的这个modules的出口文件，而不是你的样式出口文件。
-
[…] 我今早写了一个Note，就是讲解决这个问题的思路。简单的说就是，不能直接@import "module"，而是应该import一个具体的入口scss文件，而这个scss文件只提供变量、函数等的出口，而不产生实际的css规则。这样，当你import这个入口scss文件之后，虽然编译实际上还是会引用这个scss，但是编译的结果中没有任何module的css输出，因为你只是引入了当前你的项目文件中需要的一些scss全局变量之类的。 […]
当一个作用域内的一个（或多个）函数使用的上述作用域的变量，而这个函数并不被立即使用，而是处于备用状态，那么这个作用域将会驻留在内存中（更长的生命周期），这种现象被称为闭包。这个作用域不一定是该函数内变量的上一级作用域，也可能是该函数上很多级作用域。不被立即使用有两种情况，一种是被作为返回值（或返回值的一个方法）被赋给作用域之外的变量，由该外部变量来决定什么时候使用；另一种情况是，被当作异步操作的回调函数。驻留内存的时间由该函数的引用最终被释放来决定，当这个作用域内类似的引用全部被释放时，作用域才可能在内存中被销毁，闭包才会关闭。
有的时候需要获取用户的家目录路径，使用下面代码获取：
const USER_HOME = process.env.HOME || process.env.USERPROFILE
这样就可以在其他地方使用USER_HOME，如果为了多地方使用，可以写成一个函数导出模块。
react和vue都如此的受追捧，是否意味着以组件为核心的开发模式已经成为各个公司前端开发的主要模式？而react和vue如此像，以至于网上那么多文章对它们进行比较。剖去语法和封装的不同，react和vue在本质思想上所运用的技术似乎非常接近，特别是vue2直接把react中的一些技术借鉴过来之后，两者的本质区别越来越模糊，这是否意味着它们实际上在共享一种还未被点破的前端思想，以至于它们会不约而同的给开发者惊喜。而这个被共享的思想，我觉得就是关于组件的思想，它们所要解决的一切，都是为了组件这个问题而出发。未来，这种思想，或许将会统一为一种技术，也是我现在思考的“组件衣服”的技术。
阅读《Vuejs权威指南》的感触之一是，书里的内容实在太老了，很多api早都换了，无论是vue-resource还是vue-router都升级了多个版本。可见，一门技术必须从一开始就追，等到它都长大了，稳定了再看，就会发现很多东西都工程化复杂了很多。对于写权威指南的作者们而言，相信也很痛苦，要是更新书的版本，这些升级后的版本的内容肯定也要全部替换掉，工作量巨大啊。所以，我读这本书，也只是摸清一些原理性的东西，在整体感官上知道有什么，以后再阅读具体的官方文档，不至于陌生。
