Real developers don’t use UIs

4 minute read

Real developers don’t use UIs

Notes and comments on this article by Micah Linnemeier.

At first glance, CLIs appear to be worse than UIs in almost every way.

Feature CLI UI
Where is the input entered? Command prompt only Web or app
Accepts input as Files and text anything
Presents information to users Files and text anything (images for example)
Produces output for further processing as Files and text files

If this perspective is real then…

Why haven’t UIs killed off CLIs

CLIs are more widely available

  • They use less resources and have fewer dependencies so can be more easily installed on any machine.
  • They work in low latency environments.
  • They have reduced security attack surface.
  • They sometimes come pre-installed on many many OSes.

CLIs are automatable

It’s easy to create repeatable processes with CLIs

CLIs are more easy to share

If I have a series of CLI commands I can share them directly with someone else who has the same CLI installed and they can run them. It’s more difficult to share instructions for repeating a process on a UI.

CLIs are composable

Because all CLIs share the same input and output formats (text and files), they can be composed into chains of operations.

CLIs are faster

CLIs have a simpler rendering process and can be faster than CLIs for that reason.

Some of the comments in this section are misguided in modern situations.

Where CLIs typically request only raw data from the server, web UIs must transfer not only raw data, but also presentation information

Less true these days in the world of JSON APIs.

CLI commands typically only hit one server endpoint once. Web UIs often request resources which then request their own resources, which then request their own resources

Not sure about this one. This is a problem typically caused by religious REST implementation and Hateos. GET /projects returns a list of project IDs and the client must then traverse the list and hit 50 different GET /projects/:id endpoints in order to be able to render the page. Both CLIs and GUIs can succumb to this issue.

CLIs can also be more friendly to advanced users who can cut their usage down to a small set of specific commands that they need to run. The clicking around on a UI is a bit more winding.

CLIs make remote systems feel local

Using UIs across a slow network is horrible. This is a common issue when dealing with internal tools in the enterprise where there may be multiple jump boxes between the GUI and the data.

Where are GUIs better?

GUIs can leverage signifiers

UIs can have tooltips, icons, popups and title attributes in order to pack more information into a smaller space. CLIs can just display flat text.

GUIs can use images to pack information

GUIs can take tabular information and turn it into images and graphics which make it more easy to consume. CLIs can output ASCII charts to perform some of the same functions but they can’t compete with the information density of a GUI. They also can’t do visual formats such as maps.

GUIs can display options

GUIs can show the user the options when they are constructing a command to execute in a way that completely flat CLIs struggle to do. For example, consider this command to create a VM on Digital Ocean:

doctl compute droplet create <name> --image <image-id> --size <size> --region <region> --ssh-keys <ssh-key-id> --wait

What are the available image IDs, sizes, regions and ssh key IDs? I can’t tell without running a number of other commands. I can’t hardcode because images may be deprecated at some point and thus I need to send multiple request and write my own error handling code before I could use this CLI command in a production situation.

A UI can use select boxes or other controls to show the user what the options are.

Advanced CLIs can use auto-complete to do a similar thing but doing so will negate a number of the advantages of a CLI.

GUIs can offer more intuitive interaction

Think of Trello’s card dragging interaction. This simple idea changed the face of planning tools. This couldn’t have happened with a CLI.

It’s worth realizing that typing in a standard web form isn’t intuitive interaction of the type that really gels with the brain. Tapping and dragging are more representative of things we can actually do in the physical world.

GUIs can achieve superior performance in some tasks

Think of scrolling by flicking the Apple touch mouse vs holding the down key on the keyboard.

GUIs can guide users via Paternalism

paternalism is limiting a person’s autonomy in a way that is intended to promote that person’s own good.

Whether paternalism helps or hurts a UIs success depends on three factors:

  1. How smart the UI is. How accurately can it know what the user needs right now.
  2. How experienced the user is. Experienced users don’t need or want suggestions.
  3. The culture the user comes from. Many Software Engineers hate paternalism as a rule.

Most CLIs are aimed at allowing the user to do anything they want.

The GUI wins when the relief of having the right thing suggested to you outweighs the pain of things being hidden from you that you want.

Where CLIs win

  • Anything which can be automated
  • Expert, frequent users
  • Workflows involving other CLIs

Where Web UIs win

  • The getting started phase
  • When users don’t quite know what they’re looking for. Discoverability.
  • Workflows that involve analyzing large amounts of data.
  • Workflows that involve interaction with the rest of the web

What Web UIs should not do

Reimplement the CLI

Clis are very good at making everything possible. Web UI are not. The CLI can act as a safety net for the users so you don’t have to make every command possible in the UI.