9 ms·
You might like to follow OniVim2: https://onivim.io https://onivim.io It is native, cross platform, and not based on Electron. It also uses Vim as the core edi
by jordwalke 7y ago
You might like to follow OniVim2: https://onivim.io https://onivim.io
It is native, cross platform, and not based on Electron. It also uses Vim as the core editing engine.
- grok2 7y agoIf not Electron, is it native or does it use some other web engine?
- nxrabl 7y agoIt uses the authors' own Revery [0] framework, based on ReasonML and GLFW. So there's Javascript in the stack, but no Chromium. [0] https://github.com/revery-ui/revery https://github.com/revery-ui/revery
- jordwalke 7y agoReasonML does not imply JavaScript - it can compile natively using the OCaml native compilers - and that's exactly what Revery does. GLFW is also native/C.
- pcr910303 7y ago> 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 https://github.com/revery-ui/revery [1] https://github.com/revery-ui/revery/blob/master/README.md#design-decisions https://github.com/revery-ui/revery/blob/master/README.md#de... [2] https://news.ycombinator.com/item?id=20612195 https://news.ycombinator.com/item?id=20612195
- jordwalke 7y agoI'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 7y agoFWIW 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 7y ago