7月安卓手機性價比榜：努比亞+紅魔兩款新機入榜
7月登場的新機有努比亞Z50S Pro和紅魔8S Pro，除了三星之外目前唯二的兩款搭載超頻版驍龍8Gen2處理器的產品，而且努比亞和紅魔也一貫有著不錯的性價比，所以在本次的性價比榜單
大家好，我卡頌。
最近，一款基于Rust的linter工具Oxlint在國外前端圈引起熱烈討論，很多大佬給出了高度評價。
他相比于老大哥Eslint有什么優勢？未來他會取代老大哥么？本文讓我們來聊聊這個話題。
oxlint是Oxc項目旗下的一款產品，Oxc作為一款Rust實現的前端工具鏈集合，包括：
與Oxc抱有同樣設計理念（都是基于Rust開發的工具鏈工具）的還有Biome與Ruff，其中：
Oxlint之所以引發熱烈討論，主要原因是「他的性能太炸裂了」。
尤大用Oxlint跑了Vue3倉庫，～590個文件跑～200條規則，僅用時50ms。
我自己（蘋果M1 pro，32G）跑一個大概50個文件的小項目，也只用了18ms，官方宣稱的在基準測試中比Eslint快50～100倍果然不是空穴來風。
當然，除了「性能優勢」，Oxlint與老大哥Eslint還有很多區別。接下來我們從3個角度對比Oxlint與Eslint：
Eslint誕生于2013年，他相比于競爭對手（JSHint、JSHint）最大的優勢是「提供了大量可選的規則，并且一些場景下對于不符合規則的代碼可以自動修復」。
但是，隨著時代的進步，他的優勢逐漸變為劣勢 —— 開發者不再需要大量自定義規則，而是需要「開箱即用的規則集的最佳實踐」。在此理念下誕生了很多新產品，比如：
Oxlint吸取了上述產品的優點，默認提供了一套開箱即用的規則集。這套規則集主要關注「代碼的正確性」（比如「語法錯誤」、「冗余代碼」、「容易造成誤解的語法」）而不是「代碼的細節優化」（比如語法的性能、風格）。
所以，你只需要在項目執行如下命令，就能滿足常規的校驗：
npx oxlint@latest從易用性上看，Oxlint比Eslint強很多。
當linter診斷出問題后，會給開發者提供相關信息。Eslint給的信息通常比較簡短，只告訴你「為什么報錯」。比如對于如下代碼：
let a;通過信息「a is defined but never used」可以知道報錯原因是「a定義了但未使用」。
但如果是更復雜的規則，簡短的信息可能并不能直觀表達「具體哪里報錯」以及「解決辦法」，很多時候我們還需要查下規則文檔，看看這條規則的具體含義，再結合報錯的代碼分析。
相比于Eslint，Oxlint的信息更直觀與準確。舉個例子，下面的代碼執行后會得到「數字翻倍的數組」：
const numbers = [1, 2, 3, 4, 5];const result = numbers.reduce((accumulator, current) => { return [...accumulator, current * 2];}, []);// [ 2, 4, 6, 8, 10 ]console.log(result);這里每次執行reduce回調都會將數組展開，當數組比較長時會造成性能問題。
對此，Oxlint的信息包括三部分：
這段示例代碼比較簡短，可能體現不出Oxlint信息的價值，讓我們看看下面這段報錯信息：
一眼就能看出是哪個reduce（紫色字體）中的哪個展開操作（青色字體）引發的問題。
雖然有些同學會說：如果項目大了，lint信息這么詳細看的人腦袋痛。
但我們要知道 —— 「你能提供，但我不用」和「你不能提供」完全是兩個概念。
從「診斷可讀性」看，Oxlint比Eslint更優秀。
「參與成本」是指開發者自定義規則的成本。Oxlint是Rust編寫的，如果開發者自定義規則也得寫Rust，那成本就太高了。相比之下，Eslint的規則都是JS編寫的，成本低很多。
Oxlint從2個角度出發嘗試解決這個問題：
你別自己寫了，官方將常用的規則都寫好了。
截止本文發稿，官方實現了200個左右的規則，從名字就能看出，這些規則是從各個常見庫的最佳實踐中摘出來的，比如：
實現一套專門編寫規則的DSL。
Oxlint正在研究開發一套DSL，專門用來編寫規則。至于這套DSL何時問世、好不好用暫不得知。
從「參與成本」角度看，Eslint完勝。
基于已知的現狀 —— Oxlint規則參與成本高于Eslint，只要這個問題不解決，就一定存在某些Eslint支持，但Oxlint不支持的規則。所以，要完全取代Eslint，短期內并不現實。
但是，就像Vite之于Webpack，前者也沒有實現后者的所有功能。但只要滿足開發者最常見的90%需求且體驗更好，就能從Webpack手中搶走大部分用戶。
Oxlint顯然也是這么做的 —— 他們建議開發者在lint-staged或CI設置中先運行Oxlint再運行ESLint。這樣，大部分常見問題還沒走到Eslint這一步就被Oxlint擋住了。
這種方式能顯著提高lint流程的速度，且上手成本極低。所以很可能在開發者中快速普及開。
當這種方式普及后，隨著Oxlint規則覆蓋度與日俱增，會在「最常見的90%需求」中逐漸取代Eslint。
屆時，會形成一種Oxlint為主，Eslint為輔（處理少量特殊規則）的局面。
從這個角度看，Oxlint的贏面很大。
雖然Oxlint有著不錯的前景，但當前他還存在一些不足，比如：
Oxlint原生支持js(x)、ts(x)，但不支持Svelte、Vue模版語法。
比如下面代碼中警告的應該是第1、3行，但是第2行也被標記了。
相信隨著開發團隊的持續投入，社區生態的形成，Oxlint及其背后的Oxc會有不錯的未來。
[1]基準測試:https://github.com/oxc-project/bench-javascript-parser-written-in-rust。
[2]基準測試:https://github.com/oxc-project/bench-nodejs-resolver。
[3]eslint-plugin-antfu:https://github.com/antfu/eslint-plugin-antfu?tab=readme-ov-file。
本文鏈接：http://www.www897cc.com/showinfo-26-48349-0.htmlEslint 會被 Oxlint 干掉嗎？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 使用 Sidecar CRD 優化 Istio 性能
下一篇： 消息隊列，聊聊發送消息的四種姿勢~
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號