VSCode 與 WebStorm 橫向對比

VSCode 與 WebStorm 橫向對比

吾輩的博客原文連接: https://blog.rxliuli.com/p/52...

前言

不能認清本身，怎能看清別人？

最近很長一段時間，VSCode 彷佛成爲了前端口中的標準開發編輯器，前端圈處處都在推薦 VSCode，勸說其餘人放棄 Sublime, WebStorm, Atom 之流，彷彿真的是信巨硬，得永生通常。而吾輩做爲一個長時間使用 JetBrains 系 IDE 的全沾開發者，這裏就來對比一下 WebStorm 與後起之秀 VSCode 以前的異同點吧？

比較

插件生態

VSCode 的生態無疑很是好，基於 Web 技術構建的編輯器一樣可使用 Web 技術開發插件，而 Web 開發人員的數量也確實很是龐大。且因爲其輕量跨平臺的特性，受到不少開發者的喜好，將之做爲主力文件編輯器或者將其打形成 IDE 使用。它們的插件市場首頁分別以下

VSCode

WebStorm

WebStorm 官方給出的插件總數是 1607，而 VSCode 吾輩並未找到插件的總數量，但顯而易見，VSCode 的插件數量應該遠遠高於這個數字。並且你能夠看到 WebStorm 下載量第一的插件僅僅只下載過 5,558,762 次，而 VSCode 的熱門插件的下載數量是以 M 來計算的。咱們來搜索一下前端流行打包工具 webpack，對比一下結果。

VSCode

WebStorm

是的，VSCode 搜索到了 16 個插件，而 WebStorm 的搜索結果是。。。0？不瞭解 WebStorm 的小夥伴可能會有疑問，難道 WebStorm 不支持 webpack 嘛？那要它何用，仍是拉出去砍了吧！
泥萌先別急着掀桌子，箇中原因且聽吾輩細細說來。之因此出現這種狀況，主要是由於兩者的策略不一樣形成的。WebStorm 的目標是讓用戶擁有開箱即用的生產力工具，下載安裝完成後就能夠當即進行項目開發了，因此它將不少功能內置了 IDE 之中，或者是由官方開發插件出來，而後直接集成到 IDE 中，給我的開發者開發插件的機會很少。
而 VSCode 因爲官方的開發團隊沒那麼強大，並且又是免費的開源產品，因此理所固然只能發動廣大人民羣衆的力量了，因此有不少插件就只能交給第三方開發者進行開發和維護。而這點也形成了安裝完 VSCode 以後並不能當即使用，還須要下載插件、進行配置等一系列操做。
以上二者模式的孰優孰劣早有人分析過，這裏吾輩只說本身的使用體驗。WebStorm 的開箱即用作的確實比 VSCode 更好，但問題在於若是官方不支持的話就會很難受，由於其實並無太多人同時精通前端和 Java（是的，必須使用 Java 開發插件）。這也是吾輩目前仍然使用 VSCode 做爲主力文本編輯器編輯配置文件，以及使用它寫 Markdown 文章的緣由，包括這篇文章亦是經過 VSCode 寫出來的。

