以Vite為代表的前端構建工具進入加速賽道

ESM 大勢所趨，勢如破竹，由于 ESM 的普及，而帶來的打包工具的革命以及適用于 ESM 下一代 CDN 的發展，業務項目在生產環境開始使用原生的 ESM 代替以前的 Bundle方案，從而導致開發體驗及網站速度的大幅提升。

核心代碼：

<script type="module">
  import lodash from 'https://cdn.skypack.dev/lodash';
</script>
復制代碼

還記得我在20年的時候，就吐槽構建速度問題，嚴重影響我們開發的效率。

其中憑借ESM成長最快的構建框架Vite，一種全新的前端構建工具。你可以把它理解為一個開箱即用的開發服務器 + 打包工具的組合，但是更輕更快。出自尤大之手，目前npm月下載量超過130萬次。

核心原理

• 開發環境下，模塊以原生 esm 的形式被瀏覽器加載。
• 生產環境下，模塊被 Rollup 以傳統方式打包，而且做了很多默認優化。
• 開發和生產環境下共享同一套 Rollup 插件機制，所以單個模塊的編譯在開發和生產環境下是一致的。

框架優勢

• 快，極速，使用原生ESM文件
• 超快的HMR(熱重載)
• Rollup 插件機制
• 天然優先支持Vue3
• .....你來體驗挖掘

豐富的生態

更多構建工具介紹：
css-tricks.com/comparing-t…

以Vue3+Ts+Vite+Pinia組合的高效開發套件

上面已提到Vite基于Ts語法，并且對Vue3天然的支持，加上尤大主推的Pinia作為vuex的最佳替代品。此套組合或成為22年Vue開發的最佳選擇。我建個了Vue3+Vite+Pinia的基礎模板 供大家參考，后續也會加入一些工具包(自封裝的)。這里只是基礎，根據自己項目需求可以增加 Volar / Vue Router / Vue Devtools / VueUse / Element Plus / NutUI等。

我們團隊是在21年3月份就開始使用Vue3開發項目了，也是第一批使用vite構建項目的。無線端業務最高峰值PV30萬+，整體項目運行穩定，比較多的還是Android/ target=_blank class=infotextkey>安卓端兼容問題(歷史問題了)。此套組合整體的優勢：

• 面向未來技術棧，不需要維護復雜的依賴升級問題
• 擁抱更多新特性，類似SFC等
• 提高構建效率-翻倍的
• .....

工具包分享

另外分享一下我們團隊使用的技術包，可以大大團隊提升研發效率

• pnpm 節省你的磁盤空間，讓依賴包也能統一管理，按需更新，老板再也不用擔心我的C盤臃腫了
•  
• tailwindcss，艾瑪香的一塌糊涂，一行css不寫，3分鐘出一個頁面。不適合初中級前端，建議還是先踏實學基礎再用框架。
•  
•  
• Vue I18n 是 Vue.js 的國際化插件，如果你想做開源框架，國際化首選插件。
• ViteSSG，seo優化，這個項目有點意思，大家可以玩玩這個方案，之前我都是通過服務端渲染搞SEO，后來了解到這個可以直接在Vue3的服務器上生成。
• Vitest,基于Vite的單元測試工具，目前迭代比較快，尤大金牌贊助?？梢猿掷m關注，不建議使用在小項目中。
•  

Web3D圖形技術的研究

在之前的分享里我已經寫過一部分，這里不做過多趨勢發展方向的贅述，主要以我們實際案例聊一下這塊技術的發展。

需求背景

10月份左右我們做了個web3D的項目，主要目標是建立一個小型的城市，讓大家基于企業文化做一些線下任務并獲取獎勵，獎勵可以用于裝修城市或兌換禮品。例如：按時寫日報，閱讀最新人事公告，積極參與文化活動等等。不再是冷冰冰的Push通知或內部信，調動大家活躍的工作氛圍。

這個項目需要思考的是如何玩出花樣？鋪天蓋地的任務機制在各大App隨處可見，用戶早已玩膩了。宏大的城市模擬需要安裝App或較大的人力投入。輕量級的游戲化應用確實近幾年的主流，加持C4D視覺的流行，也更加迎合用戶新鮮感的期待。

那么定出來的方向是（搞全棧的，后端接口隨心所欲，就不多說了）：

• 3D類，輕游戲化城市模擬（基礎玩法）
• 好玩，可以保持用戶新鮮度（皮膚系統）
• 夠輕，Web端打開就能玩

產出

框架選擇Oasis Engine ,為了提高美術還原度，我們提供了一套標準化的Blender烘焙流程。過程中遇到模型數量太多，美術人手不足的問題，于是自研了一套模型渲染工作臺（未來計劃貢獻給社區，保持關注），可以快速導出模型代碼和渲染圖。預覽圖片非常大不知道能否顯示原圖地址

分享

通過這個項目，我們團隊也嘗試了Three.js、PlayCanvas.js 等框架，對圖形技術也算是知道了點皮毛。個人建議不要盲目跟隨VR、AR、元宇宙等熱點冒然入門某個細分領域。畢竟術業有專攻，保持好前端技術敏感性，根據公司業務發展再做定論。如果能帶動業務發展，一般企業都會大力扶持，隨著項目迭代你才有機會真正深入某一項技術。因為凡是通過簡單的學習和了解都不算是入門，很可能在你某個晚間體操后就忘記了某項技能(剎車)。

