Moving away from VSCode and use Terminal instead

I was teasing myself to use the terminal only. I have not been newbie to the terminal, and surprisingly over the years I can even work with applications like vi (but not good at it at all). But it never occurred to me until recently that, maybe I should stick with the Terminal more often, thus ditching IDEs such as VSCode. It’s more of a realization than a challenge that I throw to myself.


What made me make this transition is an App called CodeRunner. It’s a small application (not terminal based) that sets up an environment for each language, so all you have to do every time, is to pick a language, type in some code and hit run button. You can imagine this can be very effective in prototyping your idea, competing in some online competition, or just randomly coding some stuff so you can see the result right away. Very much like CodePen, except it’s installed in your own computer, also it supports a lot of programming languages. If it doesn’t support your language, you can just extend it with some custom terminal commands.

One side effect by using CodeRunner for long extended hour is that, I start to get an idea I don’t need much support from an IDE, such as Visual Studio Code. Instead, what I need is a text editor, a terminal to run commands and see results in text format. And this is exactly the basic definition of an IDE, with one small subtlety. I do not expect all these things done in a single application. Instead, I can tolerate some of them to be done here, and some of them to be done there.


The lesson learned from studying React is that, more isn’t always better. Instead, being a small feature can be no problem, as long as that the small feature is stand-alone. Because once a feature is proven to be useful in a small domain, whether it can survive in other environments is only determined by how small (or precise) its interface is. A big application can carry with lots of functionalities, but in the end, it also carries with lots of assumptions, thus eventually the interface becomes bloated. That’s the fate of a big application, at least eventually.

Let’s get back to our topic, Terminal. Pretty much every system you can see in the market supports a terminal, though not graphically capable, you can do almost anything with it. Moreover, you can spin as many terminals as you want and organize the screen with any type of layout. It can not limit your imagination how you want to make your own “IDE”. Moreover you can be with different mood everyday, which means you can toil with it anyway you want.


Now the question becomes, how easy it is to use the terminal as the IDE. This question boils down to what you need from the IDE. If you need everything, then the terminal isn’t a good answer here. Since as you might imagine, the terminal serves the opposite point, which is, you need to know exactly what you need.

I have to admit, it’s not easy to make a transition from everything to exactly-what-I-need mindset. Suppose we don’t need to rush to get the job done today, or let’s say you can start from the scratch all over again. For instance, today my job is to type 10 lines of codes onto the screen, what do you need?

I can open a terminal, and fire an editor called vi or vim . It might take me a day or two to learn the crazy commands from vi , but I don’t have much expectations. Moreover, after couple of days of practice, you actually found you can precisely control what you need even in typing. If you want to go to the end of line, do it; if you want to change a character, do it. The point is that you need to be consciously tracking what you need, but as long as you’re aware, with some practice, you can nail it precisely. I guess that’s the spirit, after you lower the expectation, you get better results (but narrowed).

Say you are done typing the code, you want to run it now. Go ahead, open another terminal, type in something to run it. Leave the terminal open, because you will be looking at both terminals from now on. What’s the difference here? IDE might have a button or a shortcut written for you, so you don’t need to type in the exact command. But can you fine turn the button? or duplicate the button at any place you want and whenever you want to run it?

I guess not, since you don’t have the source code of the button.


This comes to the point. Terminal is probably the source code of an IDE. If you know the terminal commands well and you switch between the IDE and terminals often, maybe it’s not too difficult to ditch the IDE. Because there’s nothing more in the IDE that is not already available in the terminal. But to make a transition, you probably need to stay in a small set of functionalities long enough to realize that. I can assure you, the best of part of not using an IDE, is that the terminal won’t disappear from the market tomorrow, but your IDE might. Of course that’s the marketing line, the real benefit is that you know exactly what you need to get the job done. But you need to work a little bit to get to know what you need.




Front-end Engineer, book author of “Designing React Hooks the Right Way” sold at Amazon.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Learn for 30 Days September–October Habitica Challenge

Think, Then Code…Don’t Think in Code

Explain the Rationale for Your Decisions


DragonBall: Introducing the first real-life lottery on BSC powered by Chainlink VRF

The Soul of Formula E?

Using tuples to pass simple data quickly in C#

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Fang Jin

Fang Jin

Front-end Engineer, book author of “Designing React Hooks the Right Way” sold at Amazon.

More from Medium

Neovim -Plugins

Heroicons for Your Svelte Project

Ever wondered how to manage state in Svelte applications?

VS Code DevContainers