出了新的語言，新的框架，自己要跟不上了？如果你的焦慮感來自語言和框架的時候，就要看你所處的工作方向，如果是做開發，特別是前端開發，App 開發，必須跟着框架走。只有極少數公司會從頭自研框架，一個完整的項目絕對依賴無數其它的框架，如果完全脫離其它框架不停重複造輪子，肯定得編到吐血。
前端開發，哀鴻遍野
前端開發，離不開 JavaScript、CSS 和 HTML。
你可知 05 年 AJAX 剛興起到如今各類前端框架百花爭鳴，中間經歷多大變化？首先是 JS、CSS、HTML 自身標準不停變化，瀏覽器標準不停變化。
前端框架從最早的 prototype，到 jQuery，到 Bootstrap，到 Ext JS、Angular、React、Vue。精通 JS 底層的人我見過很多，手寫框架的也很多，但所有人都非常頭疼各類瀏覽器兼容性，包括各個框架大版本的兼容性，沒有人有精力完善一個完美的框架。比如 Angular 1、2、3 幾乎都是不向下兼容的，換你你想不想死？所以當 Vue 作者說要重構 3.0 版本，底下哀嚎一片，我很理解。
你想以一己之力做個還算完美的前端框架，全國到現在也只有 Vue 一個，何況還有個 team。對於做商業項目的大多數程序員，一邊寫業務代碼，一邊寫框架？沒幾家能做到，百度、騰訊和阿里，纔有自己獨立的前端框架的，而且都是深耕五年以上。
而且甲方非常容易對 UX 這個層面指手畫腳，一天換四五個設計非常正常，但是程序員就難受了，一個 UX 的小改動，可能是對當前框架做一個大的補丁
App 開發，痛徹心扉
最早 Symbian 系統一家獨大，BlackBerry 和 Windows Mobile 吃剩飯時，世界還是一片祥和，程序員就三種，一種是會 Symbian C++的，一種是會 JavaME 的，剩下一種會 C#。然後 iOS 和 Android 帶着 Windows Phone 突然出來攪局了，本來是件好事，世界以後無非也就是兩種系統嘛（BlackBerry 和 WP 忽略不計），大不了會 Symbian C++轉行 Objective-C，會 JavaME 的轉行 Android，會 C# 的繼續 .Net。
但 Android 天生就不是一個省油的燈。
隨着廠家的加盟，史上最恐怖的 Android 系統“碎片化”來了。這意味着 App 開發必須在系統框架這個層面上被迫變化。Android 從 1.0 到 Pie，每一次系統變化，都是非常大的變化，變化到 Google Android 開發團隊自己都在不停地打自己的臉，上個版本說好的 API，這個版本就不能用了，或者你得繞着彎子用。
你的團隊可能做了一個很不錯的框架，下個版本，哎呦我去，部分功能被標記爲 Deprecated 或者直接禁用了。這也就是 Android 的開源庫在 Github 上一般活不過三年的原因。
軟件是一層，硬件碎片化更恐怖，哪一家移動開發公司不是要買幾百臺各類 Android 手機做測試，做各類補丁。這種情況下，你再提自己造輪子？連下輛車長什麼樣都不知道，你還造輪子？
關鍵是 Google 自己都認爲這輛車有點造殘了，乾脆做一倆新的吧，叫 Fuchsia，如果有一天 Google 宣佈 Android 閉源或者不再更新，而轉向 Fuchsia，同時 App 開發轉向 Flutter 時，對那些抱怨跟不上的程序員，你還要批評是因爲沒掌握核心？
再說 iOS，iOS 程序員在早期還笑得出來，這兩年也笑不出了，隨着機型的增多，加上蘋果開始力推 Swift，並且逐漸降低對 Objective C 的支持，他們也漸漸體驗到什麼叫碎片化了。而且每一代 iOS 系統更新，也開始出現 Android 類似的框架兼容問題。
最後不得不提的 Hybrid App，和跨平臺 HTML5 小程序。從 Cordova、ionic、React 再到各大流量渠道推出的內置“小程序”，期間無數跨平臺框架，前赴後繼地嘗（xī）試（shēng）在移動世界一統江湖，千秋萬代。
後端開發，亂中求穩
比如做後端的用 Spring 框架，必須要研究 IOC、DI、AOP 這些原理，還可能會自己手寫一個仿 Spring 的 REST 框架。精通原理會讓你在框架更新時更快地理解變動，和更快地開發，但這並不能減輕各類框架更新時所帶來的痛苦。比如 Spring MVC 從 1 到 2, 3，5，每一次迭代都會有相應的兼容問題，你的項目必定依賴數以百計的第三方庫和框架，任何一次官宣迭代都是切膚之痛。
從 Spring MVC 到 Spring Boot，這種跨越式的換代更是給後端開發帶來巨大挑戰，更別提 Spring Boot 向 Spring Cloud 微服務的轉變。
又或者長期項目中，任何一個小的第三方庫，都可能因爲停止更新，或安全隱患帶來無窮無盡的項目重構。你會問，爲什麼不自研？
項目不會給很多時間和預算，從頭開發。
時間成本定死，給你自己造輪子的試錯機會就少。
你可以開發一兩個輪子，但開發幾百個輪子是幾乎不可能的任務，小團隊不可能！
你可能一個兩個輪子造的非常完美零瑕疵，但是其餘每個輪子的各個方面都考慮到零瑕疵，這也是幾乎不可能的任務。
業務需求變化非常大，比如開始設計是圓形，可能最終要六角形輪子。
很有可能項目發佈後，客戶又要從六角形輪子變爲五角形輪子（尤其在 UX 層面）。
另一個例子，消息隊列，比如金融業有用 RabbitMQ 的習慣，目前看好像 Kafka 性能優於 RabbitMQ，金融爲什麼不用。因爲 RabbitMQ 推出事務性功能時，Kafka 還沒有，而金融業開發特別強調原子性。但隨着 Kafka 日益完善，很可能金融業開始使用 Kafa 替代 RabbitMQ，這對程序員又是挑戰。有人要問爲什麼不開始就自研 MQ？
中國那麼大，也就阿里才自研了一個 RocketMQ，去哪兒自研了一個 QMQ。而且去哪兒也說了爲什麼自研：『MQ 在當時也有很多開源的選擇：RabbitMQ, ActiveMQ, Kafka, MetaQ(RocketMQ 的前身)。首先因爲技術棧我們排除了 erlang 開發的 RabbitMQ，而 Kafka 以及 Java 版 Kafka 的 MetaQ 在當時還並不成熟和穩定。而 ActiveMQ 在去哪兒網已經有很多應用在使用了，但是使用過程中並不一帆風順：宕機，消息丟失，消息堵塞等問題屢見不鮮，而且 ActiveMQ 發展多年，代碼也非常複雜，想要完全把控也不容易，所以我們決定自己造一個輪子。』
構架師選擇框架，第一要素肯定是足夠地茁壯健康。但是就算當時再怎麼茁壯健康，過三五年可能也就是羸弱之軀。因爲硬件和網絡是不斷迅速發展的，這和底層硬件原理萬年不變不同，構架於底層系統之上的應用框架，迭代速度非常快，框架與框架之間切換間隔也越來越短。
所以不少領域的程序員纔會抱怨跟不上了。
爲什麼說前端和 App 開發的程序員更愛抱怨，因爲這兩個領域和底層系統開發以及後端開發相比，更心累。底層系統和後端開發一般是着重一個字：穩，但是前端和 App 開發就一個字：變！
有句話叫做“方法不對，努力白費”所有的前端大神都有自己的學習方法，而學web前端的學習也基本一致，而對於一個什麼都不懂的初學者，根本不會知道該怎麼學，這也是造成失敗的最直接原因。所以學web前端一定要有人指點。如果你處在迷茫期，找不到方向。可以加入我們的前端學習交流qun： 784783012 。有任何不明白的東西隨時來問我。