對低代碼技術的嘗試，助力前端進入深水區

低代碼能力解決的絕不止10-20倍提速的問題，而是技術發展賦能企業運行效率的最佳實踐。通過整合前后端技術應用（這里是應用層面而非技術層面），從而解決企業面臨的各種復雜問題。

原理性

前端通過可視化拖拽式交互操作，后端通過動態表單技術實現。當然，低代碼平臺也不像我說的那么簡單，各家平臺融合的技術也各有特色。以下分析幾個關鍵性指標。

首先，數據結構，低代碼編程的數據結構是完全托管的， 用戶可以創建任意的數據表，選擇各類型字段。 除了數據庫通用的字段類型外，低代碼編程一般會封裝額外的字段類型。

其次，數據關聯，能否根據模型，自動生成多層級交叉調用的代碼，成了低代碼工具關鍵性指標。

再者，頁面配置，目前比較主流的方案是通過 Json Schema ,一種國際規范的詞匯表，允許你注釋和驗證。目前，采用此模式的低代碼框架有很多，例如：阿里的XRender，vjsf等后面介紹。

最后，基于Seveless的事件機制，通過靈活定義函數與事件來滿足更加復雜的業務流程。

案例

使用Schema快速搭建一個基于Vue3+antdv的注冊表單：地址

它的好處在于能夠讓前端研發人員徹底從機械重復性工作中抽離出來，有充足的時間劃水研究新技術，解決更棘手的復雜問題。

我們團隊從17年就一直在折騰這方面，起初只是解決一些靜態頁面組裝，到后來就是可視化裝修業務頁面。但因為人員精力不足，缺乏迭代和更新也是停留于內部，未能落地業務。不過也算打下了基礎，去年又重新撿起來，參考Json schema的規范，重新基于業務研發了自己的效率工具平臺，以解決中后臺，業務單一的營銷活動，官網，數據大屏等需求。

其實，我們也一直在思考如何讓更多組件通用。隨著低代碼場景的豐富，越來越多的復雜組件將被設計出來。如果每個團隊都閉門造輪子可能又是個惡性循環。如果，我說如果，能夠有一套類似schema的規范來定義各類組件，甚至復雜的業務組件，形成一個統一規范的倉庫。那么前端同學就能夠很輕便的選購組件和復用組件了，研發效率也將會再一次提升。

DevOps已徹底重構了研發各環節

認識DevOps

21年還有一項技術在釜底抽薪一樣重塑著開發者的流程，那就是DevOps。從最早的單體架構+瀑布模式開始，全棧是吃香的，自己搞一個Demo研發好，找一臺服務器安裝好環境，把項目解壓上去開啟服務就可以了。模式單一，出了問題拉一下日志，為了解放雙手自己寫一些腳本用于監聽日志，自動備份等。

隨著業務體量增加，一臺機器扛不住，加機器，單機變多機，架構也開始加入Nginx，redis,CDN,Nat等通用基礎服務。隨著多機器（大公司動則上千臺），多人協作模式的發展，越來越多的問題暴露出來。全棧這個階段作用減弱，分身乏術，開發專注于業務，運維進場。這時 Ops 的主要職責就是：硬件維護、網絡設備維護、DBA 、基礎服務維護、數據監控等，運維們擅長寫各種部署，監控腳本，減少機械的重復工作。運維要求門檻變高，行業運維開發人員質量參差不齊，短時間無法靠人解決量的問題。隨著架構越來越大，流程溝通成本變高，發布流程變長，測試無限排期，需求交付變成了畫雞成鴨。

上線以后，偶爾會出現的結果

微服務+DevOps，主流架構，應對BAT級別體量的技術研發和交付。項目從研發到交付的各個環節都得到了有效治理，而這個階段的全棧又發揮作用， 不再分散精力學習運維而是專項前后端業務側。

