> Personally I think it's a biggest mistake to use browser engine for a text editor. We already knew how slow and clunky the browsers are and thanks to vscode and atom our text editors are becoming the same
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?
Just because you can make a slower text editor doesn't really demonstrate anything unless the person you are arguing against would have used that slower one (and "architecture" is definitely something constrained by an implementation decision as critical as "implemented using a web browser").
Sure. Any concrete implementation detail constrains your architecture and freedom to some extent.
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.
Then go ahead and "do it better"... so far VS Code has how many plugins? and how many users compared to other editors (excluding the cli editors vim/emacs etc). Yeah, sublime is faster and has a lot of aging plugins that haven't kept up... and there are IDEs that do more.
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?
Visual Studio is not native, large parts of it are built in .NET. Hence the slowness.
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?