前端開發：如何寫一手漂亮的 Vue

前幾日聽到一句生猛與激勵並存，可怕與尷尬同在，最無奈也無解的話：“90後，你的中年危機已經殺到”。這令我很受觸動。顯然，這有些誇張了，但就目前這日復一日的庸碌下去，眨眼的功夫，那情形就會在這骨感的現實面前，悄然的被顯現。所以，越發體驗到，當必要有計劃的去做，去寫，去玩，去嗨，利用好這荷爾蒙分泌還算旺 ...

前幾日聽到一句生猛與激勵並存，可怕與尷尬同在，最無奈也無解的話：“90後，你的中年危機已經殺到”。這令我很受觸動。顯然，這有些誇張了，但就目前這日復一日的庸碌下去，眨眼的功夫，那情形就會在這骨感的現實面前，悄然的被顯現。所以，越發體驗到，當必要有計劃的去做，去寫，去玩，去嗨，利用好這荷爾蒙分泌還算旺盛的時光，去厚積去博取，去發現去折騰；讓自己的生命不在僅是工作與惆悵，還有時間分與“詩和遠方”。不用分析，就知道這該如何去做，高效去完成工作，然後去學著優雅地生而活。目前猶身為前端開發者，且在使用 Vue，那麼就有了此文；這不僅是紀錄或分享，也是在漫漫之路上下求索，更希望能探討和指點，以資見識，提升其效。

微註：早先在寫[如何優雅地使用Sublime Text]時候，前後歷經10月，至今雖不斷更新猶在，離該話題也是相去甚遠。所以，談及此一個寬廣話題的存在，欲一談也須深入研究，非朝夕可至；所以本篇將採取不定期更新，當然，這麼做，也是治療自身拖延症之一法子；另外也是限制聚合網抓取的一種嘗試。
更新：對於如何構建 VueJs 項目，自然推薦官方的腳手架 vue-cli
；而對於微小型項目，個人倒挺看好poi —— (Delightful web development)，它能讓你十分便捷的使用當前流行的框架（Vue React等）。即便如此呢，很多業界朋友，對 Vue 項目的構建，還是不盡如人意；鑒於此，有根據過往的些許經驗，設計出一套樣板 ——vue-boilerplate-template，以供參考，當然也期待朋友給予指正。其中已經依賴了vue-router
、vuex、 vue-i18n、 element-ui、 bootstrap 諸多庫；也註入了 webpack、 Eslint、 pre-commit等等便捷開發相關的庫。其中對與後臺介面調用與使用，vuex 的運用，視圖結構的塑造，路由和多語言的配置，公共方法的調度，webpack打包優化等等，都基於便捷開發的前提下，做了相應的設計，希望有緣人會喜歡；這一番設計緣由，得空會另起一篇文章予以闡明；而這番設計也會，在不斷的學習中持續改進，敬請期待

隨言: 身在程式的江湖，如你是一位即將出征武士，對決於浩瀚無盡的需求大軍；那麼你不僅需要一副好的體格，還需要一身技藝：而這軟體工程學
(抑或加演算法)就好比內功（查克拉）；而所使用的各家語言
，則好如武學招式（獨孤九劍？）；那加以利用的各種工具，當如隨身利器（小李飛刀？）；那屬於自己一套極致開發流程，便是輕功（電光神行步？）……如是斯言，那麼作為開發者的你，幾技傍身耶？
如上隨言，此篇準備從以下幾個方面來探討：

如何漂亮使用 Vue 之工具篇

欲先利其器，必先利其器，這是此博客一大倡導；關於如何優雅地去寫好 Vue，工具自是首當其衝要提及的，畢竟這非常重要；在你選擇使用 Vue 來從事前端開發的那一刻，你已經同意的這一論點：畢竟 Vue 也是用原生 Js 寫的，Js 則是用 C 語言寫，而 C 又是彙編寫的….. 這不再是刀耕火種的年代，而你也未用彙編或 C 來解決你的需求，So，你是同意的。既是贊同的，豈有不用好它的道理？那麼來一起探討下：

外設：除了那些舒適坐騎與書桌外，雙屏顯示器，Mac則是必備外設裝備；你知道，一屏編輯器中寫著代碼的同時，就能在另一屏 Chrome 下看到表現，這很高效便捷，也令人很是舒服。而 Mac 這設備中堪稱優雅情人的存在，更是居家良品。倘若，所處的工作環境沒那麼看重效率，或者未表現出該有的慷慨，則一定須善待自己的精力和時間，勇於將自己的開發環境打造精良。

