[pikaynu]

The inflow of new engineers which are not so familiar with traditional tools like a basic terminal and a text editor. That was all which was needed to write software. Most of the software stack was quite flat back then. Today, the way everyone starts is by installing a bunch of tools, frameworks and an IDE to navigate through those tools. Even a simple web page requires to install 100MBs of dependencies. Trying to learn those tools from scratch is not useful because it's all abstracted and is almost never dealt with. These terminals are making the use of those tools simpler using features like autocompletes, suggestions, metadata about the command etc. It's just like how an IDE became necessary for some languages like .NET or Java because it was no longer just the language. For terminals it's now good 'ol coreutils vs a bunch of npm crap.

I personally don't like to use pimped up terminals because they are written in electron and are not portable. The whole point of using a minimal terminal is being snappy and portable. Just like engineers today can't write code without autocomplete, new engineers won't be able to navigate the cli without assistance.

An analogy would be, vim purists with 0 config vs people who have elaborate configs.

[cookiengineer]

> An analogy would be, vim purists with 0 config vs people who have elaborate config

I find this pretty offensive. I have a vim config that automated my workflows, and integrated linters and build tools etc...and I am using Linux based systems for over 22 years now.

While I consent with the rest of your comment, I think that most people don't want to deal with shitty syntaxes that are less memorable than they should be. Computers and TTYs have moved far beyond 80 character screenlines these days.

Having a -s instead of "sync", for example, doesn't make sense from the UX perspective. Most of the reimplementations of common CLI tools of coreutils and others are mostly there because they were fed up with inconsistent parameters, options, and flags of those programs that have historically grown out of proportions.

On the other hand I can also understand why people use zsh, even when I don't like it because I'd consider myself a minimalist. Though I also have a lot of aliases for common tools I use, because I would go rogue when I would have to type all those parameters on a regular basis.

The issue most terminals try to solve is explainability and predictability, because they see terminals as a human interface, and not as a tool to write yourself one.

The clashes of those different philosophies are also found in shell implementations. I mean: off the top of your head, do you know all string manipulation syntaxes in bash? Probably not.

[0des]

> I find this pretty offensive.

First of all stop what you are doing. This is about vim configs, it is not this serious.

[cookiengineer]

Pardon my French, but everything about vim is serious.

[pikaynu]

vim wars. I am on the vim side. I don't care about vscode that much. The only gripe is the first class support vscode gets in terms of plugins as compared to (neo)vim.

[pikaynu]

The vim purist having 0 config wasn't my original thought. I had heard about it before and I have seen talks where the speaker would do everything with default vim syntax and not use plugins or maps. I personally have a bunch of plugins and shortcuts because I can't touch type. so I need most used keybindings close by.

I agree the inconsistencies with coreutils. Having helper tools and scripts vs spoon feeding with all options using arrow keys. Just the extremes, having aliases is all good and I never remember awk and sed syntax.

[pdimitar]

> I personally don't like to use pimped up terminals because they are written in electron and are not portable.

Alacritty, Wezterm and Kitty say hi. Uber-fast native apps that also render all the modern Unicode symbols correctly (well OK, Kitty has some Python).

You are also over-exaggerating and coming across as the "get off my lawn" guy.

