在程序圈里面会有很多框架束缚，比如jshint,jslint,eslint就是一些代码检测工具，能帮我们发现一些不规范的写法，然而什么是规范的写法，需要一个度量，并不是一竿子打死所有。书是死的，人是活的。就连这些工具也是说的推荐，并不是说一定要这么写，只会提示你这块可以这么改比较好，但是改不改是需要程序员衡量的。

最怕的就是认死理，只要用上了这个工具，这个工具就是yyds，所有规则全部加上，导致编辑器一片红和一片波浪线，反而影响了开发效率。永远记住工具是帮助我们提高开发效率的不是降低开发效率的，如果用工具影响开发效率还不如不用。比如某个功能三两行代码就可以快速手写出来的代码非要用一个插件或框架，而且自己还不是很精通，一顿操作各种配置，影响性能不说还影响效率，这种是大忌。

为什么程序员需要经验丰富的才好（当然也要看总结能力），因为在每个程序员心里都有一杆秤，去衡量各种事物逻辑的权重（这个是智能化无法替代的），尤其是写代码，很多时候都有多种途径可以实现某个功能，使用哪一种途径就是这杆秤发挥的作用。今天就来看看程序里面的一些常见的衡量场景：

1.前端dom属性的读写会影响效率，要把关键数据存在内存中。No

单从速度来讲，确实是内存的吞吐量是最大的，微秒级别，在人类感知里几乎是宇宙光速。而dom属性的修改需要经过dom的查询过程，修改dom属性，渲染,尤其是查询dom和渲染这两步骤是非常耗时的。

but,如果不是批量和频繁调用的方法是无所谓存哪里的，尤其是单点操作上，比如说点击事件里面，即使慢个几十毫秒是完全无感的，因为人的手速不可能一秒点几十下几百下，数据存dom里面反而有优势，优势在哪？所见即所得，这在调试里面是非常有利的。

2.requestAnimationFrame一定比setTimeout和setInterval好用？No

如果你去搜索requestAnimationFrame相关的，得到的结果几乎全是好评yyds，却没有人注意到它的缺点和不适用的场景，众所周知requestAnimationFrame是固定的时间间隔去执行任务，比如你的浏览器刷新率60fps,那么它执行的间隔是1000/60=16.7ms/次，执行频率完全取决于系统帧率，这可以极大的节省cpu资源，不像setInterval可以自由设置执行间隔时间，这在需要非常流畅的动画里面使用requestAnimationFrame会有严重的延迟视觉感，总是慢一拍的感觉，比如说在canvas绘制音乐频谱动画，对实时性要求是非常高的，此时cpu资源已经显得不那么重要，如果动画跟音乐节拍不同步那将毫无意义，所以更重要的是尽可能发挥cpu的极限来保证视觉的冲击效果，此时用setInterval是最合适的。setInterval甚至可以设置低于16ms，比如10ms执行一次，

那么requestAnimationFrame何时使用才合理，适用于对执行频率要求不高的，比如走动的时针，股票实时走势图这种不需要密集连续的动画场景。

3.vue一定比jq更高级，No

见过很多程序员的鄙视链，就不乏有使用vue/react/angular的人鄙视jquery，最主要的是我见过的鄙视者他们jq都写得都非常烂，很纳闷了为什么自己不会写会怪到工具上来。。。看他们的jq大法几乎都是满屏“尽带黄金甲”（黄金甲指的是js里面的字符串），dom查询为所欲为，不做缓存，不做dom结构的设计，在频繁调用的函数去读写dom而不做节流和防抖。

然而jq是众多企业不可或缺的库，正因为他是一个成熟的，兼容性出色的工具。如果只是完成页面的基础数据绑定没有必要多引入一个框架来解决，多一个框架对性能就多一份负担，包括jq也是，如果只是为了使用jq的dom查询函数，没必要使用jq库，手写封装一个查询函数即可，这就说明js基本功是有多重要，而不要为了学习一个框架把基本功都丢了。

好像这样评价新技术会遭人唾骂，但是作为一个技术人员不是应该秉承能求真最好，不能求真至少做到存疑吗？vue在我的网站也有使用，不是不提倡使用，只是倡导不能为了使用而使用，切记这是大忌。

