IDEA vs VS Code的故事是一個低端顛覆高端的故事，VsCode幾乎吸引了所有年輕和時髦的觀眾。同時，JetBrains似乎仍能保持生存，這主要歸功于辛勤的工作和運氣。

考慮到VS Code迭代開發(fā)的速度（很大程度上要歸功于JS + Web渲染器的生產(chǎn)力），我認為VS Code將對JetBrains IDE構(gòu)成威脅，但它似乎永遠無法完全達到JetBrains功能級別。JetBrains中的每個IDE功能都實現(xiàn)得很好，無論是代碼分析，重構(gòu)，導(dǎo)航，運行/調(diào)試，運行測試，添加新文件，git集成還是上下文功能（如添加程序包引用等）。JetBrains中的一切都更好一些。我認為VS Code是一個無處不在的智能編輯器平臺，具有成千上萬個插件，介于精美的文本編輯器和IDE之間，我經(jīng)常使用它進行快速的開發(fā)更改，快速搜索文件夾，前端UI開發(fā)，嘗試新語言或編寫文檔。但是，如果我必須開始一個漫長的開發(fā)進程，我將轉(zhuǎn)向JetBrains，我發(fā)現(xiàn)它的工作效率更高。

感覺它們來自不同的開發(fā)哲學(xué)。Vscode是“文本編輯器”或“代碼編輯器”。通常，這意味著它相當輕巧，可以支持每種語言，具有高度可配置性和可擴展性，但是沒有很多非常深入的功能，依賴第三方擴展來提供更深的功能。另一方面，Jetbrains可在為一種特定語言顯式構(gòu)建的IDE上工作。考慮CLion for C，它只有兩年的歷史了！他們投入了大量資源來支持一種語言及其所有相關(guān)的工作流程。簡而言之，代碼編輯器通常會具有很多可配置性和可擴展性的網(wǎng)絡(luò)，而（jetbrains）IDE往往會深入研究單一語言或工作流，而擴展性卻較低，并且受支持的語言本身也具有很深的可配置性。

Intellij允許您將所有其他jetbrains IDE的大部分功能安裝為插件。另外，他們的大多數(shù)IDE都具有使用多種其他語言進行編碼的能力，這些語言與核心體驗是分開的。例如，他們大部分都可以與javascript生態(tài)系統(tǒng)集成。Intellij實際在后臺有一個jetbrains IDE。這個IDE是一個單一平臺，可以使用任何語言的插件和代碼，并且可以根據(jù)您的喜好進行自定義。從表面上看，Jetbrains并沒有完全向公眾發(fā)布這個IDE。他們在這個IDE基礎(chǔ)上提供了不同的配置和不同的默認值，然后將其鎖定并以不同的名稱運送每一個配置文件中。所有這些IDE基本上都是在完全相同的，在一個核心平臺上運行不同的插件。這就是為什么CLion才幾年還算不錯的原因。這是因為只要新開發(fā)一個插件，將其推入了現(xiàn)有的生態(tài)系統(tǒng)中即可。這與Vscode沒什么不同。兩者都是可以插入新功能的編碼平臺，只是jetbrains鎖定了一些自定義功能，并通過插件捆綁銷售其IDE，從而提供了更好的核心體驗。使Jetbrains變得更好的是這種集中而又質(zhì)量較高的功能組合，感覺具有凝聚力。使Jetbrains更糟的是，他們的中央平臺變得臃腫，導(dǎo)致一切都很緩慢，需要花費很長時間啟動，并且可能會鎖定。

IDEA產(chǎn)品類似Borland IDE或Quick Basic之類的空間，而VSCode似乎更像是JavaScript時代的Emacs。

不知道現(xiàn)在有多少開發(fā)人員用一種語言編寫代碼。我每天都會在Go，Dart和C ++之間往返，因此使用像VSCode這樣的IDE（具有從擴展名到快捷方式再到片段的熟悉功能）是一個很大的幫助。

我也是維護幾種語言，JetBrains IDE都內(nèi)置了對JS / TypeScript +所有流行的Web文件格式的一流支持，無論您使用何種后端語言。對于C＃，F(xiàn)＃和VB，我使用Rider。對于Dart，Java和Kotlin，我使用Android Studio，但是如果我需要使用Java / Kotlin進行大量開發(fā)，那么我會跳到IDEA。對于TypeScript / JS npm項目，我使用VS Code進行較小的更改，但是對于較長的開發(fā)則使用WebStorm。對于Swift軟件包，我將Xcode用于開發(fā)，將VS Code用于git，更新文檔并運行發(fā)布腳本。對于所有其他語言我將使用VS Code，這主要是因為我沒有安裝IDE。

Jetbrains IDE性能是如此糟糕，我覺得煩惱。我發(fā)現(xiàn)VSCode是功能最豐富的編輯器，我可以忍受它的速度。從資源消耗或啟動速度上來講，VSCode絕不是理想的選擇，但使用VSCode編寫rust，node.js，前端js等語言是一條黃金之路，而使用其他更輕便的編輯器則是一個很大的降級。Sublime的前景令人難以置信，但就我的經(jīng)驗而言，其功能不足是不言自明得。我會把錢和精力投入到本機的、性能更高/更輕便的VSCode中。

