前端基礎(chǔ)架構(gòu)和硬核介紹

技術(shù)棧的選擇

首先我們構(gòu)建前端架構(gòu)需要對前端生態(tài)圈有一切了解，并且最好帶有一定的技術(shù)前瞻性，好的技術(shù)架構(gòu)可能日后會方便的擴(kuò)展，減少重構(gòu)的次數(shù)，即使重構(gòu)也不需要大動(dòng)干戈，我通常選型技術(shù)棧會參考以下三點(diǎn)：

一、提出自身業(yè)務(wù)的需求

• SEO 是否非常重要？
• 主要面向：移動(dòng)端還是 pc 端？
• 是否有開發(fā) app 的規(guī)劃？

有了這樣的問題我們可以帶著問題去重點(diǎn)選型一些這寫問題技術(shù)方案比較成熟的技術(shù)棧。

二、自身是否成熟，文檔是否友好

這里舉一個(gè)以前開發(fā)過程中實(shí)際遇到的，當(dāng)時(shí)為了優(yōu)化用戶體驗(yàn)，節(jié)省開發(fā)效率 選型了一款 MVVM 輕量框架，可惜當(dāng)時(shí)沒有決定權(quán)，CTO 選型了 avalon

當(dāng)時(shí)之所以沒有選擇 backbone ，主要是因?yàn)闆]有成熟的中文文檔，考慮到團(tuán)隊(duì)的流動(dòng)性和上手性暫時(shí)沒做考慮，最終選擇了 司徒正美的 avalon 當(dāng)時(shí)來說還是比較前衛(wèi)的，也有一些以去哪網(wǎng)為首的大公司都在用。我們當(dāng)時(shí)用的時(shí)候 avalon2 剛出不久，直接用的 2.0，使用過程也出現(xiàn)了一點(diǎn)問題：文檔離散，這一塊那一塊，存在后置性，生態(tài)少，擴(kuò)展性價(jià)比不高 ，有時(shí)候遇到匪夷所思的 bug 尋找原因翻了幾遍 demo 、文檔 可能會找到答案，沒有重點(diǎn)標(biāo)識。當(dāng)然就當(dāng)時(shí)來說確實(shí)是給我們提升了部分開發(fā)效率，但是我可能當(dāng)時(shí)更偏向 Angular 或 vue 的。因?yàn)樗麄冇袩o以倫比的生態(tài)圈和各種問題的技術(shù)方案以以及完善的開發(fā)者文檔，值得一提的是 avalon 的作者是兼職維護(hù)的，如果全棧運(yùn)營的話，我相信遠(yuǎn)比現(xiàn)在更好，看一看 avalon 的源碼也會對自己有不少的提升。對于生產(chǎn)的技術(shù)選型要更加謹(jǐn)慎。

三、了解其生態(tài)系統(tǒng)

上文提到了生態(tài)系統(tǒng)，以我比較常用的 vue 來舉例，vue 發(fā)展至今僅官方為我們提供了以 vuex、 vue-router、 vue-loader、 vue-cli、 vuepress、 vue-devtools、 vue-ssr 為首的 89 個(gè)開源項(xiàng)目，包括無數(shù)的 vue 相關(guān)的 UI 庫，vue 插件 甚至是近兩年淘寶提供的 Hybrid ： weex 的支持

截止今天 github 開源的 與 vue 相關(guān)的項(xiàng)目多達(dá) 167,752 個(gè)，與 angular 相關(guān)的多達(dá) 416,811 個(gè)，與 react 相關(guān)的 多達(dá) 594,272 個(gè)。

統(tǒng)計(jì)時(shí)間 2018-09-01

我想有了這樣的生態(tài)支持，完全可以滿足我們中小項(xiàng)目的 95% 以上的需求，至于比較哪個(gè)更強(qiáng)是沒有意義的 。

因?yàn)楸容^熟悉讓我斗膽私自選擇 vue 作為我們的 SPA 主架構(gòu)

