Loading...
Loading...

Why do developers create and use Command Line Interface (CLI) apps? Why are TUIs on the rise? Why did Claude Code decide to make their application a Terminal UI instead of a GUI? These are the questions we will answer in today's episode of DevQuestions.
Website: https://www.iamtimcorey.com/
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/
Why do developers use the command line so much?
If you watch any older developer,
you'll probably see them drop into the terminal
to execute git commands, to launch programs,
or even to edit documents.
Even with the advent of AI and advanced coding techniques,
the 2E or terminal user interface
is seeing a huge rise in popularity.
Claude Code primarily runs in the terminal.
Why don't they develop modern GUIs instead?
That's where I talk about in today's episode of DevQuestions.
Welcome to the DevQuestions podcast with Tim Corey.
Software development is more than just writing code.
So let's talk about the rest of it.
Specifically, let's talk about the purpose and value
of command line applications.
Now, whenever I show off the terminal application,
or said commands in the terminal,
inevitably someone pushes back,
complaining that the terminal is outdated.
But there's a very important reason
why software development has so many tools and systems
that work on the command line.
Here are just some of the benefits.
Number one, predictability.
Things don't move around.
If you have to use Microsoft Word today,
it's different than Microsoft Word was five years ago.
But a command line,
unless they have deprecated commands,
the command line stays the same.
That means a script that ran five years ago,
probably will still run today.
Now, yes, things are deprecated change.
But for the most part, for example, Git,
those Git commands still work.
So when it comes to predictability,
you know that the command will run on this machine,
we'll run that machine, we'll run the next machine,
because it's going to do the same exact thing,
the same exact way.
The things don't move around.
Buttons don't have to just based upon a screen resolution.
So you don't have to say, well,
click this menu, then go down to here,
then click these options, then scale down to,
just say, run this command and it'll work.
So predictability, number one.
Number two, kind of goes along with that,
and that's repeatability.
If I run this specific command,
it will do this specific thing.
If I run that same command later,
or on a different machine,
it will do that same exact thing.
Having something that's repeatable is really valuable.
If you're installing a server,
and you set things up, you set it up manually,
you're gonna install Windows,
and you install this software and that software,
that's okay because it's one server,
but imagine you have 100 servers to do,
and they're all the same.
Well, if you write a script,
then you can say, hey,
this is a script that installs all these things.
And then just run that 100 times, guess what?
All 100 instances will be exactly the same.
Now, if you have exactly the same problem,
if you're not careful, that's on you.
So repeatability is number two.
Number three, again,
kind of goes along with these first two,
and that's automation.
Having a predictable, repeatable process
that you can run without having to use your mouse
allows you to automate these things,
allows you to create repeatable commands
that you can execute over and over again.
This is the entire foundation of CICD,
the continuous integration and continuous deployment process.
We use automation to run commands,
run things that are predictable, they're repeatable.
That way, we know that it worked the first time,
the second time, the third time,
is gonna work the fourth time.
And that's really what CICD is.
We deploy locally, deploy to our dev box,
we deploy to our testing box,
our staging box, our QA box,
and then finally to our production box.
And what we get, the same results every time,
which means by telling you the production,
we're happy with the results.
That's number three.
Number four is speed.
Terminal commands are much faster to execute.
If I say, go ahead and create a new project
for .NET, I might create a new console app.
Well, if you go to command line,
that's .NET new console, I believe.
And then you can give it a name in the switches.
If I say I do that in Visual Studio, okay, file, new project,
and then you search for console,
you're gonna find that click on it,
then you're gonna fill out all the fields,
or at least look at them because they're all there,
but they're probably the defaults,
which would be the default in the command line by the way.
And then you fill the name, and then you hit next,
and then you hit complete, and it creates the application.
Well, that's a whole lot more steps,
and it's more click here and go there and search this
and do that instead of just .NET new console, right?
Much faster to execute, much easier to execute.
And it's also actually faster
in terms of actual processing too,
because Visual Studio has to load the GUI,
it has to load the list, and it has to show you things,
and process things,
whereas on the terminal, all I'm doing is
writing the actual commands.
So the GUI's on top of those commands.
So it's all getting faster to run on the terminal.
Same as true for Git.
If you use a Git client,
well, you can visually do things,
and quite frankly, the GUI's are nice for Git,
because some of it's rather confusing.
But when you drop down to the terminal,
run the Git commands,
they can be much faster because of the fact
that GUI doesn't have to render all that.
It's a very least.
So terminal is both faster for you as a human,
but also faster in terms of CPU cycles as well.
Number five, it's easy to use.
Now, you may push back in and say,
I can't remember the commands.
I can't either.
I actually made a mouse mat that has commands for Git
and the shortcuts for VS code and all these other things,
because the fact that I can't remember it all.
So yes, I get that,
but at the same time,
it's easy to use in the fact that I can train you to say,
hey, write us down a notebook,
or write us down a notepad somewhere that says.net new console.
That's easy to understand.
As opposed to install this application,
make sure your settings are installed as well,
then go here and do this.
Oh, they said an update.
It's actually now over here.
That's more problematic.
Number six, it requires less or no installation.
So this allows for much easier work.
If you've got the.net 10 SDK installed, for example,
well, by having that installed, you can just say.net
and then whatever command you want,
and it's already there.
Whereas if you actually run on GUI,
well then you've got to figure out which GUI you want to have
installed, and then download and install that set up,
configure and all the rest.
This is true for pretty much anything.
If you have get installed on the device,
well, you can just start using get commands on the terminal.
But if you want to have a GUI,
now you have to install a GUI on top.
Now sometimes you may not realize
that's what's happening.
You're installing two things.
Like if you install Visual Studio,
installs.net 10 SDK.
But that's actually two things in one.
So when you're installing that bigger thing,
you usually install on a smaller thing first.
So it requires less or no installation,
depending on if it's already built into the system,
or if it requires an install, but it's a quick install, okay?
So this easily works on more systems.
So it also allows you to work on different systems.
You work on Windows today and Mac tomorrow
when it comes to.net or Linux,
like we're doing our series right now,
not a problem because the.net command line is the same.
Easy to use.
All right, number seven,
they're easier to execute remotely.
Let's say that you want to work on a server.
Maybe you're working on remotely
from your parent's house.
And they have an old computer
and nothing installed as far as your tools,
but you can SSH into your server.
Well, also, you can run commands on your server
that do all the work that you need to do
because it's just command line.
As opposed to having to have a work laptop
and everything set up on it
and configure it and all the rest,
you just use SSH and terminal into the server
and run your commands.
It's very easy to execute commands remotely
if you're using some type of terminal or command line
as opposed to the overhead it comes into
trying to connect a system remotely.
Number eight is efficiency.
Terminals and terminal applications
use less memory to execute commands,
which means you can do more or less.
You can be more efficient to have,
especially if you're using like a CICD system
where the more you can save your memory, the better.
Well, this is where command line really comes in handy.
So that's eight.
There's a bonus one.
It's easy to make cross-platform, okay?
If you're a .NET developer,
super easy to make cross-platform apps
if you're using terminal applications,
creating terminal applications
because it has work.
If you create console application,
it can run on Linux, Mac, and Windows.
Out of box.
You just say deploy to Linux, deploy to Mac,
to Windows, and we'll just work.
So it's easy to make cross-platform.
That's just a bonus.
Command line interfaces can have higher barriers to entry
because yes, you have to learn the command line
you have to learn how it works.
But once you understand how to use them,
they offer a lot of advantage over a full GUI system.
So that's why developers, especially experienced developers,
often favor CLI applications
or at least use them consistently.
The GUIs may change, the command line is still there.
Thanks for listening.
As always, I am Tim Corey.
Thank you for joining us for this episode of DevQuestions.
When you're ready to learn to think and code
like a professional developer,
head over to imtimcory.com and enroll in a course.

DevQuestions with Tim Corey

DevQuestions with Tim Corey

DevQuestions with Tim Corey