I am 42, I was there when terminals were as bland as non-salted spaghetti in boiling water with nothing else in. Nowadays I like the autocompletes (with context nonetheless -- a huge improvement; you can autocomplete GIT verbs for example), I like the fuzzy finders that I integrate with (a) looking for files, (b) looking in my command history, (c) looking in my OS process list and (d) looking through all modified / untracked GIT files in a repo, I like the colors, I like the icons for separate file types, and I like modern incarnations of coreutils whose output provides you visual aid that objectively reduces the amount of parsing that your eyes must do on the screen. Eye and mind fatigue are real and all visual aid [that's not overdone] helps a ton. There are even scientific studies on it.

Want me to go on?

Conservatism like yours is not productive. Like with everything in life, there's good and there's bad e.g. I won't ever use the terminals that are written in Electron and phone home -- that gets an immediate "NOPE!" from me -- but there are objectively useful terminals, terminal extensions and CLI tools out there.

That you judge all of them by a few hip repos that are making the rounds here on HN only says something non-flattering about your abilities to gauge innovation.

Be more open-minded. It helps in an objective manner and with objectively improving metrics to show for it afterwards. At least it did for me and 30+ colleagues.

[pikaynu]

I use Alacritty full time (tried kitty, didn't work with my workflow), personal and work. I am not ruling those off. I don't mean to come as mean and conservative. I just don't like the over emphasis on "spoon feeding" tools across media. I know there are much better tools which can help with productivity. But, new engineers are only going to pick tools which are "marketed", the "hip" ones without weighing merits. But for sure, whatever works for them, who am I to judge.

I too use a whole lot of tools to keep the output less messy and I know some tools which have changed my life, ripgrep, exa, neovim, zsh, alacritty, git extensions, fzf and what not.

[t-3]

I'm baffled by the repeated insistence that alacritty and kitty are fast (never tried wexterm). There's noticeable lag spawning either on my reasonably new and fast laptop, which xterm just doesn't have.

[pdimitar]

How often do you restart it though? Mine lives for days or even weeks sometimes, and is only restarted when it gets updated.

When saying "fast" I definitely meant it as "all the operations it does while alive" and not "how many times per minute I can restart it" (lol).

[t-3]

When I need a terminal, mod+enter spawn one and close it. I'll often do this to download a file, start yt-dlp, mpv etc. The session is all tmux so I never keep the window around when not in use.

[leephillips]

Me too. On my systems, running Debian with dwm, a Kitty terminal appears instantly. It’s the fastest terminal I’ve ever used, by a big margin, including xterm. The fact that I can do things such as ssh into a remote machine and see an image in that machine’s filesystem displayed in the terminal are bonuses. I mainly use it because of its speed and Unicode support.

[pdimitar]

Sure, if that's your workflow then I get it. I and many others keep around several persistent windows or tabs however. I don't care if Alacritty takes 1s to start.

Still doesn't invalidate its usefulness, too. Alacritty in particular is often times a better Unicode-rendering citizen compared to other terminals.

[shpx]

I don't care either, just don't call it fast if it takes 4 billion CPU instructions to start drawing a black square to the screen.

[schwartzworld]

> The inflow of new engineers which are not so familiar with traditional tools like a basic terminal and a text editor.

I think many people start learning to use these tools at the same time they learn to program, I know I did. You expect junior devs to be terminal wizards?

> Even a simple web page requires to install 100MBs of dependencies.

No it doesn't? Some tooling requires lots of dependencies, but it's still very possible to open a text editor and spin up a web page.

[Brian_K_White]

They aren't literally claiming a physical requirement, they are describing todays most common workflow.

If I said you need to install 100's of mb of gcc to produce a binary, would you say "no you don't? you can write bytes directly from the shell right into a file" It would be a technical fact, and yet kind of stupid to pretend not to understand that today, in all practical senses, one produces a binary with a compiler suite of one sort or another.

Today, it's a growing trend that software is developed using huge ides and stacks of frameworks. And a new developer is started right off at the highest most abstract (most automatic and magic, sold as most "productive" or "practical") layers possible, which requires the fattest of ides and the tallest of stacks.

[pikaynu]

Yo! exactly my point. I never expect new devs to be experts. But the labor I am spending to teach one of those newbies (well 1.5yrs of experience) about how to check for a port listening is just astonishing. Being a whiz and knowing the basics of the environment you are working with daily, there is a difference.

[pikaynu]

I understand it takes one text editor to write a static website. But hear me out, If you asked a dev today to make a landing page, they look for templates instead of writing that stuff. It's possible, but it's not probably today. Everyone is going to whip up a react or it's derivative to even write a simple project.

[iso1210]

> Even a simple web page requires to install 100MBs of dependencies

I had problems with having to log in to a bunch of audio encoders last weekend to find out why they were engaged.

I looked at the webpage, a few calls with http/digest returning xml.

I strung together a quick perl script to take an ip/user/password, fire it off to the device, decode the output, fire off more queries, and dump out a <tr>, and then wrapped that in a bash script which generated the rest of the page for the N devices I wanted the status of. Took less than 60 minutes. Deployed it as a new apache virtual host with +ExecCGI.

3878 bytes plus OS provided packages for things like kernel etc, and now I can save time again and again by looking at the status page.

You can choose to make a simple webpage to perform a simple task and have it take 100s of MB, or you can choose not to.

[shreyshnaccount]

The purists got it wrong. The maximalist JS devs got it wrong. Imo the best way for most things in life is to have it as simple as possible without abstracting away everything, kinda like a middle path- like using zsh with autocomplete and highlighting in st, huh?