> We need to get back to native UIs. Is it awfully hard? Yes it is. Do the users care? No, they don't. Many people want fast UIs.
I wouldn't say native UIs necessarily, IMO, but I definitely agree that something has to change.
Current systems are not only getting slower and less useful, but they're also getting harder to develop, test and maintain as well -- and, consequently, buggier.
The fact that there still are many old, TUI-based systems out there AND that users favor them over the newer ones exposes a lesson we've been insisting on overlooking.
You are correct, it doesn't matter how will the improvement happen as long as it does happen.
If Electron is rewritten in C / Zig / Rust / whatever and becomes much more lightweight then I'll be on board about using it myself.
But the abusive relationship between today's software and what is essentially supercomputers has to be ended and started anew on a more respectful foot.
The problem with electron is not the implementation - after all it is a bundled web browser and those are really really performant and written in C++. They pretty much make displaying a HTML document with complex CSS and running JavaScript as fast as possible (or at least close to it)
The problem is the abstraction level, instead of a locally running program manipulating objects that are turned into render instructions basically in a one-to-one fashion, there is a whole added indirection with generating and parsing HTML and then converting the dynamically created DOM into renderable elements.
Add that to the fact that it's reasonably simple to make a cross platform TUI, and I think you're on to something there. I'm ready to move forward to TUI's over the terrible GUI's we're all stuck with.
Indeed, and this "back to the TUI" I advocate isn't restricted to developer tools. I actually think of such replacement with end users in mind.
Maybe not necessarily something as radical as terminals, but anything providing the same programming ergonomics (in order to be easy to build and maintain) and constrained by the same restrictions (so that functional requirements get tamed).
At first, it would definitely sound as an involution, but I feel somehow confident that the market in general will accept such constraints as soon as the results become evident.
I agree completely. As long as displaying faithful image/video isn't a constraint, I don't see any reason why a TUI/similar would not be acceptable for any given task, after the user gets over the "text is scary" stage.
And even if your application needs to show graphics, you could easily do that on a separate, graphics-enabled pop-up window, while the forms, tables etc. would still be rendered by the TUI engine.
Out of curiosity, do you have a list? I'm always looking for good replacements.
I'm currently using nvlc and cmus for music playback, and then of course your standard complement of text editors etc. I like Lynx et al. for some web browsing, but compatibility is a pain.
- `lnav` for inspecting log files has turned out to be surprisingly good.
- Do you use `fzf` in tandem with your shell so you can also search your command history (and not just look for files)? I use that for like a year now and can't live without it.
- `mc` for TUI file management has been moderately alright.
- How about `ripgrep`? Can't believe I lived without that one too.
- Rust's tool `skim` (the command is `sk`) in tandem with `ripgrep` or `the_silver_searcher` to very quickly search in file contents in big directories has saved me a ton of time already (although I moved to search file contents in projects in Emacs since). To be fair, you can just use `fzf` instead of `sk` here though; I am just positively biased towards Rust.
- `ripgrep_all` allows you to search in ZIP archives, PDF docs, Office docs/spreadsheets etc. Really useful.
- `ht` is a Rust rewrite of `httpie`, the Python friendlier `curl`. I like `ht` much more because it doesn't incur any startup overhead and started replacing my scraping / syncing scripts with `ht` where applicable which is NOT everywhere because `curl` is extremely powerful and it doesn't often make sense to replace it.
- Command-line or in-terminal charting/plotting: `jp`. I have made a CSV file out of all file sizes on my NAS (bucketed by powers of 2) and then invoked it on the input. Here's a sample CSV from a random directory:
But your question makes me sigh. I really have to start a blog. I am a very practical guy and people usually love my posts (scattered on different forums) where I make such lists. I should roll my own blog static web site generator in Rust I suppose, because the existing ones are either slow or don't support what I need... So, not going to happen in the next year, most likely. :(
I'll have to try some of those out. I've used fzf a little, but haven't really looked at it enough to get the full productivity gains. I've heard of rg ofc, but ripgrep_all has flown under my radar thus far, and actually sounds amazing, I've got a decently large library of pdf's I keep losing stuff in.
The rest I haven't looked at, but will have to add to my list, they fill a couple voids I've been feeling.
> I should roll my own blog static web site generator in Rust I suppose, because the existing ones are either slow or don't support what I need... So, not going to happen in the next year, most likely. :(
It isn't powerful enough to support what you need I'm sure, but I actually did something similar a little while ago.
It's written in Rust, with dependencies on sh and markdown. I'm thinking about adding the ability to automatically execute an (optional) shell script in each directory, so that it would be easier to do things that markdown doesn't.
The code quality is atrocious (first Rust program of any size, and I'm not great at programming in the first place), but it may be useful. If you're interested in me adding that functionality, let me know, it may be the push I need to move it to the top of my pile.
The `sssss` program might have a potential. But let me give you an example: I want my every blog article to also have versions / revisions and I'd like visitors to be able to read the older versions as well as the last version.
I'd also like multilingual article ability (but I think some of the engines out there can do that). The more I think of it, the more I wonder if it should be something like Ghost.org: namely backed by sqlite and not naked files. But who knows.
I wouldn't say native UIs necessarily, IMO, but I definitely agree that something has to change.
Current systems are not only getting slower and less useful, but they're also getting harder to develop, test and maintain as well -- and, consequently, buggier.
The fact that there still are many old, TUI-based systems out there AND that users favor them over the newer ones exposes a lesson we've been insisting on overlooking.