以Vite為代表的前端構(gòu)建工具進入加速賽道

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

核心代碼：

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

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

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

核心原理

• 開發(fā)環(huán)境下，模塊以原生 esm 的形式被瀏覽器加載。
• 生產(chǎn)環(huán)境下，模塊被 Rollup 以傳統(tǒng)方式打包，而且做了很多默認優(yōu)化。
• 開發(fā)和生產(chǎn)環(huán)境下共享同一套 Rollup 插件機制，所以單個模塊的編譯在開發(fā)和生產(chǎn)環(huán)境下是一致的。

框架優(yōu)勢

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

豐富的生態(tài)

更多構(gòu)建工具介紹：
css-tricks.com/comparing-t…

以Vue3+Ts+Vite+Pinia組合的高效開發(fā)套件

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

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

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

工具包分享

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

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

Web3D圖形技術的研究

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

需求背景

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

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

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

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

產(chǎn)出

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

分享

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

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

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

原理性

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

首先，數(shù)據(jù)結(jié)構(gòu)，低代碼編程的數(shù)據(jù)結(jié)構(gòu)是完全托管的， 用戶可以創(chuàng)建任意的數(shù)據(jù)表，選擇各類型字段。 除了數(shù)據(jù)庫通用的字段類型外，低代碼編程一般會封裝額外的字段類型。

其次，數(shù)據(jù)關聯(lián)，能否根據(jù)模型，自動生成多層級交叉調(diào)用的代碼，成了低代碼工具關鍵性指標。

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

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

案例

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

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

我們團隊從17年就一直在折騰這方面，起初只是解決一些靜態(tài)頁面組裝，到后來就是可視化裝修業(yè)務頁面。但因為人員精力不足，缺乏迭代和更新也是停留于內(nèi)部，未能落地業(yè)務。不過也算打下了基礎，去年又重新?lián)炱饋恚瑓⒖糐son schema的規(guī)范，重新基于業(yè)務研發(fā)了自己的效率工具平臺，以解決中后臺，業(yè)務單一的營銷活動，官網(wǎng)，數(shù)據(jù)大屏等需求。

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

DevOps已徹底重構(gòu)了研發(fā)各環(huán)節(jié)

認識DevOps

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

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

上線以后，偶爾會出現(xiàn)的結(jié)果

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

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

DevOps平臺

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

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

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

體驗流水線

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

首先，創(chuàng)建流水線，綁定github倉庫和分支，配置倉庫webhooks，并監(jiān)聽提交事件。

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

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

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

5G在加速Web通信的增強

WebRTC

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

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

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

更多關于WebRTC文章

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

Chrome97發(fā)布，QUIC協(xié)議到來

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

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

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

文獻地址

協(xié)作神秘面紗OT算法的普及

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

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

文獻地址：

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

最后

這幾年一直深陷業(yè)務，苦于鉆研，從17年前端網(wǎng)下線以后，就再也沒有寫過博客了。最近幾年由于工作職責變更，需要更多的關注技術發(fā)展方向，團隊管理模式，協(xié)作流程等。所以重新?lián)炱饋砹薆log，也希望我這種一看就懂，一學就會的分享能夠給大家?guī)硪恍╈`感。

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