4.typescript一定比原生js好？No

1. typescript确实对模块化，类型检测，面向对象编程，es6及以后的新语法有很大的优势，尤其是类型检测，如果js变量和参数命名得好，类型检测也是没有必要的，typescript优势在于可以在编写的时候检测语法是否正确，这对于盲写不测试的同学是福音。至于模块化并不是它的优势，因为es6已经支持模块化，即使不用typescript也可以使用模块化引用js,但是使用typescript有一点是我认为最大的欣赏点，就是如果后端代码是用nodejs编写的话，前端和后端一些相似的功能函数可以进行复用，没错就是既可以import也可以require模块，实现一份代码多端使用。比如md5模块，后台代码有的地方需要使用，前端账号登录注册也需要使用，但是md5版本可能多种，如果前端和后端不小心引入两个不同的md5模块，就会造成匹配不上的问题，而且造成没必要的资源浪费。如果md5模块只放一个文件在后端的文件目录，前端js要使用的话也可以通过require这个文件进来，当然这是webpack的功劳而非typescript，只是说你使用了typescript就必须引入webpack打包，webpack附带了很多特效。

2. 再来看下面向对象编程我的看法，无疑就是class的使用，这也不是typescript的特点，毕竟es6也是支持class写法，那么它优点在哪？在于属性的访问限定符，以及写法完全类似java的类的写法，如果你学废了typescript的语法，你学java也是异常轻松，因为这门语言本来就是后端程序员创造的。除此之外es5的原型prototype也能实现面向对象的一些大部分功能

3. 可以为所欲为的写es6新语法而不用担心兼容问题，因为typescript的编译可以把es6或更高级的语法转成es5。这就像突然打开了一扇大门，以前一些冒进的写法都可以写进来，比如let/const/箭头函数/对象成员的简写/解构赋值/函数默认参数等等。当然这也不是typescript的特性，只是它编译顺带有这个特性，其实是webpack的功劳。

好了，说了这么多优点，它的缺点是什么？

1. 刚谈到编译，这个就是缺点之一，至少对于原生js来说它多了这一步，这对于复杂的系统是要牺牲开发体验来成全的，因为增加了开发人员等待编译的时间，尤其是切换分支的代价，编译时间特别长。

2. 另外一个缺点还是编译，开发的代码是唯一的，但是打包后的代码可能会出现非常多重复代码。比如a文件引用的c文件，b文件引用了c文件，d文件引用了a文件和b文件，一个html页面里面引用了d.js,这d.js的代码是a+c+b+c,可以看到出现了两次c文件的代码,导致d文件异常庞大，尤其是对于复杂的系统，错综复杂的引用关系，会造成运行代码大量冗余，使得浏览器的效率变得极差。

3. 语法混乱，写久了可能会分不清这个语法是ts特有的还是es6的语法还是原生的语法还是java的语法。另外对于跨应用的代码不利，比如一些公共的代码库想移到另一个项目使用，而另一个轻量级项目没有使用ts，要么这个项目引进ts要么公共组件库改成原生js，否则无法使用，得从头开始写。
   

5.减少http请求数量，js和css分别只引用一个。No

在以往的http连接是基于tcp协议的三次握手来完成一个请求，每发一个请求就要建立三次握手，这对服务端开销是很大的，我们要尽可能减少tcp连接来优化性能，于是js、css、图片合并是常规操作，但这个的前提是HTTP1.0版本。

在HTTP1.1中已经实现了长链接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启长连接keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

更新版本的HTTP2.0更是实现了多路复用，使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。

这些更新都使得一个页面里面http请求数量不足挂齿，那么还需要合并成一个请求吗？对于两个不相同的组件代码强行合在一起是完全没必要的，比如说jq的代码和页面应用的代码，分开调用无伤大雅。

这是我工作生活中经历的比较有感触的知识点，当然实际远不止这些，凡事多问几个为什么？分析优点和缺点以及对比有何特点就会发现没有绝对的事情，得要磨好这杆衡量的秤。世界上有两种人不能效仿，一种是故步自封的，一种是yyds无脑舔的。