軟體：身為開發人員，你電腦以及其中配備的軟體，就好如武士手中的利劍，是助你大殺四方的存在；所以無論是用它來玩一玩惡作劇，還是來致敬把Dota，抑或是搞搞需求，皆十分有必要將其鋒利化。因此，諸如 Alfred，Brew，Iterm2，Oh-my-zh，Git等必備就不說了；對於前端開發，編輯器與瀏覽器的配備與運用，尤其重要（對於這一點很多前端開發者，尚未達到及格，一如其水平）；對於瀏覽器，只推薦Chrome，不只是瀏覽或者調試，更在於其搜索。而編輯器則推薦 SublimeText3與 Atom；VsCode也很棒的存在，寫前端後臺都十分趁手(目測 Google 也都力推之)；不太推薦使用 WebStorm，因為其除了反人類的操作設計外，感受不到其他可記住點。

周邊：使用 Vue 開發開發前端，當須保持對周邊工具體系，經常保持關註，比如Node，Npm(Yarn)，Webpack，Gulp等，以及Lodash，superagent，d3等工具庫，再有就是 Vue 系本身具庫，譬如Vue-cli, vue-router等輔助；再有就是不斷衍生出來的 Vue 插件擴展。Atwood定律中闡述到：Any application that can be written in JavaScript, will eventually be written in JavaScript.(翻譯過來即是：凡是能用JavaScript寫出來的，最終都會用JavaScript寫出來)。這個理論同樣適用於 Vue，它簡易強大的存在，吸引了很多超厲害的開發者或團隊，為其貢獻了無數好用的組件庫。比如: 餓了麽出品的Element-UI，還有 vue-echarts，vue-multiselect …… 具體可以參看awesome-vue，略睹其繁華似錦。

（web前端學習交流群：328058344 禁止閑聊，非喜勿進！）

如何漂亮使用-Vue-之基礎篇)如何漂亮使用 Vue 之基礎篇

軟體工程學，作為程式員，本就該是當學好的一門技藝。像[代碼大全2]以及[程式整潔之道]，一定是需要好好讀一讀的。Web 前端開發，因其入門的容易性(還有需求的旺盛)，造就了這一行涌進了不少急功近利者，也驚現了很多令人“不堪卒讀”的代碼。而前端發展日新月異，如不能漸而掌握，長期來看，委屈的倒也不全是別人(讀你代碼者)，更是自己；舉個淺顯的例子來講，如不能學會很好的組織代碼結構，即便有高手寫了架構，一旦項目漸大，不也是照樣面臨被自己坑苦的凄楚？事實上，不乏很多開發者，未能養成很好的編碼素養，基礎如變數方法命名，也是能令人心驚肝顫；很顯然這是損人不利己的行為，勢必當善之。

對於團隊來講，Eslint實在是需要配備的利器；既然難以保證每個人都很有素養，那麼必須適當強制；至少避免了叢生些雜亂不堪的代碼，以亂軍心。當然，使用伊始，總會有些人不太適應，所以玩轉編輯器的重要性，就再次體現出其價值了；由此也引出了自動化(半)工作流的話題了，這在之後的內容中會加以探討。

前端基礎技術，從事前端開發，長久之計來看，基本功是非常重要的；尤其是 JavaScript；這在寫 Vue 時候，也體現的比較明顯。其他如 Html，Css，自然不用說；除此之外，Scss 等預處理器，也是當學習並加以運用，以提升開發效率，節省開發成本；畢竟只有節省出充裕的時間來，才會去做更多優化，節約出更多精力與時間，一個優良的迴圈就此得以形成。

Vue 基礎，這一點很重要，熟讀[Vue.js 官方教程]，再沒有比這更好的教程了；根據之前經驗來看，心急是吃不到熱豆腐的，欠下的也終究得還；至少起初需通讀之，否則遇到問題，無法及時定位出在哪兒查究，這無疑會浪費更多時間。除此之外，Github 上找一份好的微型項目，認真讀下，可以發掘出很多值得學習的玩法。

善用配置，《代碼大全》第 18 章，講到表驅動法（Table-Driven Methods），對於編程從業者，很有必要一讀。很多時候，可藉助查詢表來加以簡化邏輯和繼承樹關係。這在團隊協作，分模塊開發模式具有更非凡價值；應該善用配置，將各個模塊予以抽離，使得相互間不存強依賴，如此開發環節也大大的避免代碼衝突。譬如，瞭解 JavaScript 特性，即可做如下寫法：

