zsh doesn't require any 'plugins' for its tab-completion, everything you need is distributed with the shell. A lot of people who use zsh just don't understand how it works and think that OMZ/Prezto/whatever are doing something special for them that they couldn't achieve themselves with one line in their .zshrc (or that may even be enabled by default in their OS's global zshrc, as is the case on Ubuntu for example)

Yeah, I went that route before settling into Oh-My-Zsh. The thing is, those single lines add up quick leading to increased mental overhead and time investment.

It's never been about 'understanding' zsh or not, it's always been about making it comfortable to use, quickly, on any given system I might use.

Sometimes a nice set of defaults is more productive than a custom solution.

I agree that zsh's default configuration sucks (and the new-user wizard is overwhelming). I would like the project to provide a more opinionated set of defaults to OS vendors; i think we are probably just nervous about breaking 30 years' worth of expectations, and so far nobody has really pushed for it.

But i do think the misunderstanding i mentioned is very common, as illustrated by the fact that the GP seems to think that OMZ itself provides zsh's completion functionality. It's also a frequent point of confusion with people seeking assistance on zsh's IRC channel.

I used fish for a while, but the fact that it is a clear break from bash / sh syntax for things like chaining and redirecting made my reflexes all wrong. I'd type `dothis && dothat` and fish would just say, "umm, I think you mean `dothis and dothat`", or I'd have to use a bash subshell to run some command someone else wrote with some fiddly find syntax piping to xargs. So I just switched to zsh. Less cool name, but my reflexes are once again correct.

They caved and support that syntax now in fish.

While not caving on plenty of others. E.g. errors when a wildcard can’t be expanded (because it is not meant as a wildcard) and you have to explicitly quote. Or (subcommand) instead of $(subcommand). There are more cases I frequently encounter.

Infuriatingly, fish knows what I meant, as the error tells me what to do instead. But it won’t do it for me and prefers to lecture me instead.

I used fish for a while. It was nice but way too many compatibility issues. Zsh is a nice compromise.

IMO compatibility issues are the result of conflating a CLI with a scripting language. If a script was written for bash, run it with bash, not fish or zsh. I can withstand having two shells installed.

You can, but if Fish's value proposition is ease-of-use, then people who can't withstand that need to be able to use fish easily still. Not being able to run `PORT=5000 yarn start` or `make && ./a.out` or whatever snippet you copy-paste from the web without understanding are going to be a big pain point for newcomers to fish.

Don't get me wrong, I'm a happy fish user myself. But breaking backwards compatibility with shells from the past 40 years and then saying "you're doing it wrong" is not how to make easy-to-use software.

Fish 3.0 addresses the common `&&` and `||` operator incompatibility and if you pasted the first snippet it suggests that you should use `env`:

fish: Unsupported use of '='. To run 'yarn' with a modified environment, please use 'env PORT=5000 yarn…'

They fixed many of those recently. And just in case you have a script that doesn't run, you can install a plugin called `bass` that basically runs them in your native bash without leaving fish.