ASP.NET Monsters #42: Goodbye to Gulp

Download this episode

Download Video

Description

A special guest episode with fellow Canadian ASP.NET MVP Maxime Rouiller. In this episode we talk about how the ASP.NET Core team have been pulling back on some cool technologies, especially gulp. Watch to see if we think it is a mistake. 

Tag:

ASP.NET

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      BraveStarr

      I'd have to say this is really disappointing. I saw a talk by Mads late last year showing how Gulp will work in VS, was very excited about it, and am using it now. The idea of using the same tools as non-.NET developers was great.

      I thought his new extension was just a more-UI friendly way of doing the same thing, but was really using Gulp on the back-end, so that is disappointing too. I also thought one reason the extension was going to go away was the problems keeping it up-to-par with other tools...

    • User profile image
      Mads Kristensen

      The NUglify package that BundlerMinifier uses is a .NET Core port of AjaxMIn. It is being actively developed whereas AjaxMin isn't.

      @BraveStar, all the Gulp, Grunt and npm tooling in Visual Studio isn't going anywhere. In fact we keep investing in it and you'll see more features coming live in the next release. All the extensions for Task Runner Explorer for Webpack, Broccoli, Brunch etc. will continue to work and receive updates. It doesn't use Gulp/node under the hood because it doesn't have to in order to bundle and minify. Otherwise it would have.

      If you want to go above and beyond what BundlerMinifier offers, then using Gulp or Webpack is a great choice still. 

      I would encourage you to check out the BundlerMinifier wiki for more details that will shed some light on what this is.

      Remember, Gulp support isn't going anywhere and is fully supported in Visual Studio now and in the future.

    • User profile image
      BraveStarr

      Cool - Thanks for the clarification Mads.

    • User profile image
      Patrick

      You can still do everything you like with Gulp, Grunt ... with a console next to Visual Studio. Let's not make a storm where there is none.

    • User profile image
      BraveStarr

      @Patrick:Why would you want to do that instead of using the tools in Visual Studio though? I never need to open a console... I just save a file or build a project and Gulp tasks automatically run...

    • User profile image
      David​Paquette

      @Patrick: We did talk about that in the video. You don't even need a console outside of Visual Studio since you can still use the Task Runner Explorer to use Gulp directly in Visual Studio. Our main concern is that since Gulp is being removed from the default project template, most people will never use it.

    • User profile image
      Francisco

      Good info on the video, but you need to check your audio setup, you could hear someone breathing heavily for quite a while starting the 6 min mark, it was really distracting/annoying

      http://i.imgur.com/NUyttbn.gif

    • User profile image
      tarkus

      It's sad to see how ASP.NET developers are struggling with front-end stuff ..for years. One way to deal with it is to accept the fact that client-side development is a completely different beast, and doesn't play well with ASP.NET paradigms and tooling. Move client-side code into a separate project with its own build tools and infrastructure. While ASP.NET developers discuss Gulp and thinking what's the best way to integrate it into their project, in the other part of the world, the front-end community is using Webpack, JSPM and similar module bundlers instead.

      Here is a recommended project structure that will work well for both .NET and front-end developers => ASP.NET Core Starter Kit on GitHub

    • User profile image
      David​Paquette

      @tarkus: did you mean JSPM? 

    • User profile image
      tarkus
    • User profile image
      Maxim​Rouiller

      As David mentioned, we're just sad to see something that is understood by most Front-End developers being taken out of a template that is basically a front-end project.

      We may be changing our tooling from B&M to gulp/grunt/webpack/npm scripts... but most developers will do File -> New Project and basically go "Yep. This is my life now".

      The template is what everyone will end up using. So want to minify your images as part of your dotnet bundle? Nope. No plugins for this yet. Want to sprite-ify an image/css? Nope. Not done yet and the list goes on. My most important one will be the linter. 

      I might not know what is to come but I know that once this hits Visual Studio and people start using it? We'll be working with the basic template for the next 10 years. I still work on ASP.NET MVC 2 projects and I have to work so hard to convince them to upgrade to MVC 3-4-5.

      Why? Because if it ain't broken, don't fix it.

    • User profile image
      JoelBennett

      Maybe I'll share my $0.02.  Keep in mind that I haven't actively been doing any ASP.Net development, but I have been trying to keep up on all the news.  (For my day job, I do Python web development.  I'm on the back end team, but have to deal with front-end issues.

      In an ideal world, the build process would be as automated as possible.  I hit F5, it transpiles my TypeScript, minifies it, and bundles it without me having to mess with anything.  At work we've been using Grunt, and I have done a bit of reading about Gulp, and was looking forward to using it.  Given that it isn't part of the default project template does make it a lot less likely that I'll be looking into it.  I don't have a ton of time to do my hobby development, so the less I deviate from the default project template, the easier it is for me.

      In some regards, the current documentation is still pretty scant - I haven't seen a ton of examples of building an entire app from the ground up - back end models using entity framework, showing some basic queries, building controllers, and then making a nice front-end.  The reason I think we haven't seen a ton of tutorials like that is because things are still changing at such a rapid pace.  If someone wrote a tutorial last week using the basic/starter template, they'd now need to go back and update it.  I know that is kind of the nature of software development (constant change), but it is a bit frustrating to try to pick up the new things without some nice solid examples.

      More on grunt/gulp: In the end it really doesn't matter so much to me what the tool is - as long as it doesn't cost me a lot in terms of time to learn how to use it, and it is reasonably painless to use.  The end result should be the same - minified, uglified JavaScript.  As long as I know how to use it, and it does the job well enough, I'm fine with it.

    • User profile image
      AdmSteck

      Personally, I completely understand the reasoning for removing gulp from the standard template. I was exited by it at first, but I'm also the type of developer that enjoys learning all the ins and outs of the tools I use.  Most of the others I work with are focused on the task, and not the tools.  The template is just that, a template to get you started.  It isn't, and shouldn't, be the complete answer to all your development needs.  I don't want to start with an empty folder, but I also don't want to have to delete a bunch of cruft if I prefer something besides gulp.  Not to mention the extra learning curve added to simple apps.

      Also, they started with grunt, then switched to gulp because of popularity.  What happens if grunt bounces back or webpack becomes more popular?  We can't possibly expect Microsoft to update Visual Studio to keep up with whatever the most popular framework/tool is at any point in time.  

      I think they are doing the right thing, and providing some minimum support in the template for recommended best practices, like bundling and minification, so when you do a file/new, you are shown the correct path.  When you run into a wall with the basic functionality, then you look for other solutions.  In the end, it is our job as developers to use the correct tools for the job at hand and we shouldn't rely on any one person/company/framework to dictate which frameworks we use.  As long as their tools (Visual Studio, VSCode) play nice with the tools I want to use, the basic functionality is there, and best practices are encouraged, they are doing their job as far as I am concerned.

      P.S.  How many of us are lucky enough to work on new projects anyway?  Some of our application is still using Classic ASP.  :)

    • User profile image
      cagomez

      There's just as much to say here about the community being unable to do anything if it isn't in the default templates.

      How does the node community survive when they have to figure out how to implement new things on their own, without someone deciding what templates come in a box?

      I certainly understand there are problems with reach, ease of use, and productivity.  Many people just want to get things done.

      I had a lot of hostile reactions to gulp and grunt in ASP.NET vNext (when it was still that).  They questioned what would happen when the next hot thing came along, and the whole key (for them) to the platform was stability.

      It'd be nice if a gulp template was in the box, just to maybe foster the idea that you can go beyond the basics, and what's built by MSFT.  But some people actually tell me they see the insular bubble of everything invented by Redmond as a good thing.

    • User profile image
      Stephen Dee

      RC 2 was mentioned as having the Gulp template, right ?

      So these new (removed) templates / approach to bundling and minification -- Gulp went bye-bye with VS 2015 update 3 ... or in vNext ?

    • User profile image
      David​Paquette

      Gulp was removed from the default templates as part of the ASP.NET Core 1.0 release (which is separate from the VS 2015 Update 3 release)

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.