On the other hand, the worst way to go about selecting a framework is, in my opinion, benchmark testing (or looking at some blogger's benchmark tests). Your framework might run a million hello world programs faster than mine as of last month, but you have no idea if the people working on the framework will even be around in the next 6 months when your MVP is actually complete. And if you wind up having to solo-support your own dead framework while concurrently trying to run a small business, good luck finding time to build new features, hiring qualified programmers, and not coming around to hate javascript.
Brunch is older than Grunt and Gulp, how is your comment in any way relevant? If this was a post about the advantages of Java over Go would you complain about the amount of time you have to spend investigating various language platforms?
The world is changing rapidly around us, whether we like it or not.
If people said to themselves, "Nope, don't have time to read some docs," and went about their business without dropping coder angst-bombs, there might actually be useful comments to read that would help someone decide whether looking into Brunch or whatever was worth the time.
Furthermore, the age of the tool has nothing to do with the fact that there are literally 10 tools that do almost the same thing. But are syntactically and dependency different. It's a huge pain when someone new is hired or you leave for somewhere else. Too many cooks in the kitchen type of thing.
Instead use a filter. Pay attention to the stuff that makes it to HN, Reddit or DailyJS, yes, but don't wander off reading a dozen articles about every new shiny. Think like a medic during a disaster: learn triage. Learn to quickly assess the general idea of new projects and make a mental note that it is out there and whether it is relevant to anything you're currently doing or planning to do.
If it really is useful, you'll hear about it again. There's no point in getting invested in something nobody else is using. You don't have to be an early adopter of everything. If you see something new you could immediately benefit greatly from, sure, you may want to give it a try right now and see whether you switch everything over to it. But that should happen very rarely.
Your job isn't to know everything or to understand every new technology and be fully prepared to answer any possible question about it. Your job is to get things done. If there are technologies that help you be better at doing that, sure, you should probably be aware of them. But you don't need to evaluate every single one.
If you adopted every single new technology that could be useful to you, your productivity would crash to zero. Adopting something new creates overhead -- unless you're fairly certain that adopting it will save you orders of magnitude more work than it creates, you're not missing out.
The allure of using this is that it's faster, but there is a lot of text talking about itself and it really puts me off. It indicates to me that the author doesn't consider these factors, and possibly ignores others, too.
These tools should be concise, and I should be able to get started off a single README.md. Anything less wastes my time.
There are, however, cases where you simply need to use code. In these cases I'd rather use the language I'm developing in rather than bash. I haven't used Brunch for more than a simple project, so I can't really comment on it too much. I have used Gulp though, and I commend its authors for creating great abtractions following the UNIX philosophy in this context.
http://substack.net/task_automation_with_npm_run
Seeing all these grunt-* and gulp-* wrappers makes me sad. Unless your project is very complex, all you need can fit in your package.json (and, maybe, some scripts if you can't find anything that already does what you need it to do).
There are some projects that benefit from using dedicated build frameworks like Grunt, Gulp and so on. But the vast majority of projects using them just use them to run one or two tasks that already have a CLI. In those cases it's over-engineering a non-problem.
I agree that AngularJS is needlessly complex. It hides a lot of straightforward ideas behind confusing terminology ("this is a service, this is a constructor, but a constructor isn't actually a constructor, it's a function that creates a service, no not that kind of service, that one's just a function called service because reasons"). But I don't think that's representative of all libraries and frameworks.
jQuery for example, though ridiculed by many at this point, still exists and is still a go-to solution for conventional web pages. If your "app" is just a bunch of static content, it's probably just a conventional website and jQuery is likely sufficient. It's a good general solution and with some discipline you can even solve moderately complex problems with it.
Other projects are not as likely to stick around as long as jQuery has but small and specialised enough that they can be replaced relatively easily (i.e. without a major rewrite of all the code) in the future if necessary.
If you just want to build a website, you can probably get away with using jQuery. If you just want to write a node.js web server, you can probably get away with just using express. If you just need utility functions, you can probably get away with underscore.
Besides, even if you use hot spanking new technologies, you should still strive to make your code as maintainable as possible given what you have. That niche REST framework you built half the application on may need to be replaced, but if the code is readable and grokkable, maybe at least the guy who has to do it will understand what the application actually does.
Then what happens when you leave your position and someone comes in a year later? Oooh, that sass preprocessor doesn't work? What's an angular, some kind of measuring tool? The entire system has a "doesn't matter I'll be at the next startup in 2 years" kind of feel to it.
I should really move into Java or C....