But VS Code first and foremost uses a web-browser for UI. How much does the choice of a UI-technology really constrain the rest of your application and its architecture?
I would argue that with a good architecture, the choice of UI-platform should place near zero effective constraints on the rest of your application, how it's structured and how it performs. It should certainly not be a critical component of your overall design, it should be an implementation detail.
Are you arguing otherwise? Can you come up with some concrete examples where the choice of UI-library causes troubles other places in the application? If not, it seems you're more or less agreeing with my original statement.
And as such, I don't see any fundamental problems using a web-browser in a text-editor.
Those IDEs are all much slower in my experience, and even Sublime is outmatched in terms of plugins. Because it's just so damned accessible with VS Code. If it runs good enough on the hardware you're using, wtf does it matter?
Note: native means the platform's native toolkit, running with the best performance on that platform. E.g: Java or C and C++ for Android, C and C++ for Linux, C and C++ and Obj-C for macOS, C and C++ for Windows, etc.
Things that are not native: Python, .NET, Xamarin, JavaScript, Java on anything except Android, etc
That's an interesting claim, given that Visual Studio (not VS Code) is native through and through and still it's orders of magnitude slower to work with on any sizable code-base compared to the "slow" editor VS Code.
It's almost as if you could say that on modern hardware the architecture of the application dictates overall performance much more than the technology used to implement it.
But yeah, that would certainly be madness, so let's not go there, eh?