Helix was originally meant to be a "batteries included" editor without any scripting/plugins. That PR intends to change this and so there is a bit of controversy around it. Overall it looks like the PR will eventually be merged.
The Mitos fork could have be made for totally unrelated reasons. This is really just my speculation.
I commented on that PR a few years ago and got downvoted, primarily for asking why they're using some random person's pet Lisp-in-Rust project over something more established, even Lua like Neovim is. I still don't understand why, but in the age of AI looks like we can build anything we want instead.
I know about steel as that is the Lisp I was referencing but it is unused anywhere else unlike Lua, and therefore only really maintained by one person which is not how I'd want a critical language to be used in an editor. Looks like Mitos is looking into using Wasm, from their Reddit comments.
Yeah I wondered this too! The website explains the features, but from what I can tell it's just the feature set of Helix. I'm sure there's a plan behind what the forker wants to do with the project, would be awesome if the website explained!
Loved helix and batteries included philosophy but was wishing for more batteries. Specifically the lack of a good diff viewer. Yes I can create a shortcut to lazygit but the way swapping between processes worked was buggy and uncomfortable.
And even though abstractly I like helix's keyboard model better than vim, I wish there was a way to just switch to vim mode because it is too ingrained.
Maybe this fork can address some of this either directly or by allowing plugins.
Similar for me. I understand the impetus to stick to only standard Language Server Protocol (LSP) features, but on the other hand support for what e.g. RustAnalyzer offers would be incredibly useful
for me.
I've been building my own personal editor, borrowing some of the features I enjoyed in Helix and other editors - https://github.com/joefreeman/aether - being able to deeply customise has been satisfying.
An articulated rationale for why a fork would go a long way for awareness of why an existing user of Helix might consider to use Mitos instead (or not) really needs to be the first thing we see on the front page of the site for Mitos.
One thing that really sticks out to me and gives me a feeling I won't consider to use Mitos, is the presentation further down on Mitos' front page of rendering of image files inside the terminal emulator. I rather that an image viewing program be opened, maybe called with options to not display interface widgets, and to be displayed in a new window tab. I use i3 or Sway, so I already have macros that do just this, and I don't fail to appreciate that others have this luxury (or not).
Alternative branches, or even forks like this are a good thing. Sometimes these help reach new consensus and merge back into the original project making the new project stronger, provided the original reason for a fork wasn't really issues of conflicting personalities.
I think a fork of Helix can be a step in the right direction. But "view images inside the terminal" doesn't pass the smell test. The mindset of displaying images inside of a terminal window and the macOS window decorations in the example screenshots, those two things together are part and parcel.
They allude it at the end by talking about faster iteration but the real, legitimate reason to fork Helix is that it is essentially inactive at this point
Yeah, and these features are very needed. People have been asking for a new release for half a year. There haven't been a lot of changes in the past 8 months, majority of them are grammar and theme updates.
BTW, if you compile helix from the main branch, source code indentation will be broken.
It's a fascinating time to launch a new code editor. I haven't properly used one for months (except some small .env changes and the like). Even Zed seems to be moving away from the "editor" part, into Delta.
Ok I'd like to bring up something a bit more bold/controversial: why are we building big TUIs at all? Like... ever? Isn't it pretty trivial to make your rust GUI native across the three major operating systems these days, or am I underestimating that?
I prefer a TUI to a heavy Electron app, don't get me wrong. But Helix (& Mitos!) seem like a baffling choice compared to Sublime Text. Not worse: I literally don't understand the appeal.
If I were to build an editor, I’d want the GUI platform-native so would probably go straight for Xcode and Swift.
If I had a strong aversion to Swift, I might consider a hybrid design where the UI is Swift and write a backend in a modern, fast language I prefer (Go/Rust/C# come to mind, but this isn’t a call-to-arms in the language wars). I believe this could be achieved since LSP works well as a backend server supplying IDE-level niceties, so I could keep most functionality implementations there. I’d have to have a strong reason though since Swift is a fine language, and AI does much of the writing now.
Then again, most devs live on a Mac and deploy to Linux, and are increasingly using Agents which may be better off cloud-hosted or at least sandboxed, so lightweight Swift UI and most logic in a headless cli app could be an interesting design choice.
But the important part to me would be low-bloat and native UI, and I’ve never found cross-platform UI frameworks to hold up in practice — even if only because different OSes necessarily have different ideas of idiomatic design, so you’d either be using least common denominator UI components that feel uncanny, or reimplementing the UI for each platform.
Have you found a language / framework combo that’s fast, fits into the OS well, and is _fun_ to write and use? Or is your idea that separate implementations are now so low cost — who cares — let the AI maintain them?
Legitimately asking in good faith, so please don’t interpret anything as snippy in there — it’s just my understanding of the state of the world. I’d genuinely love to learn about how cross-platform options have expanded if I’m missing something!
> lightweight Swift UI and most logic in a headless cli app could be an interesting design choice
With absolutely no hard data to back this claim, my instinct is that a library would be even better. Anything you can manage to fit into a library can be much more easily tested, and then you can define whatever frontends you want (CLI, SwiftUI, etc.) that wrap it, and even leave the door open for people to implement whatever UI they might want.
Depends on the split. You’re probably right — even after worrying about cross-language ABI stuff, compiled libraries would have many advantages.
But especially with Agentic AI, I could imagine some scenarios where being able to run the guts of your editor out of process, e.g. on a cloud box or even a local docker container, being pretty advantageous.
This is how Claude Code GUI works but to be fair that’s less of an editor.
I still feel like having that CLI be a frontend into a library that could then be reused by arbitrary GUI frontends as well would achieve basically the same thing.
In my mind, an application is basically a bunch of state, various ways of mutating or accessing that state, and then logic to present that state to the user. The ideal way to structure this seems like it would be putting the state behind an API that provides endpoints for the valid state transitions and for accessing the state without mutating it; at that point, you can wrap it with whatever interactive wrapper you want (a CLI, a GUI framework, etc.), and all of them will have identical semantics. An agent can use the CLI if that's what makes sense, a technical user with extremely strong opinions on GUI frameworks can wrap the library in the framework of their choice even if you don't provide a pre-built version of it. If anything, this approach seems like it makes even more sense in the agent of LLM coding; five years ago it would not be worth it for me to look at something like this and say "they provide a CLI and a Windows native GUI, but I really want a Qt GUI, so I'll make it myself", but nowadays I can probably just point whatever the best model that's available for free from OpenCode at a library structured like this and get something working without too much manual effort.
> If I were to build an editor, I’d want the GUI platform-native so would probably go straight for Xcode and Swift.
That's where we'd diverge. I'm a heavy user of Flutter especially in the age of AI because even if you could have the AI rewrite 6 different version for 6 different platforms, it's just a waste of your own tokens. Rust for desktop is good enough these days, with GPUI or iced, etc.
Ok so first off I haven't done this in the agential era myself. In fact, I've made multiple (small/toy-ish) TUIs in the meantime! So I'm something of a hypocrite off the bat lol -- my only excuse is that I'm pretty darn webpilled, AKA the ultimate cross-platform system ;)
That said: I indeed was referring to rust in particular[1], based on some vague recollections that I finally took some time to confirm:
1. There is indeed a host of relatively mature options for the mapping to the boring ol' native route(s): Qt through `cxx-qt`, FLTK via `fltk-rs`, wxWidgets via `wxdragon`, and Tk via... itself, I guess? GTK also has `gtk4-rs` and `relm` and is supposedly cross platform, but with some confusing caveats. See the very end for the other "just build three apps" options, on that note.
2. The most practical option for time-crunched, not-huge projects (IMHO) is anything that lets you still use web languages for styling; obviously this stretches the sense of "GUI", but it's also wildly popular and is still far better than a full Electron monstrosity. Namely: `tauri`(/`yew`/`leptos`) automatically ties into a separate WebView impl per OS, `dioxus` made their own impl to afford React-like rendering goodies, and `ply` seems like a really promising minimalist option. All actively maintained & growing.
3. It seems the default for not-technically-native-but-feels-native apps (i.e. most apps) is `egui`, which does WASM magic for you across platforms and web (!), or `iced` which seems far too Java-y for my tastes. Neither are at v1.0.0, but I blame the abandonment of semver for that goofiness -- both have sizable teams developing in them full time, with ~30k stars each. `slint` is more mature but seems targeted at IoT/embedded.
4. I'll be honest: I was really just hinting at "whatever Zed uses", since the thread's about text editors! It turns out to be `gpui`, their own custom (yet OSS) engine with a popular external metaframework: https://github.com/longbridge/gpui-kit . As above, does WASM wizardry. More niche options that similarly implement their own languages: `xilem`, `freya`, `floem`, and `ribir` are popular growing options with ~beta vibes (i.e. pre-v1.0.0 but, like, for real this time); `vizia` and `cushy` are more alpha vibes.
5. There's a crowd of "GPU-heavy" (?) frameworks that go beyond my capability to really assess in the first place, but `makepad` is the only one that seems definitely cross-platform. `kas`, `blinc`, `tessera`, `azul`, `pax`, `rosin`, and `rui` (nice snag, that) came up too, but are (pre-)alpha vibes. Game-focused ones also exist, somewhat bafflingly (people make games in Rust??): `imgui-rs`, SDL3 via `yakui`, and Bevy via `bevy_egui` all seem mature.
6. As a bonus there's options to just build a Flutter GUI and attach a rust process to its backside via `flutter_rust_bridge` (genius!) and/or (?) `Rinf`. I've never touched Flutter at all, so uhh take that as you will, I suppose.
7. Finally, to your Swift suggestion: I think you're privileging your OSX and/or Swift preference a lot, there. I'm not sure how that even gets to be cross platform based on what I'm seeing right now, but even if it it's possible, all the OSX-specific apps I see these days (RIP Orion...) put fear into the depths of my heart. What Swift would work for is the megacorp strategy: just implementing three separate apps! Via `UniFFI` or `cacao` for Mac, `windows-rs` for DOS, and any of the open ones above for Linux.
Sorry for a long response -- procrastinating my life for sure, though I have been meaning to do this research for a long time. So thanks for the excuse! Shoutout https://blog.wybxc.cc/blog/rust-gui-survey-2026/ an...
Honestly, I initially regretted posting my comment because besides a native iPhone app, I've never built GUI software. I did no research of my one and asked a very open-ended question and felt intellectually dishonest and lazy, and almost deleted it.
I'm so glad I didn't.
This comment is one of the most information-dense helpful resources I've read in a long time (and such a welcome reprieve from the "slop"), that anything I did to contribute to its existence was worth it.
Thank you so much for writing this, and I strongly recommend you post this somewhere very public — on your _beautiful_ personal site at the very least, and I'll do my best to spread it around. I've only built an exquisitely designed iPhone app, as the sole eng alongside a great designer, and barely considered anything but native because our brand was very high-end in the startup-of-a-lifetime great way, and we wouldn't settle for anything else.
I think you're underestimating this. I released a GUI app in Rust earlier this year, and I already feel like it was a headache because there was pretty much no way to avoid dynamically linking a bunch of stuff, at which point any confidence of it working across various distros went out the window, so I had to settle for an AppImage as the only binary that I distributed. I wasn't even trying to target Windows or MacOS but I have to assume that would complicate things at least as much.
I'm not saying it's insurmountable, but I don't think it's accurate to call it "trivial". There are comments on this thread mentioning that Helix hasn't released in a while but that it's relatively straightforward to build from source; I'm not confident that would be easy to preserve for a full GUI.
It's a lot easier to write and customize tuis. And it works over ssh. The appeal is probably that it's good, performant, functioning software. As a counterpoint what's the appeal of sublime over vim? What is the gui providing that I don't already have?
It’s just more convenient to stay in the terminal where I already do a lot of other things. Switching between guis is more of a hassle, since they try to support both keyboard and mouse but often not equally well
I have been building a batteries-included vim-like editor for a couple of years. It all started as a series of streamings but I really like where it is right now.
we still use text, only we no longer rely on these awesome vim, emacs, helix advanced features, instead you spit out commands in English, tell what you want to achieve, your AI does it for you, nobody bothers learning these systems
I can only imagine this being said from someone not really using these editors daily, I use Helix, so:
"xdjp" becomes "move this line two lines down",
"mic" becomes "replace text in current quotes with",
"A" becomes "at the and of the line add",
no thanks.
52 comments
[ 0.87 ms ] story [ 27.2 ms ] threadhttps://github.com/helix-editor/helix/pull/8675
Helix was originally meant to be a "batteries included" editor without any scripting/plugins. That PR intends to change this and so there is a bit of controversy around it. Overall it looks like the PR will eventually be merged.
The Mitos fork could have be made for totally unrelated reasons. This is really just my speculation.
https://github.com/mattwparas/steel
https://www.reddit.com/r/HelixEditor/comments/1wpt22a/mitos_...
And even though abstractly I like helix's keyboard model better than vim, I wish there was a way to just switch to vim mode because it is too ingrained.
Maybe this fork can address some of this either directly or by allowing plugins.
One thing that really sticks out to me and gives me a feeling I won't consider to use Mitos, is the presentation further down on Mitos' front page of rendering of image files inside the terminal emulator. I rather that an image viewing program be opened, maybe called with options to not display interface widgets, and to be displayed in a new window tab. I use i3 or Sway, so I already have macros that do just this, and I don't fail to appreciate that others have this luxury (or not).
Alternative branches, or even forks like this are a good thing. Sometimes these help reach new consensus and merge back into the original project making the new project stronger, provided the original reason for a fork wasn't really issues of conflicting personalities.
I think a fork of Helix can be a step in the right direction. But "view images inside the terminal" doesn't pass the smell test. The mindset of displaying images inside of a terminal window and the macOS window decorations in the example screenshots, those two things together are part and parcel.
The last release was in July 2025
The project has had hundreds of commits (incl major features) since that last release.
BTW, if you compile helix from the main branch, source code indentation will be broken.
I prefer a TUI to a heavy Electron app, don't get me wrong. But Helix (& Mitos!) seem like a baffling choice compared to Sublime Text. Not worse: I literally don't understand the appeal.
If I were to build an editor, I’d want the GUI platform-native so would probably go straight for Xcode and Swift.
If I had a strong aversion to Swift, I might consider a hybrid design where the UI is Swift and write a backend in a modern, fast language I prefer (Go/Rust/C# come to mind, but this isn’t a call-to-arms in the language wars). I believe this could be achieved since LSP works well as a backend server supplying IDE-level niceties, so I could keep most functionality implementations there. I’d have to have a strong reason though since Swift is a fine language, and AI does much of the writing now.
Then again, most devs live on a Mac and deploy to Linux, and are increasingly using Agents which may be better off cloud-hosted or at least sandboxed, so lightweight Swift UI and most logic in a headless cli app could be an interesting design choice.
But the important part to me would be low-bloat and native UI, and I’ve never found cross-platform UI frameworks to hold up in practice — even if only because different OSes necessarily have different ideas of idiomatic design, so you’d either be using least common denominator UI components that feel uncanny, or reimplementing the UI for each platform.
Have you found a language / framework combo that’s fast, fits into the OS well, and is _fun_ to write and use? Or is your idea that separate implementations are now so low cost — who cares — let the AI maintain them?
Legitimately asking in good faith, so please don’t interpret anything as snippy in there — it’s just my understanding of the state of the world. I’d genuinely love to learn about how cross-platform options have expanded if I’m missing something!
With absolutely no hard data to back this claim, my instinct is that a library would be even better. Anything you can manage to fit into a library can be much more easily tested, and then you can define whatever frontends you want (CLI, SwiftUI, etc.) that wrap it, and even leave the door open for people to implement whatever UI they might want.
But especially with Agentic AI, I could imagine some scenarios where being able to run the guts of your editor out of process, e.g. on a cloud box or even a local docker container, being pretty advantageous.
This is how Claude Code GUI works but to be fair that’s less of an editor.
In my mind, an application is basically a bunch of state, various ways of mutating or accessing that state, and then logic to present that state to the user. The ideal way to structure this seems like it would be putting the state behind an API that provides endpoints for the valid state transitions and for accessing the state without mutating it; at that point, you can wrap it with whatever interactive wrapper you want (a CLI, a GUI framework, etc.), and all of them will have identical semantics. An agent can use the CLI if that's what makes sense, a technical user with extremely strong opinions on GUI frameworks can wrap the library in the framework of their choice even if you don't provide a pre-built version of it. If anything, this approach seems like it makes even more sense in the agent of LLM coding; five years ago it would not be worth it for me to look at something like this and say "they provide a CLI and a Windows native GUI, but I really want a Qt GUI, so I'll make it myself", but nowadays I can probably just point whatever the best model that's available for free from OpenCode at a library structured like this and get something working without too much manual effort.
That's where we'd diverge. I'm a heavy user of Flutter especially in the age of AI because even if you could have the AI rewrite 6 different version for 6 different platforms, it's just a waste of your own tokens. Rust for desktop is good enough these days, with GPUI or iced, etc.
That said: I indeed was referring to rust in particular[1], based on some vague recollections that I finally took some time to confirm:
1. There is indeed a host of relatively mature options for the mapping to the boring ol' native route(s): Qt through `cxx-qt`, FLTK via `fltk-rs`, wxWidgets via `wxdragon`, and Tk via... itself, I guess? GTK also has `gtk4-rs` and `relm` and is supposedly cross platform, but with some confusing caveats. See the very end for the other "just build three apps" options, on that note.
2. The most practical option for time-crunched, not-huge projects (IMHO) is anything that lets you still use web languages for styling; obviously this stretches the sense of "GUI", but it's also wildly popular and is still far better than a full Electron monstrosity. Namely: `tauri`(/`yew`/`leptos`) automatically ties into a separate WebView impl per OS, `dioxus` made their own impl to afford React-like rendering goodies, and `ply` seems like a really promising minimalist option. All actively maintained & growing.
3. It seems the default for not-technically-native-but-feels-native apps (i.e. most apps) is `egui`, which does WASM magic for you across platforms and web (!), or `iced` which seems far too Java-y for my tastes. Neither are at v1.0.0, but I blame the abandonment of semver for that goofiness -- both have sizable teams developing in them full time, with ~30k stars each. `slint` is more mature but seems targeted at IoT/embedded.
4. I'll be honest: I was really just hinting at "whatever Zed uses", since the thread's about text editors! It turns out to be `gpui`, their own custom (yet OSS) engine with a popular external metaframework: https://github.com/longbridge/gpui-kit . As above, does WASM wizardry. More niche options that similarly implement their own languages: `xilem`, `freya`, `floem`, and `ribir` are popular growing options with ~beta vibes (i.e. pre-v1.0.0 but, like, for real this time); `vizia` and `cushy` are more alpha vibes.
5. There's a crowd of "GPU-heavy" (?) frameworks that go beyond my capability to really assess in the first place, but `makepad` is the only one that seems definitely cross-platform. `kas`, `blinc`, `tessera`, `azul`, `pax`, `rosin`, and `rui` (nice snag, that) came up too, but are (pre-)alpha vibes. Game-focused ones also exist, somewhat bafflingly (people make games in Rust??): `imgui-rs`, SDL3 via `yakui`, and Bevy via `bevy_egui` all seem mature.
6. As a bonus there's options to just build a Flutter GUI and attach a rust process to its backside via `flutter_rust_bridge` (genius!) and/or (?) `Rinf`. I've never touched Flutter at all, so uhh take that as you will, I suppose.
7. Finally, to your Swift suggestion: I think you're privileging your OSX and/or Swift preference a lot, there. I'm not sure how that even gets to be cross platform based on what I'm seeing right now, but even if it it's possible, all the OSX-specific apps I see these days (RIP Orion...) put fear into the depths of my heart. What Swift would work for is the megacorp strategy: just implementing three separate apps! Via `UniFFI` or `cacao` for Mac, `windows-rs` for DOS, and any of the open ones above for Linux.
Sorry for a long response -- procrastinating my life for sure, though I have been meaning to do this research for a long time. So thanks for the excuse! Shoutout https://blog.wybxc.cc/blog/rust-gui-survey-2026/ an...
Honestly, I initially regretted posting my comment because besides a native iPhone app, I've never built GUI software. I did no research of my one and asked a very open-ended question and felt intellectually dishonest and lazy, and almost deleted it.
I'm so glad I didn't.
This comment is one of the most information-dense helpful resources I've read in a long time (and such a welcome reprieve from the "slop"), that anything I did to contribute to its existence was worth it.
Thank you so much for writing this, and I strongly recommend you post this somewhere very public — on your _beautiful_ personal site at the very least, and I'll do my best to spread it around. I've only built an exquisitely designed iPhone app, as the sole eng alongside a great designer, and barely considered anything but native because our brand was very high-end in the startup-of-a-lifetime great way, and we wouldn't settle for anything else.
I'm not saying it's insurmountable, but I don't think it's accurate to call it "trivial". There are comments on this thread mentioning that Helix hasn't released in a while but that it's relatively straightforward to build from source; I'm not confident that would be easy to preserve for a full GUI.
https://youtu.be/eX1ZhXY0VZU?si=hUufOFS5ifTGeh-g
If you're looking for something like that I'd love if you could take it for a spin:
https://getred.dev
https://github.com/paradise-runner/toast
This is a lesson for any maintainer. Previously, helix was releasing approx every 6-months. It was unofficial but that was the rough cadence.
Then they stopped. But still committing updates.
Communities get accustom to convention and when even unofficial convention changes, the community will get frustrated.