Probably they have a different experience! I love using helm but I feel I got used to go templates and sub charts done right. I use it at work a lot and at home on my homelab with no issues at all: I guess is the usual tab vs spaces.

The alternatives of helm are not that interesting to me: I still have nightmare when I had to use jsonnet and kustomize just for istio, with upgrade hell.

So I am sticking to helm as it feels way straight forward when you need to change just a few things from an upstream open source project: way fewer lines to maintain and change!

Most of the time discussion derails as everyone is focusing on different aspects of the experience.

When you look into all the complaints one by one they are exceptionally acurate.

  * yaml has its quirks. - check
  * text templating can’t be validated for spec comformity - check
  * helm has lot’s of complexity - check
  * helm has dependency problems - check
  * helm charts can have too many moving parts with edge cases causing deep dive in the chart - check

and many others. However proposed solutions cut short on providing the value helm brings on.

Helm is not just a templating engine to provide kubernetes manifests. It’s an application deployment and distribution ecosystem. Emphasis on the "ecosystem".

  * It brings dependency management,
  * It provides kubernetes configuration management.
  * It provides abstraction over configuration to define applications instead of configuration.
  * It provides application packaging solution.
  * It provides an application package manament solution.
  * There is community support with huge library of packages.
  * It’s relatively easy to create or understand charts with a varied experience level. A more robust and strictly typed templating system would remove at least half of this spectrum.
  * The learning curve is flat.

When you put all of these in to consideration, it’s relatively easy to understand why it’s this prominant in the kubernetes ecosystem.