一、 從前端技術演進看前端發展野心

前端的技術近幾年發展非常迅速，各種框架也如同雨後春筍。

從兩個維度去分析前端的技術發展，一個維度是前端複雜度，具體來講就是前端在解決建立應用複雜度方面做的一些事情；另一個是從廣度層面看前端做的事情， 這兩個維度構成了一個類似於二維平面的時間事件平面。

1. 逐漸降低建立應用複雜度

單看複雜度，前端最開始的階段只有HTML、JS、CSS，應用雖然是非常簡單的，開發起來卻是非常複雜的，因此，單單只是DOM操作方面就有大量的DOM操作API。為了降低操作成本，就出現了DOM操作框架，比如jquery。這個階段類似於從原始的刀耕火種進入石器時代。對dom的操作帶來了很大的便利性。儘管如此，真正在構建一個複雜應用的時候，因為業務邏輯和手動操作dom邏輯交織在一起，應用維護變得越來越難。

下一個階段，引入了MVC分層思想，比如backbone,這能夠將邏輯梳理的更加清晰一些。不過，MVC還是需要去關注檢視層的。

接著，就出現了mvvm框架，開發者不需要再關注檢視層的更新，只需要關注邏輯層、資料層。這一點為構建複雜大型app提供了極大的便利性。mvvm從Angular到現在react、vue的廣泛應用，前端在邏輯構建層面發展已經到了一個新的階段。

在構建大型應用的時候，僅有邏輯層是不行的，還缺乏工程性的思想。因此，出現了打包的模式，幫助我們構建更復雜的應用。這樣我們所能做的APP複雜度是一個指數型的增長。

為了進一步提高可構建應用的複雜度、增強前端的效能，assembly技術標準出現，提供了前端位元組碼的標準，為建立更加複雜的應用打好了堅實的基礎。

2. 一直在擴充套件的前端廣度

剛開始只能在瀏覽器上執行，後來有了node程式碼，可以讓我們的程式碼擴充套件到伺服器端。緊接著PC端有electron。再到移動端有RN框架，支援我們向移動端進展。

現在出現了小程式，小程式框架能夠讓前端繼續在移動端輕應用做探索。

這裡沒有講到的嵌入式開發，這方面也有相應的解決方案。

前端不斷擴充套件廣度，把前面的邊界不斷擴大。

最終前端想一統天下，把前端全棧化。

二、 同時滿足技術需求和商業需求的前端全棧

所有的技術在發展時期都有兩條線去支撐著它發展，一條線是技術需求，即技術層面的技術創意和技術訴求；另外一條線是商業需求，即技術要滿足對應的商業訴求。

一個解決方案只有同時滿足商業訴求和技術需求，才能蓬勃的發展。如果偏離這兩條線，就很難發展起來。舉個例子，比如Symbian，有些人有想嘗試這個技術訴求，但是因為它已經脫離商業需求的層面，所以這個技術會慢慢被淘汰掉。

那麼，如果僅有商業需求又會出現怎樣的情況呢？

比如，2000年的時候對AI有商業上的需求，但是技術需求並滿足，當時AI就是一個要被擱置的東西。

前端全棧，是怎樣在滿足技術需求的同時滿足商業需求的呢？

我們迴歸到移動端APP的開發實際場景，只有兩個層面：一個是UI互動介面的開發，這個是可以被使用者感知到的，另外一個是使用者感受不到的服務邏輯層面。如果來看現有的開發模式，單單從UI互動介面上來看，就有不同的平臺端android、ios、h5，對應的語言有Java、OC、swift、js等幾種語言，後端的語言和技術實現是更多的。在現在的模式下，一個小型公司如果需要開發一個完整的APP專案，就需要六種技術！

每一種技術如果需要找一個專門的人來做，這就需要6個人。那麼反映到公司企業運營上面，人力成本是比較高的，除了人力成本還有同樣非常高的溝通成本。從溝通的角度上來看，全棧式開發模式的出現，能夠讓一個人負責更多的業務開發，降低溝通成本。

由此可見，前端全棧既滿足技術需求，也滿足商業需求的，所以我相信未來前端全棧一定會蓬勃發展。

三、 打破物理隔離，實現真全棧

再回過頭看前端散落的各種技術，在這個發展的過程中，有一個很深的隔離，這個隔離本質上就是物理隔離，比如前端和後端，存在手機和伺服器之間的物理隔離。

