如何看待前端技术的不断更新及持续学习的态度

前端的更新迭代很快，很多知识来不及学就已经有新的内容出来了，让你猝不及防。从过去的Jquery和Bootstrap时代到现在的React、Vue、Angular时代，PC端、移动端、小程序，npm、webpack、git，浏览器、http等等内容。这么多概念，去了解就需要花很多时间。

前端的内容分为基础和实践两块，基础部分包括了HTML（语言、元素）、CSS（语言、功能）、JavaScript（运行时、文法、语义）、浏览器和API（实现原理、API），实践部分包含了性能、工具链、持续集成、搭建系统、架构与基础库。

明白什么是真正重要的

知道什么是重要的不容易，人太容易走神了，注意力太容易分散，人的感官依据外界刺激的强烈程度而反馈，刺激越多越新鲜越强烈，人的反应就大。在这些刺激之中，我们用在思考什么是重要的这个问题上的时间变得越来越少，我们独立判断的能力一天天被磨损。

年龄越大，学习的能力确实会越弱。一方面是因为身体的原因，因为年龄增长，大脑功能的衰退，思维能力相较于年轻人就已经发生了退化。还有知识的难度很高，也很难学习进去。日常的琐事太多，刚才也说了，注意力会被越来越多的事情分散掉，已经没有办法，如同学生一样专心学习，所以学习能力才会下降。

前端开发里真正重要的东西，很多年来都没有变过，也不会变（至少是很长时间内）。

一是语言本身，HTML, CSS, Javascript，前两者因为简单所以常被人忽视，但深究也有不少学问。Javascript最值得说，大家都知道前端的核心是Javascript，我们写来写去都是Javascript，runtime跑的是Javascript。但真正投入到语言的学习中的可能不多，很多时候我们都是被开发任务带着走，需要的时候学两下字，学习也就是搜索一下，很多时间被工具的熟悉消耗掉了。工具当然是需要熟悉的，只不过如果没有对语言核心的掌握，配置工具的时候就“配不进去”，只能让我们拷贝黏贴，使用过Gulp，webpack的应该都有这些体会。

二是web平台的工作原理，DOM，HTTP，浏览器装载渲染这些，细节有很多，这些东西不因为我们用的库和框架的不同而改变，而是库和框架在它们的基础上建立起自己的封装实现。要真正理解库和框架，往往核心就是理解它们的底层是什么，很多时候就是平台的API，平台提供的基础设施，比如NG用的zoneJS实现了change detection，如果理解了它背后的原理是对于浏览器异步API的patching，NG也就不神秘了。

还有一个是程序设计的能力。我可以不知道怎么在“框架A组件化”，但我知道怎么“组件化”，后者比前者更有适应能力和长期价值，万变不离其踪。JS程序设计，无论你用什么框架，真正需要注意力的是一些通用的问题，比如如何合理地实现App的模块化，如何让这些模块通信，什么是合适的通信机制，什么模式可以帮我架构等等。理解这些，任何框架我拿起来都可以和原有概念体系接上，并不需要特别地学习，用就是了。

基础和框架都重要，也都不重要，就算你js、浏览器、http原理、css新特性玩得飞起，要你设计一个UI框架你可能还是需要查文档或借鉴别人的东西，不信你试试看。就算你个人做出来看有几个人follow你的框架。术业有专攻，别歧视框架，也别抬高底层，这些所谓的底层能有多高的技术含量呢？重要的是你现在做的是什么，APP？企业应用？游戏？这些业务层面才是离用户或者客户最近，最能体现技术价值所在的地方。因为技术永远都是工具，是实现功能需求的工具而已。

明白了什么重要，我们就在它们身上投入更多，不那么重要的那些，就少投入一点；对待的心态也有所区别，核心的东西追求完整透彻，辅助的东西我们可以拿来主义。对待工具就用对待应有工具的态度，拿出来用，用好放回去，不用请它们吃饭。

我也不喜欢面试官问的一些很原理性的东西，就比如我同事面试会问，说一下你理解的原型链...这时有些面试者会说不上来，然后我就会问，那你说下你什么时候用到过prototype，实例化的对象怎么指向的prototype，typeof null和typeof undefined一样吗等等。这些很原理吗，不是吧。照样好多人说不对，你说这样的人再“会”那些新框架又如何。不过你要从企业管理上看，基础好不好无所谓，能按时干活就行。我遇到一些拿着20多k的人写的代码垃圾的一比，一点抽象解耦意识都没有，后期维护相当困难。我并不是说能解释清原型链闭包就能写好程序一样，我只是说必须要掌握基础，其次有编程思想。

工程师

