有了新语言，新框架，我跟不上？如果你的焦虑来自于语言和框架，那就要看你的工作方向了。如果是做开发，尤其是前端开发和App开发，一定要遵循框架。只有极少数公司会从头开发自己的框架。一个完整的项目绝对依赖于无数其他框架。如果你完全脱离其他框架，一直重复造轮子，那肯定要吐血。前端开发，前端开发离不开JavaScript、CSS和HTML。你知道从2005年AJAX的兴起到各种前端框架的百花齐放之间发生了多少变化吗？首先，JS、CSS、HTML的标准在不断变化，浏览器的标准也在不断变化。前端框架从最早的原型，到jQuery，到Bootstrap，再到ExtJS、Angular、React、Vue。遇到过很多精通JS底层的人，手写的框架也很多，但是大家对各种浏览器的兼容性很头疼，包括各个框架大版本的兼容性，也没人有精力去完善一个完美的框架。例如，Angular1、2和3几乎不向后兼容。你想死吗？所以当vue的作者说要重构3.0版本的时候，一片哗然，我也理解。想自己做一个相当完美的前端框架，而目前国内只有一个Vue，更别提一个团队了。对于大多数做商业项目的程序员来说，写框架的同时写业务代码？很少有公司能做到。百度、腾讯、阿里都有自己独立的前端框架，而且都深耕了五年多。而且，甲方很容易将矛头指向用户体验层面。一天改四五个设计很正常，但对程序员来说就难受了。UX的一个小改动，可能是对当前框架App开发的一个大补丁，伤害最早的Symbian系统是唯一的。当BlackBerry和WindowsMobile成为剩饭剩菜时，世界依然太平。程序员只有三种，一种会SymbianC++，一种会JavaME，还有一种会C#。随后iOS和Android突然问世，WindowsPhone打破了局面。这是一件好事。未来的世界无非就是两个系统（黑莓和WP可以忽略不计）。最坏的情况是，他们将从SymbianC++转向Objective-C，从JavaME转向Android。将继续使用C#.Net。但Android本身并不是一盏省油的灯。随着厂商的加入，史上最恐怖的Android系统“碎片化”来了。这意味着App开发必须在系统框架层面被强制改变。从Android1.0到Pie，每一次系统的改变都是非常大的改变。GoogleAndroid开发团队不断地打自己的耳光。上一版本约定的API，本版本不能使用。或者你必须在弯道周围使用它。你的团队可能已经做了一个非常好的框架。在下一个版本中，哎呀，有些功能被标记为Deprecated或直接禁用。这就是为什么Android的开源库一般不会在Github上活三年。软件是一层，硬件碎片化更可怕。哪个移动开发公司不想买上百台各式各样的安卓手机来测试和打各种补丁。在这种情况下，您是否提到自己造轮子？你连下一辆车长啥样都不知道，还造轮子？关键谷歌自己也觉得这车有点废，干脆造个新的，叫Fuchsia。如果有一天Google宣布Android闭源或者不再更新，转向Fuchsia，App开发转向Flutter，对那些抱怨跟不上的程序员，你还是要批评，因为你还没掌握核心？再说iOS，早期的iOS程序员还能笑，这两年就笑不出来了。随着机型的增多，以及苹果开始推Swift，逐渐减少对ObjectiveC的支持，他们也逐渐体会到什么是碎片化。而且，随着每一代iOS系统的更新，类似Android的框架兼容性问题也开始出现。最后不得不提一下HybridApp，还有跨平台的HTML5小程序。从Cordova、ionic、React到各大流量渠道推出的内置“小程序”，无数的跨平台框架都曾试（xī）试（shēng）称霸移动世界，世世代代。对于后端开发，乱中求稳。比如后端使用Spring框架，就必须研究IOC、DI、AOP的原理。你也可以自己写一个类似Spring的REST框架。精通原理会让你在框架更新的时候更快的理解变化，更快的开发，但这并不能减轻各种框架更新带来的痛苦。比如SpringMVC从1到2、3、5，每一次迭代都会有相应的兼容性问题，你的项目必须依赖上百个第三方库和框架，任何一个官宣迭代都是痛苦的。从SpringMVC到SpringBoot，这种跨越式的替代给后端开发带来了巨大的挑战，更不用说从SpringBoot到SpringCloud微服务的转型了。或者在一个长期的项目中，任何一个小的第三方库都可能因为停止更新或安全隐患而导致无休止的项目重构。你可能会问，为什么不自己做研究呢？该项目不会给出大量的时间和预算来从头开始开发。时间成本是固定的，自己造轮子试错的机会更少。开发一两个轮子可以，但是开发上百个轮子几乎是不可能的，小团队更不可能！您可能会完美地制造一个或两个轮子而没有缺陷，但几乎不可能考虑其他每个轮子的所有方面都为零缺陷。业务需求变化很大。例如，最初的设计是圆形的，最终可能会变成六角形的轮子。很有可能项目发布后，客户端会从六角轮变成五角轮（尤其是在UX层面）。另一个例子是消息队列。比如金融行业有使用RabbitMQ的习惯。目前看来Kafka的性能要优于RabbitMQ。为什么不在金融中使用它。因为RabbitMQ推出事务功能的时候，Kafka还没有，金融行业的发展特别强调原子性。但是随着Kafka越来越完善，很可能金融行业会开始使用Kafka而不是RabbitMQ，这对程序员来说又是一个挑战。有人要问为什么不自己开发MQ呢？中国那么大，只有阿里巴巴自己开发了一个RocketMQ，去哪儿自己开发了一个QMQ。而去哪儿也说了为什么要自研：“MQ当时也有很多开源的选择：RabbitMQ、ActiveMQ、Kafka、MetaQ（RocketMQ的前身）。首先我们排除了erlang开发的RabbitMQ，因为技术栈，而当时JavaKafka的Kafka和MetaQ还不成熟稳定，ActiveMQ已经被去哪儿网的很多应用使用，但是使用过程并不顺畅：宕机、消息丢失、消息拥塞等问题很普遍，ActiveMQ发展了很多年，代码也很复杂，不容易，所以我们决定自己造一个轮子。』strongandhealthy.但无论你当时多么强壮和健康，三到五年后你可能会变得虚弱。因为硬件和网络是在不断快速发展的，这和底层硬件几千年不变的原理是不一样的。建立在底层系统之上的应用框架迭代速度非常快，框架之间的切换间隔也越来越短。这就是为什么很多领域的程序员抱怨跟不上的原因。为什么前端和App开发的程序员更爱抱怨，因为这两个领域比底层系统开发和后端开发更累。底层系统和后端开发一般只关注一个字：稳定，而前端和App开发只关注一个字：变！有句话叫“方法不对，功夫白费”。所有的前端高手都有自己的学习方法，学习web前端的学习方式基本大同小异，但是对于一个什么都不会的初学者来说，根本不知道怎么学，这也是最直接的失败原因。所以学习web前端一定要有人指导。如果你处于迷茫时期，你就找不到自己的路。可以加入我们的前端学习交流群：784783012，有不懂的可以随时问我。
