You're right to point out the speed, but it is just not true that GUIs can't be fast. You can have screens that load quickly and shortcut keys etc.

You just have to make fast navigation and data entry a high priority. The assumptions and approaches people make today mean that generally isn't the case. With a TUI there is a hard limit on the amount of data you can load and that helps as a starting point.

- Often it's hitting a server is that is far away rather in the same building.

  - you can put the web server in the same building

- Each page is very heavy with lots of JavaScript etc. loading

  - you can build lightweight web pages if you priority small script size, minimal dependencies,
    and do profiling to keep things in check

- Data loading delays rendering

  - limit the amount of data loaded and displayed at one time

- Data is slow to load

  - an older system has limited capacity meaning it's not an option to keep inactive data around
  - this means data is more likely to be indexed
  - new systems have very large storage capacities, leading to a larger and larger growing db
  - eventually default configuration for the database does not allow for everything active to be indexed
  - solution is to keep inactive data out of active tables being queried for normal operations

- Slow to navigate with mouse

  - you can create a keyboard navigation system
  - you can build keyboard shortcuts into every screen
  - you can create autocomplete shortcut commands to jump to screens

▲ c22 16 hours ago | parent | next [-]

Many years ago I used a TUI retail/inventory terminal that was running in an SSH session over a painfully slow wireless link. Each keystroke came with several seconds of latency. This was not a problem, though, since I'd memorized all the important menu sequences. I could just punch in a rapid-fire string of keyboard strokes representing an entire transaction and then just wait a few moments for the screens to catch up and a receipt to print.

	▲	endgame 13 hours ago \| parent \| next [-]
		I think this is one of the deepest problems with modern UIs - event delivery is no longer reliable. You type "abc" and only "ac" gets delivered to the application, or "b" ends up sent to another window. Maddening.
	▲	1718627440 13 hours ago \| parent \| prev [-]
		I do this to this day, over a crappy kilobyte line via Phone via Bluetooth and it works great.

▲ Sander_Marechal 16 hours ago | parent | prev | next [-]

At work we recently moved from Jira to Linear. It it fully keyboard navigatable and has shortcuts for pretty much everything. It's great! For me the only downside is that al that keyboard greatness clashes with my Vimium browser extension. Oh well...

▲ bigstrat2003 14 hours ago | parent | prev [-]

> You just have to make fast navigation and data entry a high priority. The assumptions and approaches people make today mean that generally isn't the case.

Indeed. Most developers today make their own easiness of development the priority, not anything related to the end user's experience. This is why software is so bloated and slow, but the pernicious idea of "developer experience matters more than speed" doesn't seem to be going away any time soon.