[camus2]

> I am working on a larger .NET web application in my day job... and it requires things like.. Typescript + typings files, Webpack/Gulp/Grunt/etc. and therefore Node.js and NPM, NuGet, .NET Framework, onion architecture, front-end framework (Angular, or React, or..), Entity Framework, multiple databases, web services/web API, ASP.NET MVC.. I mean, it's just crazy if you step back and think about it.

All long as all the tools and pipelines work flawlessly it's painless.

As soon as something goes wrong, if you are not a specialist or have a deep understanding of the inner-working of all these it actually hinders productivity.

What if Webpack doesn't work as expected because you mis-configured it? what if there is a bug in AngularJS and you're not capable of fixing it yourself? What if Entity framework doesn't support a specific use case/feature of your DB?

While in a professional environment implementing the domain is already a lot of work and people want the rest to be coded fast by using ready-made solutions, each new component, framework should be carefully vetted, adding a new framework or library shouldn't become a reflex.

[sixdimensional]

Although, in the longer term, it is unlikely that these tools and pipelines will remain stable, and the interdependence between them often causes you to have to update one to update the other (especially the more dependencies you're dealing with). I realize that most package managers have a way to deal with this (and via semver/good version practices), but sometimes finding the right stable combination of versions of dependencies is like finding the magic incantation.