Earlier quoted context omitted.
Not anymore it isn't. "Claude, make this a web app".
Just what I need! A bloated react app to manage my systemd units
Just use something like Tk or wxWidgets.
Why TUIs are back
151–160 of 443 posts
Re: Why TUIs are back
#152Earlier quoted context omitted.
I’m relatively certain it’s just this at the end of the day. Everything I see people doing in their custom built TUIs or claude/codex CLI can be done, likely even easier, in a simplified IDE or easier to scan UI, but it feels nice/cool/cyberpunk/work-like to look like you’re doing more. Everyone will have a “reasonable” explanation though for why they have to stay in the terminal even when they aren’t really coding a…
No it can never be the same. The terminal is about not having to switch from the keyboard. My entire workflow is tmux panes with different TUIs and terminals. Not to mention performance, with a neovim IDE you may have tens of them open in different panes for example. I wouldn't try that with VSCode.
You can make even lighter weight and just as keyboard driven GUIs. The only downside, as you say, is them not integrating with Tmux.
Re: Why TUIs are back
#153I think part of it is also that we're able to still LARP as full developers of complex systems while vibe coding by seeing an interface that makes us look like l33t h4xx0rs even though we're just pressing continue 15 times
I thought that that was the case for me, but then I tried using Claude Code through the desktop app last week and it was so bad. Slow, glitchy... I went back to the TUI in no time.
Re: Why TUIs are back
#154Earlier quoted context omitted.
I’m relatively certain it’s just this at the end of the day. Everything I see people doing in their custom built TUIs or claude/codex CLI can be done, likely even easier, in a simplified IDE or easier to scan UI, but it feels nice/cool/cyberpunk/work-like to look like you’re doing more. Everyone will have a “reasonable” explanation though for why they have to stay in the terminal even when they aren’t really coding a…
Hot take: TUI’s default to providing utility, GUI’s are prone to extra style/bloat. Obviously both are capable of the other. The vanilla HTML styles look bare, so you have do _something_. TUI’s look sort of cool in their simplest form.
It's an aspect I've wondered about, constraints do make you consider what's essential. For example in btop (screenshot in the article) the graphs are rendered with dots at low resolution, if there was another version where those graphs were full resolution is it telling you meaningfully more?
Re: Why TUIs are back
#155> The hardcore, moved to vim or emacs, trading immediate feedback and higher usability for the steepest learning curve I’ve seen The only hard part about vim is to be forced to strecth the finger up to Escape for what is essentially the most essential function in a modal editor: Going back to command mode. The ideal workflow is do a quick edit and go back to command ("normal") mode instantly. The fact that Escape is…
Not sure if this is bad form but i’ve always loved using jk for escape. It feels so natural to roll your index and middle fingers to get back to normal mode. I agree, too, besides reminding myself to use numbers before movement commands there was really nothing that felt super hard about vim. It almost disappointed me, I always heard the jokes about not being able to quit it!
Yes but jk does not work in other contexts (shell vi modes at least for me) and it's actually to have Escape closer to home to quickly get out of a situation
To be fair I mostly use `/` + (n/N) + Enter with `incsearch` on (by default in nvim), I feel it's really the superior way to move around and it has deprecated a lot of my vim-fu.
In the same way, apart from occasinal `ciw` (or other text-objects), I do most of my edits with `:s/old/new`. I don't even use a complicated regex as sometimes it's just easier to write one or two simpler ones. It's just faster to not have to go to a specific location before you make an edit.
Re: Why TUIs are back
#156Earlier quoted context omitted.
Yes but then you get used to jj (or jk) which might not be available on other vi modes (shells vi modes, gdb, glide browser ?) and it's overall quite nice to quickly escape any situation by having the key be closer. Ctrl + [ would be acceptable if it wasn't, imo, the most important function of the editor. EDIT: My bad, you can do it with Glide apparently
I've yet to come across something with vim bindings that lacks a .vimrc where you can map 'jk'. Either way, switching back to ESC is as annoying as it is in the first place.
Well I have given at least one example. Do you not use bash/zsh/fish/nushell vi modes ?
Re: Why TUIs are back
#157It's nuts that software developers are allowed to design user interfaces at all. They're incapable of making a user interface that isn't text. It's like if plumbers designed houses, they'd make all the floors slope downward, because that's the easiest way for pipes to run.
Oh we need multiple windows we can move around/resize? Let's make them text windows. We want people to be able to quickly select options? Yeah make those text boxes. We want to quickly compose documents with some kinda style/formatting? Yeah they'll need to write more text to format it (but let's not make any apps to easily view the text in formatted mode).
Re: Why TUIs are back
#158Because nobody is investing in native UI development. Electron is proof that if there were a simple to use GUI stack that companies would adopt it.
Zed did. I know it has it's fans, but it doesn't seem to be generating a stampede of adoption despite what looks like a monumental effort to build a GUI system from the ground up.
What I do not like on Zed or electron GUIs is lack of customization. Older IDEs using sdks like Swing, JWT, QT, GTK etc. allowed user to design its user interface using drag and drop. ie compare older IDEs like eclipse or idea and try to create layout which fills screen with information important for you. And then try to do the same with vscode or zed. I like functionality and speed of zed but UI customization is too limited for me. It might be design choice or sdk limit I am not sure.
Re: Why TUIs are back
#159TUIs are extremely more portable, and offer a more uniform UX across platforms.
Re: Why TUIs are back
#160Earlier quoted context omitted.
To me the worst case is trying to develop some small utility like a tool to search in files using regex. Because if you are developing something large, the amount of time you spend dealing with packaging, distribution, etc., is small and you don't care about file sizes. But if I want to, say, develop the app for Windows. That is easy. You get a tiny binary to just opens a form and runs with a double click. No install…
I want to say you could statically link a GUI application, but I'm pretty sure libpthread doesn't cooperate on static linking.
libpthread is fine with static linking. Where you run into issues is libraries like libresolv that use configuration files in a specific path.