> All those things you suggest adding to the terminal, well, they are baked into VS Code.
> you'll understand why terminal first is dying
I don't think I mentioned terminals at all? Since when terminals are a useful distinction? I don't think I ever suggested to add anything to the terminal. I don't think anything "Terminal first" was ever wildly successful in the general public since the 1980's.
It's just that the "this approach has more dimensions" isn't very useful.
Again, I reiterate that terminal is not the main point or be-all-end-all of CLIs. In fact I would argue that all highly successful CLIs aren't terminal first at all:
* spreadsheets;
* search engines;
* Jupyter Notebooks;
* VSCode and IntelliJ Command Pallete;
* and, now of late, LLM prompts;
If anything, you don't want a terminal to be the center of your UI, unless you're a terminal emulator.
> So moving to the terminal includes having to add a bunch of things manually to get to the same point VS Code is at, which does have a terminal when they need it, but it's not the central UX.
To me the main point of CLIs is exactly a extremely minimal and constrained interface, that makes creating inter-connectable modular systems easier. That of course is meant to be useful to system builders, not to be necessarily exposed and useful for system users.
The specifics of how you make a system do your bidding, if by clicking a icon on a GUI, on a command palette, or typing stuff on a keyboard, is inconsequential and not a very useful distinction to the end user. How many "dimensions" there are isn't a useful distinction to the end user either. As long as the user doesn't have to memorize a lot of things, and that it considers Fitt's law, it should be OK.
It just happens to be that often, text is easier to memorize that some god-forbidden Ideogram/ideograph that "because UX" changes in shape and placement every version of a program.
> Each has merits, but most people are now picking VS Code. Why is that?
It is exactly because the core of VS Code is a CLI. If you wished to use an actual "GUI IDE" you would use "Visual Studio" or "JetBrains IntelliJ IDEA". But people don't use those because they don't like GUIs that much.
I myself am a heavy JetBrains IntelliJ IDEA user. I would argue that IDEA is one of the most GUI-centric IDEs around. If you want, you don't need to use the terminal or the command pallete at all. You can configure environment and run parameters of everything using the GUI. It's very discoverable. The UI is very unified. You're never thrown back to a terminal anywhere. You basically never have to manually edit some random JSONs that invoke CLIs. If you want, you're never configuring parameters to call anything, the GUI does that for you.
That of course makes IntellJ bloated as hell and consume a ton of memory - in my machine it uses 1.6GiB to open, never mind how much it actually uses to do anything useful - but that is what you pay to have "options" and "icons" and "windows" for you to eventually discover.
As a general thing unfortunately I think that often on UI, systems/UI are too biased towards either discovery or power. And often you can't change the bias, even after you become an expert of the system/UI. On most "discoverable WIMP GUI" the tradeoffs are often as such to making stuff discoverable, instead of powerful.
VS Code is a CLI interface that happens to have a good text editor built-in. So it has a much better Power-to-weight ratio that your average IDE as it doesn't need to drag all that "discoverable WIMP GUI" bloat around.
But, as on my first argument, it doesn't have a terminal as a "centerpiece" of the GUI. And it should not. I want a IDE/text editor, not a terminal emulator! But the fact something "has a terminal" or not isn't what define a CLI, a *command line interface* is what defines a CLI.
I hope more programs to become like VS code and have powerful command line escape hatches.
Side note: I think that the fact that IDEs have terminal emulators built-in is more of a sign that Gnome/Windows/macOS suck so badly at window management that you need to have "manual" window management at a program level. "For UX", you have to bolt in everything that might come in handy, so unfortunately garbage-tier todo managers/Git branch managers/terminal emulators/whatnot's are bolted on IDEs. It is a failure of the OS window manager. Same reason as browser tabs, there is in theory no reason why they "need" to exist besides Gnome/Windows/macOS sucking at managing browser windows.
> Gnome/Windows/macOS suck so badly at window management that you need to have "manual" window management at a program level
Have you tried hyprland? You can have a keyboard centric experience with perfect window management.
I have a browser, a terminal and a few other things (ex: deadbeef to play music, sioyek for reading PDFs) each in fullscreen for maximum information density and concentration.
I can reorganize anything (ex: have the terminal and the browser next to eachother), but I find it more convenient ti use keyboard shortcuts to jump from one to the other as needed
> you'll understand why terminal first is dying
I don't think I mentioned terminals at all? Since when terminals are a useful distinction? I don't think I ever suggested to add anything to the terminal. I don't think anything "Terminal first" was ever wildly successful in the general public since the 1980's.
It's just that the "this approach has more dimensions" isn't very useful.
Again, I reiterate that terminal is not the main point or be-all-end-all of CLIs. In fact I would argue that all highly successful CLIs aren't terminal first at all:
* spreadsheets;
* search engines;
* Jupyter Notebooks;
* VSCode and IntelliJ Command Pallete;
* and, now of late, LLM prompts;
If anything, you don't want a terminal to be the center of your UI, unless you're a terminal emulator.
> So moving to the terminal includes having to add a bunch of things manually to get to the same point VS Code is at, which does have a terminal when they need it, but it's not the central UX.
To me the main point of CLIs is exactly a extremely minimal and constrained interface, that makes creating inter-connectable modular systems easier. That of course is meant to be useful to system builders, not to be necessarily exposed and useful for system users.
The specifics of how you make a system do your bidding, if by clicking a icon on a GUI, on a command palette, or typing stuff on a keyboard, is inconsequential and not a very useful distinction to the end user. How many "dimensions" there are isn't a useful distinction to the end user either. As long as the user doesn't have to memorize a lot of things, and that it considers Fitt's law, it should be OK.
It just happens to be that often, text is easier to memorize that some god-forbidden Ideogram/ideograph that "because UX" changes in shape and placement every version of a program.
> Each has merits, but most people are now picking VS Code. Why is that?
It is exactly because the core of VS Code is a CLI. If you wished to use an actual "GUI IDE" you would use "Visual Studio" or "JetBrains IntelliJ IDEA". But people don't use those because they don't like GUIs that much.
I myself am a heavy JetBrains IntelliJ IDEA user. I would argue that IDEA is one of the most GUI-centric IDEs around. If you want, you don't need to use the terminal or the command pallete at all. You can configure environment and run parameters of everything using the GUI. It's very discoverable. The UI is very unified. You're never thrown back to a terminal anywhere. You basically never have to manually edit some random JSONs that invoke CLIs. If you want, you're never configuring parameters to call anything, the GUI does that for you.
That of course makes IntellJ bloated as hell and consume a ton of memory - in my machine it uses 1.6GiB to open, never mind how much it actually uses to do anything useful - but that is what you pay to have "options" and "icons" and "windows" for you to eventually discover.
As a general thing unfortunately I think that often on UI, systems/UI are too biased towards either discovery or power. And often you can't change the bias, even after you become an expert of the system/UI. On most "discoverable WIMP GUI" the tradeoffs are often as such to making stuff discoverable, instead of powerful.
VS Code is a CLI interface that happens to have a good text editor built-in. So it has a much better Power-to-weight ratio that your average IDE as it doesn't need to drag all that "discoverable WIMP GUI" bloat around.
But, as on my first argument, it doesn't have a terminal as a "centerpiece" of the GUI. And it should not. I want a IDE/text editor, not a terminal emulator! But the fact something "has a terminal" or not isn't what define a CLI, a *command line interface* is what defines a CLI.
I hope more programs to become like VS code and have powerful command line escape hatches.
Side note: I think that the fact that IDEs have terminal emulators built-in is more of a sign that Gnome/Windows/macOS suck so badly at window management that you need to have "manual" window management at a program level. "For UX", you have to bolt in everything that might come in handy, so unfortunately garbage-tier todo managers/Git branch managers/terminal emulators/whatnot's are bolted on IDEs. It is a failure of the OS window manager. Same reason as browser tabs, there is in theory no reason why they "need" to exist besides Gnome/Windows/macOS sucking at managing browser windows.