前端的學習曲線

每個人在學AngularJS的時候都會覺得Angular 1.x自創的概念實在太多，學習曲線也因此變得非常陡峭。但對于一(yī)個完整的前端項目來說，所需要的東西本來就不夠簡單，而AngularJS作爲一(yī)款大(dà)而全框架，自帶一(yī)攬子解決方案，隻要學習上手之後還是會有一(yī)勞永逸的感覺。就像Python的web框架代表Django和Flask一(yī)樣，蘿蔔白(bái)菜各有所愛，輕量級框架所帶來的靈活性固然很棒，但對于新手來說依舊(jiù)會很容易玩脫。就像當前所興起的React大(dà)潮，暫且不讨論深度玩家所表現的态度和看法，就論一(yī)個前端新手所面臨的問題，在沒有主見的時候到底該師從何派？

對于前端剛入門的我(wǒ)(wǒ)來說，依舊(jiù)會推薦從一(yī)個大(dà)而全的框架開(kāi)始學起，一(yī)個好的框架不但會強制你不犯錯誤，由此帶來的「配置大(dà)于約定」也會讓一(yī)個還沒有能力進行約定的能力去(qù)學習如何約定。當你學有所成的時候自然會似脫缰一(yī)般出去(qù)闖蕩一(yī)番。就像當初青春期的我(wǒ)(wǒ)們，在蛻變之前我(wǒ)(wǒ)們安定得學習該有的技能，當有了一(yī)定資(zī)本之後就開(kāi)始自我(wǒ)(wǒ)思考，決定去(qù)走自己的路。

反過來說，其實走自己的路，又(yòu)何嘗不是陡峭的呢？對于React來說，也許它所帶來的概念非常簡單給力。但與此同時，若是以完成整個前端項目爲目标的話(huà)，你所需要絕對不僅僅隻是一(yī)個View層的React所能辦到的，你會發現前端還可能面臨構建、路由、數據流處理等等一(yī)系列問題。所以就像當初遇見AngularJS一(yī)樣，又(yòu)開(kāi)始接觸眼花缭亂的第三方庫所灌輸的各種概念。這個時候，你還會認爲組合拳的方式好于一(yī)攬子式的解決方案嗎(ma)？

當我(wǒ)(wǒ)們站到一(yī)定高度之後再回過頭來看問題，似乎問題就變得簡單乃至問題都不複存在了。而如何能站到更高的高度呢？那就是開(kāi)始同時嘗試兩種方案吧。隻有積攢了一(yī)定的經驗之後，才會認識到跟随永遠不是最終的答案，隻有親身體(tǐ)驗之後才會擁有自己的認識。那麽，最終送上一(yī)句話(huà)：就是幹！

AngularJS 1.x到2.0

從Angular 1.x官方文檔的變遷中(zhōng)就可以看出，Google已經有意精簡了核心Modules的内容，并且讓其所引入的概念盡可能少。AngularJS擁有着諸多特性，人們津津樂道就是：依賴注入、模塊化、自動化雙向數據綁定、語義化标簽等等。而如果你是一(yī)個習慣于寫後端的軟件工(gōng)程師的話(huà)，所謂的DI和模塊化都是常用的代碼分(fēn)層手段，而雙向綁定也隻是一(yī)種VM的簡化形式，最核心也是最新穎的概念反而就是Directive，賦予了HTML更強大(dà)的能力，相當于讓浏覽器學習了新的語法。

但與此同時指令也變得過于複雜(zá)，賦予Template過多的功能之後隻會讓人想起原來的服務端腳本語言，比如JSP或者ASP，它們使用數據庫的内容加上邏輯判斷來直接填充HTML模闆。而目前AngularJS中(zhōng)的賦予了類似JSP的過強能力，允許了，甚至鼓勵了程序員(yuán)把代碼寫得混亂的行爲，模闆再次成了灰色地帶。

AngularJS的創始人之一(yī)Misko Hevery：AngularJS彌補了HTML在構建應用方面的不足，其通過使用标識符（directives）結構，來擴展Web應用中(zhōng)的HTML詞彙，使開(kāi)發者可以使用HTML來聲明動态内容，從而使得Web開(kāi)發和測試工(gōng)作變得更加容易。

