一個C++眼中的前端技術發展的規律

背景

由于項目原因，從一個Windows客戶端開發，跳進前端開發這個大坑。從一開始的茫然，到下定決心放空心態學習，到現在逐漸有了清晰的思路。我想，許多從客戶端（后臺）轉來學前端的，應該和我有類似的經歷。

1段：指令化編程

一開始學習的是基本的html，css，用簡單的javascript操作DOM。這是最迷惑的階段，拋去HTML/CSS的各種標準，各種瀏覽器的兼容等干擾信息。在頁面中的script標簽中，寫下操作DOM的代碼。這個階段，像極了剛開始學習C語言，做作業的場景。一段代碼，完成一個任務。

2段：函數（庫）式編程

項目中遇到了稍微復雜的需求，比如msgbox，slider等，網上搜到的都是jQuery的擴展。于是乎發現了jQuery以及 Zepto，好像終于發現了終極武器，從此信步于代碼江湖。原來這些都是YY，寫一些些簡單的頁面騙騙妹子可以，真正的生產環境中，這才是初級。這個階段，像極了學習數據結構時，用C寫一些簡單的應用，比如一個簡易編輯器。會用到很多其他人封裝好的常用操作，比如文件操作等。

3段：結構（模塊）化編程

隨著項目變多，很多東西可以沉淀下來，在其它的項目中使用。這就需要把一個特定的功能的文件封裝起來，當有項目需要時，可以引入進來。這里要解決全局變量命名空間污染問題，作用域問題等。比如，AMD、UMD、CommonJS標準，再比如requirejs，seajs，nodejs等，都針對這個解決了問題。只有到了這個階段，工程化才能真正的起來。因為不用重復造輪子了。這個階段，像極了用C語言開始工作后，使用公司及外界現有模塊開發。

4段：面向對象編程

手頭的模塊逐漸多起來，但還是多不過變換無窮的需求。有些需求，用A模塊實現了，但下一個需求，和A類似，于是有人寫了B模塊。當你用的時候，會糾結于用A還是B？那么我看下載量吧，選了一個下載量大的，結果下載下來，還是需要手動該一些代碼，才能適合自己的需求。現在npm，估計很多都是這種情況吧。只有語言更深一步的抽象，更好的封裝，且在一個強大的基礎類庫下，才是個好的解決方案。React，Backbone，ES6以及各種框架，也模擬了面向對象的一些特性。這個階段，回想起Borland公司的Delphi和C++ Builder，在Windows客戶端開發時期的輝煌，就把這個玩到了極致。

5段：組件化編程

還原真實世界，工程無一不是由各種基本的元件搭建起來的。到了軟件工程世界，就是組件化編程。這是工程的最高效率階段，各種“快速開發工具”紛至沓來。市面上有各種酷炫的組件，并號稱“一行代碼就能讓你的項目也同樣的吸引眼球”。還是Borland公司，把這個玩到極致，回想起為了實現一個效果，第一反應不是如何從技術考慮，而是在網上找“控件”的破解版。同樣，遇到了bug，很少自己去修改（也很難改），而是再去搞一個控件來。目前，React正在這個階段發展，當各種Component積累成熟后，前端開發效率會進一步提升。這個階段，對標的還是Borland公司，還有微軟的 COM技術。

6段：面向服務

面向組件的缺點是明顯的，為了一個效果，引入一堆代碼（以及bug）。我只需要你的服務就好了。把組件功能封裝成服務，通過通信協議（RPC，HTTP等）和自己的工程鏈接起來，就能完成需求。這個階段還沒有明顯的對標，我想各種統計代碼從概念說應該是相當的，還有各種api接口。也就是說，前端技術中，很可能把面向服務形式，轉移到了后端中。

7段：分布式/虛擬化

當網絡及虛擬化技術不再是門檻，那么通過分布式及虛擬化技術，能將工程快速部署到各個平臺，各個互聯網角落。這個階段前端開發反而不用考慮了。因為分布式天然的網絡環境可以提供，而虛擬化由js引擎已經考慮到了。而面向技術的虛擬化已經慢慢開始，React-native，angular，都在慢慢開疆擴土。

附加：打包，部署

在傳統的客戶端開發中，這些都是IDE提供的，但前端開發卻百花齊放。r.js，webpack，browserify，grunt，gulp，duo等。其實不必亂和糾結，找到一個適合自己的就可以了。

總結，至此，經歷了一個階段（半年了吧）的js采坑，才慢慢的思路清晰起來，技術的發展路線都是有規律的。前端的亂，其背后還是有一條清晰的主線的。