作者：卡頌

大家好，我卡頌。

這麼多年大家習慣了使用描述的。甚至部分場景下使用時也會選擇而不是。

好像一切就這麼自然而然發生了。

然而，如果梳理歷史的走向，才是更自然的選擇。接下來讓我們看看選擇背後的邏輯是什麼？這是如今生態繁榮的關鍵因素麼？

本文參考HTML模板語言縱覽：https：//blog。yzsun。me/html-templating/

模版語言簡史

前端在有足夠複雜度之前都是作為後端框架的（view，即檢視層）存在的，操作的主流方法是。

雖說是最好的語言，但在早期更多是作為模版語言出現的，這也能從他的全稱（超文字預處理器）中窺探出一絲端倪。

當瀏覽器請求網頁時，服務端會執行模版中的程式碼，將填充了變數值的會作為資料返回。

比如如下模版，會被填充為變數值：

很多服務端語言都實現了風格的模版語法，比如：

基於的

基於二次封裝的

基於的

這類模版語法雖然功能全面，但是當頁面結構複雜時，邏輯（程式碼）會不可避免的和（）混雜在一起。

為了更好的展示，的聯合創始人開發了。

這是一款重而輕邏輯的模版解析引擎，主流程式語言幾乎都有各自的實現。

對於上面的例子，語法為：

能直觀的表達，但是缺失對邏輯的表達能力。更多則嘗試在與邏輯之間尋找平衡。

比如的（Django Template Language）除了使用與相同的語法表達中的變數，還包含大量的常見邏輯，比如：

等流程控制邏輯

迭代邏輯

過濾器

現如今，前端框架的中可以看到很多服務端曾使用的的影子。

如果你是個服務端工程師，看到如下模版語法時想必會很親切：

所以，從後端層分離並逐漸發展的前端框架，最符合直覺的方式就是採用描述檢視，比如09年出現的現象級前端框架。

然而，並不這麼認為。

用逆向思維思考

前端框架需要描述兩樣東西 —— 與邏輯。

的底層邏輯是：即然前端使用描述，那麼我們就擴充套件語法，讓他能描述邏輯。

即：從出發，擴充套件，描述邏輯。

那我們換個思路，在前端用什麼描述邏輯呢？。

那我們能不能從邏輯（即）出發，擴充套件邏輯，讓他能描述，不就達到同樣的效果嗎？

這，就是 —— 一種語法糖。

後記

由於以邏輯為起點，所以能輕鬆描述複雜的變化。這使得社群的早期參與者可以快速實現各種複雜的基礎庫，豐富社群生態。

對於前端框架的選型，一個重要的考量是：社群生態是否繁榮？

換言之，對於日常業務開發遇到的需求，能否很快速在社群中找到成熟的解決方案？

專案一旦確定了技術選型，中途再切換其他技術棧會付出極高成本。這進一步推動更多開發者參與社群建設，最終形成源源不斷的正反饋。使得長期霸榜工程師最願意使用的前端框架。

這一切，從另闢蹊徑發明那一刻就埋下了伏筆。