四、畫出我們期望的前端基礎(chǔ)架構(gòu)模型

因?yàn)槲覀兩弦徽逻x型了 Vue，如果只考慮前端我們最初的想法:技術(shù)棧大概是這樣的：

通過 node 和 webpack 的支持 把 vue 組件 build 打包成傳統(tǒng)元素，發(fā)布到 http 服務(wù)中，請求后端服務(wù)。

隨后可能是這樣的：

隨著目前主流第三方庫的越來越多和技術(shù)的嘗鮮、客戶端的需求、或被動(dòng)[不得不用]、或主動(dòng)的去引用了 babel less sass *.loader 和 hybrid 等組件庫。

再后來的技術(shù)棧需要我們根據(jù)真正踩坑之后才會逐步完善

可能是 polyfill 懶加載 xss protobuf 等 針對 瀏覽器兼容、速度優(yōu)化、 SEO 、通信協(xié)議 等具體問題。所以，前期可以不用過多考慮，我們只要知道：這個(gè)問題我們是可以解決的，但是現(xiàn)在可以先不去考慮，有些同學(xué)，太過于“完美主義”以至于想法不錯(cuò)，但動(dòng)起手來做了幾天就不做了，完美主義害死人。

了解 Webpack

WebPack 可以看做是模塊打包機(jī)器，它可以分析你的項(xiàng)目結(jié)構(gòu)，找到 JavaScript 模塊以及其它的一些瀏覽器不能直接運(yùn)行的拓展語言：Stylus、Scss、less、TypeScript、CoffeeScript 等，并將其轉(zhuǎn)換和打包為合適的格式供瀏覽器使用。比較常用的還可以通過 webpack-dev-server 進(jìn)行開發(fā)模式的熱更新

WebPack 是一種模塊化開發(fā)的方案

當(dāng) webpack 處理應(yīng)用程序時(shí)，它會遞歸地構(gòu)建一個(gè)依賴關(guān)系圖(dependency graph)，其中包含應(yīng)用程序需要的每個(gè)模塊，然后將所有這些模塊打包成一個(gè)或多個(gè) bundle

webpack 通過 loader 可以支持各種語言和預(yù)處理器編寫模塊，最后打包為一個(gè)（或多個(gè)）瀏覽器可識別的 *JavaScript css * 文件

目前支持的 loader 列表

了解 ES6

官方說法

ECMAScript 6（簡稱ES6）是于2015年6月正式發(fā)布的JavaScript語言的標(biāo)準(zhǔn)，正式名為ECMAScript 2015（ES2015）。它的目標(biāo)是使得JavaScript語言可以用來編寫復(fù)雜的大型應(yīng)用程序.

科普

很多人總是搞不清楚 ES 這些東西，這里大白話講講： 他們的先后順序是：ES5、ES6(ES2015)、ES7、ES8

在 2015 年 6 月 ES6 的第一個(gè)版本發(fā)布， 正式名稱就是 《ECMAScript 2015 標(biāo)準(zhǔn)》（簡稱 ES2015）算是 2011 年 ECMAScript 5.1 之后的 6.0版本 2016 年 6 月，小幅修訂的《ECMAScript 2016 標(biāo)準(zhǔn)》（簡稱 ES2016）[因?yàn)楦膭?dòng)小，其實(shí)他是 6.1 版本，但總有人愿意叫它 ES7 ，不標(biāo)準(zhǔn)的] 2017 年 6 月發(fā)布 的《ECMAScript 2017 標(biāo)準(zhǔn)》（簡稱 ES2017） [因?yàn)楦膭?dòng)小，其實(shí)他是 6.2 版本，但總有人愿意叫它 ES8 ，不標(biāo)準(zhǔn)的]

就像 Kubernetes 人們開他起了一個(gè) K8S 的名字 (K 和 S 中間有 8 個(gè)單詞)，他是不標(biāo)準(zhǔn)的

了解 Babel Traceur

