前端打包工具大亂鬥

2021-10-22 05:15:49 字數 1177 閱讀 3400

過去很長一段時間,人們使用 webpack,或基於 webpack(taro)的外掛程式系統,構建複雜應用

隨著專案複雜度的公升高,一層層 loader 和 plugin,將開發鏈路大大延長

過長的開發鏈路,除了打包時間變慢,更重要的是嚴重影響力除錯,測試,維護

除此之外,case by case 的 ast 轉譯方式,擅自扭曲語法語義,也是很不地道的行為

從去年開始大家開始意識到這個問題,開始製造鏈路更短,開發體驗更好的打包工具,前端進入打包工具大亂鬥的 2021 年

其中一類是基於 native module 機制開發 bundless 工具,比如 vite,snowpack,wmr

其中 vite 的作者是知名前端框架 vue 的作者,wmr 的作者則是 preact 團隊

這類工具的機制是一模一樣的,本質上是乙個 dev server,面向的目標群體是現代 web 應用,比較重要的是對 ssr 的實現

svelte/roolup 作者開源一種 native module 跑到 node 的思路,被 vite,snowpack 所使用

因為 ssr 同構是必須將 native module 跑到 node 端的

與此同時,這類框架還需要借助 rollup 或 esbuild 進行打包和預處理

所以與其說他們是打包工具,不如說他們是不依賴 webpack 的構建工具

前面的第一類工具主要是針對現代瀏覽器,而非 web 平台,也有對應的替代方案

比如 metro 是專門用來打包 rn 的,它的作者是 facebook 官方,未來會成為 rn 的標配

這一類工具的共同特點是,他們都是因為非 web 平台產生,並服務於這特定場景

因為 js 不再是一等公民,通常這類工具無法使用 rollup,esbuild 等工具

但無論如何目的都是一樣的——拋棄 webpack

第三類工具則以 esbuild 為代表,它的作者是大名鼎鼎的 figma cto

這類工具通常使用非 js 語言,利用其他語言的天賦來提公升編譯速度

比如前面提到的 vite 就使用 esbuild 進行預編譯

工具眾多,大家除了根據自己的業務嘗試新型框架,更重要的是理解這些框架的內在

另外,對於公司而言,歷史包袱先於新業務,剷平一座 shi 山的意義遠大於開始乙個新專案

所以這些工具其實都不是對標歷史債務的

該自己扛的,還得自己扛

NOIP模擬 顏料大亂鬥

開始看到前面的題目那麼水,到這題時就開始胡思亂想了,待修改莫隊?樹套樹?30棵線段樹?然後我打了30棵線段樹,常數十分的大啊!超時30分tat。然後旁邊的人把30個顏色的值放到同乙個節點上,然後就對了,常數小而已嘛!雖然兩個方法的時間複雜度理論上是一樣的。其實就是每個節點儲存30個顏色是否出現過,然...

JZOJ4603 顏料大亂鬥

這裡就不罵辣雞出題人了 這題查詢和修改區間 l r 竟然 l 可以大於 r!而且白色是顏料1!注意上面那些細節,開30顆線段樹就可以ac了。include include include include define fo i,j,k for int i j i k i define fd i,j,...

JZOJ 4603 顏料大亂鬥

畫師傅又要開始畫畫了,這次他花了三天三夜將一堵牆塗成了白色。但是畫師傅有個頑劣的 小花,小花討厭畫師傅對ta始亂終棄,所以趁 畫師傅不在用不同的顏料將牆塗來塗去。然而畫師傅為了保護他的大作,設定了乙個監控機制a。a每隔一段時間會 查珣某一段牆上的顏料的種類數,並將其記錄下來。現在畫師傅回來了,看到五...