3

I work at a small web development company, and we use no dependency management whatsoever at the frontend side. External libraries are simply downloaded and pasted into the lib folder of whatever website needs them, and our own libraries are happily copy-pasted. All websites are built on ASP.NET MVC.

Recently I was asked to see if frontend package managers like npm and bower were useful for us, mainly because those are terms that you encounter often nowadays when you're searching online for javascript libraries and such.

So I went and read a lot of articles on npm, bower, grunt, gulp, yeo and many more, and I started experimenting with them in a test web application. But after following a few tutorials, I felt that I was spending a lot of time on things that Visual Studio and ASP.NET MVC already did for me, like bundling scripts and minification. There was a lot of new syntax I had to learn, even though I still had no idea what the point of it all was. It felt like I was adding a whole bunch of configuration in what felt like a clunky way just to make updating frontend libraries is slightly easier. I struggled with Gulp/Grunt the most; I simply could not think of anything that I wanted to do with it, that I couldn't do already.

So the actual question is this: Why would I want to use things like bower and gulp in an ASP.NET MVC environment? What problems are they solving, besides making library updates slightly faster? We don't really feel the urge to update our libraries daily; many of our sites run on pretty old jquery versions, and run fine. An I missing something completely, or are we simply not the intended audience for these systems?

I am sorry if this has been asked before or is common knowledge, but I couldn't find it anywhere. For example, if you search online for 'bower + ASP.NET', you will get plenty of articles on how to use them, but hardly any that touch the why.

UPDATE: Let me clarify the question: What are common things that a developer would use the new host of supported managers in VS2015 (gulp, bower) for, that he can't do without them?

Dennisch
  • 141
  • 5
  • 1
    recommended reading: **[On discussions and why they don't make good questions](http://meta.programmers.stackexchange.com/q/6742/31260)** – gnat Aug 27 '15 at 16:14
  • You might want to bring this up on the P.SE [chat room](http://chat.stackexchange.com/rooms/21/the-whiteboard) – Dan Pichelman Aug 27 '15 at 16:28
  • I have always felt this way, too, until I had a project with a lot of libraries and some that were hard to find. And then I had projects where I had to hunt down DLLs on the developer's machine and really liked the idea of package managers. You also touched on time - not all companies value minimal code and some value time more than anything else; package manger ultimately saves time. But you're right and for most of my typical scenarios, it was simply a trade-off. – rlb.usa Aug 27 '15 at 16:53
  • Fair enough, I wasn't looking for a discussion. Edited. – Dennisch Sep 01 '15 at 12:14
  • @Dennisch the a key part of the too broad close reason is " too many possible answers." The update has in it "What are common things that a developer would use ..." which is asking for multiple things leading to the likelihood of getting answers like "I haven't seen it mentioned yet that XYZ" which is generally considered a poor answer. You need to write your question in a way that discourages poor quality answers like that. List of things type questions have historically produced very poor quality answers. –  Sep 01 '15 at 12:58
  • All right, then This is not the type of question to ask here, I guess. Too bad. – Dennisch Sep 01 '15 at 13:50
  • @Dennisch When StackExchange fails you (and believe me, it does and will) try reddit - the discussions are much more open and you can still get good answers. –  Sep 02 '15 at 11:59

1 Answers1

4

I'll hazard an answer for this one.

You're a .NET developer, stepping into the land of frontend tooling in Javascript. Let's address some of the tooling.

First - in your question, you have blurred the distinction between package managers (npm, Bower) and task runners (Gulp, Grunt). Each is a tool in the toolset, responsible for different areas.

Visual Studio provides task runners for frontend workflows (such as minification and bundling), but outside of Nuget, it doesn't provide a package manager for any frontend modules. While Nuget works, in a sense, it wasn't really designed for frontend packages, specifically; further, as it's not part of the frontend ecosystem, the wealth of packages available in npm or even Bower aren't available through Nuget. (The ones that are may have been altered or tailored to a specific environment, which isn't always what you want.)

In terms of task runners, the web ecosystem has evolved and open-source plugins have been created for Gulp and Grunt that allow a lot of behavior - but these aren't available for Visual Studio. The ecosystem, language, and tooling simply don't match.

Frontend development is no longer a subset of backend development, like it used to be. Javascript in the browser has become its own system, not just an afterthought; the tooling has been updated to reflect this. It's come a long way over the years, and it's moving faster - much faster - than the equivalent tools in Visual Studio. The main reason you'll want to transition to these tools are as follows:

  1. The .NET ecosystem is migrating to the existing toolchains, instead of trying to roll their own. New versions of .NET are changing their task runners to use Grunt, and they are also switching to JSON-based configuration.

  2. .NET is aiming to become more portable. Using the tools provided by the frontend ecosystem (which is by nature platform-agnostic) makes sense in this regard.

  3. These tools are usable outside of the confines of .NET (as JS in the browser, again, has become its own system).

  4. You'll simply have more options in the long run (and, arguably, earlier).

That said - if using the provided tools in VS is easier, then by all means, use them to get your work done. Familiarize yourself with the new toolchains, though, because you're going to need them.