const files = require.context('.', true, /\.svg$/)
const modules = {}
files.keys().forEach((key) => {
  if (key === './index.js') return
  modules[key.replace(/(\.\/|\.svg)/g, '')] = files(key)
})
export default modules

這樣即可寫出便捷的 [Icon Component]，使用時只需添加新 Svg 入 assets，然後引用 icon 時填寫對應 Svg 名字即可，十分方便；推此及它，我們可藉助這樣配置，去分解、組合各個模塊，甚是方便。

Vue有三大特性，十分令人欣喜；一是其數據的雙向綁定，即：通過數據綁定鏈接View和Model，讓數據的變化自動映射為視圖的更新。另一個是其數據驅動的組件系統，即：用嵌套的組件樹來描述用戶界面(而一個組件恰恰可以對應MVVM中的ViewModel)，其三是基於構建工具的單文件組件格式，即其所提供了強大的loader API，來定義對不同文件格式的預處理邏輯，從而讓我們可以將CSS、模板，甚至是自定義的文件格式等，當做JavaScript模塊來使用，極大提升了代碼的可復用性；Webpack 基於loader還可以實現大量高級功能，比如自動分塊打包並按需載入、對圖片資源引用的自動定位、根據圖片大小決定是否用base64內聯、開發時的模塊熱替換等等。當然 Vue 還具有其他若幹令人擊節贊嘆的設計。

鑒於此，如果可以很熟練的掌握其數據的綁定與傳輸，組件的開發，以及周邊 Webpack 等相關配置，則能將運用水平視為進入了一個新的層次。據以往經驗來看，這不是一件容易的事兒，畢竟使用這 Vue 也是衝著解決需求去了，而非在搞研究。誰能說開車上路的司機，能瞭解關乎車的所有？相信，接下來的很長時間里，都須對這幾方面加以學習、探索，然後加以利用。

如何漂亮使用-Vue-之實戰組件篇)如何漂亮使用 Vue 之實戰組件篇

Vue 一大特色是用嵌套的組件樹來描述用戶界面。所以組件的設計與編寫至關重要；至少要保證她是易於修改和維護，可復用性和可讀性高，耦合度低，接納團隊合作性開發… … 諸此等等。項目一旦龐雜，更得事先考慮好整個架構的設計，使其清晰合理；組件緩存的使用、避免過重組件的衍生 … 。而 Vue 組件系統又是有數據所驅動，更得兼顧數據在各種組件間通信，避免數據被多方操作，Bug 難以定位等問題。

這是一個須長期積澱的技能，非朝夕可至。但，部分內容只需刻意關註，即可見其成效的。比如，簡明且見名知義的命名，良好的編碼規範，團隊統一編碼風格，以保證代碼的可讀性。運用設計模式原則，比如單一職責原則，將組件拆分抽離成更細粒度，保證組件功能單一，以提升組件復用行；再如介面隔離原則，採用穩定的服務端介面，將變化模塊分離，使得組件得以解耦；在複雜的項目中，也是需要用到冗餘、繼承，這時候也需要關註下里氏替換原則、依賴倒置原則… 。另外還當學習 Vue 本身所提供的優化，像[路由懶載入], 即：結合 Vue 的非同步組件和 Webpack 的 code splitting feature, 輕鬆實現路由組件的懶載入，使得該組件訪問時才載入，以提升頁面載入效率，還有利用服務端實現首屏渲染，組件緩存等等，尤須註意的是組件間數據通信，這在之後一節中會提及，此處不做贅述。

這裡需要學習探究的點很多，非片言可蔽之，看到一份 PPT Vue.js實踐: 如何使用Vue2.0開發富互動式WEB應用；個種談到 Vue 許多相關的點，值得一覽。另外，如是為團隊寫公用組件，一定記得附上對應使用文檔，這很重要。你看，如上所說，要寫好一手漂亮 Vue(代碼)，軟體設計學問，是少不了的存在，不是麽？（web前端學習交流群：328058344 禁止閑聊，非喜勿進！）

如何漂亮使用-Vue-之實戰通信篇)如何漂亮使用 Vue 之實戰通信篇