wiki定義微服務: 微服務（英語：Microservices）是一種軟件架構風格，它是以專注于單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎，利用模塊化的方式組合出復雜的大型應用程序，各功能區塊使用與語言無關 (
Language-Independent/Language agnostic）的API集相互通信。

DevOps平臺

這一類的平臺比較多，就不一一列舉了，看你們公司具體采購哪一個。分享一下我們團隊一些創新項目目前使用的DevOps——阿里云效，目前新入駐的企業免費，不過限制一定事務處理數量。對于敏捷研發團隊來講，我們不一定要了解每個流程的原理，如果能夠讓我們更好開展自己的工作，又能低門檻上手的，那么它就是最好的。

我認為阿里云效的優勢在于，整合了各種工具以后在此基礎上又做了相對友好的上層應用。通過上層應用的方式關聯各saas和paas服務，你無需關注底層技術配置，只需要管理好你的業務即可。

• 項目協作，解決的是PM需求管理問題，內置功能強大的過程管理能力。
• 代碼管理，底層相當于gitlab，只是這里生態做了整合，可以上下文系統調用。
• 流水線，這個就很D了，支撐豐富的插件機制，自定義腳本等，CICD的整合。
• 制品倉庫，就是鏡像倉庫，支持Maven，Npm，通用制品等
• 效能洞查，可以理解為一個BI中臺，度量報表維度表多，代碼提交量，缺陷數，任務數等
• 應用交付，APPStack，用于管理容器集群，K8S集群，應用部署，環境部署等
• 云端開發，阿里自研的云端代碼編輯器DevStudio，有幸被下過Offer,體驗很不錯最快10秒部署，自動分配臨時域名用于調試。
• .....自己體驗吧

體驗流水線

以vvt倉庫 為案例，設計一個流程，如果有main提交或合并動作，就觸發代碼審查和單元測試，并通知釘釘機器人，再構建代碼，最后發布到阿里云服務器指定目錄下。

首先，創建流水線，綁定github倉庫和分支，配置倉庫webhooks，并監聽提交事件。

其次，配置代碼掃描，可選使用本地ESLint配置，添加釘釘機器人插件(插件機制可以做很多事情)

最后，流水線執行操作科爾一看到具體日志，會輸出代碼掃描的結果，以及單元測試等，無所不能

還有很多騷操作：生產環境，正式環境一鍵切換，自由服務器掛載，集群部署，自動擴容，備份，日志監控Push等等

5G在加速Web通信的增強

WebRTC

WebRTC (Web Real-Time Communications) 是一項實時通訊技術，它允許網絡應用或者站點，在不借助中間媒介的情況下，建立瀏覽器之間點對點（Peer-to-Peer）的連接，實現視頻流和（或）音頻流或者其他任意數據的傳輸。WebRTC包含的這些標準使用戶在無需安裝任何插件或者第三方的軟件的情況下，創建點對點（Peer-to-Peer）的數據分享和電話會議成為可能。——出自MDN

• 2012年： 谷歌已經把這款軟件集成到Chrome瀏覽器中，Opera初步集成WebRTC。
• 2013年 6月： Mozilla Firefox[5]發布22.0版本正式集成及支持WebRTC。
• 2017年11月： W3C WebRTC 1.0 草案正式定稿。
• 2021年1月： WebRTC 被 W3C 和 IETF 發布為正式標準（見《WebRTC 1.0: Real-Time Communication Between Browsers》）。

主流瀏覽器都支持 WebRTC 標準 API ，因此也讓瀏覽器之間無插件化的音視頻互通成為可能， 大大降低了音視頻開發的門檻，開發者只需要調用 WebRTC API 即可快速構建出音視頻應用。

更多關于WebRTC文章

《開源實時音視頻技術WebRTC的現狀》 《簡述開源實時音視頻技術WebRTC的優缺點》
《訪談WebRTC標準之父：WebRTC的過去、現在和未來》
《[良心分享：WebRTC 零基礎開發者教程（中文）附件下載]》
《WebRTC實時音視頻技術的整體架構介紹》
《新手入門：到底什么是WebRTC服務器，以及它是如何聯接通話的？》
《WebRTC實時音視頻技術基礎：基本架構和協議?！?br />《淺談開發實時視頻直播平臺的技術要點》

Chrome97發布，QUIC協議到來

一周前，Chrome 97發布，最大的亮點是WebTransport，得益于強大的QUIC協議，WebTranport可以提供更強更快的雙向通信能力，有望用于游戲、直播、視頻會議等低延時場景。

WebTransport默認使用HTTP/3，同時使用HTTP/2作為備胎。

• 提供類似于TCP的可靠通信，處理丟包、擁塞等網絡異常情況；
• 基于TLS/1.3進行加密，保證通信的安全性，同時避免中間節點干擾導致協議僵化；
• 提供類似于HTTP/2的多路復用能力，在網絡傳輸層增加了流的概念，解決了TCP協議的頭部阻塞問題；

文獻地址

協作神秘面紗OT算法的普及

我在2016年就全棧設計了文檔系統，目前在公司內部已發展了5個年頭，且已成為默認的Wiki知識庫系統。但由于是業余維護一直沒有更改原有的Websocket鎖模式，也規劃22年一定要重構一版完成實時協作的能力。當然，目前協作已經過時不再新鮮了，而背后的OT算法缺悄悄活了起來，已被應用到各種場景。在線圖片實時協作，項目實時協作，甚至視頻編輯也加入了OT。

OT算法的關鍵技術點為：定義原子操作，版本確認機制，操作轉換，客戶端狀態轉移。有點懵是吧？為了能讓大家通俗易懂，我也絞盡腦汁了，以下是通過可視化演示一下OT的魅力。

文獻地址：

• 深入理解Operational Transformation
• operational-transformation.github.io

最后

這幾年一直深陷業務，苦于鉆研，從17年前端網下線以后，就再也沒有寫過博客了。最近幾年由于工作職責變更，需要更多的關注技術發展方向，團隊管理模式，協作流程等。所以重新撿起來了Blog，也希望我這種一看就懂，一學就會的分享能夠給大家帶來一些靈感。

鏈接：
https://juejin.cn/post/7051901448044429349