Actually the main thing I want is to be able to use my phone however I like, and install whatever I want, without Google telling me whether I have their permission to do so or not.
> My partner got the Moto G Stylus 2025 after we swore off Samsung last year.
I've been wanting to get away from Samsung for years, but keep coming back because of the s-pen. I've yet to find another manufacturer that makes a decent phone with a proper stylus. As in, a stylus which the device recognises as being something different to your finger. Most styluses use the same technology as the cheap ones you can buy on Amazon and use on any phone: all they do is imitate the finger. As far as I know, the Moto stylus phones are like that, right? That makes them very awkward to use for many things e.g.:
S-pen -> scroll down a PDF with my finger -> highlight with the pen
Regular stylus -> scroll down a PDF with my finger -> select highlight option in app -> highlight with stylus, being very careful not to touch the screen anywhere with my finger -> select browse option in app
With the latter, you have to specifically tell the app every time you are switching to/from finger and stylus. With the former, the app knows the difference.
If you give me a high end phone with a proper stylus and GrapheneOS, I'd probably never look back.
Yeah I've been wondering about this in regards to the honor magic stylus. If it can do real palm rejection. Do you have experience with this one perhaps? Since you mention you saw some other manufacturers.
Except there was nothing "cool" about them. Vibe-coding ugly looking GUIs with slop-code backends is not interesting or impressive in 2026. Literally anyone can do it, and I'm pretty sure 90% of HN readers are aware that it's possible. Plus it did nothing to further the claimed purpose of the article, which was to explain why you shouldn't make TUIs.
I found most of the article completely unreadable. I was actually beginning to wonder if the HN post had linked to the wrong article, as it had nothing to do with TUIs until the very end. It was just a long list of "look at this slop code I made" and "look, here's another one!".
The whole article reads as a post around jealously on the popularity of TUIs and writes a pseudo-intellectual rant about them.
While I don't use most of them, but I can see why TUIs they are popular around devs. But in this post it reads like this:
"I don't like slop TUIs because they are popular, but please look at my vibe coded slop GUIs and I like vibe coding them and you should too"
One of the worst, if not part of my top ten worst blog posts I have ever seen on this orange site and absolutely do not listen to that horrible take that the author just wrote.
A lot of vibe-coded GUIs aren't fast, so this particular issue changes nothing. You're describing a property of the software development method, not TUIs vs GUIs.
I like TUIs for largely the same reasons as you, but I don't think this is actually a valid criticism of the article. It specifically addresses this by pointing out that you can make your GUI keyboard driven if you want to, so this isn't really an advantage of TUIs per se. It just happens that TUIs tend to be keyboard focussed while GUIs tend to be mouse focussed. But that's a design choice rather than an inherent property of TUIs vs GUIs.
I agree that I found the article to be poorly written. Mainly because it takes a long time to make its point. I didn't really need to see a million examples of the author's vibe coded slop before getting to the topic which the title suggested the article would be about.
> I didn't really need to see a million examples of the author's vibe coded slop before getting to the topic which the title suggested the article would be about.
Agreed. One would hope the article would go into detail of how to make a great GUI (including tips on how to make sure it’s easy to navigate with a keyboard).
If your app absolutely must rely on the cloud for every one of its interactions, then fine. If not, you're just applying band-aids to a problem of your own making. Many apps could easily be local only, or local first. If you're not constantly accessing the network for information which could be stored locally, then you don't need to hide your app's slowness behind animations.
Canva replaced PowerPoint. Canva is cloud based and PowerPoint is not. There's so many apps that are cloud only so that corporate it no longer has to manage installations and users don't need to ask IT for permission anymore. I think SaaS doesn't really work without the cloud, you could technically do what adobe does but why bother with app distribution and windows' quirks. Cloud based web apps are write once, run anywhere come true with no installation required. Cloud based is more convenient for the user and the developer, at the cost of app runtime speed
I like this example. A lot of people would prefer to use PowerPoint because they can still use their files and templates they made last year even if Microsoft doubles the price of Powerpoint, removes features, discontinues the product, or goes bankrupt.
Just nerds I think. I'm not seeing any evidence that people who want freedom from the cloud make up any sizeable market segment. Most corporations actually prefer the opposite - they prefer a monthly fee and continuous silent updates.
They literally unlicense the product out from under you as part of windows update. You’re the one having to sue, unless you never connect your machine to the internet anyway.
I have seen many companies migrate to gsuite away from Microsoft. It's perfectly compatible with excel, word and PowerPoint files unless you use macros
I'm not familiar with Canva but I don't see any technical reason why every interaction would need to rely on the server. Since Canva uses client-side JavaScript, it could be designed so that the local version of a document updates immediately and the cloud version syncs with the local version as soon as possible.
I would guess Canva already does something like this.
(1) Keep manufacturer's Android plus some plausible apps and data in a reserved part of the drive. (2) GrapheneOS runs from the other part of the drive. (3) Make sure PIN screen designed to not give away the OS. (4) When duress PIN is entered, erase GrapheneOS and restore manufacturer's Android. (5) Now you won't be charged for having GrapheneOS because they won't know you had it.
The important thing is that I could learn to use a flint and steel pretty easily if I wanted to. I don't need to carry out that particular task, but my ability to adapt to new problems means I can carry out more relevant tasks when needed. The most useful part of school and university for me wasn't that I learned the difference between a cirrocumulus and a cirrostratus cloud in geography class. It's that I learned how to learn.
If we let children cheat their way through school and justify it by saying they don't really need to think for themselves anymore, then we're going to end up with a generation of adults who struggle to take on any difficult tasks at all. I suppose your counter-argument to that will be "but we can just hand over everything to the AI" but that's an essentially an argument that humans should be considered obsolete altogether. I sincerely hope that that's not a path we end up going down (although I'm genuinely scared that it is).
