In a Microsoft ecosystem (i.e. WebForms/MVC/WebAPI VisualStudio projects) why should I rely on an external task runner for JavaScript files like Grunt if I already have MSBuild at my disposal as the default building/task running system?

When I first saw grunt in action I wondered why it was even being used, as it seemed to me that I could do what it was doing by relying directly on MSBuild tasks. I usually favor centralized tools for doing the same type of job, and I assume both MSBuild and Grunt are doing basically similar types of actions: running tasks against/using files as input. All the javascript files for these web projects are already referenced in the csproj anyway, so they are automatically part of the build process. Using MSBuild to process them seems much more natural to me than injecting a new framework in the middle to do that.

I believe that using another framework to perform the same type of work you already do with an existing framework is a bad decision since it adds new unnecessary dependencies that have to be learned/mastered by the team. Additionally, we all know that more moving parts equals more chances for stuff to fail in general. I also argue that MSBuild already integrates nicely with Visual Studio, while grunt requires extensions or manual command line work to run.

Is there a specific reason why MSBuild was not leveraged for the kind of work Grunt does nowadays?

I understand they are completely different ecosystems and would totally understand someone using Grunt on a non-Microsoft open source type of project, but it doesn't make sense to me that it has become a standard for .Net applications seeing that we already have a tool to do just the types of tasks it does.

Don't get me wrong, I understand the "there are many plugins available" argument, but that to me is similar to saying we should all stop using TFSBuild and migrate to Jenkins because it has more plugins readily available. It is a valid argument, but not so much as to completely dismiss TFSBuild's strengths in some situations.

  • Well, is MSBuild has everything you need ? JS minificaiton ? HTML minification ? Livereload server ? you may consider some of them are not needed for you it's up to you. The basic thing is that if you don't need to move on and have something working with technologies you master, don't move.
    – Walfrat
    Commented Dec 29, 2016 at 21:14
  • @Walfrat I don't even know if MSBuild does have all of those tasks (I know some of them do exist), but they could be created. My point is that folks are moving to Grunt because it processes "JavaScript files" but MSBuild can do that too with no apparent problems. Why have a separate task runner?
    – julealgon
    Commented Dec 29, 2016 at 21:21
  • 1
    @julealgon don't forget, there are lot of folks that just move to new things because of the "hype". If MSBuild is enough for you and work, don't change it. If you search on workplace.SE you can find a lot of questions about "I'm coming from school and I want to change all the technos to get the flashy new one and seniors don't want"
    – Walfrat
    Commented Dec 29, 2016 at 21:38
  • 1
    Comparing Grunt to MSBuild is like comparing Java to MS Visual C++. Voting to close, since language comparisons are off-topic on this site.
    – Doc Brown
    Commented Dec 29, 2016 at 22:08
  • 1
    @julealgon: Tool comparisons are off-topic for this site as well. I am afraid for this type of questions there is probably no SE site. You can try on quora instead.
    – Doc Brown
    Commented Dec 30, 2016 at 8:51

1 Answer 1


Here are the advantages:

  • The error messaging is generally more specific
  • The stack traces are more readable
  • The turnaround time for supporting new JavaScript specifications is usually faster


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.