抛开前端，我们也是属于工程师，那也意味着需要具备工程师的一些能力。一个前端工程师需要具备三大底层能力，编程能力-去解决难的问题，架构能力-去解决大的问题，工程能力-去解决人的问题。难的问题，大概就是偏向逻辑的复杂，那我们可以通过逻辑拆分一些方式和刻意练习进行强化，所以你现在知道为什么面试造飞机，工作拧螺丝了吧，面试官就是要考察出你的潜力和编程能力是怎样的。大的问题，就是去解决复杂系统分析、多个协同管理，你也许一个大的系统里的每一块内容都可以做的不错，但是你无法把他们整理成一起，架构能力就能在其体现。人的问题，更多的是代码的规范、如何减少成本沟通，写出clean code，当然还有其他部分，目前阶段还不是很好的理解。

团队

前端需要和四个岗位线进行协作，设计、产品、后端、测试，而在其两两之间少不了沟通和交流，而如何让这些成本降到最低，也是对你能力的考察。其中你审美情况是怎样的，交互做的怎么样，对产品逻辑的理解有多少，为后端逻辑的考虑有多少，缺陷的产生是否比较少，对用户体验的感知又是一个什么样的程度，都是不可或缺的，效率也往往在其体现，这些能力就脱离具体的专业技术能力了，但也会起着比较关键的作用。

没人有选择的“智慧”，区别只是勇气

对待那些很不重要的东西，我们需要有做选择的勇气，这对嘈杂的技术圈里的不少人，是一个不小的挑战，所以需要自我训练：不用就是不用，不喜欢就是不喜欢，大大方方地怀疑，大大方方地恨。

每个人都做过nice guy，觉得所有新技术都是机会，所以一一请吃饭 —— 结果被强奸一百遍。

“大大”，“巨巨”说得天花乱缀，招聘启示写得再殷切，但决定是你自己的，你的精力在你有限的时间里是极其有限的，所以要把技术当成主动投资，投资就是选择这个，不选择那个，是有意识地自我控制的行为，投资不是把一万块分成100份，每份都压100块。三个框架你可以都做点功课，但你得决定投资那个，决定了就投入。

现在的技术，今天一个花样，明天又一个花样。每次都有承诺，每个承诺都很可疑：如果你这样这样这样再那样那样那样，问题就解决了，你看，很简单吧！比如大家都热爱的React，我个人就十分讨厌，不管他们怎么说，对我来说这就是一个缺乏品味的技术栈。今天Flux，明天Redux，后天MobX，破坏了一致性，反而回过来鼓吹JSX的表现力。Redux这样的承诺，化成“直观”的图形，多数人类却看不懂，却说它好用。

放屁。

我个人的看法是FB的技术团队只懂Hack，不懂设计，只不过有时候厂子大了Hack做得像模像样，让人误以为是好设计。很多人把自己的项目当FB。

Not me. 我决定不投资React，这是我的选择。因为这是我的选择，所以你也没有必要给我留言和我争论。我做了一个选择，我心安理得，我承担潜在风险，我愿意。

你也应该这样。

你可能有不同的选择，选择什么的结果都不会很差。但是如果你没勇气选择东搞搞西搞搞什么都搞，被坑了，你得先怪你自己。项目是你的，代码是你来维护的，搞好搞坏是你的。所以你得负起责任来，对自己诚实一点，做点接地气的决定。

不要害怕和别人不同，需要和别人不同的时候，就结结实实的决定。你受的教育不教独立和勇气，所以你得自己训练自己。

有时候靠谱的事只有一件，就是“顺其自然”

工具的开发者真想坑人的很少，但他们也是人，有时候一激动就把我们坑了。

把我们坑了不意味着工具不再提供价值了，我们应该把注意力放在它们提供的价值上，善加利用之，它升级你就升，他说同志们下一版本咱不兼容了，请大家把app重新搞一下，那你就搞，早点搞，不要想东想西耽误了时辰。多数时候也不过是npm update，不需要花太多力气。

在有价值的东西上投入一点时间来维护，这就像你投资了基金要交点年费一样，是正常的。你上了贼船，没太多选择，你不得不尊重这种选择，继续搞下去。

有时候该换的时候就换，工具只是工具，不是结婚对象，策略灵活务实一点，大多数情况下，做一个pros/cons分析并不难。

同样，不该换就不换，工具服务于更大的产品和商业的目标，如果这些目标是达成的，谁在乎你用的那个东西是不是最新版本呢，不是最新版本又怎么样呢，团队用了几年熟悉了，能当裤子穿了，就是自己的东西，版本也就没那么重要了。

搞清楚收益与成本，该干嘛干嘛。