If only the core was some sturdy C++ or Rust or whatever as opposed to JS and a nice GUI/Canvas lib as opposed to DOM.
Besides, they're still writing in a typed "language" (ts), so it's not like the dynamic language nature of JS that allows the VSCode base code to be developed incredibly quickly.
What really allows them to develop it incredibly quickly is the plugin API -- which allows tons of npm stuff to be ported and tons of JS programmers to create plugins for VS Code. A native statically typed based core would allow for that too. In fact the VSCode team already have moved some VSCode processing to C++ libs exactly for speed (and of course node itself is C++).
Using DOM for the drawing is faster (for a convenience perspective, not execution speed) yes, but with MS resources they could have made a streamlined equivalent that's much faster, more memory efficient, and doesn't have all the baggage of a web rendering engine. In fact, they have several native alternatives lying around they could make cross platform.
As it is, VSCode will ever have the burden of rendering to the DOM.
No, but it would "just be" an open source, MS backed, version of Sublime or TextMate. The concept of Visual Studio is different.
>We would get updates once a year instead of once a month.
The language the core is in is irrelevant as to whenever we would see updates. That's a concern of the release process.
>There are less C++ devs than JS devs.
Not really important, as most of the contributors are MS guys anyway. In fact a single person has made Sublime Text, an editor that offers most of what VSCode offers, with 1/100 the budget and manpower. If only it was Open Source too, or had a few more devs...
For what it's worth, the Visual Studio team now releases minor updates roughly every six weeks (including bug fixes and new features), and service updates almost weekly [1]. They also rely quite heavily on user feature requests [2].
[1] https://docs.microsoft.com/en-us/visualstudio/productinfo/vs...
[2] https://visualstudio.uservoice.com/forums/121579-visual-stud...
I'm not saying that it wouldn't have been as successful, but we're here, now, and it is. It's a great product regardless of the fact that it's written with HTML/CSS/JS.
Why not? Didn't hurt ST or TextMate much (though them being closed source did). And we still use Vim, written in C, 40+ years on, and it has tons of plugins...
>Would Microsoft have continued investment in the product if it hadn't?
MS developed Monaco for over a decade, with very little adoption, so why not?
Vim has a pretty huge community of plugins, and with NeoVim that plugin development has greatly accelerated. Intero, Fireplace, Vim FSharp (which works on regular Vim as well), and NeoComplete are excellent, and make NeoVim competitive with a lot of IDEs in my mind.
Part of the reason I don't use VS Code is that I really don't feel the need to run an instance of Chrome just to edit text. On my Mac, after loading a relatively large FSharp file, with FSAutocomplete (which is not known to be particularly efficient software), in NeoVim, it's taking so little CPU on the NVim side that it doesn't even register in Activity Monitor or `ps`. The same file loaded in latest version of VS Code (downloaded about thirty minutes ago) with the Ionide plugin is taking about 8% of the total CPU power.
With computers as powerful and wonderful as they are nowadays, I think you could make a solid argument of "Who the hell cares?", but in my mind, we have been editing text with full screen editors since the 80s, and had interactive IDEs since the 90s. If we could do this efficiently since the 90's, why should we opt for an inefficient solution now, especially if the efficient solutions are competitive?
Again, I'm saying this out of love. I use VS Code or Atom occasionally when I want to edit Markdown or HTML, and I think they are solid editors, especially considering that they are free. I understand that they are there to more to offer an open source and competitive solution to something like Sublime Text, and not to win-over the command-line-editor crowd, and at that I think they succeed. I just wish that an efficient framework like Qt, which has JS support, had caught on instead, since I think it would be a lot more efficient.
(I don't know if that is a great vision, but it is a good rationale to use Web tech for IDE development)
How low have we fallen from what programmers were concerned with memory use, and speed, and the right tool for the right job, and so on, and even Emacs was considered bloated...