早先有在[Vue 各類數據綁定]一文中，對 Vue 數據綁定有過些描述(version 1.)；雖然如今 Vue 早已升級至 2.，不過數據綁定變化雖多，但大局影響不大，譬如：不再允許片段實例；須以v-html取代三 Mustache 語法；變更 v-for 遍歷時參數順序等等，具體可參見[從 Vue 1.x 遷移]。此處就數據在 vue 組件間傳遞做下探討。

Vue2 移除

Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop’s value.

但，如果傳遞的 prop 本身是引用型傳遞，像對象或者數組，由於數據類型自身特性，無論是什麼綁定方式都會是雙向綁定！這些在Vue文檔－單向數據流中有作說明；請看這個例子：

這裡需要留意的是：Vue 要麼監聽的是基本數據類型的值變化，要麼監聽的是引用數據類型的引用變化；因此，vue對於數組，才自己封裝了一套方法（包括$set , $remove），如果直接變更引用類型的內容，即便數據已經修改，但 Vue 是感知不到的，所以視圖將不會更新（針對性的對屬性進行賦值操作，則會調用其屬性的 set 方法，因此Vue會得到感知，從而驅動視圖更新）。這裡需要補充的是：Vue 使用 Object.defineProperty（ES5特性）將數據轉為 getter/setter，從而實現對數據的 watcher，setter被調用時重新繪製關聯的 Dom，從而刷新視圖。

所以，對父組件傳遞來引用型數據，如需更改，最好改動做深度拷貝後的數據，而且需要註意得失，Object.assign不是深度拷貝，即便採用了 Object.freeze()去凍結。對於子組件向父組件回傳參數，可藉助 $emit，當然也可以使用 callback Functon，可參見jsfiddle 示例。非父子組件間通信，Vue 有提供 Vuex，以狀態共用方式來實現同信，對於這一點，應該註意考慮平衡，從整體設計角度去考量，確保引入她的必要。如果項目不怎麼複雜的話，完全可以自己設計一套 vue-bus，以提供了一個全局事件中心，使得可以像使用內置事件流一樣，便捷的使用全局事件。當然，Vue 也提供了 $refs，可以跨層調用，或者諸如這樣this.$parent.$parent；提供了不代表推薦；儘量少的去運用，除非逼不得已，或者去惡作劇坑人。當然，也可藉助原生Api sessionStorage, localStorage 等等進行數據存儲，以到達通信目的；對於，兼顧得失，爭取扁平統一化通信方式就好。鑒於篇幅，就不多贅述。

如何漂亮使用-Vue-之Webpack篇)如何漂亮使用 Vue 之Webpack篇

前文提到，推薦使用Vue-cli，它已然幫助我們貼心的配置好了 Webpack 相關。在編寫 router 配置之時，可以輕鬆實現路由組件的懶載入，使得項目可以拆分成若幹個 js 小包，和一個略大的 vendor，運行時按需去載入。即，我們可以像如下用法，去配備路由組件（當然，我們也可以把組件按組分塊）：

import Frame from './../views/Frame'
export default {
  path: '/',
  component: Frame,
  children: [{
    path: '/nicelinks',
    meta: {
      title: setTitleLang('晚晴幽草軒', 'Nice Home Blog')
    },
    component: resolve => require(['./../views/Nicelinks'], resolve)
  }]
}

DllReferencePlugin
除此之外，在webpack這塊，還是有非常多東西需要去優化，以縮短包構建的時間、改善其體積等等。比如可利DllReferencePlugin將常用不怎麼變更的文件，抽離出來打入另一統一的文件(vendor.dll.js)，外鏈以 script 引入。這個網上教程很多，此不贅述。

webpack-bundle-analyzer
最新 Vue-cli還幫著註入了 [webpack-bundle-analyzer]插件（Webpack插件和CLI實用程式），她可以將內容束展示為方便交互的直觀樹狀圖，讓你明白你所構建包中真正引入的內容；我們可以藉助她，發現它大體有哪些模塊組成，找到錯誤的模塊，然後優化它。我們可以在package.json中註入如下命令去方便運行她(npm run analyz)，預設會打開 http://127.0.0.1:8888作為展示。

“analyz”: “NODE_ENV=production npm_config_report=true npm run build”

webpack-bundle-analyzer在引入了 DllReferencePlugin插件後，想必會在 webpack.dll.conf.js中將 vue加入進去；例如進行瞭如下配置：