**因為各種端是實體端，每個端之間都存在物理隔離。**就比如前端和後端，存在手機和伺服器之間的物理隔離。如果能解決這些隔離，就可以把前端的技術做到真正的統一開發模式，才能做到真全棧開發。

其實後端的物理隔離，比如每臺伺服器之間的物理隔離，可以通過雲端化，我們把程式碼上傳到雲端平臺，雲端平臺會遮蔽機器之間的物理隔離，暴露給開發者的只有一個叢集的概念，而不是一臺機器一臺機器管理部署。雲端化之後，後端的物理隔離被消除了。

我們現在的前端程式碼和伺服器之間終存在一個物理隔離，目前的解決方案是通過中間的協議打破物理隔離，比如http協議，但http協議畢竟是中間協議。

而serverless的理念就能完完全全解決掉這層物理隔離，因為程式碼即服務，serverless能打破這層隔離實現前端的真全棧。

Serverless中的FaaS，函式即服務，我在使用後端服務的時候，不再關心後端的ip地址，後端的域名是什麼樣的，直接呼叫函式即可，對前端來說，後端服務是一個函式，函式就是前端的程式碼的一部分，後端服務和前端完全的融合在一種程式碼體系裡去了，這樣後端的服務即是一個函式，至於這個函式是在前端實現，或者是在後端很遠的地方實現，開發者都可以不用關心。所以說，severless打破了物理隔離。開發者不再去做任何隔離中間層的事前，我只需要關心函式的實現就可以了，函式也是用我的前端程式碼來寫，所以達到了充分融合的定義。

回過來看具體的實現場景，比如雲開發，整個小程式的前後端邏輯都能在一個IDE裡面完成，使用者其實完全不用擔心哪些是伺服器的邏輯，他們都去向了哪裡，只需要像前端函式一樣去理解就可以了。雲函式現在也支援了本地除錯，就像前端程式碼一樣除錯，所以可以做真正的前端全棧技術開發，這對現有的開發模式是一個很大的革新。

四、 小程式雲服務的發展優化

那麼，在大前端技術發展的這波浪潮裡面，小程式雲服務又有什麼樣的發展呢？

早在2017年初小程式正式釋出的時候，第一代騰訊雲小程式雲服務就已經誕生了，但隨著8月份全面向個人開發者開放，我們發現這套支服務還是有一定門檻的。於是就開始著手去做更深度的雲服務整合和優化，才有了後來的wafer2 和現在的雲開發。

早期第一代產品 Wafer 的整個開發部署流程，統計了一下大概需要十幾步，對許多中長尾的客戶來說並不是那麼友好。於是我們開始著手優化。

**通過整個優化，可以簡略成四步。**第一步是通過一鍵的配置購買就能把雲開發產品開通起來，第二步是工程師進行小程式的前後臺開發，第三步進行程式碼的預覽上傳，測試體驗完，最後便是釋出。經過我們這一兩年的努力，小程式開發的流程已經由十幾步簡化到四步了。目前如果從市面上來看，我們這個產品在使用者體驗以及流程簡化度上，在行業內是較為領先的。

那麼，我們騰訊雲團隊和微信團隊如何一步一步優化我們的產品，將產品的接入門檻降低、流程變簡的呢？

最初我們看到的是可以將 devops 的部份環節給優化一下，包括程式碼上傳部署。這就催生了後來的Wafer 2，亦即第二代的小程式雲服務產品。

另外開通購買步驟也是比較繁瑣的。將騰訊雲和小程式的賬號打通後，可以做到一鍵授權並且開通環境與服務，並且我們提供了一個免費的開發環境，這樣可以讓更多開發者在進來發布小程式之前，可以以更低的成本門檻用上雲開發。

剩下還可以優化的就只有 SDK 引入和填寫配置的環節了。

SDK 其實可以採用內建的方式，畢竟小程式的前端介面也是直接內建到執行環境的 webview裡面的。但是配置這塊並不太好做了。因為一直以來，小程式前端和後臺的開發都是割裂的，因此整個使用者的鑑權機制都是交由小程式開發者自己去處理。但為什麼小程式與雲服務一定是要割裂的呢，為什麼不能整合到一起呢？而 Serverless 這種開發模式是前後端緊密結合的最佳粘合劑。

