If many people believe this is the case, why not? All articles get some common types of responses based on the topic, this is just one topic/response combo that you happen to disagree with.
>It's a trade off: performance for a cross platform JavaScript app development.
It's an unnecessary tradeoff.
If a single developer can create ST from scratch for Windows, OS X and Linux, then surely GitHub or Microsoft (for VSCode) can create a cross platform native set of UI components in C or C++, wrap them, and have the rest of the development (plugins etc) happen in JS (to keep the familiar language, easy access to npm modules, etc).
One of the reasons why some people are switching from ST to Atom/VSCode is the former's tortured development schedule, which has seen months or years go by without an update. Contrast VSC, which reliably delivers a heap of improvements every month. JavaScript is probably responsible for a big portion of this. Again, it's a tradeoff.
> then surely GitHub or Microsoft (for VSCode) can create a cross platform native set of UI components in C or C++,
Maybe they can. Or maybe they can't, and if they tried then they'd have the same slow pace as ST. You don't know.
That said, one of the Atom developers says using web technologies made development harder in many ways.[1] Very few solo developers can match a team with Microsoft's resources, and a monthly release schedule is more about discipline than anything else.
I am pretty sure the project being open source and in the hand of a team in a big company instead of an independent developer has more to do with it.
Because such comments tend to be repeats, making them not interesting. They also tend to derail interesting discussion. When there's an article on an interesting detail about X, but the top comment litigates why X should even exist, the interesting part of the article never gets discussed. And when that happens on all threads that involve any aspect of X, it's boring.
Someone already has done it. An one-man-shop built Sublime Text by himself.
Surely it's not having JS as an extension language as opposed to Python (the only difference between ST and what I propose) that's making it difficult.
>Furthermore, is there even an actively maintained, open source, cross platform, development-focused text editor with native UI components?
There's a "cross platform, development-focused text editor with native UI component" that's working great.
Whether there's an open source editor like that is orthogonal, since what I'm discussing is whether is technically feasible to create such a browser -- and the existence of ST proves that it is (and that's by a single developer: with resources such as that GitHub or even better MS, have, it would be much easier).
The choice of license is just a decision after that.
>> "Sublime Text 2 is mostly coded in C++ and uses a custom UI toolkit." ... [0]
How many other devs/teams are going to reasonably take that on.
(And how do you think the debugging story of his custom framework compares to Chrome Devtools).
The minimap extension is made easy because they can just throw some HTML in a side pane, the image preview plugin just leverages the image displaying abilities of the browser, custom styling is as easy as throwing some CSS in a file, the extensions which let you preview the web page you are working on right in the browser use the full extent of the browser, the plugin that lets you easily preview markdown just uses a simple markdown->html converter then just displays the HTML/css. Themes are just a set of CSS which targets certain classes. Plugins can move, change, hide, show, do anything.
It also let's plugin authors do things the original developers never imagined possible. 3D object preview using webgl in a custom pane, replacing the whole implementation of tabs with something else, completely redesigning how the sidebar works and looks because it's all just HTML.
And while none of that can ONLY be done in a browser, the fact that a browser is the UI means that it's much easier, much quicker, and much more maintainable.
But in order to achieve an outcome such as: "an editor that's cross platform and is programmable in JS", using Electron and/or the DOM is not a necessary tradeoff at all.
