I think a lot of this is caused by the fact that projects usually on their README.md don’t explain why they are needed, instead assuming that the reader already knows what their for.
If open source projects would have a WHY.md file explain the problem that their solving instead of a one-liner, I think this would happen less and people would be less annoyed by learning a new tool or library if they know why its really needed and not only based on the hype.
Imagine what it would be to write a C#, Ruby or Java without import statements, how could that work?
Also a module system is needed to be able to reuse stuff from other people and dealing with dependency hell.
CommonJs is one of the greatest things thats happened to programming in the last years. The ability to be able to have dependencies that depend on different versions of the same library is huge for open source. Compare that to ther ecosystems like Java where you have to throw a kitchen sink like OSGI to do the same.
Everything has a ton of plugins, true but the thing about open source is that except for the larger projects its mostly done by hobbyists.
So individual contributors can only spare so much time of their personal lifes and the day only has 24h and you have a full time job. Making a core tool like gulp and providing some plugins and allowing other people to do the rest is the only way we have things like gulp in the first place.
Writing gulp plus 50 plugins would consume a huge amount of time for only one hobbyist. So again we need modules to reliably use each others stuff to build larger things without shooting ourselves in the foot and having to write monoliths for everything.
Nothing prevents people to create a module which is a curated list of a tool plus selected plugins, and a README for how it all fits together.
Also the complaint of npm and semantic needs to be addressed. All you really have to do to solve it is to npm shrinkwrap the project. It generates a json file with the exact dependencies you have. Just push it to git and the next developer that does an install will have the exact same dependencies than you, the build server the same.
You don’t have to be at the mercy of semantic versioning hell.
I think PostCss is a good thing. Its a return to the sources in the search for simplicity. If you take plain Css and a good methodology like SMACS and use low specificity selectors you don’t need anything else. A lot of Yahoo is built like that. If you stumble upon a use case, then you can include the minimal functionality you need. For example the ability to define variables for a theme might be all you need besides plain CSS. I use post-processors but Im convinced that in most cases they can be replaced by plain good Css practices.
The React guys are the first to say don’t use the Flux architecture used to fix the issue with the message counter and other stuff if you don’t really need it: If you don’t have: some stateful data being changed at the same time by the server or the user, or have multiple part of the app reacting to the same data, no need for undo/redo, and other specific examples you don’t need flux. Check the React How-to https://github.com/petehunt/react-howto
“You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.”
I don’t think its a bad thing to use React in places other than a SPA. You create a component that you can reuse elsewhere. A React component is usually much easier to understand than a jQuery plugin. If you try to add a feature to most jQuery plugins out there its very hard if you are not the original developer, each time you see hundreds of lines of DOM manipulation code. I think jQuery is still needed but to build reusable components I would stay away it from it in favour of a modern framework.
A SPA is a great user experience. The way the user can much quickly move around the app, keep dialogs open across pages, its much more engaging if done right and a pleasure to use. The problem is still indexing but there are solutions for that.