It's a fine point if made in isolation, but TUIs tend to be more technical and useful simply because they require using a terminal at all. GUIs tend to be made for the non-technical iPhone audience.
So while I'm not fundamentally opposed to graphics, I'm absolutely opposed to the "average user" culture surrounding it. I don't care about the "normal person", I don't want "user experiences" that hide the computer, I want all of the computer's primitives exposed so that I have full control.
Yeah. This is Unix nerd bs and toxic behavior and silly belief that only terminals deliver complex behavior.
I was visiting a radio test lab in last February for our new product. They use a professional software which was written in WPF. The assistant there was flying with the keyboard shortcuts.
I recommend every self-describing Unix or terminal fan to watch videos of photo or video editors / VFX people on YouTube. They are hella fast.
Absolutely true. But the OPs statement is not without merit. While there is a lot of professional software for which GUI is the correct choice, there is also a lot of "GUI slop" which is just a GUI to look good on marketing and to be easier to onboard new users at the expense of long term effectiveness.
If you use the terminal a lot then TUIs keep you there wo the need to manage yet a other window in the OS. For e.g. you can run nvim in another pane in tmux.
There are customers who would like to see attribution on changes where AI contributed (companies, users, etc). True, that's not everyone, but you can query our repo for the issues for which this feature was implemented.
The rationale I suppose is those customers what to be more careful with code that was contributed by AI.
I don't see how this would actually help. If people don't want to disclose they used AI they will just strip the message from the commit.
Maybe those customers should just be more selective with the people they allow to contribute to their project?
Also, this kind of message doesn't even bring valuable info: it doesn't explain how the AI was used (could be 99% vibe-coding, or just a quick "Please review current changes" + minor fixes at the end?), which model was used, etc. Like other commenters here I can't see this as anything else than a marketing push for Copilot.
Don't take it personally though, you are probably not the one that should be taking the heat since the change was directly pushed by your product manager.
Claude tends to disregard "NEVER do X" quite often, but funnily enough, if you tell it "Always ask me to confirm before going X", it never fails to ask you. And you can deny it every time
There are plenty of examples in the RL training showing it how and when to prompt the human for help or additional information. This is even a common tool in the "plan" mode of many harnesses.
Conversely, it's much harder to represent a lack of doing something
Calculators are a particularly bad example for your case. There was absolutely hyperbole against calculators when they were introduced. [1]
With similar sentiment as well
"They make us dumb"
"Machines doing the thinking for us"
Cars were definitely seen as a fad. More accurately a worse version of a horse [2]
If you looked through your other examples, you'd see the same for those as well.
Some things start as fads, but only time will tell if they gain a place in society.
Truthfully it's too early to tell for AI, but the arguments you're making, calling it a fad already don't stand up to reason
We did an A/B test of an old SPA app, and a modern re-write using SSR and server-rendered pages.
By every performance metric, the new app was faster.
But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site.
I'm not sure if this is a universal experience, but I think a lot of other sites that tried the CSR -> SSR move had similar experiences. It's just harder to talk about, since it goes against the usual narrative.
SSR can feel worse than SPA if you don't get the end-to-end latency under a certain threshold. If your SSR pages are taking upward of 100ms to render on average, it's going to start to feel like shit once you factor in the network latency.
My design goal for modern SSR pages is 500 microseconds render time on the server. A modern CPU can crank through several gigabytes of UTF8 text per second. There really isn't any excuse from a technology perspective. SSR pages being perceived as clunky & slow boils down to a skill / people / organizational problem. The computers and associated networks can definitely do it well.
Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.
Looked at the first one, and that's in a game setting? And they test 600 ms??
edit: The second one is more useful IMO. It's hard to get under 100 ms with a roundtrip, but < 300 ms should be doable, right? So you do lose the sense that you are directly manipulating data. In most cases I think that's a good trade-off. Exceptions would be things like Google docs, but that's also because it's a well made app I trust to actually sync my data without loss. Unlike most SPAs..
300ms for network latency both ways, with server potentially doing its own network calls for data to fulfill the request, interpolating the html, and then browser rerendering client seems like a stretch
I am curious to identify what your users are perceiving that isn't be being captured by your metric. If it is accurate and not just rhetoric that MOST of your users are asking for a rollback for purely performance reasons, that is a very extreme outcome.
Are your p90 metrics testing:
- navigation after first load?
- users who are going to the app after it is cached on their browser?
Are your actions going through server actions or rest apis? Do you have metrics on those?
> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.
You're also arguing for CLIs which are absolutely great. But TUIs provide none of the composability of CLIs nor the malleability of GUIs