前端體系
想要成爲真正的互聯網Java全棧工程師，前端是繞不開的一門必修課。
接下來我們就來認識前端、瞭解前端、掌握前端，爲成爲互聯網Java全棧工程師而前進。
前端三要素
前端三要素爲：
- HTML（結構）：超文本標記語言（Hyper Text Markup Language），決定網頁的結構和內容。
- CSS（表現）：層疊樣式表（Cascading Style Sheets），設定網頁的表現樣式。
- Javascript（行爲）：是一種弱類型腳本語言，其源代碼不需經過編譯，而是由瀏覽器解釋運行，用於控制網頁的行爲。
結構層（HTML）比較簡單，省略。
表現層（CSS）
CSS 層疊樣式表是一門標記語言，並不是編程語言，因此不可以自定義變量，不可以引用等，換句話說就是不具備任何語法支持。
它的主要缺陷如下：
- 語法不夠強大，例如無法嵌套書寫，導致模塊化開發中需要書寫很多重複的選擇器。
- 沒有變量和合理的樣式複用機制，使得邏輯上相關的屬性值必須以字面量的形式重複輸出，導致難以維護。
因爲這些缺陷導致我們在工作中無端增加了許多工作量。爲了解決這個問題，前端開發人員會使用一種稱之爲CSS 預處理器的工具，提供 CSS 缺失的樣式層複用機制、減少冗餘代碼，提高樣式代碼的可維護性。大大提高了前端在樣式上的開發效率。
什麼是CSS預處理器？
CSS 預處理器定義了一種新的語言，其基本思想是，用一種專門的編程語言，爲 CSS 增加了一些編程的特性，將 CSS 作爲目標生成文件，然後開發者就只要使用這種語言進行 CSS 的編碼工作。
簡單來說就是：用一種專門的編程語言，進行 Web 頁面樣式設計，再通過編譯器轉化爲正常的 CSS 文件，以供項目使用。
常用的CSS預處理器
- SASS，基於 Ruby，通過服務端處理，功能強大。解析效率高。需要學習 Ruby 語言，上手難度高於LESS。
- LESS，基於 NodeJS，通過客戶端處理，使用簡單。功能比 SASS 簡單，解析效率也低於 SASS，但在實際開發中足夠了，所以後臺人員一般建議使用 LESS。
一些大型的網站每到一些節日的時候都有一套不一樣的皮膚。其實是因爲他們在後臺已經編寫好了多套主題，要使用的時候通過LESS一鍵切換。
行爲層（Javascript）
JavaScript 一門弱類型腳本語言，其源代碼在發往客戶端運行之前不需經過編譯，而是將文本格式的字符代碼發送給瀏覽器由瀏覽器解釋運行。
Native原生JS開發
原生JS開發，也就是讓我們按照ECMAScript標準的開發方式，簡稱是 ES，特點是支持所有瀏覽器。ES 標準已發佈如下版本：
- ES3
- ES4（內部，未正式發佈）
- ES5（全瀏覽器支持）
- ES6（常用，當前主流版本，webpack打包成爲ES5支持）
- ES7
- ES8
- ES9（草案階段）
從ES6開始每年發佈一個版本，以年份作爲名稱，區別就是逐步增加新特性。
微軟的標準：TypeScript
TypeScript 是一種由微軟開發的自由和開源的編程語言。它是 JavaScript 的一個超集，而且本質上向這個語言添加了可選的靜態類型和基於類的面向對象編程。由安德斯·海爾斯伯格（C#、Delphi、 TypeScript 之父，.NET創立者）主導。
Javascript框架
jQuery
大家最熟知的Javascript庫。優點是簡化了 DOM 操作，缺點是DOM 操作太頻繁，影響前端性能。在前端眼裏使用它僅僅是爲了兼容 IE6、7、8。
Angular
Google收購的前端框架，由一羣Java程序員開發，其特點是將後臺的MVC模式搬到了前端並增加了模塊化開發的理念，與微軟合作，採用TypeScript 語法開發。對後臺程序員友好，對前端程序員不太友好。最大的缺點是版本迭代不合理，如：1代 -> 2代，除了名字，基本就是兩個東西，已推出了Angular6。
React
Facebook出品，一款高性能的 JS 前端框架。特點是提出了新概念虛擬 DOM用於減少真實DOM操作，在內存中模擬DOM操作，有效的提升了前端渲染效率，缺點是使用複雜，因爲需要額外學習一門JSX語言。
Vue
一款漸進式Javascript 框架，所謂漸進式就是逐步實現新特性的意思，如實現模塊化開發、路由、狀態管理等新特性。
其特點是綜合了 Angular（模塊化） 和 React（虛擬 DOM） 的優點。
Axios
前端通信框架。因爲Vue 的邊界很明確，就是爲了處理 DOM，所以並不具備通信能力，此時就需要額外使用一個通信框架與服務器交互，當然也可以直接選擇使用jQuery提供的 AJAX 通信功能。
Javascript構建工具
- Babel：JS 編譯工具，主要用於瀏覽器不支持的 ES 新特性，比如用於編譯TypeScript。
- WebPack：模塊打包器，主要作用是打包、壓縮、合併及按序加載。
前端需要掌握的後端技術
前端人員爲了方便開發也需要掌握一定的後端技術，但Java 後臺人員知道後臺知識體系極其龐大複雜，所以爲了方便前端人員開發後臺應用，就出現了Node.js這樣的技術。
Node.js的作者已經聲稱放棄 Node.js（可能是因爲架構做的不好再加上笨重的 node_modules讓作者不爽了），並且開始開發全新架構的Deno。
既然是後臺技術，那肯定也需要框架和項目管理工具，Node.js框架及項目管理工具如下：
- Express：Node.js框架。
- Koa：Express簡化版。
- NPM：項目綜合管理工具，類似於Maven。
- YARN：NPM的替代方案，類似於Maven和Gradle的關係。
UI框架
常用框架
- Ant-Design：阿里巴巴出品，基於 React 的 UI 框架。
- ElementUI、iview、ice：餓了麼出品，基於 Vue 的 UI 框架。
- Bootstrap：Twitter 推出的一個用於前端開發的開源工具包。
- AmazeUI：又叫“妹子 UI”，一款 HTML5 跨屏前端框架。
- Layui：輕量級框架（Layer）。
iView
iView是一個強大的基於 Vue 的 UI 庫，有很多實用的基礎組件比ElementUI的組件更豐富，主要服務於PC界面的中後臺產品。使用單文件的Vue組件化開發模式，基於npm + webpack + babel開發，支持ES2015（ES6）高質量、功能豐富、友好的 API ，自由靈活地使用空間。
官網地址： https://www.iviewui.com/
Github： https://github.com/TalkingData/iview-weapp
iview-admin： https://github.com/iview/iview-admin
備註：屬於前端主流框架，選型時可考慮使用，主要特點是移動端支持較多。
ElementUI
ElementUI是餓了麼前端開源維護的Vue UI組件庫，組件齊全，基本涵蓋後臺所需的所有組件，文檔講解詳細，例子也很豐富。主要用於開發PC端的頁面，是一個質量比較高的Vue UI組件庫。
官網地址：http://element-cn.eleme.io/#/zh-CN
Github：https://github.com/ElementUI/element-starter
vue-element-admin：https://github.com/PanJiaChen/vue-element-admin
備註：屬於前端主流框架，選型時可考慮使用，主要特點是桌面端支持較多。
ICE
飛冰是阿里巴巴團隊基於React/Angular/Vue 的中後臺應用解決方案，在阿里巴巴內部，已經有270多個來自幾乎所有BU 的項目在使用。飛冰包含了一條從設計端到開發端的完整鏈路，幫助用戶快速搭建屬於自己的中後臺應用。
官網地址：https://alibaba.github.io/ice
Github：https://github.com/alibaba/ice
備註：主要組件還是以React 爲主，截止2019年2月17日更新博客前對 Vue 的支持還不太完善，目前尚處於觀望階段。
VantUI
VantUI是有贊前端團隊基於有贊統一的規範實現的Vue組件庫，提供了一整套UI基礎組件和業務組件。通過VantUI，可以快速搭建出風格統一的頁面，提升開發效率。
官網地址：https://youzan.github.io/vant/#/zh-CN/intro
Github：https://github.com/youzan
AtUI
AtUI是一款基於Vue 2.x的前端UI組件庫，主要用於快速開發PC網站產品。 它提供了一套npm + webpack + babel前端開發工作流程，CSS樣式獨立，即使採用不同的框架實現都能保持統一的UI風格。
官網地址：https://at-ui.github.io/at-ui/#/zh
Github：https://github.com/at-ui/at-ui
CubeUI
CubeUI是滴滴團隊開發的基於Vue.js實現的精緻移動端組件庫。支持按需引入和後編譯，輕量靈活，擴展性強，可以方便地基於現有組件實現二次開發。
官網地址：https://didi.github.io/cube-ui/#/zh-CN
Github：https://github.com/didi/cube-ui/
Flutter
Flutter是谷歌的移動端UI框架，可在極短的時間內構建Android和iOS上高質量的原生級應用。Flutter可與現有代碼一起工作, 它被世界各地的開發者和組織使用, 並且Flutter是免費和開源的。
官網地址：https://flutter.dev/docs
Github：https://github.com/flutter/flutter
備註：Google出品，主要特點是快速構建原生APP應用程序，如做混合應用該框架爲必選框架。
Ionic
Ionic 既是一個CSS框架也是一個Javascript UI庫，Ionic是目前最有潛力的一款HTML5手機應用開發框架。通過SASS構建應用程序，它提供了很多UI組件來幫助開發者開發強大的應用。它使用Javascript MVVM框架和AngularJS/Vue來增強應用。提供數據的雙向綁定，使用它成爲Web和移動開發者的共同選擇。
官網地址：https://ionicframework.com/
官網文檔：https://ionicframework.com/docs/
Github：https://github.com/ionic-team/ionic
mpvue
mpvue 是美團開發的一個使用Vue.js開發小程序的前端框架，目前支持微信小程序、百度智能小程序，頭條小程序和支付寶小程序。 框架基於Vue.js，修改了的運行時框架runtime 和代碼編譯器compiler實現，使其可運行在小程序環境中，從而爲小程序開發引入了Vue.js開發體驗。
官網地址：http://mpvue.com/
Github：https://github.com/Meituan-Dianping/mpvue
備註：完備的Vue開發體驗，並且支持多平臺的小程序開發，推薦使用。
WeUI
WeUI是一套同微信原生視覺體驗一致的基礎樣式庫，由微信官方設計團隊爲微信內網頁和微信小程序量身設計，令用戶的使用感知更加統一。包含 button、cell、dialog、toast、article、icon 等各式元素。
官網地址：https://weui.io/
Github：https://github.com/weui/weui.git
注：以上知識點已將 WebApp 開發所需技能全部梳理完畢。
前後端分離的演變史
後端爲主的MVC時代
爲了降低開發的複雜度，以後端爲出發點，比如：Struts、SpringMVC 等框架的使用，就是後端的 MVC時代。
以SpringMVC流程爲例，其運行流程如下圖所示。
- 用戶發送請求到前端控制器
DispatcherServlet。 - 前端控制器請求
HandlerMapping查找Handler，可以根據xml配置、註解進行查找。 - 處理器映射器
HandlerMapping向前端控制器返回Handler。 - 前端控制器調用處理器適配器去執行
Handler。 - 處理器適配器去執行
Handler。 Handler執行完成給適配器返回ModelAndView。- 處理器適配器向前端控制器返回
ModelAndView，ModelAndView是SpringMVC框架的一個底層對象，包括Model和View。 - 前端控制器請求視圖解析器去對視圖進行解析，根據邏輯視圖名解析成真正的視圖（
JSP）。 - 視圖解析器向前端控制器返回
View。 - 前端控制器進行視圖渲染，視圖渲染將模型數據（在
ModelAndView對象中）填充到request域。 - 前端控制器向用戶響應結果。
優點
MVC 是一個非常好的協作模式，能夠有效降低代碼的耦合度，從架構上能夠讓開發者明白代碼應該寫在哪裏。爲了讓 View 更純粹，還可以使用 Thymeleaf、Freemarker 等模板引擎，使模板裏無法寫入Java代碼，讓前後端分工更加清晰。
缺點
- 前端開發重度依賴開發環境，開發效率低
這種架構下，前後端協作有兩種模式：
1、第一種是前端寫DEMO，寫好後，讓後端去套模板。好處是DEMO可以本地開發，很高效。不足是還需要後端套模板，有可能套錯，套完後還需要前端確定，來回溝通調整的成本比較大。
2、另一種協作模式是前端負責瀏覽器端的所有開發和服務器端的View 層模板開發。好處是 UI 相關的代碼都是前端去寫就好，後端不用太關注，不足就是前端開發重度綁定後端環境，環境成爲影響前端開發效率的重要因素。 - 前後端職責糾纏不清
模板引擎功能強大，依舊可以通過拿到的上下文變量來實現各種業務邏輯。這樣，只要前端弱勢一點，往往就會被後端要求在模板層寫出不少業務代碼。還有一個很大的灰色地帶是Controller ，頁面路由等功能本應該是前端最關注的，但卻是由後端來實現。 Controller 本身與 Model 往往也會糾纏不清，業務代碼經常會出現在 Controller 層。 - 對前端發揮的侷限性
性能優化如果只在前端做空間非常有限，於是我們經常需要和後端合作。
注：在這期間（2005 年以前），包括早期的 JSP、PHP 可以稱之爲 Web 1.0 時代。
基於Ajax帶來的SPA時代
2005年Ajax（Asynchronous JavaScript And XML，異步 JavaScript 和 XML，老技術新用法）被正式提出並開始使用 CDN 作爲靜態資源存儲，於是出現了JavaScript 王者歸來（在這之前JS 都是用來在網頁上貼狗皮膏藥廣告的）的 SPA（Single Page Application）單頁面應用時代。
Ajax的運行原理如下圖所示。
優點
這種模式下，前後端的分工非常清晰，前後端的關鍵協作點是 Ajax接口。看起來是如此美妙，但回過頭來看看的話，這與 JSP 時代區別不大。複雜度從服務端的JSP裏移到了瀏覽器的 Javascript，瀏覽器端變得很複雜。類似 Spring MVC，這個時代開始出現瀏覽器端的分層架構，其架構如下圖所示。
缺點
- 前後端接口的約定
如果後端的接口一塌糊塗或者業務模型不夠穩定，那麼前端開發會很痛苦。不少團隊也有類似嘗試，通過接口規則、接口平臺等方式來做。有了和後端一起沉澱的接口規則，還可以用來模擬數據，使得前後端可以在約定接口後實現高效並行開發。 - 前端開發的複雜度控制
SPA 應用大多以功能交互型爲主，JavaScript 代碼過十萬行很正常。大量JS 代碼的組織，與 View 層的綁定等，都比較複雜。
前端爲主的MV*時代
這裏的MV*模式主要指的是以下三種模式：
- MVC（同步通信爲主）：Model、View、Controller
- MVP（異步通信爲主）：Model、View、Presenter
- MVVM（異步通信爲主）：Model、View、ViewModel
爲了降低前端開發複雜度，涌現了大量的前端框架，比如： AngularJS 、 React 、 Vue.js 、 EmberJS 等，這些框架總的原則是先按類型分層，比如 Templates、Controllers、Models，然後再在層內做切分，如下圖所示。
優點
- 前後端職責很清晰
前端工作在瀏覽器端，後端工作在服務端。清晰的分工，可以讓開發並行，測試數據的模擬不難。前端可以本地開發，後端則可以專注於業務邏輯的處理，輸出 RESTful等接口。 - 前端開發的複雜度可控
前端代碼很重，但合理的分層，讓前後端代碼能各司其職。 - 部署相對獨立
可以快速改進產品體驗。
缺點
- 代碼不能複用。比如後端依舊需要對數據做各種校驗，校驗邏輯無法複用瀏覽器端的代碼。
- 全異步，對 SEO 不利。往往還需要服務端做同步渲染的降級方案。
- 性能並非最佳，特別是移動互聯網環境下。
- SPA 不能滿足所有需求，依舊存在大量多頁面應用。URL Design 需要後端配合，前端無法完全掌控。
Node.js帶來的全棧時代
前端爲主的 MV* 模式解決了很多很多問題，但如上所述，依舊存在不少不足之處。隨着 Node.js 的興起，Javascript 開始有能力運行在服務端，這意味着可以有一種新的研發模式，如下圖所示。
在這種研發模式下，前後端的職責很清晰。對前端來說，兩個 UI 層各司其職：
- Front-end UI layer處理瀏覽器層的展現邏輯。通過 CSS 渲染樣式，通過Javascript 添加交互功能，HTML 的生成也可以放在這層，依據應用場景而定。
- Back-end UI layer處理路由、模板、數據獲取、Cookie 等。通過路由，前端終於可以自主把控URL Design，這樣無論是單頁面應用還是多頁面應用，前端都可以自由調控。後端也終於可以擺脫對展現的強關注，轉而可以專心於業務邏輯層的開發。
通過 Node.js，Web Server 層也是 Javascript 代碼，這意味着部分代碼可前後複用，需要 SEO 的場景可以在服務端同步渲染，由於異步請求太多導致的性能問題也可以通過服務端來緩解。前一種模式的不足，通過這種模式也能完美解決。
與 JSP 模式相比，全棧模式是一種向原始開發模式的迴歸，不過是一種螺旋上升式的迴歸。
基於 NodeJS 的全棧模式，依舊面臨很多挑戰：
- 需要前端對服務端編程有更進一步的認識。比如 TCP/IP 等網絡知識的掌握。
- NodeJS 層與 Java 層的高效通信。Node.js模式下，都在服務器端，RESTful HTTP 通信未必高效，通過 SOAP 等方式通信更高效。一切需要在驗證中前行。
- 對部署、運維層面的熟練了解，需要更多知識點和實操經驗。
- 大量歷史遺留問題如何過渡？這可能是最大最大的阻力。
小結
綜上所述，不管是模式還是技術，沒有好壞優劣之分，只有適合不適合。前後分離的開發思想主要是基於 SoC （關注度分離原則），以上提到的種種模式，都是爲了讓前後端的職責更清晰，分工更合理高效。