附: VSCode 能夠經過一些插件的同步功能避免每次安裝都須要配置的問題，但插件的同步還存在一些小問題。並且這種操做自己也是一個問題。
附: 插件開放讓第三方實現與官方本身實現並集成的優劣之分參考知乎的一篇文章: Visual Studio Code 有哪些工程方面的亮點。
經過插件來擴展功能的作法已是司空見慣了，但如何保證插件和原生功能同樣優秀呢？歷史告訴咱們：不能保證。你們能夠參考 Eclipse，插件模型能夠說是作得很是完全了，功能層面也是無所不能，但存在幾個煩人的問題：不穩定、難用、慢，因此很多用戶轉投 IntelliJ 的懷抱。可謂成也插件，敗也插件。問題的本質在於信息不對稱，它致使不一樣團隊寫出來的代碼，不管是思路仍是質量，都不一致。最終，用戶獲得了一個又亂又卡的產品。因此要讓插件在穩定性、速度和體驗的層面都作到和原生功能統一，只能是一個美好的願望。
來看看其餘 IDE 是怎麼作的，Visual Studio 本身搞定全部功能，而且作到優秀，讓別人無事可作，這也成就了其 「宇宙第一 IDE」 的美名；IntelliJ 與之相仿，開箱即用，插件無關緊要。這麼看起來，本身搞定全部的事情是個好辦法，但你們是否知道，Visual Studio 背後有上千人的工程團隊，顯然，這不是 VS Code 這二十幾號人能搞定的。他們選擇了讓你們來作插件，那怎麼解決 Eclipse 所遇到的問題呢？
這裏分享一個小知識 ——Eclipse 核心部分的開發者就是早期的 VS Code 團隊。嗯，因此他們沒有兩次踏入同一條河流。與 Eclipse 不一樣，VS Code 選擇了把插件關進盒子裏。
這樣作首先解決的問題就是穩定性，這個問題對於 VS Code 來講尤其重要。都知道 VS Code 基於 Electron，實質上是個 node.js 環境，單線程，任何代碼崩了都是災難性後果。因此 VS Code 乾脆不信任任何人，把插件們放到單獨的進程裏，任你折騰，主程序妥妥的。
VS Code 團隊的這一決策不是沒有緣由的，正如前面提到的，團隊裏不少人實際上是 Eclipse 的舊部，天然對 Eclipse 的插件模型有深刻的思考。Eclipse 的設計目標之一就是把組件化推向極致，因此不少核心功能都是用插件的形式來實現的。遺憾的是，Eclipse 的插件運行在主進程中，任何插件性能不佳或者不穩定，都直接影響到 Eclipse，最終結果是你們抱怨 Eclipse 臃腫、慢、不穩定。VS Code 基於進程作到了物理級別的隔離，成功解決了該問題。實際上進程級別的隔離也帶出了另外一個話題，那就是界面與業務邏輯的隔離。

智能提示

做爲寫代碼的工具，代碼提示已經司空見慣了。可是，就算一樣是代碼提示，有的代碼提示只是簡單的代碼片斷（snippets），而有的倒是基於代碼語法樹分析進行的，甚至於編輯器會學習使用者的習慣，將最經常使用的提示放在最前面。WebStorm 從始至終一直都是第三種，而 VSCode 最近官方纔開發了基於 AI 自動學習的智能提示插件 Visual Studio IntelliCode。

VSCode

WebStorm

前端支持

前面提過，VSCode 生態很好，基本上不少語言/框架都有支持，並且官方也有一些很是優秀的插件。可是，有一些地方很重要，VSCode 對於 HTML/CSS/JavaScript 這些 Web 基本元素的支持相比於 WebStorm 確實能夠說的上是糟糕。

先來測試前端三劍客: HTML/CSS/JavaScript。

VSCode

WebStorm

能夠看到，對於 HTML/CSS 之間的代碼提示、跳轉這些基本功能，VSCode 其實並無作好。現代前端說是再也不寫 HTML 了，但實際上終究仍是要寫（即使是 JSX 仍是要符合寫 HTML 的直覺的），VSCode 代碼提示在這裏明顯不太夠看。還有一點也頗有趣，VSCode 在打完 document.querySelector('#hello') 以後完全沒了動靜，而 WebStorm 在 style 輸入完成以後，馬上就有了各類 CSS 屬性提示了。

附: VSCode 中經過輸入 h1.hello#hello Tab 以後就獲得代碼是一種前端 HTML 代碼編寫方式，被稱爲 Zen Coding。但實際上，這種編寫方式在代碼提示方面存在劣勢，因此使用 WebStorm 時並未演示。
附: VSCode 引用文件路徑提示須要插件 Path Intellisense

對於庫的開發者而言最難受的地方是 VSCode 實質上依賴於 TypeScript 才能作到代碼提示，若是你也像吾輩是一位 JavaScript SDK 的開發者，那麼也會遇到這件使人鬱悶的事情: 若是想要使用你的 JavaScript SDK 的 VSCode 用戶有正常的代碼提示的話，你就必須接觸 TypeScript。要麼使用 TypeScript 重構整個 SDK，要麼寫 .d.ts 專門爲 VSCode 維護一份註釋文檔，詳情能夠參考文章 JavaScript => TypeScript 遷移體驗。

