回複內容：
可憐的孩子，如果你上手的是 Vue 就不會這麼慘了
---
為了避免偏題，我還是針對題主的感受多說一點。你用 Angular 遇到的這些挫折，根本原因不是因為你追求新技術，而是因為你在進入一個你比較陌生的領域的時候，卻還選擇了一個 learning curve 很糟糕的架構。
Angular 1 本身的 API 設計很繁瑣，這些東西其實是 java 程式員把他們習慣的那一套『儀式感』帶入了前端架構導致的，簡言之就是『抽象概念太多』。然而這些東西在前端的語境下大部分都是除了增加系統複雜度之外毫無意義的糟粕。更糟的是對於新手來說，這些東西極大的增加了學習成本和挫折感。（諷刺的是另一方面也讓很多投入了大量精力學習 Angular 的人產生了一種斯德哥爾摩情結 - 好不容易搞懂了，怎麼能承認這些東西毫無意義？）
Angular 2 為什麼要付出相容性斷層的代價徹底重寫？就是因為 Angular 1 的 API 友好度太糟糕了。Angular 2 也轉向了『一切都是組件』這樣清晰易懂的模式，而不是上來就跟你提什麼 dependency injection, controller, scope, service, factory, provider...
到目前為止，可以說你只是因為隨大流所以選擇了一個不理想的上手方向。但到你去追著用 Angular 2 的 router 的時候，就有些操之過急了。對於這種尚未發布的試作品，Google 自己都沒用到生產環境裡呢，如果你不是已經對 Angular 本身和前端架構有了深入的瞭解，基本上是 hold 不住的。
最後，追求新技術籠統來說肯定是有意義的，學無止境嘛。但是在解決實際問題的時候，選擇一個自己 hold 得住的方案才是靠譜的。什麼時候是在解決問題，什麼時候是在學習，這個就得你自己拿捏了。自己學習時要激進，要主動去瞭解最新的技術進展，以把握技術發展的脈博。
開發正式項目時，特別是商業項目則要保守，用最多人用的，坑己經被填得差不多的技術。用最新的主流技術，並嘗試理解相比它替換掉技術，改進和原因所在。
至於“用 5 到 10 年前的技術”這種說法我不是沒聽過，只不過首先這樣的項目都是在處理 5 到 10 年前就被人解決完成了的問題，往大了說 10 年前還沒有 iOS 開發呢不是（笑）前端是如此活躍的領域，倒退 10 年人們還在燒高香期待 IE 6 解放生產力，跟你現在瞭解的東西幾乎沒有什麼關係。
其次你在可以試錯的時候不去儘可能的犯錯，等到你必須維護一坨 PHP 代碼並賴以糊口的時候你就只有哭的事了。
所以，做足功課，如果現在在前端 MVC 上的主流前沿是 AngularJS 1.4，就不要浪費時間在 1.2 上。給自己一個時間架構，然後全力以赴去試；如果到時間了還是不能解決問題，那麼立刻放棄，用自己熟悉的技術把項目完成，然後再去在沒有項目時間壓迫的地方實驗。
不要停止腳步。一定要更新知識結構
否則很快成為古董！！！
學習新的技術
不會讓過去的知識顯得過時
而是為你點亮了又一盞路燈
相信我
身後的路燈，
雖然離你漸遠
其光芒一直在助你前行
遲早有一天
你會發現
你已經點亮了地圖上的所有路燈
這讓你自由馳騁
一往無前
少年，沖吧！基本功稀鬆
看什麼都是新技術
基本功紮實
看什麼都像是新瓶裝舊酒別問別人爽不爽，要問自己疼不疼
你不覺得疼你用新技術來做什嗎？先就自己想做的定義問題，然後看看根據自己現有的知識要怎麼解決，如果能解決就開始動手，如果動手覺得工作量大／繁瑣／心塞，這就是疼了，這時候看看別人怎麼解決這個，過渡就很平滑，學習成本就很低。如果一直不疼，那你沒事找什麼事？我覺得作為技術人員，更應該focus在為什麼會出現這種新技術上。
比如javascript大家不是用的好好的麼，為什麼會有coffeescript、typescript出現？
比如jquery操作dom不是挺好的麼，為什麼會有knockout、angularjs出現？
比如memcached不是挺好的麼，為什麼會有redis出現？
而且上面所說的，看似關係不大，但其實又有關係，如果你不知道你為什麼要去用angularjs，你也一定會覺得MV(Whatever)是MV(What the fu*k)，單純為了發明一種技術而推出的技術不是技術，那是商品，而你是他們的產品。因為某種需求“自然而然”產生的技術是技術，你是他們的使用者。
你們的項目越來越大，越來越慢，你難道不應該去想為什麼慢，怎麼能不慢嗎？
說到這兒，我想到一個故事，說MIT有幾個人閑的無聊去監聽俄羅斯衛星，後來嘗試定位俄羅斯衛星，他們也確實做到了。有一天將軍說，你們能不能用衛星定位自己？這在軍事中會非常有用。於是有了GPS。angular的話，你要用路由幹什嗎？我覺得angular本身的路由功能應該很強了呀？如果你設不對的話，很可能是因為你的web service介面定義沒有完全符合HTTP 1.1標準吧？或者有可能如果你看看編譯原理就能找到一些可以繞過bug的方式了？
至於語言學習本身，我覺得語言可以說是貪多嚼不爛的典型，尤其python這種傳統的OO語言和Javascript這種功能型語言可以說是風馬牛不相及的（對於初學者而言）。所以我覺得先把其中一門大體吃透再去學下一門比較好。
不過不論如何，大四能做到這些東西還是很厲害的。堅持下去的話你一定會做的比大多數人好的多。新的技術本質是伴隨著"重構"的，你要做一個新東西，當然用最熟練和穩定的技術，實現的差不多了，再考慮重構，web裡面的前後端分離，mvc也只是新瓶裝舊酒罷了，正如《modern operating system》裡面所說的那樣，電腦科學中各個技術發展是個迂迴的過程，一些沒有意義的舊技術可能會在某個時間點重新發光，現在的新技術也會很快過時。
我很久以前也很喜歡追新的技術，xx架構來了，趕緊學，而且只要官方有了v xx.xx.xx,就算不是stable version，也不想使用v xx,xx,xx-1,後來發現沒什麼卵用，v00.00.01裡面的feature都夠用了。
架構是"你為架構服務"，這雖然對養成所謂的"best practise"有點用，但是你這樣寫出來的代碼是死的，一旦出bug很痛苦(更何況現實情況是bug層出不窮呢，那就一直非常痛苦了)，即使架構開源，你在漫無邊際的源碼中找到自己的bug原因也是非常困難的。在找這些bug的過程中，雖然可以一定程度上學到一些東西，但這些東西系統性很差 ，花費很多時間來接架構的鍋是真的事倍功半。
我現在一般不會用別人的架構，而是每次重構都為自己的架構增添東西，可能自己的架構並沒有那麼flexiable,也不能應付所有的應用情景，但我每次都盡量完善它。
你還會發現，一些語言的feature,你自己不寫架構的話，可能永遠都不會用到，這對於喜歡這門語言的人是個多麼大的損失啊！
所以，我最後想說的是，自己慢慢寫一個小的架構吧，然後培育他，讓他長大。
實際項目過程對於大多數人來說真的只是一步步google，這個過程只能讓你達到你能到的最低點，但你能到的最高點，取決於你的基本功。
多看書，多寫代碼，少寫那些所謂的實際項目(特別是那些兩三個人，一個月就能做完的那種)，外包更是有多遠離多遠，全棧工程師不需要追求，一層層的都弄懂，隨時完成C++->全棧的進化。
還有，那些說("自以為瞭解底層越多，程式越好")的前端工作者，我忍你們很久了。
手機快沒電了，知乎碼字都這麼費電-.-不止一次問過自己這個問題。
快做了十年軟體開發，這個問題上，個人是偏向保守的，下面回答幾點是做了這些年的感悟，請獨立思考，判斷取捨。
- 我們編程最終是為了使用者，不是為了老闆，不是為了產品部門，更不是為了自己，如果程式提升了使用者使用的效率和體驗，程式才有價值，使用者不關心她用的東西是怎麼實現的，但她確實關心是否能早一點用到某個功能，某個功能穩不穩定，如果不穩定我們能多塊修複，還有，這個過程會化掉她多少時間和金錢；我說這一點的目的不是要下結論我們應該總是沿用老技術，也不是要宣揚總是去嘗試新技術，知道“什麼時候做什麼選擇”比“做了什麼選擇“一樣重要，心裡要有一個標準，知道為什麼這個時候我做了這樣的選擇，要有能說服自己的理由；選不選Angular都應該有”具體“的理由，別人說的Angular如何如何先進永遠不成為理由，最多就是個參考因素；只要環境允許，我們做技術選擇的落腳點都應該是對使用者的實際意義
- 有本書叫做Facts and Fallacies of Software Engineering，有幾個章節可以比較好得回答這個困然很多程式員的問題，“盲目追求新技術”帶來的隱性成本，最終變成沉沒成本
- 新技術有時候只是用一種不一樣的“抽象”去做同樣的事情，這時候與其把它們叫新技術，不如叫新“方法”，我還是想提醒自己使用者並不關心你的技術“方法”，一個例子就是ECMAScript這些年的進化迭代，許多新的語言功能，但事實是這些是程式員自己關心的東西，用了這些語言新功能會否提升編程的簡潔度，穩定性，效能等等還需時間來證明，但程式員社區已經趨之若鶩了，巴不得立刻進入ES6，ES7時代；我想說這些事沒有它們看上去那麼重要，我知道一定很多人不同意，但我說過了這是我個人對技術的判斷；我舉一個相反的例子，H264視頻編碼，AAC音頻編碼以及MP4格式都是存在很多年的技術，但是網路流媒體的發展給了這些老技術許多新機會，他們已經是如今互連網多媒體的事實標準，所以儘管不是新技術，但非常值得深入瞭解（如果你從事這一塊），格式的統一對媒體的消費者和媒體的創作者當然是有意義的，這不僅意味著使用者端的工具會更簡單，流程更一致，使用者端需要的處理時間成本更低，還意味著她們所接觸到的視頻網站的實現的簡化，而這總是導向更好的使用者體驗，這背後的技術HTML5 video，HLS等等，都值得一併研究。說回來，這裡的觀點是新技術不一定新，老技術未必老。
- 不要太相信那些看起來能解決你所有問題的所謂新技術（我覺得Angular算一個）。承諾太多要麼是因為這個技術還太年輕，沒有太多人用，所以該暴露的問題沒有暴露出來，該被看到的短板，人們還一無所知；要麼是因為背後的團隊把過多注意力放到了市場，太顧及切中市場痛點而忽略了這種技術本身設計上應該有的平衡，這就跟做一個討好市場的RPG遊戲去拿遊戲裡的香豔去吸引使用者一樣；我想一個技術人員並不需要資深的經驗才能明白軟體開發本身的開放性和複雜性，不是一個兩個工具和技術的更新換代所能夠徹底解決的；承諾太多的技術，往往作出不切實際的設計，為了疏通邏輯在架構概念上造一堆輪子，犧牲技術使用者的學習時間，增加他們的知識負擔。這裡的觀念是，做項目的時候，強大全面的新首先意味著項目成本的增加。
- 大多數語言要學好幾年才能到“熟練”的程度，不要說精通了；但大多數人會在一兩年內放棄對這種語言縱深的學習，而轉而橫向拓展（很多人都這樣，包括我自己），這並不總是壞事，因為有時候橫向生髮本身就是縱向的啟發；我想說的是這個時候很多人可能意識不到自己其實並不怎麼“熟悉”自己認為熟悉的東西；比如用PHP寫Web應用，三個月半年換一個架構，但沒有試過去理解第一個架構的架構和設計意圖，編程技巧，可用性等等，到第二個架構的學習，還是重複那些老的概念，於是天天MVC，也只有MVC，表面上是研究新技術，實質卻還是老的思維架構；但如果研究下去，一個普通的Responsibility Chain的設計與應用就可以學到很多。所以這裡的觀點是，技術的“老”有時候是一種認知偏見，因為你不知道自己不知道的東西。
話題可以展開去說很多，但我想就此打住，千言萬語也最終依賴於你自己的研究和判斷，真正的回答我相信也在這裡，“你自己的研究和判斷”。
上面的觀點僅作參考。
