[pcr910303]

> It is native

It isn’t native in this context; As a sibling comment mentioned, OniVim2 uses revery[0], which uses it’s own widgets (not native ones) like flutter[1].

Quoting from my old comment[2]:

> We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch.

> Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y.

[0] https://github.com/revery-ui/revery

[1] https://github.com/revery-ui/revery/blob/master/README.md#de...

[2] https://news.ycombinator.com/item?id=20612195

[jordwalke]

I'll adopt whatever definition you want "native" to mean for the discussion - and under your definition of native, I would say it's pretty clear that users of text editors and developer tools don't care much at all about "native"(your definition of using the platform provided widgets). Just look at the market share of developer tools and IDEs/editors that don't use stock platform widgets. They are the ones that have become dominant. The problems that people have with the dominant players that have gained traction is the performance. You might be able to make the case that using stock widgets matters for non-developer tools (and I would only partially agree there), but for developer tools when people say they want "native" they are more likely to mean they want the performance that more often comes with natively compiled languages without a VM. It makes sense that developers would trade stock platform-widgets in exchange for an editor with greater cross platform reach because users of these tools benefit from network effects of these tools having wider reach. They want someone to have written the plugin/extension they're looking for.

Personally, I'm not looking to increase the ways that I'm locked into my current operating system, so all else equal, I'd favor an editor that runs everywhere.

[Crinus]

FWIW personally with "native" i mean "native widgets too, where possible". It isn't always possible and i'm ok with that, but if your application uses a text edit area, a treebox for project files, a menu bar, a bunch of tabs and perhaps a toolbar (the "standard" IDE layout -AFAIK- introduced by MSVC4 back in the 90s and replicated by pretty much every IDE and most "programming" text editors since then) then every mainstream (and most niche) desktop OS outside of Linux/X11 has native widgets that provide 99% of the functionality (with that missing 1% being the text edit area itself and some minor UI stuff).

(and also FWIW, of all text editors personally i use Notepad++ on Windows and Geany on Linux - though as i really dislike Gtk3 and Geany switched to that, i'm looking for some alternative that uses a more snappy and lightweight toolkit - for now the Debian version i use is still on Gtk2 but that is just a matter of time to be replaced)

[jordwalke]

Under that definition of "native", it's pretty clear developers don't care very much about having "native" text editors/IDEs, wouldn't you agree? You can look at editor usage to see how they are voting.

[Crinus]

Yeah most developers probably do not care, but it isn't like nobody cares (for example i do and i read comments like mine on HN often, so there are others who do too). At least when it comes to text editors there are options and you can use whatever you want regardless of what a complacent majority votes for :-P.

Though i also believe that the functionality some people want from their applications is only available on (what i see as) applications with inferior UIs and they'd rather get used to these UIs than not have the functionality - that is, their vote is for the functionality, not for the UI.

[jordwalke]

The other thing to consider is that developers spend up to ten hours a day in these editors. The biggest benefits of OS-coherent UI is that an application is quickly learnable for the first week. But when you use an editor for multiple years, all day long, many would trade that for increased customizability.