前端支持

前面提過，VSCode 生態很好，基本上不少語言/框架都有支持，並且官方也有一些很是優秀的插件。可是，有一些地方很重要，VSCode 對於 HTML/CSS/JavaScript 這些 Web 基本元素的支持相比於 WebStorm 確實能夠說的上是糟糕。

先來測試前端三劍客: HTML/CSS/JavaScript。

VSCode

WebStorm

能夠看到，對於 HTML/CSS 之間的代碼提示、跳轉這些基本功能，VSCode 其實並無作好。現代前端說是再也不寫 HTML 了，但實際上終究仍是要寫（即使是 JSX 仍是要符合寫 HTML 的直覺的），VSCode 代碼提示在這裏明顯不太夠看。還有一點也頗有趣，VSCode 在打完 document.querySelector('#hello') 以後完全沒了動靜，而 WebStorm 在 style 輸入完成以後，馬上就有了各類 CSS 屬性提示了。

附: VSCode 中經過輸入 h1.hello#hello Tab 以後就獲得代碼是一種前端 HTML 代碼編寫方式，被稱爲 Zen Coding。但實際上，這種編寫方式在代碼提示方面存在劣勢，因此使用 WebStorm 時並未演示。
附: VSCode 引用文件路徑提示須要插件 Path Intellisense

對於庫的開發者而言最難受的地方是 VSCode 實質上依賴於 TypeScript 才能作到代碼提示，若是你也像吾輩是一位 JavaScript SDK 的開發者，那麼也會遇到這件使人鬱悶的事情: 若是想要使用你的 JavaScript SDK 的 VSCode 用戶有正常的代碼提示的話，你就必須接觸 TypeScript。要麼使用 TypeScript 重構整個 SDK，要麼寫 .d.ts 專門爲 VSCode 維護一份註釋文檔，詳情能夠參考文章 JavaScript => TypeScript 遷移體驗。

自動修復

咱們在平常開發中常常會遇到一些低級問題，而編輯器實際上是有可能幫咱們自動修復的。這裏便對吾輩瞭解的一些問題進行對比，問題詳細信息請參考文章 JavaScript 規範整理

注: VSCode 沒有原生的自動修復功能，必須使用插件才行。

分類	對比項	VSCode	WebStorm
命名規範
	不要使用拼音命名	支持	支持
	函數中的變量	支持	支持
	內部變量	不支持	不支持
	不要使用無心義的前綴命名	支持	支持
ES6
	優先使用 const/let	支持	支持
	使用新的函數聲明方式	支持	支持
	優先使用箭頭函數而非 function	不支持	支持
	不要使用 if 判斷再賦予默認值	不支持	不支持
	優先使用 Map 作鍵值對映射而非傳統的對象	不支持	不支持
	優先使用模板字符串拼接多個字符串變量	不支持	支持
	當獨立參數超過 3 個時使用對象參數並解構	不支持	支持
	不要寫多餘的 await	支持	支持
	不要使用 == 進行比較	支持	支持
	使用計算屬性名替代使用方括號表示法賦值	不支持	不支持
	簡單的選項列表優先使用 Map 而非數組	不支持	不支持
	存放 id 標識列表使用 Set 而非數組	不支持	不支持
邏輯代碼
	不要判斷一個 Boolean 值並以此返回 Boolean 值	支持	支持
	不要使用多餘的變量	支持	支持
	不要使用嵌套 if	不支持	支持
	不要先聲明空對象而後一個個追加屬性	不支持	不支持
	不要使用無心義的函數包裹	不支持	不支持
	不要使用三元運算符進行復雜的計算	不支持	支持
	若是變量有所關聯則使用對象而非多個單獨的變量	不支持	不支持
	應該儘可能解決編輯器警告	不支持	不支持
	使用類型定義參數對象	不支持	不支持
	儘可能扁平化代碼	支持	支持
	自執行函數前面必須加分號	不支持	不支持

