跳到主要內容

【2020 COSCUP】Vue 作者尤雨溪分享 現場座無虛席

 【2020 COSCUP】Vue 作者尤雨溪分享 現場座無虛席

2020 COSCUP 第二天的重頭戲兼開場為主辦單位邀請到 Vue 作者—尤雨溪與現場會眾分享即將正式上線的 Vue 3 與個人開源心得。現場座無虛席並且與會眾問答的來回問答十分精彩,文中也邀請到台灣最大的 Vue 社群「Vue.js Taiwan 台灣」的 Kuro Hsu 做 Vue 的簡單懶人包。


COSCUP 第二天的開場為主辦單位邀請非常多次重量級來賓 Vue 作者尤雨溪(Evan You),而今年雖因為疫情關係,Evan 無法來到現場,但恰好搭配著 Vue 3 釋出的熱度,一早就湧進大量人潮。


目前 COSCUP 主辦單位已完整的將影片釋出到網路上囉!有興趣的網友們可點網址觀看:https://youtu.be/Z-i7VY-ez2Q

COSCUP 工作人員也邀請到了台灣最大的 Vue 社群「Vue.js Taiwan 台灣」的 Kuro Hsu 為我們摘錄本次演講與 Vue 3 最精華與懶人包的內容(註:演講時間為 2020 年 8 月 2 日,可能與最新版本有不同,以最新釋出的版本消息為主唷!),若想討論 Vue 的技術與內容的話,也可以加入「Vue.js Taiwan 台灣」與他們一起討論喔!(社團連結:https://www.facebook.com/groups/vuejs.tw)


---

小編問題(一):7/18 release Vue 3(註:此為 Release Candidate、或稱 RC 版本,非正式版)和以往最大的改變(三個):


Kuro 回答:


  1. Vue.js 以往版本 (v1、v2) 的核心底層是以 JavaScript 來開發,而型別檢測系統在 Vue 2 以來一直都有,底層是透過 Flow.js 來實作。


尤雨溪在演講中提及,首先是在近年的前端領域裡,使用 TypeScript 來開發的人越來越多, 而這點對 Vue 2.x 來說對 TS 的支援顯然是不足的;再來是 Flow.js 原本是 facebook 團隊開發用來作為檢查工具,並不是新的程式語言或超集語言, 而 Vue 3.0 底層改用 TypeScript 除了同樣能做到原本 Flow.js 的功能,並且在經過編輯器的整合 (如 VSCode) 甚至可以做到程式碼的即時檢查以及自動補完的提示等功能。 另外,TypeScript 團隊也與 Vue 作者有多次的討論與技術的支援,TypeScript 是否是主流相信不是 Vue 最主要考慮的原因, 而是 TypeScript 團隊積極擁抱社群,聽取並採納社群的意見,這才漸漸成為前端主流。


  1. Proxy-based Reactive Link Text


過去 Vue.js 是採用 ES5 的 Object.defineProperty 來作為資料更新檢測的依據,而 Vue 3.0 則以過去為基礎,更進一步改用 ES6 的 Proxy API。 原因是過去使用 Object.defineProperty 需要針對每一個要監測的狀態加上 getter / setter,而 ES6 Proxy 則無須像過去一個一個為每個屬性加上 getter / setter, 而是透過代理的方式,一次就可以直接監聽狀態物件的存取更新,效率比起過去來得更好,代價就是老舊瀏覽器的支援程度較差。 (就是 IE 不支援啦)


  1. Virtual DOM rewrite for better performance


如上題所述,過去由於 Vue.js 的更新檢測是透過 getter / setter 來做到更新的最小化,所以無需透過迴圈式的 dirty-checking 來做到組件的更新, 但是在單個組件內部的 Virtual DOM 仍需遍歷整個 VDOM 的各個節點來進行比對,如果這個組件裡的動態節點並不多,那麼就會造成多餘的檢查以及效能的浪費。


Vue 3.0 對 Virtual DOM 的重構,會將模板切分成一個個的巢狀區塊,每個區塊的節點結構是固定的, 且只需要透過一個陣列來記錄與追蹤其所包含的動態節點部分。 這樣一來, VDOM 的更新效率則與模板最終的大小無關,而是由組件內動態節點的多寡來決定。 簡單來說,只有動態節點的部分才會進行 VDOM 的重新渲染,這樣就可以做到整體效能的大幅提升。


小編問題(二):Vue 3 release 之後與其他相比最大的優勢是?會不會導致更多人使用?


Kuro 回答:


不跟別人比,就拿 Vue 2.x 來說,同樣功能的程式在 Vue 3.0 的執行效能更快、打包後的程式碼更小, 在開發體驗上,由於採用了 TypeScript,即使開發者不用 TypeScript 來進行開發,也同樣能享受 TypeScript 帶來的好處 (型別檢查、程式碼自動補完等)。 同時,因為採用了 Composition API,更可以減少過去 mixins 所造成的資料衝突,狀態來源不明等問題, 更不用說還從 React 陣營借鑒像是 Portals、Suspense 等新功能,都是非常實用的。

就我個人的看法,即使是在 Vue 3 正式推出後,雖然不見得會吸引其他陣營 (如 React、Angular 等) 立刻將手上專案轉過來改寫, 但正在對為新專案挑選框架的開發者來說,是很有吸引力的。


小編問題(三):若要從 Vue 2.0 升級到 3.0 的須知或建議


Kuro 回答:



首先要考慮的是對舊瀏覽器的支援,如果專案需要支援到老舊瀏覽器 (對就是在說 IE),那麼可能就不適合升級到 Vue 3.0,可以等待 Vue 2.7 的推出做為過渡期的轉換。 而若專案使用過多第三方所開發的 Vue 2.x plugins,也要注意那些 plugins 是否在近期內有升級支援 Vue 3.0 的打算,或是尋求替代品。

如果沒有上述問題,那麼建議可以從小型專案或自己的 side project 開始嘗試 Vue 3.0 的升級, 尤其現在 Vue-cli / vite 等工具已經可以支援直接以 3.0 作為新專案的啟動,或是也可以利用 Vue-cli 來做升級,搭配 vue-cli-service lint 工具,都會有新版本相關的建議與提示。 相信這次的 3.0 版本不會讓你失望的。


如果有更多問題想討論,歡迎加入「Vue.js Taiwan 台灣」與一起討論喔!

留言

這個網誌中的熱門文章

為什麼電視直播比賽總是比網路快?看低延遲串流如何搶秒數

  大多時候,你在網路上看的 Live 直播串流,其實不是與現實世界完全同步的即時轉播,先看看以下這些場景,相信對你來說並不陌生。 NBA 冠軍賽才正看到精彩處,隔壁鄰居卻突然爆出一陣歡呼,原來,用電視觀賞同一場比賽的他們,比你早 30 秒歡呼慶祝三分球入網,不小心點開社群媒體,更發現朋友們早已發文熱烈討論比賽結果。 就像電影被暴雷一樣,少了即時參與的驚喜感、提早知道結局,觀看直播活動的樂趣頓時大打折扣。 或是,收看跨年演唱會時,正當你興高采烈倒數最後 30 秒時,才發現,窗外的慶祝煙火已經此起彼落,大家都已經跨入新的一年,只有你還停留在前一年。 雖然從絕對時間來看,這些狀況都僅有延遲短短幾秒鐘,但在體感上,觀賞體驗卻大受影響,用「失之毫釐,差之千里」來形容再恰當不過。 使用直播串流時,為什麼你的世界總是比別人慢幾秒?原因正是「串流延遲」。 從攝影機到觀眾螢幕的層層關卡 串流延遲,指的是攝影機拍到影像後,直到觀眾端螢幕出現畫面的時間差。 一般來說,有線電視直播約延遲 5 到 10 秒,而 YouTube、LINE、Twitch 等多數 OTT 平台,延遲大多介於 15 秒至 30 秒,距離延遲秒數低於 3 秒的「超低延遲」(Ultra Low Latency)標準,還有一大段距離,這也讓現有直播內容的互動效果有限。 但想克服延遲並不容易,光是一段畫面要從現場攝影機,傳到電腦和手機螢幕,中間所需流程多到難以想像。 KKStream 執行副總李卓軒 Kevin C.H. Lee 解釋,這流程大致包含一開始的攝影機收取影音訊號,接著需轉換訊號、傳輸、上傳雲端、加密、備份,傳到終端裝置後再解碼,最後才是播放。 這整段「螢幕到螢幕」的過程,就像是將包裹從A點運送到B點,只要中間有幾個環節耽誤,就會讓整體運送時間不斷疊加。「每個步驟都要優化,只要有個點延遲很高,加總起來就無法達到超低延遲的標準,這需要很強的技術掌控力。」Kevin 說。 另一個挑戰則在於,由於各大終端裝置原廠(如Apple、Google)雖然有提供低延遲串流相對應的規範,但並未說明實際的執行細節,因此串流技術業者只能自己摸索。 受限於技術瓶頸,目前大多數的直播串流服務,只能在延遲、直播規模和影像品質三者間取捨。例如,常見的視訊會議軟體,像是 Zoom、Google Meet,雖然延遲相對低,但參與人數上...

COSCUP x UbuCon Asia 2026 錄取攤位公告/Full List of Accepted Community Booths at COSCUP x UbuCon Asia 2026

Full List of Accepted Community Booths at COSCUP x UbuCon Asia 2026 COSCUP x UbuCon Asia 2026 Booth now release. See which community you can meet on COSCUP x UbuCon Asia 2026. No. Community Introduction 01 UbuCon Asia HackMD 02 Ubuntu Community & Ubuntu-TW HackMD 03 Cloud Native Taiwan User Group x WasmEdge HackMD 04 Automotive Grade Linux HackMD 05 Ruby Taiwan HackMD 06 Wikimedia Movement in AI Era HackMD 07 t2linux HackMD 08 Twinkle AI HackMD 09 Taiwan JVM team HackMD 10 Interledger Foundation HackMD 11 SITCON Student Information Technology Conference HackMD 12 OpenEverest HackMD 13 WordPress Taiwan Community HackMD 14 OSPN (Open Source People Network) Japan HackMD 15 GolangTW HackMD 16 opencocon distribution HackMD 17 Open Culture Foundation HackMD 18 GDG TW (Google Developers Groups Taiwan) HackMD 19 FediDev KR & FediLUG (Japan) HackMD 20 Blockchain and Distributed Ledger HackMD 21 Open-EP (E-Paper) Community HackMD 22 FOSS for All HackMD 23 ...

你的程式碼,你的硬體,你的 AI。掌握你的晶片未來。Your code, your hardware, your AI. Own your silicon future.

在 Tenstorrent,我們從晶片設計的最底層開始打造一切。我們不只採用 RISC-V,更將我們的擴充指令集規格全數公開。指令集架構 (ISA) 與硬體架構也完全開源。整個軟體堆疊,從韌體 (firmware)、運算核心 (compute kernels) 到編譯器,全都放在 GitHub 上,並採用你真正能用的授權條款 (Apache 2.0 / GPL)。我們的下一代晶片 Blackhole,旨在掃除傳統設計的低效率,讓你直接掌控資料流 (dataflow),實現更高的速度與電源效率。 Blackhole p150 (單晶片,次世代架構): 32G 記憶體,512GB/s 頻寬 387 TFLOPS (BFP8) / 774 TFLOPS (FP8) 大規模可程式化 RISC-V 核心陣列 算子函式庫、編譯器,整個軟體堆疊 — 全部開源 (OSS) 以原生 CCL 達成真正的多卡擴充,拒絕使用 PCIe workaround $1399 Wormhole n300 (雙晶片,經市場驗證的成熟架構): 24G 記憶體,576GB/s 頻寬 262 TFLOPS (BFP8) / 466 TFLOPS (FP8) 大規模可程式化 RISC-V 核心陣列 算子函式庫、編譯器,整個軟體堆疊 — 全部開源 (OSS) 以原生 CCL 達成真正的多卡擴充,拒絕使用 PCIe 土炮 $1499 現已上市。 立即在官網購買運算卡,或在我們的雲端平台上體驗。 如果你受夠了嚴苛的 EULA (使用者授權合約) 或處處受限的記憶體;又或者,你一直想親自動手,深入探索驅動你類神經網路的 C++ 程式碼;甚至想挑戰組合語言,親眼見證它...