UI and CLI Are Equivalent!

The idea? End-user’s interaction with webapp in a browser has equivalent command line command sequence! And how to avoid duplicating interface implementation for CLI, UI, and API? The answer is that the API should be the master API and both the UI and the CLI should use that. We can also go further and force UI to transform its API requests into CLI commands so that CLI can execute them. So in short, the pipeline could looks like this:

UI/Browser -> CLI -> API

For example, let’s imagine there is a service called “Deals” that informs you when there are good online deals available in your favorite online stores. If the user “john.smith@example.com” types his email address in a form field and hits Submit button to register himself to a new service, the equivalent textual CLI command could be “deals register ‘john.smith@example.com'”. Nowadays for example gloud service providers prefer using CLI – at least to cover most complex interactions.

Modern web application often consists of fronted (Javascript) application, application programming inteface (REST API), and backend. A concept in modern programming languages it a tool called Command Line Interface (CLI) that allows for example Repeat-Eval-Print-Loop (REPL) loops. Nowadays strict separation of the frontend from the API and backend is a popular design choice. I will claim that the following is true and that treating UI and CLI as interchangeable concepts is the future of web apps:

1. Frontend is separated and it is independent from the backend. HTTP requests are text.
2. Interactions which come from the UI should be formatted as they were native CLI commands and queries. This new idea has immediate impacts:
   – every UI command and query can be translated into CLI alternative, and vice versa
   – API must accept them as-is
3. When backend implementation gets changed the API contract must not be changed.
4. When frontend, i.e. UI, is changed the visual appearance should not changed always. It can change, but it should not be obvious that it changes. Changes increase cognitive stress for end-users, and typically require educating them.
5. CLI can but not must require interaction with a user, which is programmatic automation requirement!

Automated testing is still quite difficult and the tests are brittle. What if you could test browsers by using visual AI to recognize different DOM elements and compare different interactions with textual output! The whole point is that text is still the de-facto way of communication in computer systems. The UIs exists because they hide complexities and improve discovery. So I propose that make your UI CLI compatible, allow users to use CLI alternatively, require textual input and output in APIs, and finally understand that visual layout should not change always when implementation changes – it is a contract too. . And see my other post about Human interaction Interface (HII)

P.S. There is interesting development going on related to this topic: see for example CLUI that is about how to build a graphical command line tool! In a way, also command-line auto-completion is also a UI: see for example client for PostgreSQL.

P.P.S. Another interesting development project is the tool that allows you to turn (almost) any Python Console Program into a GUI application with one liner.