一般而言，請求從小程式側發起，到雲服務的後臺邏輯進行鑑權處理，如果鑑權成功再呼叫微信公開發 API，然後再把資料返回到小程式。

但我們稍微將整個請求鏈路改變一下，小程式側的請求先通過微信的服務，認證並鑑權成功之後，再到騰訊雲這邊的 Serverless 服務進行邏輯的處理，處理完畢後再返回到小程式側。這樣，我們把整個配置和鑑權服務都幫使用者完成了，這又大大減輕了開發者的負擔。

通過介紹整個小程式雲服務的優化歷程，相信大家能感悟到整個產品的理念，就是希望一方面雲能力逐步成為小程式開發的基礎能力，另一方面也希望儘量減少開發者需要理解的概念。

五、 從前端開發到全棧開發

在雲開發模式的推動下，我們開發模式是怎麼一步步走到現在的開發模式的？

在Web剛出現的時候，後臺開發本就是大包大攬，後臺邏輯完成後，再把模板和資料吐出來到瀏覽器渲染。當時基本上都是做一些比較簡單的Web應用。但是當時沒有人會吐槽你的後臺工程師只有一個人，怎麼都把後臺和前端服務都幹完了，可能當時的業務邏輯並不是很複雜，前端技術也不是那麼的規範化，應用場景不是那麼多，所以才出現這樣的情況。

可是到後來，隨著瀏覽器逐步發展，JS、CSS、HTML有一個規範委員會幫它每年制定一些新的特性。而且隨著業務場景越來越複雜，這種情況下開始提出前後端分離，開始要求後臺和前端是分開兩個人做事情，前後兩端是通過API的請求和返回去做一個資料互動。

再到了2008年的時候，喬老爺子憑一己之力開啟了移動端的開發生態。到了2017年張小龍大神也跟微信團隊推出了小程式且打造了小程式生態。這個時候很多專家提出了“大前端”的概念，希望只寫一份程式碼，就是編譯並完成不同客戶端的業務，這些端只需要共享一個後臺服務就可以了。

這個時代國外出現了一些跨端方案，比如React Native，國內也湧現了 Taro， Omi 等優秀的跨端方案。這幾個時期的前端職能是有明顯擴張的。

只做了大前端完全滿足不了前端的野心，隨著Node.js的發展，有一些中臺的服務，比如同構渲染和業務介面但逐步轉給Node.js 來做。後臺的同事開始專注於去寫一些後臺的排程服務或者優化整個資料的讀取效能。這個時期，前端開發者也開始從前端逐步往後臺做一個擴充。

但大前端的步伐遠遠不只於此，在很多業務場景裡面，前端工程師比較貼近客戶，所以他更能夠去理解到一些業務邏輯，無論是業務的前臺或是後臺，交給前端工程師來做是更好的。舉個例子，雲開發的其中一個客戶是唯品會的前端團隊。他們其中有個業務需要依靠後臺來支援，但他們的後臺人力很緊缺沒有辦法馬上投入支援。於是他們的前端就藉助雲開發，投入1個前端工程師就迅速把這個業務給做完上線了。其實許多公司的業務都有類似的情況，公司業務發展非常快，但有的時候要前端等待後臺的人力，這樣就影響到整個公司的業務發展。

可是前端的全棧開發的模式，從前端到後臺，把所有的業務全都寫完了，其實你會發現又回到我們最初的一個工程師大包大攬的做事情。可是這個業務是複雜的，如果沒有一個工具或者一個雲的基建設施去支撐這個夢想的話，其實是完全不能實現的。

面對這樣的挑戰，我們應該怎麼答覆我們的老闆呢？

騰訊雲目前提供的解決方案就是雲開發。

傳統開發模式會讓前端變成大包大攬地做業務，其實是相當困難的，因為一方面要開發前端和後端的邏輯，還要處理所有的運維的事情，靠一個人是不可能的，所以才有了現在這樣的傳統分工模式，就是前端、後臺、運維。如果把這個業務用上雲開發的話，我們主要關心的只有一小部分，主要都是我們的業務邏輯。至少只要這個工程師能夠懂Node.js，基本上就可以把服務穩定、效能卓越和有一定安全性的小程式應用獨立開發出來。

雲開發的開發模式真正可以實現前端工程師全棧開發的理想模式。