資訊專欄INFORMATION COLUMN
摘要：前端準備前端了解過關了嗎前端基礎架構和硬核介紹技術棧的選擇首先我們構建前端架構需要對前端生態圈有一切了解，并且最好帶有一定的技術前瞻性，好的技術架構可能日后會方便的擴展，減少重構的次數，即使重構也不需要大動干戈，我通常選型技術棧會參考以下三
# 前端準備 ：前端了解過關了嗎？前端基礎架構和硬核介紹
技術棧的選擇首先我們構建前端架構需要對前端生態圈有一切了解，并且最好帶有一定的技術前瞻性，好的技術架構可能日后會方便的擴展，減少重構的次數，即使重構也不需要大動干戈，我通常選型技術棧會參考以下三點：
一、提出自身業務的需求SEO 是否非常重要？
主要面向：移動端還是 pc 端？
是否有開發 app 的規劃？
有了這樣的問題我們可以帶著問題去重點選型一些這寫問題技術方案比較成熟的技術棧。
二、自身是否成熟，文檔是否友好這里舉一個以前開發過程中實際遇到的，當時為了優化用戶體驗，節省開發效率 選型了一款 MVVM 輕量框架，可惜當時沒有決定權，CTO 選型了 avalon
當時之所以沒有選擇 backbone ，主要是因為沒有成熟的中文文檔，考慮到團隊的流動性和上手性暫時沒做考慮，最終選擇了 司徒正美的 avalon 當時來說還是比較前衛的，也有一些以去哪網為首的大公司都在用。我們當時用的時候 avalon2 剛出不久，直接用的 2.0，使用過程也出現了一點問題：文檔離散，這一塊那一塊，存在后置性，生態少，擴展性價比不高 ，有時候遇到匪夷所思的 bug 尋找原因翻了幾遍 demo 、文檔 可能會找到答案，沒有重點標識。當然就當時來說確實是給我們提升了部分開發效率，但是我可能當時更偏向 Angular 或 vue 的。因為他們有無以倫比的生態圈和各種問題的技術方案以以及完善的開發者文檔，值得一提的是 avalon 的作者是兼職維護的，如果全棧運營的話，我相信遠比現在更好，看一看 avalon 的源碼也會對自己有不少的提升。對于生產的技術選型要更加謹慎。
三、了解其生態系統上文提到了生態系統，以我比較常用的 vue 來舉例，vue 發展至今僅官方為我們提供了以 vuex、 vue-router、 vue-loader、 vue-cli、 vuepress、 vue-devtools、 vue-ssr 為首的 89 個開源項目，包括無數的 vue 相關的 UI 庫，vue 插件 甚至是近兩年淘寶提供的 Hybrid ： weex 的支持
截止今天 github 開源的 與 vue 相關的項目多達 167,752 個，與 angular 相關的多達 416,811 個，與 react 相關的 多達 594,272 個。
統計時間 2018-09-01
我想有了這樣的生態支持，完全可以滿足我們中小項目的 95% 以上的需求，至于比較哪個更強是沒有意義的 。
因為比較熟悉讓我斗膽私自選擇 vue 作為我們的 SPA 主架構
四、畫出我們期望的前端基礎架構模型因為我們上一章選型了 Vue，如果只考慮前端我們最初的想法:技術棧大概是這樣的：
通過 node 和 webpack 的支持 把 vue 組件 build 打包成傳統元素，發布到 http 服務中，請求后端服務。
隨后可能是這樣的：
隨著目前主流第三方庫的越來越多和技術的嘗鮮、客戶端的需求、或被動[不得不用]、或主動的去引用了 babel less sass *.loader 和 hybrid 等組件庫。
再后來的技術棧需要我們根據真正踩坑之后才會逐步完善
可能是 polyfill 懶加載 xss protobuf 等 針對 瀏覽器兼容、速度優化、 SEO 、通信協議 等具體問題。所以，前期可以不用過多考慮，我們只要知道：這個問題我們是可以解決的，但是現在可以先不去考慮，有些同學，太過于“完美主義”以至于想法不錯，但動起手來做了幾天就不做了，完美主義害死人。
了解 WebpackWebPack 可以看做是模塊打包機器，它可以分析你的項目結構，找到 JavaScript 模塊以及其它的一些瀏覽器不能直接運行的拓展語言：Stylus、Scss、less、TypeScript、CoffeeScript 等，并將其轉換和打包為合適的格式供瀏覽器使用。比較常用的還可以通過 webpack-dev-server 進行開發模式的熱更新
WebPack 是一種模塊化開發的方案
當 webpack 處理應用程序時，它會遞歸地構建一個依賴關系圖(dependency graph)，其中包含應用程序需要的每個模塊，然后將所有這些模塊打包成一個或多個 bundle
webpack 通過 loader 可以支持各種語言和預處理器編寫模塊，最后打包為一個（或多個）瀏覽器可識別的 JavaScript css 文件
目前支持的 loader 列表
了解 ES6 官方說法ECMAScript 6（簡稱ES6）是于2015年6月正式發布的JavaScript語言的標準，正式名為ECMAScript 2015（ES2015）。它的目標是使得JavaScript語言可以用來編寫復雜的大型應用程序.
科普很多人總是搞不清楚 ES 這些東西，這里大白話講講：
他們的先后順序是：ES5、ES6(ES2015)、ES7、ES8
在 2015 年 6 月 ES6 的第一個版本發布， 正式名稱就是 《ECMAScript 2015 標準》（簡稱 ES2015）算是 2011 年 ECMAScript 5.1 之后的 6.0版本
2016 年 6 月，小幅修訂的《ECMAScript 2016 標準》（簡稱 ES2016）[因為改動小，其實他是 6.1 版本，但總有人愿意叫它 ES7 ，不標準的]
2017 年 6 月發布 的《ECMAScript 2017 標準》（簡稱 ES2017） [因為改動小，其實他是 6.2 版本，但總有人愿意叫它 ES8 ，不標準的]
就像 Kubernetes 人們開他起了一個 K8S 的名字 (K 和 S 中間有 8 個單詞)，他是不標準的
了解 Babel TraceurBabel、Traceur 是一個編譯JavaScript的平臺，它可以編譯代碼幫你達到以下目的：
JavaScript.next-to-JavaScript-of-today compiler
今天就使用未來的 JavaScript
截止發布日期 (2018-09-04) ，沒有一款完全支持ES6的JavaScript代理（無論是瀏覽器環境還是服務器環境），所以熱衷于使用語言最新特性的開發者需要將ES6代碼轉譯為ES5代碼。
讓你能使用最新的JavaScript代碼（ES6，ES7...），而不用管新標準是否被當前使用的瀏覽器完全支持；
ES7 作者完全沒精力看 ，不過 Bable 逐漸替代了 Google 的 Traceur 成為主流了，我是個俗人，所以我選 Bable了解 Sass Less Stylus
Sass 是不是違反了中國的廣告法了？？
Sass 、Stylus 和 Less 之類的預處理器是對原生CSS的拓展，它們允許你使用類似于variables, nesting, mixins, inheritance等不存在于CSS中的特性來寫CSS，CSS預處理器可以這些特殊類型的語句轉化為瀏覽器可識別的CSS語句。
一張表格對比三語言
| 語言 | 實現 | 特性 | 賦值 | 縮進 |
|---|---|---|---|---|
| Sass | Ruby | 變量$開頭 | $var: value | 不需要 |
| Less | JavaSript | 變量@開頭 | @var: value | 不需要 |
| Stylus | NodeJs | 不能使用@開頭 | var:10 | 都可以 |
你現在可能都已經熟悉了，上文講 WebPack 講過： webpack 里使用相關 loaders 進行配置就可以使用了，以下是常用的CSS 處理loaders:
Less Loader
Sass Loader
Stylus Loader
自己去找：loader 列表
像：哪種語言更好、使用的更多、更簡單 容易引起爭議的 博主不想討論，看自己喜好了解 Electron
一個可以使用使用： JavaScript, HTML 和 CSS 構建跨平臺的桌面應用的框架，也算 hybrid 的一種，主要場景是 PC 端，沒啥好說的。
值得一提的是 Visual Studio Code 、Atom、GIthub Desktop 都是基于此構建的，有時候按 CMD + option + i 有驚喜哦
基于 Electron 開發的APP列表
總結這些也就基本是前端比較常用的主流技術棧組成的骨架了，之后的各種 webpack 插件，各種工具庫的選型隨著項目實戰引入更好，現在講大家也記不住。
別急實戰中的前端架構要比現在復雜得多，跟我一起循序漸進的的來。
下一章為大家實戰：《如何快速構建項目并升級為一個規范的前端骨架》
關于我目前在寫《從零構建前后分離項目》系列，修正和補充以此為準
不斷更新的 項目實踐地址
往期文章《從零構建前后分離 WEB 項目》 序 - 開源的意義
《從零構建前后分離web項目》：開篇 - 縱觀WEB歷史演變
《從零構建前后分離web項目》探究 - 深入聊聊前后分離架構
《從零構建前后分離web項目》準備 - 前端了解過關了嗎？前端基礎架構和技術介紹
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/113868.html
摘要：前端準備前端了解過關了嗎前端基礎架構和硬核介紹技術棧的選擇首先我們構建前端架構需要對前端生態圈有一切了解，并且最好帶有一定的技術前瞻性，好的技術架構可能日后會方便的擴展，減少重構的次數，即使重構也不需要大動干戈，我通常選型技術棧會參考以下三 # 前端準備 ：前端了解過關了嗎？前端基礎架構和硬核介紹 showImg(https://segmentfault.com/img/remote/...
摘要：前端準備前端了解過關了嗎前端基礎架構和硬核介紹技術棧的選擇首先我們構建前端架構需要對前端生態圈有一切了解，并且最好帶有一定的技術前瞻性，好的技術架構可能日后會方便的擴展，減少重構的次數，即使重構也不需要大動干戈，我通常選型技術棧會參考以下三 # 前端準備 ：前端了解過關了嗎？前端基礎架構和硬核介紹 showImg(https://segmentfault.com/img/remote/...
摘要：前端基礎架構和硬核介紹技術棧的選擇首先我們構建前端架構需要對前端生態圈有一切了解，并且最好帶有一定的技術前瞻性，好的技術架構可能日后會方便的擴展，減少重構的次數，即使重構也不需要大動干戈，我通常選型技術棧會參考以下三點一提出自身業務的需求是 # 前端基礎架構和硬核介紹 showImg(https://segmentfault.com/img/remote/146000001626972...
摘要：前端基礎架構和硬核介紹技術棧的選擇首先我們構建前端架構需要對前端生態圈有一切了解，并且最好帶有一定的技術前瞻性，好的技術架構可能日后會方便的擴展，減少重構的次數，即使重構也不需要大動干戈，我通常選型技術棧會參考以下三點一提出自身業務的需求是 # 前端基礎架構和硬核介紹 showImg(https://segmentfault.com/img/remote/146000001626972...
摘要：可以使用或來安裝我用來重新嘗試一次對速度表示不理想的可以嘗試淘寶的不要過度依賴中可以寫成放哪都行，可以寫成可以寫成看到這個畫面，安裝完成了。 初步搭建腳手架 Tips 任何不錯的開源項目都有 project-cli 腳手架、我們用它生成往往能快速配制出最佳的、理想的腳手架 我通常使用 cli 生成項目骨架再在之基礎上進行個人修改。 什么是 CLI 命令行界面（英語：command-li...
閱讀 1428·2023-04-25 19:51
閱讀 1923·2019-08-30 15:55
閱讀 1736·2019-08-30 15:44
閱讀 2697·2019-08-30 13:58
閱讀 2689·2019-08-29 16:37
閱讀 1069·2019-08-29 15:34
閱讀 3988·2019-08-29 11:05
閱讀 2618·2019-08-28 17:51