entry: {
   vendor: [
     'lodash',
     'superagent',
     'vue',
     'vue-router',
     'vue-i18n'
     'vuex'
   ]
 }

當你使用 webpack-bundle-analyzer去分析時，你會發現 Parse Size 為 71 KB 的 vue.common.js，會出現在 vendor.xxx.js 中，按預想它不是應該被打入 vendor.dll.js 中的？談及這裡，為了保證文章的完整性，不得不提下，vue2 經過 2.2 版本升級後, 文件變成了 8 個，分別是:

vue.common.js
vue.esm.js
vue.js
vue.min.js
vue.runtime.common.js
vue.runtime.esm.js
vue.runtime.js
vue.runtime.min.js

這在Vue2 dist 目錄下各個文件的區別, 可以瀏覽。另外，vue 文當獨立構建-vs-運行時構建，也闡明瞭兩者區別；這 vue.common.js 隸屬獨立構建產物，而預設 NPM 包導出的是運行時構建，為了使用獨立構建（支持 template），在 webpack 配置中添加下麵的別名：

resolve: {
  alias: {
    'vue$': 'vue/dist/vue.common.js'
  }
}

如此一來，在 webpack.dll.conf.js 配備中註入 vue，導致 vendor.xxx.js 中出現 vue.common.js，就能夠得到解釋了：dll 中對 vue 打包配置，與 resolve 中引入有出入，前者預設為運行時構建。如能保證是一致了，此問題即可解決。這一點，有經過測試，得出數據如下(resolve 配置如上)：

webpack.dll.conf.js 中註入 vue，build 之後得到 vendor.xx.js 611KB， vendor.dll.js 180 KB；

webpack.dll.conf.js 中註入 resolve 同名引入 vue/dist/vue.common.js，build 之後得到 vendor.xx.js 540KB vendor.dll.js 207 KB；

兩者比較，vendor.xx.js 相差 +71 KB，正是 vue.common.js Parse Size；vendor.dll.js 相差 -27KB，即運行時構建所得大小。打開生成的vendor-manifest.json，也會發現，前後生成 vue 相關的引用分別是：

/node_modules/vue/dist/vue.common.js
./node_modules/vue/dist/vue.runtime.common.js

如何漂亮使用 Vue 之工作流篇

“輕功不代表武功，但速度決定了你我的距離。”——白鳳（秦時明月）。智能化、自動化趨勢越發明顯，作為程式員如不能儘快適應，其所面臨的窘境可想而知。不久的將來，藍領代碼民工，勢必會在科技的浪潮中捉襟見肘；所以這更加要求從業者能快準穩的去解決需求，同時保持知識技能的不斷更新。而這快字，自然是業務技能熟練度多半取決定性作用，但如果有優善的工作流機制，勢必錦上添花。而這個話題，所涉及的點線面，非一言可以蔽之；這會在漸進的學習探索中不斷去變化更新。但至少一個當前的準則是：即便不能全自動，至少也須半自動化。（web前端學習交流群：328058344 禁止閑聊，非喜勿進！）

很多朋友使用 hexo來構建博客；hexo 是基於 Node.js產物，用它發表博文，很是方便；你只需hexo clean,hexo g, hexo d三個命令即可；文章數據一多，一套打下來，也得 20s+；如果略懂 npm，在 package.js中加入點命名，例如像這樣；

"scripts": {
  "start": "sudo hexo clean && sudo hexo g && sudo gulp && sudo hexo d"
}

那麼只需運行 npm start就好，可將時間消耗縮短至 2s節省時間雖說不多，卻也是數量級的提升，而且代價只是那麼小，並一勞永逸。所以有必要對此，以些許微薄經驗略作闡述，拋磚以引大玉。

