I tend to prefer tools that have: a) withstood the test of time, or b) I feel comfortable debugging it if my business depended on it.
My argument for battle-tested tools is, if they are still being used by a significant community even if no longer "trendy", they probably solve a problem well, there's lots of help online, and the ways in which it can fail are well known.
That said, I do try some lesser known tools if they help me ship the product. I just look at them as a risk factor until I understand them better.
> prefer tools that [...] I feel comfortable debugging it
That's really sound advice.
> prefer tools that [...] withstood the test of time
That I disagree with, sort of. In my eyes, history of tech, and hence tech popularity distribution, is closer to random than optimal. That's probably because choosing a stack is a complex process, subject to many decisions, not all pertaining to a given technology's technical efficiency.
That said, if a piece of technology is popular, sometimes its large ecosystem will help bootstrap your project faster. But not all large ecosystems, or communities, are created equal. Some ecosystems, in some cases, even though smaller in size, outperform even the largest ones.
My argument for battle-tested tools is, if they are still being used by a significant community even if no longer "trendy", they probably solve a problem well, there's lots of help online, and the ways in which it can fail are well known.
That said, I do try some lesser known tools if they help me ship the product. I just look at them as a risk factor until I understand them better.