企業前端框架趨勢論壇之問與答遺珠
先感謝 Will保哥 的邀請,舉辦了一場企業前端框架趨勢論壇的活動,來比較現代主流的三大前端框架 (Angular, Vue, React),因為活動時間限制的關係,下半場讓會眾預先提問的問題,能夠回答的題目並不多 (問券連結點此)。 其中有些我認為還不錯或是有趣的題目,這裡就以 VueJS 推廣者 的角度來談談我對這些問題的看法。
Q: 常常看到 React、Angular、Vue 比較的文章,但是都是著重在技術本身,似乎很少比較應用面,我想知道什麼樣的技術比較適合開發什麼性質的網站,這樣比較容易了解適合導入哪種技術。
答: 用什麼技術或是工具開發網站,我認為是其次,因為不管用什麼技術來開發,網站的本質都是一樣的,並不會因為某個網站用 VueJS 就寫得出來,用 React 或是 Angular 就寫不出來,當然反過來說也是。 程式是人寫出來的,技術選型首先考慮的是要不要使用框架,再來才是要使用什麼框架。
專案有它本身的複雜度,當然工具以及其生態圈也是。 如果 jQuery 甚至原生的 JavaScript 就可以解決你的需求,那麼也許你並不需要前端框架。 如果硬要在對 Vue、React、Angular 都是零經驗的基礎下挑選,我認為你可以隨便挑一套,先從小型、無長期維護需求的活動專案或是自己的 side project 開始試著實作看看,總會試出一套適合自己的,如果要問我的意見,一定是建議先挑 Vue.js 來試試看囉。
Q: 想請問前輩,如果遇到需要打掉重練(原:web layout刻板+jQ) 的問題,三種框架會怎麼引入或是怎麼解決呢(個人或顧問觀點)? 如果帶新人,也是多以jQ為主的新人,要如何帶入框架的運用呢?(一口氣學完es6/TS,可能產能會降低一段時間 v.s. 如果有可能,一步步導入,……但如何操作呢?)
答:
這裡的問題我以 Vue.js 的角度來回答。 在舊專案 (假設原網站以 jQuery 開發) 的維護上,如果要轉換到 Vue.js 的話,首先可以採取以 CDN 的方式 來引進,用法完全與過去的 jQuery 一樣,把 Vue.js 引入 HTML 後 ,就可以直接在 <script>
區塊裡面寫 code 了。
當然未來專案規模成長,就可以再進一步將 component 拆分出獨立的 .vue
檔案,會更好維護。 至於 ES6 與 TypeScript 方面,因為 Vue CLI v3 內建 babel,所以 ES6 可以無痛轉換,而 TypeScript 以目前的狀況來說,要在原有的舊專案引進 TypeScript 的轉換成本較高 (比起 ES5 -> ES6 ,ES -> TS 要重寫的部分會比較多) ,我會建議未來開新專案時再直接引進。
Q: Vue背後沒有富爸爸。請問收掉的風險會不會比較大.
答: 坦白說我滿意外這個問題有很多與會者關心。 雖說在 open source 的世界裡面沒有「收掉」這件事情,但確實有可能會「沒人繼續維護」,這點在 infoQ 最近對尤雨溪的專訪中也有提及,像 Vue.js 這樣發展快速的年輕專案,相當依賴核心開發者是很正常的事,而 Vue.js 也漸漸朝向工程化的目標前進,就是期望未來可以減低這個專案對核心開發者的依賴,當有機會參與的人越多,這個開源的專案就有力量可以走得更長久。
就目前的狀況,不管是 Vue.js 框架本身的開發者團隊也好,甚至是世界各地的聚會組織, Vue.js 的生態圈都還在持續成長的狀態。 另外在短期幾年來看,Vue.js 的作者尤雨溪對 Vue.js 的維護應該會持續下去,而他本人也很享受目前身為獨立開發者的狀態。
Q: 現職公司無使用三大框架但仍想接觸的人,該從什麼方向去練習專案開發
答: 如同我前面所說,在三大框架都是零經驗的基礎下,開始可以隨便挑一套,先從小型、無長期維護需求的活動專案或是從自己的 side project 開始試著實作看看,覺得寫得下去就恭喜你,要是不合胃口就換一套。 總會試出一套適合自己的。
Q: 無師自通那是頂尖高手在做的事情,但是對於時間有限的一般開發者來說,目前有哪些書籍、官方文件以外的學習資源。
答: 以 Vue.js 來說,在台灣 Facebook 有 Vue.js Taiwan 台灣 社團,線上討論的熱度一直都有,歡迎加入。 書籍的部分,天瓏書局也有引進相當多 Vue.js 為主題的書 (連結) 可供參考。
想要追最新資訊的話,這裡有 Vue.js News 可以訂閱。 如果沒有時間自己找資料的話,那麼挑選課程來學習也許是不錯的選擇。
如果是線上課程,這裡我推薦六角學院的 Vue.js 課程。
當然如果你更偏好實體課程,覺得應該要面對面解決你的問題,那太好了,在台北的五倍紅寶石小弟我也有開設 Vue.js 與 Vuex 前端開發實戰課程 - 假日班,最近一梯的開班日期就在九月下旬 (9/22) 喔。 (是業配廣告無誤,也是真心推薦)
Q: 之前看過一篇文章,內容提到將來可能會有"以web component作為中介,讓目前流行的三大前端框架技術在同一專案中的整合運用"這樣的趨勢,例如在angular 中使用其他兩個技術所建立的web component。想請問講師們關於web component的使用趨勢、這種整合方式的優缺點之類的。謝謝講師們!
答: 這個問題應該先回到 Web Component 的本質。 以網頁標準來說, Web Component 並不只是單一的規範,從 W3C 擬定的標準 來看,可以知道 Web Component 至少有這四個部分:
- Custom Elements
- Shadow DOM
- HTML Templates
- HTML imports
然而這四個規範的標準都是各自獨立的:像 Custom Elements 用來擴充 HTML 的語意,Shadow DOM 可以幫助我們封裝 DOM 與隔離元件之間的 CSS 樣式,HTML Templates 來達到 DOM 的動態生成,HTML imports 則是幫助我們引入外部的 HTML 內容。
這些標準看起來似乎很美好,但我們面臨的最大挑戰是什麼? 並不是「最新」的瀏覽器對標準的支援不足,而是我們需要「向下相容」的瀏覽器對這些標準的實作程度,所以我們需要前端框架。 像 React、Angular、Vue 這樣的主流前端框架就以「自己的方式」來實作 Web Component。
讓我們回到問題。 就實作面來說,想以 Web Component 的標準作為中介整合各種前端工具,似乎還不可行。 但近期有個新的概念,叫「Micro Frontends, 微前端」,是從 Micro-services 的概念發展而來,並且應用至前端領域。
當我們的網站服務應用大到一定程度的時候,這樣的架構可以幫助我們將各個功能模組獨立開發、運行、測試與部署。
關於「微前端」的說明可以參考這兩篇文章:
Q: 怎麼樣才可以稱得上是資深前端工程師?是對瀏覽器的相容性很熟,還是對專案進展速度可以掌握?可以說說看你們認為的答案嗎
答: 這個問題雖然與前端框架的關係不大,且每個人對「資深」的定義不盡相同。 對我來說,至少要能做到獨力解決問題,並且能夠給團隊成員建議,以及對自我的要求,是資深工程師的基本要素。
另外想推薦大家這篇,好友 jaceju 寫的 如何才有資格稱為資深工程師 一文。
Q: Angular有雙向綁定,vue也以訂閱者/觀察者模式實踐雙向綁訂,需要理解背後的pattern再實做嗎? **指新手盡量不要用到雙向綁定的做法? ,還是框架設計出來用就對了,讓經驗慢慢理解…… 簡化問題,那種比較合適: “某天發現原來這是一個pattern” vs “先理解pattern才實做,否則盡量避免使用”
答: 理解技術背後的實作細節絕對有助於專案的開發與除錯,但這並不是必備條件。 就好比我們學開車,沒必要非得理解引擎、輪胎是怎麼製造的之後才能學開車。
以 Vue.js 來說,如果是新手學習,我的建議是先參照官方的 教學文件 以及 Style Guide 的幫助最大,至少在學習初期不會走偏。 熟悉了基礎知識後,再去慢慢理解 Custom Directive、以及 變化追蹤的原理 甚至是 webpack 等外圍生態圈的相關知識,會是比較建議的學習路線。
Q: Vue生態從早期是抽取angular某些功能(樣板語法/雙向綁定) ,到後期越來越往類似react的概念去構思核心 (redux-vuex,next.js-nuxt.js),請問作為簡單上手的vue,如果往資深走的話,平時會選擇angular or react作為side project嗎?還是放手投入vue就好 😂
答: 以技術選型的角度來看當然是多方嘗試更好,如果平時已經在用 Vue.js 作為主力開發,在 side project 可以改用 React、Angular 等其他前端框架來開發,這些工具之間雖然實作方式不同,但有不少概念是可以沿用的,在理解彼此的差異之後,對於未來做為技術選擇的參考會更有幫助。
Q: 想要了解vue的原始碼以及架構模式,從何而學?
答: 如果對 Vue.js 的原始碼有興趣的話,可以推薦 Vue.js 技术揭秘 這個電子書,對於 Vue.js 的原始碼有相當詳細的解說。
Q: 三套工具有幫助debug 的工具嗎
答: Vue.js 有提供 vue-devtools 這個開發工具。
Q: 遇到產品使不同框架的過渡期,會建議全部統一一個框架,還是繼續做維護就好?實務上有沒有可能一個產品同時使用不同的框架
答: 原有的專案與新專案 (或是專案改版) 的技術選擇確實有可能會不一樣,以開發角度來說,如果前後端的職責拆分夠乾淨的話,不管使用什麼框架都不會影響到新舊專案之間的維護與開發。
Q: 請問從 MPA 進展到 SPA (Angular/Vue/React)設計之下,GA(Google Analytics)/GTM(Google Tag Manager) 有哪些需要注意或改變的地方?
答: MPA 與 SPA 在 Google Analytics 的用法基本上差異不大,比較需要特別注意的是,由於 SPA 的換頁其實是假的 (透過 HTML5 History API 操作),所以在換頁的時候,需要注意 virtual pageviews 的追蹤。
參考連結: Single Page Application Tracking
Q: 使用Vue的寫法與往常最大的差異在哪裡?
答: Vue.js 與過去用 jQuery 這類工具最大的不同之處是在於對 DOM 操作思維的不同。 過去用 jQuery 開發的時候,幾乎就是一行指令做一件事,雖然直覺,但是當專案規模慢慢變大,尤其像 SPA 的應用等,維護上是不容易的。
而現代多數 MVVM 框架的開發模式,會把關注點放在資料/狀態的管理,畫面與資料的同步由工具來幫我們處理掉,開發者需要關注的是資料與狀態的部分。
這裡可以參考我之前的投影片: [JSDC2017] 從 VueJS 看前端生態圈的發展變化,以及 脫離資料分散的問題,從 jQuery 換到 Vue.js 這篇文章。
最後再次工商服務
這是我最近在五倍紅寶石開設的 VueJS 入門課程,時間在九月底。 如果你對 VueJS 有興趣,卻總是不得其門而入,歡迎點此 https://5xruby.tw/talks/vue-js 報名參加,聽說目前有打折,而且折扣還不少喔。
結論
雖然前端框架這些年不斷推陳出新,但在面對這些百花繚亂的工具時,我認爲認清背後的本質是更重要的。 一窩蜂盲目地追求新技術,其實是沒有意義的。 技術是為了解決問題而生,當我們在面對技術的時候,事實上我們應該要先面對問題本身。
工具不會橫空出世,都是先有問題才有解決的方案。
這個方案可能不夠完美,那個問題也許有很多種解法,那麼哪一種才是適合自己的呢? 他們之間的優缺點以及各自的取捨又是什麼? 回歸問題目的層面,先釐清目標是什麼,再回頭來看解決的手段。