Vue-cli雖然強大，但畢竟作為基礎公用，不宜繁雜。應有自己(團隊)的腳手架，當準備開啟新的項目時候，只需運行腳手架，以初始化整個項目，而不是一點點拷貝，然後各種重新配置，引入路由，註入 Bootstrap … 。相同項目中也該有可一鍵生成的模版庫，或者自動化的 Json 解析機制。
開始編寫代碼前，必須同後臺er，預定好介面，參數以及返回數據；並令之生成方便檢索，可供測試的可視化 API 文檔。再沒有比這更重要的（如果項目超過一月/人）。像這樣開源工具，也多不勝數，比如 Swagger-Ui。
在編寫代碼時候，則該先三思而後寫。而寫時，當確保編輯工具的犀利化，比如檢索語法錯誤，開合標簽完整，自動格式美化代碼，使之契合約定的 Eslint 要求，也保證代碼清晰簡潔；想象下如果你的書桌上整天被擺滿了蟲蠅墨液，你作何想？
Vue-cli 已幫配好了代理，無需擔心本地調試跨域問題；但如何能快速提交有效代碼，需要自行配備。命令行也好，SourceTree 可視化工具也罷，方便快捷就好。也該藉助pre-commit工具，在 commit 前執行校驗，防止出現非法提交，影響隊友。
從業歷程中有經歷過手動打各種測試 APK 的凄慘，也經歷了手動各種 build 發佈的艱難，至今想起，滿是心酸。所以，監聽倉庫代碼變化，自動化構建，此乃居家生活必備良品。從業中還經歷過各種關閉 Bug 的奇葩方式，坦言做這事兒比解決所謂 Bug 花費的時間還多。而這些，無非是那時候團隊見識短淺之詬病耳，如今團隊使用 jenkins 和 GitLab，雙劍合壁，再無那種痛楚，感動。
何謂之寫出漂亮 Vue？不僅在於代碼之優美，還在於其高效，資源節省。以數據驅動的 Vue 本身很是效率；但使用 C 寫出的代碼不見得都比 JavaScript 要高效，這變數在於是不同人去寫。由此，除了 Code Review 代碼外，也須有一套行之有效的全方位分析方法。以保證代碼的按需載入，Css 的合理編寫 & 引用，凡此等等。
何謂之寫出漂亮 Vue？還在於其可靠、穩定，而這些最終是要反映在於產品之上；因此，好的產品不僅須配備訪問情況，行為分析，事件埋點，也得有錯誤上報。早先有用簡書這款讀寫一體的產品，如今上面不僅充斥各種雞湯與戾氣縱橫的標題文，還充斥這各種 Bug，尤其是在 Web網頁上(Mac mini，Pc)，反饋無門，簡直慘不忍睹；何也？斷定他們肯定是沒有使用 sentry 類似產品工具的。
一門後臺技術；不懂後臺的前端不是好設計師；這看似調侃的話，實則還是挺有道理的。如今，大行其道的前後端分離開發模式，如果各司其職的雙方，能夠懂得彼此技術，則更容易配合，也更效率。而更多時候，何況出於某些需要，前端寫後臺，也是常見；對於個人而言也是好事，藝多不壓身。最近有在寫點個人產品，如果尋找後臺開發協助，比自己學習如何寫後端，其中麻煩肯定不會少；而且也非長久之計。即便都沒這些，要解決 Vue SEO 以及提升渲染速度，做 Vue SSR 相關，也是需要懂些後臺技術。
設計相關；這個設計，不但包括代碼結構、層次、介面等設計，對於前端從業者，必然也包括頁面相關；比如，正在開發的個人產品: 傾城之鏈（英文名曰：NICE LINKS），因為設計美學上的欠缺，可謂步履維艱的初步塑造出大致應用，但，從視覺效果來看，總覺得差那麼些意思，仍在苦思中等待枯竭。即便沒有類似需求，頁面已然有設計師畫出稿來，如要完美的還原，這設計相關的素養，也是不可或缺的存在；畢竟產品最終呈現給用戶的形態，取決於我等前端開發者。

寫在最後的結語

“你首先得是一位程式員，然後才是一位前端程式員”，這個觀點很有道理，並且將隨著時間的更替，顯得越發明顯。因此本篇所要探究的，不僅僅限於對Vue的學習與運用，更深層次的意圖在於，以當前流行框架Vue為突入口，分享時下書寫前端的一些開發經驗、編程心得、以及產品用戶體驗等。很顯然，這裡談及的只是其中冰山一角。況且前端發展如此，欣欣向榮，也是很難面面俱到。我們唯有秉承不斷學習之心態，擁抱變化，面向未來，才能在這洶涌的浪潮中、不至於被落下更遠。談及這裡，很有必要分享下，最近一直在搜集更新的[與時俱進版前端資源教程]，其著重搜集時下與未來技術的優秀之文，以及工具、優化、測試、安全等精華之章，宗旨是為前端學習、技能提升、視野擴展、資料查找等行個方便；有興趣的朋友，可以關註瞭解下，或者更進一步，協助補充 & 修正，讓其能服務更多的人。