[alistproducer2]

I've always been of the mentality to use a tool only when the efficiency gains outweigh the learning curve. This is, of course, impossible to judge without spending a lot of time understanding exactly where your efficiency bottlenecks are.

The truth is, a complex application is going to be complicated no matter what tool you use. I look at application programming like this: the more complicated it is, the more likely it is that you've missed key requirements early in the process. This means you will likely need to refactor, rearrange, add/remove features, etc. Choose tools that make this inevitable process as quick and painless as possible. For me that's the number one goal.

I reject tools that make picking a project back up a week or two difficult because of dependencies or weird hacks, syntaxes, or configurations that worked fine when they were fresh in your mind but required an hour of your life to retrace how you got there using the tool.

For example, I chose to use a library that used generators to eliminate callback hell in a screen scraping project of mine. I did this for no other reason than it was too hard to modify the scrapper when everything was nested 8 levels deep. I didn't know what generators or coroutines were before that, but I had spent enough time with my problem to know that I was going to hit a serious maintainability wall unless I found a more clear syntax to write my app. In that case, it was worth the inital overhead of learning new parts of ES6 and programming language concepts.