當AngularJS剛創建出來的時候，它并不是給開(kāi)發人員(yuán)用的。它是一(yī)個工(gōng)具，更傾向于給需要快速創建持久化HTML表單的設計人員(yuán)用。随着時間推移，它作了改變以适應各種場景，開(kāi)發人員(yuán)也用它建造更多、更複雜(zá)的應用程序，而隻是在原有基礎之上直接進行「增量化地」改進是遠遠不夠的。這就是Angular 2.0在較高層次上的動機。更詳細的内容可以參考這篇［翻譯］有關Angular 2.0的一(yī)切，我(wǒ)(wǒ)還特意去(qù)翻了一(yī)下(xià)原作者Rob Eisenberg的Blog和Twitter，結果就發現他是：

Creator of Caliburn.Micro & Durandal. Former Angular 2.0 team member. Currently building a new tech startup, Durandal Inc., whose first product is Aurelia.

Aurelia和Angular 2.0有諸多相似之處，詳細的内容可以參考Introducing Aurelia，以及後Angular時代二三事這篇文章裏面所提到的一(yī)些共同特性。

最後從這篇浴火(huǒ)重生(shēng)的Angular中(zhōng)查看關于Angular 2.0最新的module、Web Components、observe、promise等特性吧，據說被诟病已久的性能也優化得不行不行的，總之我(wǒ)(wǒ)還是相當期待Angular 2.0的！

劃分(fēn)前後端邊界？

在這篇來自關于［翻譯］Angular的問題文章中(zhōng)，作者ppk乃至譯者xufei自己也提到，Angular更多地是面向企業的IT部門，而不是前端人員(yuán)，并且使用AngularJS的用戶更多是有Java背景的人員(yuán)。而在現在這個前端粥多僧少的階段，必然有很大(dà)一(yī)部分(fēn)Java開(kāi)發人員(yuán)要去(qù)寫JavaScript，但與此同時由于JavaScript代碼太過缺乏約束，也讓Java開(kāi)發人員(yuán)更加無所适從。這時Angular的約束性以及依賴注入等特性的好處就彰顯出來了，特别是對于傳統後端開(kāi)發者來說，當遵守AngularJS的約定時，生(shēng)産力也會更高。

與此同時，AngularJS獨特的編碼風格，它那種更傾向服務端而不是浏覽器端的對HTML模闆系統的封裝形式，以及嚴重而基礎的性能問題也吓跑了不少原來寫前端的開(kāi)發者。對于很多前端人員(yuán)而言，最大(dà)的問題就是，AngularJS強迫自己用一(yī)種指定的方式去(qù)幹活。

xufei提到的另外(wài)一(yī)個關于前端代碼寫得爛的原因就在于：前端開(kāi)發者缺乏架構意識，或者項目負責人和架構師（通常是後端）沒有足夠的前端知(zhī)識，而這兩點不解決，用什麽框架都一(yī)定做成渣。這點需要反對一(yī)下(xià)的就是，這跟框架可用性以及易用性的關系還是挺大(dà)的，要是開(kāi)發者都能夠有清晰的編程架構意識，那豈不是純靠原生(shēng)的Java就可以把後端寫得很漂亮，又(yòu)或者是隻靠JavaScript、CSS、HTML就可以把前端的髒活幹得很漂亮？

然後，其實這兒也牽扯出一(yī)個更有趣的問題，在前後端分(fēn)别都有相應的「模闆」概念，那麽HTML的動态内容究竟應該由誰來處理，也就是如何劃分(fēn)和界定前端後端？而評論中(zhōng)也有兩位大(dà)神對模闆應當歸屬于浏覽器端還是服務器端吵得不可開(kāi)交，而我(wǒ)(wǒ)個人還是比較贊同@calidion的觀點，不應該去(qù)區分(fēn)絕對的前端後端，更多内容在：Web開(kāi)發的前端與後端的界線在那裏？，最後的結論就在于「運行環境是唯一(yī)的前後端分(fēn)界線」。

那麽，在這個前後端分(fēn)離(lí)趨勢愈演愈烈的時期過渡之後呢？Web的未來是在哪裏？Isomorphic/Universal JavaScript嗎(ma)？其實對于一(yī)個更廣泛概念的Application來說，前後端本來就是一(yī)家，最多分(fēn)爲界面（Application的界面可能是Web/iOS/Android/Desktop等等）和背後的數據處理而已。若是使用統一(yī)的數據格式（JSON）并且在浏覽器内存和數據庫間實現數據同步（個人很喜歡Meteor的概念），剩下(xià)的就隻是編寫業務邏輯，然後如何把數據顯示到不同的「界面」上的問題而已。