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都升级了多个版本。可见，一门技术必须从一开始就追，等到它都长大了，稳定了再看，就会发现很多东西都工程化复杂了很多。对于写权威指南的作者们而言，相信也很痛苦，要是更新书的版本，这些升级后的版本的内容肯定也要全部替换掉，工作量巨大啊。所以，我读这本书，也只是摸清一些原理性的东西，在整体感官上知道有什么，以后再阅读具体的官方文档，不至于陌生。
backbone里面的set trigger坑
backbone里面set原本会触发绑定的change事件，不过如果使用$.extend(true深拷贝一个数据，但是没有实质性改变数据的值，再重新set一下，是不会触发change事件的。
let test = new Backbone.Model()
let data = {
name: 'yoyo',
}
test.on('change:data', (e, data) => console.log(data))
test.set('data', data) // triggerlet
newdata = $.extend(true, {}, data)
test.set('data', newdata) // not trigger
使用的时候应该要小心，一不小心就得不到自己预期的效果。
这里收集一下可以长期关注的php开发框架，所谓长期关注，就是说这个框架未来肯定还是有一定市场的，不会过两天就死掉：
1.Laravel
2.Symfony2
3.Yii2
4.Zend Framework
5.Slim
其他框架，例如CodeIgniter，Cakephp等，虽然还会有人用，但是从设计理念上，全然不如laravel这类组件化了的框架。对于我个人而言，越来越喜欢slim，因为它小，它自由，你可以用它做任何事情，它不提供的功能，你只需要composer去安装对应的组件即可。
-
不知道你对Yii2有没有了解？希望能看到你对yii2的梳理#265 restful 2017-04-30 16:38
-
之前一个项目，同事使用Yii开发，就接触了一下，感觉还行，一起写过一个投票页面，对于他而言，熟练上手，而且验证之类的写起来非常容易，但是我没有深入研究，现在已经转前端了，前后端分离开发的情况下，php主要是为了实现后端数据计算实现api，还在使用的是slim，所以可能要让你失望#266 回复给#265 否子戈 2017-04-30 16:44
今天开始看一个轻量级的php开发框架：slimphp，它和我以前接触过的所有php框架都不一样，以前看过的框架动不动就开始MVC，而slimphp一上来是composer，它就像一个库一样，可以由你自由支配，没有特定的文件目录结构，你想怎样就怎样，它只给你提供接口。和express非常像：
1.路由方式
跟express很像的一个地方是，采用->get('/', function($req, $res, $args) {})
2.中间件
除了req和res的地方很像，中间件也很像，甚至也包括一个$next函数。
之所以要看slim是因为我想用它来写一个api server，前端则是在componer环境下去写，到时候会用vue作为前端框架。这样一来，一方面可以让自己学到更多东西，另一方面我是在想，我未来的开发基本上都会基于这种模式，即后台只写api接口，前端会基于最流行的框架去写。现在已经非常明确了，我肯定会选择vue作为框架，如果公司或客户层面要求用react也会用。但是我之前一直对php的框架没有打定主意，最开始想学laravel，但是因为没有赶上好时机，没有在它刚出来的时候就去学，所以也就不想去学了。看到slim后，瞬间就决定，因为我只用php来写api，所以将来只会用slim来写了。什么thinkphp之类的，滚一边去吧。slim配合composer，可以避免laravel的繁复，同时又有巨大的可定制的空间。
搞起！
-
2021.6.5 记 现在我的想法一直。#1056 yuan 2021-06-05 10:16