下面是一張 WebStorm 官方使用自動修復的動圖

重構

提及重構的話，VSCode 能夠簡單的說是作的太少，而 WebStorm 則是相反作的太多，下面繼續以表格的形式進行對比。

分類	操做	VSCode	WebStorm
重命名
	變量重名名	支持	支持
	複雜變量重命名	不支持	支持
	全局重命名	支持	支持
	正則重命名	存在 bug	支持
	文件重命名	不支持	支持
提取
	提取表達式爲變量	支持	支持
	提取代碼段爲函數	支持	支持
	提取函數到新文件	支持	支持

WebStorm 重命名文件

Git/GitHub 集成

VSCode 的 Git 支持一直不太行，就算加了插件 GitLens 也沒法比得上 WebStorm。

分類	操做	VSCode	WebStorm
Git
	commit 提交	難用	支持
	push 推送	支持	支持
	pull 拉取	支持	支持
	merge 合併	支持	支持
	歷史記錄	難用	支持
	reset 回退	支持	支持
	revert 回退	難用	支持
	stash 暫存	支持	支持
	branch 分支操做	支持	支持
GitHub
	分享到 GitHub	不支持	支持
	從 GitHub 選擇拉取	不支持	支持
	分享到 Gist	支持	支持

放兩張圖對比一下

VSCode GitLens

WebStorm

歷史記錄

不知你是否曾遇到過，正在編輯着一個文件，忽然斷電，或者是由於其餘什麼緣由，致使文件內容被清空了。或者是誤刪了代碼以後以前的代碼還沒提交，又不能撤回那麼屢次，致使代碼重寫的經歷呢？吾輩就曾經經歷過，因此對本地歷史記錄這個功能至關重視，然而很遺憾，VSCode 依舊須要第三方插件 Local History 才能支持。

VSCode Local History

WebStorm

二者相比主要有如下不一樣

對比項	VSCode	WebStorm
原始文件是否爲人類可讀	是	否（XML 不列入人類可讀格式中）
是否能夠添加標籤	否	是
是否能夠對比	是	是
是否能夠合併	否	是

主題配色

二者都支持黑暗主題，並且都是默認設置，也一樣支持使用插件定製界面。下面是二者的截圖

VSCode

WebStorm

事實上，上面二者都使用了主題。VSCode 是 Monokai，WebStorm 是 Material。但其實 WebStorm 的 Material 主題 仍是存在一些 Bug 的，例若有些地方圖標莫名的錯位之類，VSCode 目前吾輩還不曾遇到過這類問題。

使用性能

WebStorm 確實很吃內存，尤爲是項目剛剛打開的時候，索引會瘋狂地吃 CPU/內存/硬盤，若是電腦性能不行的話這個過程所需時間可能泡麪都夠了。但基於 Chrome 內核的 VSCode 在使用各類插件打形成前端 IDE 以後吃的內存也並很多。吾輩打開了項目 rx-util，能夠看到 VSCode 每一個插件確實都放在了單獨的進程裏（Chrome 系的習慣 #笑），相比之下 WebStorm 只有兩個進程，其中一個仍是啓動的 nodejs，總體對比下來其實相差不大。

總結

其實在 Atom/VSCode 出現以前，WebStorm 由於在這個領域沒有對手而發展緩慢，它們的出現使得 WebStorm 有了壓力，良性競爭，這固然是好事。即使如此，就目前而言，VSCode 做爲一個 IDE 來說仍然比不上 JetBrains 全家桶系列。說了上面這麼多，總的來講: 若是你須要一個文本編輯器，那麼推薦你用 VSCode，由於它既漂亮又生態豐富，想寫點什麼很方便。可是，若是你須要真正開發項目，則 WebStorm 更加合適，徹底開箱即用的體驗，不須要安裝/配置任何插件就能馬上開始項目，強大的編輯器可讓你寫代碼更舒服一點。（實際上是沒錢就用免費的 VSCode，有錢就上 WebStorm 啦！）