The lack of a module system in JavaScript is at the heart of many of these problems. While ES6 promises a solution to this, uptil now the ecosystem is fragmented unduly because of this: there’s multiple competing ways to create JavaScript modules.
Otherwise, you can avoid a lot of hassle by skipping over the pre-proccesor trends. For example, templating languages come and go, and there’s lots of transpiled languages like CoffeeScript, also new CSS pre-proccesors appear regularly… In our agency of designer/developers we stick to HTML based templating like Jinja, Django templates or Handlebars. We don’t use Coffeescript, and we only started using a CSS preprocessor when LESS arrived, which used the same syntax as CSS.
All these tools might be great when you are working by your self, but I see it as detrimental in collaborative settings. Working in small rapidly changing teams, the amount of new stuff you can learn per project is just limited. So why reinvent JS, CSS and HTML when you know that is the stuff that is going to stick around…
Finally, working with JavaScript one toolchain that I found that succeeds at hiding a lot of this complexity from the developer is Meteor. They did it by creating their own package manager—yet again :( But they remove a lot of friction of build scripts and front-/back end discrepancies. Meteor is firmly rooted in the now though, 15-20 years is a long time :)