Babel、Traceur 是一個(gè)編譯JavaScript的平臺，它可以編譯代碼幫你達(dá)到以下目的：

JavaScript.next-to-JavaScript-of-today compiler

今天就使用未來的 JavaScript

截止發(fā)布日期 (2018-09-04) ，沒有一款完全支持ES6的JavaScript代理（無論是瀏覽器環(huán)境還是服務(wù)器環(huán)境），所以熱衷于使用語言最新特性的開發(fā)者需要將ES6代碼轉(zhuǎn)譯為ES5代碼。

讓你能使用最新的JavaScript代碼（ES6，ES7...），而不用管新標(biāo)準(zhǔn)是否被當(dāng)前使用的瀏覽器完全支持；

ES7 作者完全沒精力看 ，不過 Bable 逐漸替代了 Google 的 Traceur 成為主流了，我是個(gè)俗人，所以我選 Bable

了解 Sass Less Stylus

Sass 是不是違反了中國的廣告法了？？

Sass 、Stylus 和 Less 之類的預(yù)處理器是對原生CSS的拓展，它們允許你使用類似于variables, nesting, mixins, inheritance等不存在于CSS中的特性來寫CSS，CSS預(yù)處理器可以這些特殊類型的語句轉(zhuǎn)化為瀏覽器可識別的CSS語句。

• 一張表格對比三語言

語言實(shí)現(xiàn)特性賦值縮進(jìn)

Sass	Ruby	變量$開頭	$var: value	不需要
Less	JavaSript	變量@開頭	@var: value	不需要
Stylus	NodeJs	不能使用@開頭	var:10	都可以

你現(xiàn)在可能都已經(jīng)熟悉了，上文講 WebPack 講過： webpack 里使用相關(guān) loaders 進(jìn)行配置就可以使用了，以下是常用的CSS 處理loaders:

Less Loader Sass Loader Stylus Loader

自己去找：loader 列表

像：哪種語言更好、使用的更多、更簡單 容易引起爭議的 博主不想討論，看自己喜好

了解 Electron

一個(gè)可以使用使用： JavaScript, HTML 和 CSS 構(gòu)建跨平臺的桌面應(yīng)用的框架，也算 hybrid 的一種，主要場景是 PC 端，沒啥好說的。

值得一提的是 Visual Studio Code 、Atom、GIthub Desktop 都是基于此構(gòu)建的，有時(shí)候按 CMD option i 有驚喜哦

基于 Electron 開發(fā)的APP列表

總結(jié)

這些也就基本是前端比較常用的主流技術(shù)棧組成的骨架了，之后的各種 webpack 插件，各種工具庫的選型隨著項(xiàng)目實(shí)戰(zhàn)引入更好，現(xiàn)在講大家也記不住。

別急實(shí)戰(zhàn)中的前端架構(gòu)要比現(xiàn)在復(fù)雜得多，跟我一起循序漸進(jìn)的的來。

下一章為大家實(shí)戰(zhàn)：《如何快速構(gòu)建項(xiàng)目并升級為一個(gè)規(guī)范的前端骨架》

關(guān)于我

• 目前在寫《從零構(gòu)建前后分離項(xiàng)目》系列，修正和補(bǔ)充以此為準(zhǔn)

• 不斷更新的 項(xiàng)目實(shí)踐地址

往期文章

《從零構(gòu)建前后分離 WEB 項(xiàng)目》 序 - 開源的意義

《從零構(gòu)建前后分離web項(xiàng)目》：開篇 - 縱觀WEB歷史演變

《從零構(gòu)建前后分離web項(xiàng)目》探究 - 深入聊聊前后分離架構(gòu)

《從零構(gòu)建前后分離web項(xiàng)目》準(zhǔn)備 - 前端了解過關(guān)了嗎？前端基礎(chǔ)架構(gòu)和技術(shù)介紹

總結(jié)

以上是生活随笔為你收集整理的《从零构建前后分离的web项目》准备 - 前端了解过关了吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。