A. web前端動態網頁開發主流技術有哪些
目前主流的框架是:Vue、React、Angular三大框架。
2020年新增的開發有:小程序雲開發、react輕量級框架DvaJS和UmiJS、Vue企業級實戰項目與框架、Flutter、React-Native實戰項目。
框架詳解:
1.Angular
Angular原名angularJS誕生於2009年,之前我們都是用jquery開發,自從angular的出現讓我們有了新的選擇,它最大的特點是把後端的一些開發模式移植到前端來實現,如MVC、依賴注入等。
2.React
React,facebook出品,正式版推出是在2013年,比angular晚了4年,但得益於其創新式的VirtualDOM,性能上碾壓angularJS,一經推出,火的一塌糊塗。 特點很多,VirtualDOM、JSX、Diff演算法等,支持ES6語法,採用函數式編程,門檻稍高,但也更靈活,能讓開發具有更多可能性。
3.Vue
Vue作為最後推出的框架(2014年),借鑒了前輩angular和react的特點(如VirtualDOM、雙向數據綁定、diff演算法、響應式屬性、組件化開發等)並做了相關優化,使其使用起來更加方便,更容易上手,比較少適合初學者。
B. 前端技術棧有哪些
前端技術棧包括:1.vuejs 2.react.js 3.node.js 4.微信公眾號 5.前端安全 6.react-native 7.工程化 8.小程序 9.自動化測試等。
react的一些相關技術棧
React:用於構建用戶界面的 JavaScript 庫。
React Native:基於 React 的移動端跨平台 UI
Ant Design: React 封裝了一套 Ant Design 的組件庫。
Zarm React:移動端 React 組件庫
Taro:Taro 是一個開放式跨端跨框架解決方案,支持使用 React/Vue/Nerv 等框架來開發 微信 / 京東 / 網路 / 支付寶 / 位元組跳動 / QQ 小程序 / H5 等應用。
C. 前後端分離方案以及技術選型
作者:關開發
一.什麼是前後端分離?
理解前後端分離大概可以從3個方面理解:
1. 交互形式
2. 代碼組織形式
3. 開發模式與流程
1.1 交互形式
前後端不分離
後端將數據和頁面組裝、渲染好了之後,向瀏覽器輸出最終的html;瀏覽器接收到後會解析html,解析引入的css、執行js腳本,完成最終的頁面展示。
前後端分離
後端只需要和前端約定好接收以及返回的數據格式(一般用JSON格式),向前端提供API介面。前端就可以通過HTTP請求調用API的方式進行交互。前端獲取到數據後,進行頁面組裝、渲染,最終在瀏覽器呈現。
1.2 代碼組織形式
前後端不分離
在web應用早期的時候,前端頁面以及後台業務數據處理的代碼都放在一個工程下,甚至放在同一目錄下,前端頁面夾雜著後端代碼。前、後端開發工程師都需要把整套代碼導入開發工具才能開發。此階段下前後端代碼以及工作耦合度太高,前端不能獨立開發和測試,後端人員也要依賴前端完成頁面後才能完成開發。最糟糕的情況是前端工程師需要會後端模板技術(jsp),後端工程師還要會點前端技術,需要口頭說明頁面數據介面,才能配合完成開發。否則前端只能當一個「切圖仔」,只輸出HTML、CSS、以及很少量與業務邏輯無關的js;然後由後端轉化為後端jsp,並且還要寫業務的js代碼。
前後端分離
前後端代碼放在不同的工程下,前端代碼可以獨立開發,通過mock/easy-mock技術模擬後端API服務可以獨立運行、測試;後端代碼也可以獨立開發,運行、測試,通過swagger技術能自動生成API文檔供前端閱讀,還可以進行自動化介面測試,保證API的可用性,降低集成風險。
1.3 開發模式與流程
前後端不分離
在項目開發階段,前端根據原型和UI設計稿,編寫HTML、CSS以及少量與業務無關的js(純效果那些),完成後交給後台人員,後台人員將HTML轉為jsp,並通過JSP的模板語法進行數據綁定以及一些邏輯操作。後台完成後,將全部代碼打包,包含前端代碼、後端代碼打成一個war,然後部署到同一台伺服器運行。頂多做一下動靜分離,也就是把圖片、css、js分開部署到nginx。
具體開發流程如下:圖略
前後端分離
實現前後端分離之後,前端根據原型和UI設計稿編寫HTML、CSS以及少量與業務無關的js(純效果那些),後端也同時根據原型進行API設計,並與前端協定API數據規范。等到後台API完成,或僅僅是API數據規范設定完成之後。前端即可通過HTTP調用API,或通過mock數據完成數據組裝以及業務邏輯編寫。前後端可以並行,或者前端先行於後端開發了。
具體開發流程如下:圖略
二、前後端分離的好處與壞處。
從上面3個方面對比了之後,前後端分離架構和傳統的web架構相比,有很大的變化,看起來好處多多。到底是分還是不分,我們還是要理性分析是否值得才去做。
從目前應用軟體開發的發展趨勢來看,主要有兩方面需要注意:
· 越來越注重用戶體驗,隨著互聯網的發展,開始多終端化。
· 大型應用架構模式正在向雲化、微服務化發展。
我們主要通過前後端分離架構,為我們帶來以下四個方面的提升:
· 為優質產品打造精益團隊
通過將開發團隊前後端分離化,讓前後端工程師只需要專注於前端或後端的開發工作,是的前後端工程師實現自治,培養其獨特的技術特性,然後構建出一個全棧式的精益開發團隊。
· 提升開發效率
前後端分離以後,可以實現前後端代碼的解耦,只要前後端溝通約定好應用所需介面以及介面參數,便可以開始並行開發,無需等待對方的開發工作結束。與此同時,即使需求發生變更,只要介面與數據格式不變,後端開發人員就不需要修改代碼,只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
· 完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型,打造優秀的前後端團隊,開發獨立化,讓開發人員做到專注專精,開發能力必然會有所提升,能夠完美應對各種復雜多變的前端需求。
· 增強代碼可維護性
前後端分離後,應用的代碼不再是前後端混合,只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰,不論是代碼閱讀還是代碼維護都會比以前輕松。
那麼前後端分離有什麼不好的地方嗎?我目前是沒有想到,除非你說會增加前端團隊的配備,後端工程師會變的不全能。。。
二、前後端分離架構方案。
實現前後端分離,主要是前端的技術架構變化較大,後端主要變為restfull 風格API,然後加上Swagger技術自動生成在線介面文檔就差不多了。
對於目前用於前後端分離方案的前端技術架構主要有兩種:
· 傳統SPA
· 服務端渲染SSR
2.1 傳統SPA
傳統SPA指的是單頁面應用,也就是整個網站只有一個頁面,所有功能都通過這一個頁面來呈現。因為一個人的肉眼,某一個時間點看一個頁面,既然如此何必要不同功能做多個頁面呢?只保留一個頁面作為模板,然後通過路由跳轉來更新這個模板頁面的內容不就可以了嗎?確實如此,現在通過reac全家桶、tvue全家桶,模塊化、路由、wabpack等技術輕而易舉就能實現一個單頁面應用。
單頁面應用的運行流程
1.用戶通過瀏覽器訪問網站url
2.單頁面的html文件(index.html)被下載到瀏覽器,接著下載html裡面引用的css,js。
3.css,js下載到瀏覽器完成之後,瀏覽器開始解析執行js向後端服務非同步請求數據。
4.請求數據完成後,進行數據綁定、渲染,最終在用戶瀏覽器呈現完整的頁面。
2.2 服務端渲染
服務端渲染的方案指的是數據綁定,渲染等工作都放在服務端完成,服務端向瀏覽器輸出最終的html。大家看完這個是不是有個疑問,這不是又回到了前後端不分離的時代了嗎?答案是否定的,因為這里的服務端是用來執行前端數據綁定、渲染的,也就是把瀏覽器的一部分工作分擔到了服務端。而目前具備這只種能力的服務端是NodeJs服務端。
它的原理其實就是在瀏覽器與前端代碼中間插入了一個NodeJs服務端。瀏覽器請求前端頁面時,會先經過NodeJS服務端,由NodeJs去讀取前端頁面,並執行非同步後端API,獲取到數據後進行頁面數據綁定,渲染等工作,完成一個最終的html然後返回瀏覽器,最後瀏覽器進行展示。
服務端渲染應用的運行流程:
1.用戶通過瀏覽器訪問網站url
2.NodeJS服務端接收到請求,讀取到對應的前端html,css,js。
3.NodeJS解析執行js向後端API非同步請求數據。
4.NodeJs請求數據完成之後,進行數據綁定、渲染,得到一個最終的html。
5.NodeJs向瀏覽器輸出html,瀏覽器進行展示。
PS:其實本質就是把前端編寫成一個nodeJs的服務端web應用。實施服務端渲染後,我們最終運行的是一個Nodejs服務端應用。而單頁面應用是把靜態頁面部署到靜態資源伺服器進行運行。
看到這里,你是否又有疑問,為什麼要這么麻煩搞服務端渲染呢?
2.3 SPA與服務端渲染方案對比
SPA的優點是開發簡單,部署簡單;缺點是首次載入較慢,需要較好的網路,不友好的SEO。
so,以下就是使用服務端渲染的理由了(摘取vue官方說法):
與傳統 SPA (單頁應用程序 (Single-Page Application)) 相比,伺服器端渲染 (SSR) 的優勢主要在於:
· 更好的 SEO,由於搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。
請注意,截至目前,Google 和 Bing 可以很好對同步 JavaScript 應用程序進行索引。在這里,同步是關鍵。如果你的應用程序初始展示 loading 菊花圖,然後通過 Ajax 獲取內容,抓取工具並不會等待非同步完成後再行抓取頁面內容。也就是說,如果 SEO 對你的站點至關重要,而你的頁面又是非同步獲取內容,則你可能需要伺服器端渲染(SSR)解決此問題。
· 更快的內容到達時間 (time-to-content),特別是對於緩慢的網路情況或運行緩慢的設備。
無需等待所有的 JavaScript 都完成下載並執行,才顯示伺服器渲染的標記,所以你的用戶將會更快速地看到完整渲染的頁面。通常可以產生更好的用戶體驗,並且對於那些「內容到達時間(time-to-content) 與轉化率直接相關」的應用程序而言,伺服器端渲染 (SSR) 至關重要。
使用伺服器端渲染 (SSR) 時還需要有一些權衡之處:
· 開發條件所限。瀏覽器特定的代碼,只能在某些生命周期鉤子函數 (lifecycle hook) 中使用;一些外部擴展庫 (external library) 可能需要特殊處理,才能在伺服器渲染應用程序中運行。
· 涉及構建設置和部署的更多要求。與可以部署在任何靜態文件伺服器上的完全靜態單頁面應用程序 (SPA) 不同,伺服器渲染應用程序,需要處於 Node.js server 運行環境。
· 更多的伺服器端負載。在 Node.js 中渲染完整的應用程序,顯然會比僅僅提供靜態文件的 server 更加大量佔用 CPU 資源 (CPU-intensive - CPU 密集),因此如果你預料在高流量環境 (high traffic) 下使用,請准備相應的伺服器負載,並明智地採用緩存策略。
以vue為例,實施服務端渲染可以查看官方指南: https://ssr.vuejs.org ,或選擇Nuxt.js
2.4 預渲染技術
如果你調研伺服器端渲染 (SSR) 只是用來改善少數營銷頁面(例如 /, /about, /contact 等)的 SEO,那麼你可能需要預渲染。無需使用 web 伺服器實時動態編譯 HTML,而是使用預渲染方式,在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 文件。優點是設置預渲染更簡單,並可以將你的前端作為一個完全靜態的站點。
如果你使用 webpack,你可以使用 prerender-spa-plugin 輕松地添加預渲染。它已經被 Vue 應用程序廣泛測試 - 事實上,作者是 Vue 核心團隊的成員。
prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin
三、前後端分離技術選型
- artTemplate + bootstrap(不推薦, 不算完全前後端分離)
- vue全家桶(推薦)
- react全家桶 (推薦,生態全)