我同意，我也認為關(guān)于vs代碼作為通用文本編輯器的評論是很公平的。

Intellij在企業(yè)環(huán)境中具有巨大的優(yōu)勢，在企業(yè)環(huán)境中，一致性，統(tǒng)一性和易于更換的團隊成員至為重要，VSCode是高度可定制的代碼編輯器，適合不同的用例，團隊中的每個成員都希望盡可能地自定義工作經(jīng)驗。

我不認為Jetbrain僅憑努力和運氣就能保持領(lǐng)先。一旦您了解了Intellij的內(nèi)幕，很明顯它們具有顯著的體系結(jié)構(gòu)優(yōu)勢。VS Code是使用LSP提供重構(gòu)和導(dǎo)航的文本編輯器，而Intellij是在前端具有良好文本編輯器的重構(gòu)引擎。Intellij是一個在抽象語法樹上運行的結(jié)構(gòu)化編輯器。創(chuàng)建LSP的難點是提供諸如重構(gòu)和導(dǎo)航支持之類的功能，而這些正是IntelliJ為其語言插件提供的功能。為了實現(xiàn)給定的重構(gòu)和導(dǎo)航支持水平，LSP開發(fā)人員需要比jetbrains插件開發(fā)人員花費更多的精力。從我的角度來看，Jetbains似乎并沒有通過努力工作和運氣來保持領(lǐng)先，而通過智能架構(gòu)和設(shè)計使他們能夠以更少的努力來生產(chǎn)高級，高價值的功能似乎并沒有保持領(lǐng)先。

我并不認為IntelliJ和VSCode是競爭者。VSCode可與Atom和其他功能齊全的文本編輯器（vim，emacs）競爭...在新一代程序員中，VSCode受到了極大的歡迎，他們認為那些舊編輯器既顯得老派又對用戶懷有敵意。VSCodes對Java，Python和Golang的支持遠遠落后于IntelliJ。在我們撰寫大量Go語言的Microsoft團隊中，IntelliJ / GoLand開發(fā)人員和VS Code開發(fā)人員之間有50/50的分配比例，并且有更多人從VS Code轉(zhuǎn)向IntelliJ，反之亦然。

我已經(jīng)使用IntelliJ for Java很久。對于JS和Go，我使用VSCode。

JetBrains的東西幾乎一樣。不支持諸如如何配置其自動格式化程序以兼容特定設(shè)置的美化工具。不支持開箱即用的必需配置。而代碼構(gòu)建build和IDE通常生活在完全不同的世界中。Android Studio可能會在“索引編制”時掛起整個mac，并且通常需要“重置緩存并重新啟動”，而在VS Code中可以正常工作。

VSCode對于TypeScript非常非常好。天哪，我敢肯定VSCode本身是用TypeScript編寫的！但這并不適用于所有語言。當在帶有Java后端的Web應(yīng)用程序上工作時，我仍然更喜歡Idea，因為它對Java更好，對于TypeScript也足夠近的好，因此它在所有方面都遙遙領(lǐng)先。

我對VS Code的看法是，他們對開發(fā)容器和ssh的支持是最好的，并且是殺手級功能。

我非常想在IDEA中使用VS Code的遠程開發(fā)功能，并在YouTrack中跟蹤其遠程開發(fā)功能。我想要的只是我的代碼可以在任何地方運行，而我的本地計算機是IDE。mutagen.io最終成為了我的答案。在了解了它的工作原理之后，我對其進行了設(shè)置，并且效果非常好。這些天我主要在進行PHP開發(fā)，并且有一個LAMP堆棧作為docker容器在服務(wù)器上運行。同步幾乎是即時的（99％的時間），罕見的沖突很容易解決，并且調(diào)試當然仍然有效。我唯一缺少的是協(xié)作編輯，我仍然必須跳到VS Code來做。對于協(xié)作/結(jié)對編碼，與編輯器無關(guān)的解決方案真的很棒。

我使用VSCode進行我95％的開發(fā)，感到更開心。我將其余的5％用于IntelliJ。

我不喜歡使用JetBrain工具。無論我在使用它們的任何機器上，它們都感覺呆滯且腫脹。啟動編輯器需要花費很多時間，而且往往反應(yīng)遲鈍，或者您會感覺到屏幕上出現(xiàn)的字符與按鍵之間的延遲。

根據(jù)Jetbrains自己的調(diào)查，VS Code確實越來越受歡迎：從2017年的7％的Python開發(fā)人員到2021年的29％，而Pycharm仍然保持在33％左右。

VSCode不會殺死IDEA，但這對Jetbrains來說是一個巨大的警告 他們最好投入更多的精力來解決自一開始就困擾著他們的IDE的緩慢啟動和性能問題。