Please don't remove gulp. Don't make Bundler and Minifier the default.

[atrauzzi]

I just finished watching the June 21st ASP.net Community Standup and I have to say I'm a little dismayed. In about 15 seconds, gulp and the node ecosystem were effectively tried and executed for reasons that appear to be based on recirculated old information and oversimplifications.

If the ASP.net team didn't want it to be obvious that the Bundler & Minifier Extension was tapped as a quick ditch appeasement for those who resist learning - consider it a failure. What I'm creating this issue for is to say that based on not just my own personal opinions, but the state of every web framework out there, if ASP.net is trying to stay legitimate in the eyes of developers who are flocking to other ecosystems: Inventing and forcing an obscure tool with no mind share that reinforces bad practices is not the way to get there!

Some points of order based on the some things I heard during the standup:

• Nobody disputes whether to commit a lock file. It's not a question, you commit it! Why was this framed as an argument against gulp during the standup?
• Nobody disputes whether to commit dependencies. You don't. Why was this also framed as an argument against gulp during the standup?
• From a practical standpoint, the build file for B&M vs the build file for gulp are functionally identical. Except that one is a format nobody outside of the .NET ecosystem will have ever heard of.
• Gulp is not simply just a minification and bundling tool and to think this is very concerning.
• The typescript team themselves have embraced NPM, so at the very least the MS-web conglomeration is in discord.
• Web development is complicated and shall remain so. To guide people any way else is to invite blame from critics - and eventually - frustrated people who moved away from your framework-full-of-lowest-common-denominators
• Yes, I know I personally don't have to use B&M, trust me, I won't and I'll say here for the record: Nobody else should be using it either.

What I'd like to suggest at this point is that the ASP.net team above all else not bundle B&M as a default with new ASP.net Core projects. It's clear that the B&M tooling is a proprietary hazard that eschews the framework's responsibility to advocate current day best practices.

What this issue is not about however is to say burn it all to the ground. I'd like to also put out there that B&M might have every reason to continue existing as a solution for people who want to move away from the context switches of WebGrease without evolving to a module system. It's a good first step for evolving old ASP.net 4 projects.

So now we have a discussion: What to do instead?

I understand that the JavaScript ecosystem is difficult to navigate. What I don't think helps developers though is telling them to jam a bunch of imperative jquery code and dependencies into their projects and never think about it.

The way I see it, it boils down to:

• Bundle nothing
• Keep gulp
• Facilitate a 2nd pass when scaffolding a new project that allows one to select from a variety of JS stacks

My vote given the deadline looming for the ASP.net team is #2. Stay the course. But I think the only way you're going to fix this is by making it easier for people to know what their options are. Not force them down paths they'll later regret. That's option #3.

[nguyenquyhy]

I would agree with most of the points here. However, I would agree that having npm and gulp in some case is unnecessary. I would prefer to have 2 different templates similarly to what we had in MVC5: a basic one without npm & gulp (i.e. a setup for Program.cs and Startup.cs and a wwwroot), and a web app one with npm & gulp & other stuffs.

[cveld]

I would really like to see a yeoman / Visual Studio templating mechanism integrated. Take a look at the following full featured generator: https://github.com/Swiip/generator-gulp-angular It encompasses many options (see https://github.com/Swiip/generator-gulp-angular/blob/master/docs/usage.md#questions-the-generator-will-ask). One that could be added is "Enable ASP.NET Core".

The position of ASP.NET Core I believe ASP.NET Core has two applications:

1. Responsible for server-side rendering of html and resources, i.e. MVC
2. WebAPI

Could we refactor ASP.NET Core in such way that it is easily pluggable with any other web development setup out there? Put otherwise, can we enable real easy SPA development with TypeScript and ASP.NET Core MVC?

Webpack I am a profound supporter of Webpack which makes streaming your dev assets into one index.html with a limited set of rationalized browser assets very easy to set up. Gulp is very complex and has too many degrees of freedom.

[atrauzzi]

@cveld - Gulp vs webpack is not an apples to apples comparison. They are two separate tools that do separate things. This is an example of how the defaults and advice that ASP.net is suggesting are causing people to misunderstand the ecosystem.

The most sensible choice is to include gulp for the upcoming release and then later introduce tooling that lets people pick and choose which front end stack to layer into their project. Which is my #3 suggestion.

[gulbanana]

the things people most commonly do with gulp can be done with webpack, and sometimes better due to its integration. the comparison is relevant

[atrauzzi]

@gulbanana - Except that then you are then stuck saying the only alternative to gulp is webpack.

For people who use other tools like JSPM, the comparison is less apt. Gulp can encapsulate all these tools, regardless of which you prefer.

The point is to not corner people into a choice - and in the case of the bundler and minifier - a choice that is obsolete from day one.

[markrendle]

I question the long-term value of Webpack with HTTP/2 support already in greenfield browsers and Angular 2 actively supporting proper lazy-loading of modules. Gulp, on the other hand, for dragging packages out of node_modules and into wwwroot, as well as minifying those resources, would seem to be useful for some time to come.

[madskristensen]

The Bundler&Minifier is not a replacement for Gulp. It's a replacement for System.Web.Optimization that we've shipped in MVC for the past ~4 years. It doesn't exist on .NET Core, so we had to find a replacement. So we went through Grunt and Gulp before landing on Bundler&Minifier. Had we shipped System.Web.Optimization.Core in the project template instead, would you have had the same reaction?

[atrauzzi]

@madskristensen - Well hold on a second. I think there's a huge flaw in your usage of the term "we" here.

The only "we" is the general-organizational-we-of-Microsoft with that statement. Gulp is and continues to be the obvious replacement for System.Web.Optimization. Not more of the same with another proprietary one-off solution that isolates MS developers form the rest of the world. My hypothetical reaction to shipping System.Web.Optimization.Core is equal to my reaction to shipping Bundler & Minifier. Both tools are steps in the wrong direction.

So let's rewind back through a few assumptions. At least two of your "four reasons" from the standup were outright strawmen. The remaining two were only considered legitimate out of a fear of reprisal due to "complexity". I'm not trying to make this seem difficult, but is this not starting to sound like a false dilemma to you?

Gulp was fine, why make an inferior tool the default? Why not make the inferior tool an option and then guide people to it as needed? What you're advocating is that File-New for ASP.net Core projects should effectively make an ASP.net MVC 5 project. Why not just call the whole thing off if this is the dominant objective?

This seems more like fighting change for the sake of fighting change considering you already have the better option implemented! EF7 is changing. The hosting model is changing. Configuration is changing. Dependency injection is changing. ASP.net Core is all about change and best practices. It's a teacher and guide as much as it is a tool.

You can't tell me that because one little thing is challenging people that the baby has to be flushed out with the bathwater!

[latchkostov]

I have to agree with @atrauzzi . I work for a very large financial institution, and we were actually in the discussion process of migrating a lot of Java and Ruby applications over to .NET Core, a large reason being that the currently used Gulp and Grunt NPM modules would be easily integrated into the new project. People included in the discussion were giving kudos to Microsoft for supporting NPM in a template, and having those two have the type of integrations we have seen.

At a minimum, could you please ensure that there still is a template that treats NPM/Gulp/Grunt in the same ways that it does today, or that it can be easily integrated into a template and isn't some back-end difficult and obscure method of doing so?

Please Microsoft, listen to some of your customers on this one. This announcement has saddened a lot of us!

[davidfowl]

Everything is still easily integrated, it's just not in the default project template.

[MaximRouiller]

@davidfowl

So after watching the standup, what I get is that... it's just too much for most dark matter developers to "get" gulp. There's also the issue of performance but it's mostly because adding gulp to .NET Core would have been a huge step to get onboard the new stack.

Is that right?

[latchkostov]

@davidfowl

Perhaps showing developers how to perform this "integration" for the ones that desire to do so in either a video/blog medium would be advantageous to all parties.

[atrauzzi]

@davidfowl - I know. That's the problem.

[latchkostov]

Yeah, I will state again. Having a template available that has NPM integrated, and another that's more bare-bone would be the ideal solution in my eyes. By not including it in a template, the underlying message becomes something like "You can use NPM, but it's not part of the default template, so it's easier to 'Get Started' with the alternate solution".

[rondefreitas]

While we're at it, why not get rid of Razor and go back to webforms since so many .NET developers resisted that.

[rondefreitas]

Seriously, though, it was long overdue for .NET developers to join the rest of ecosystem. We should not be taking steps backwards, or we'll remain in the position we are now, wherein the vast majority of .NET developers are half-lost if they ever have a client who needs something written on another platform.

[Bartmax]

I don't agree with @atrauzzi grunt and gulp are old fashion, today is webpack, tomorrow will be a newshinytool. None of this tools are good for web development workflow and I don't consider using them are best practices just because are popular.

actually brunch.io exists way before grunt/gulp and is better than those two.

So image you are the one creating the framework, what would you include? grunt? gulp? brunch? webpack? all?

Those tools should be OPTIONAL. Template should have choices.

But while we don't have choices I think there are few options: 1 - No bundle/min on template. 2 - bundle/min with gulp/grunt/webpack/brunch (someone must pick one based on what?? popularity?) 3 - Use a tool provided by the framework for templates.

I like 1 better. but if I had to choose between 2 and 3, I will go with 3.

I much rather provide a basic tool and then plug the one you like/know yourself than using a predefined one. What if you like webpack instead of gulp? What's the use of the template if it's gulp. (same applies for any other utility you love)

Besides, there is no voodoo science on minifying some css/js files. Don't say like it is complicated.

But as you said, gulp/etc are not only for that, so if you need it, add to your project. Same argument you use that "we dont add this because is hard" goes the other way. It shouldn't be hard for you to right click add new file, done. right?

The templates doesn't need anything else but bundling and minifying ... why should include overkill (bad, out of ecosystem, poor, not ci friendly, heavy, etc,etc tools ?) And again, those tools are NOT the replacement for bun/min the same way that this new extension is NOT the replacement for gulp.

Come on people, if anyone thinks that gulp or webpack are great think again... 1 year ago you were saying the same for grunt...

If it works for you, great, but I don't like those to be imposed, not at all.

I would love to people save your energy about gulp or b&m or grunt or whatever and use it to request templating options once and for all. Templates with options is the REAL feature we need.

BTW: Task Runners should be (and are) supported. Every major one. None is going away.

[rondefreitas]

I don't think the discussion here is so much about the lack of them being supported... it's the new focus on proprietary tools that only exist within the .NET ecosystem, which is a shift from the starting point of embracing what the rest of the open source community has been doing.

Now, if the Bundling and Minification tools from Microsoft was going to be something available as a separate bundling tool with a strong push to be a part of the open-source ecosystem as a whole, I'd be much more open to the idea.

There is a great deal of sharing in the rest of the open-source and dev community as a whole, regardless what language your server-side code is being written in. Sure, one can argue that the majority of that is based around use of JavaScript, as we're focusing on the web community... but of course we know that JS is being used for far more than just client-side interaction... it's being used for building mobile apps, desktop apps, server applications, even as scripting languages for games.

These templates are a starting point for integrating .NET with the community at large. We all benefit when we share ideas openly.

Many of the recent changes geared at supporting .NET core across all different platforms has actually done more to drive away the greater community, whereas earlier progress with asp.net core felt like it was more welcoming.

Believe it or not, there is still a misconception out there among much of the community that the majority of .NET developers have no idea how to work with anything not custom built by Microsoft, and not tied in directly to Visual Studio. We were looked at for years as devs who could do little more than drag & drop. I still meet a lot of older developers for whom that is the case... many of them have been doing nothing but maintaining the same webforms applications for years... almost every dev house I've been involved in over the past 7 years since coming back to the .NET world has been having to reject applicants left and right who know c# but can't write a "modern" application to save their life.

I also still get scoffed at by many developers who focus on other languages at first meeting (back to that whole drag & drop impression)... which doesn't really bother me at this point.

ASP.NET Core, at least the direction it seemed to be going in before, allowed me to make a real case to other developers from outside our community that .NET had gotten better, WAY better, and they were extremely impressed by the inclusion of gulp and bower in the sample templates.

[atrauzzi]

@rdefreitas - 100%, couldn't have said it any better. I'd only like to add that many .net developers are quite talented and based on that shouldn't be so afraid of modern web dev tooling. It's a very artificial barrier and I think given the opportunity and the right guidance from their existing tooling would easily merge with the rest of the community.

@Bartmax - Sorry man, I don't really agree with your description of the JS tooling landscape. The data doesn't really make the point you want to assert. Specifically: Comparing gulp to webpack. Gulp is still quite "today" and continues to receive contributions, being featured in other frameworks.

Now, I'm not sure if you skim-read my initial post, but on the off-chance that you did, re-read it and see that I already raise the idea of better templates as my "number 3" option. But then coming back to what @rdefreitas is also saying: This is about the advice of defaults and a comparison between what's in place today (gulp) and an option that is going to saddle the community with more bad advice along the lines of bundler (bundler and minifier).

The smarter play here would be to just stay the course with gulp, avoid a bunch of legacy tooling and then work towards making front-end stacks something people can pick from during new project creation.

Again, this is about avoiding the carnage of Bundler and Minifier which is basically already obsolete.

[lvmajor]

Totally agree with @atrauzzi.

Would be really nice to have both options as starter templates, one with bundler/minifier and another one with gulp. I personally started coding with ASP.NET Core since it's first release and I loved the inclusion of Gulp. I never did any web development before so the learning curve was pretty steep for me but I still managed to get through it and I'm now really happy to know how to use "commonly used tools" in the open web development. I had to learn literally everything from html/css/js to task runners and backend work and I do not regret going the gulp way. As of now, as soon as I start a new project, I right-click on it and convert to gulp....

I'm not saying that bundler/minifer doesn't do its job, it just lacks a certain level of flexibility and extensibility. For example, a super common task to run with gulp is autoprefixing css files, it's super easy and works great for cross-browser compatibility. With bundler/minifier, there is no option to do that (as of last time I checked, maybe it's been added in the last days) and IMO, that leads to a pretty bloated css code.

[gulbanana]

I recently switched from npm-based bundling (using webpack) to BundlerMinifier in order to reduce build complexity. The performance is very good and I'm happy to not have enormous node_modules folders scattered everywhere. Overall it seems to have been entirely worthwhile - the only worrying question is whether NUglify is really maintained at all.

[atrauzzi]

Yikes. I don't think you understand the benefits and importance of the node_modules folder.

This is exactly what I was worried about with bundler and minifier. It's prompting people to have misunderstandings about industry best practices.

[mkosieradzki]

@atrauzzi I understand that not loving hundreds-dependencies large NPM packages installed in every project now makes me "misunderstand industry best practises"?

Let's face it Gulp is not the best engineered software ever and it shouldn't be shoved down the throats of .NET Core users expecting the best development experience possible. Why? For example because it is requiring you to install all the tooling locally to your project.

In case you run single package project it's ok. But VS is designed to run large projects containing hundreds of modules. Imagine every module uses gulp for it's build proces. Of course you can workaround this issue using links etc - now go and explain all the consequences and mechanisms to the newcomer.

I used to use Gulp, but when @madskristensen added the pluggable Task Runners including the new NPM Task Runner - I have reduced my number of NPM packages 50x and development experience has been drastically improved. I use babel, webpack, minifiers and many other tools but as global or local CLI. Not as "locally installed" NPM hell.

The current solution is really great:

• You want minification and bundling and you don't care about Gulp - go with Minifier and Bundler
• You want local gulp installation - use Gulp task runner and Gulp as usual
• You want webpack - use webpack task runner
• You want sophisiticated, node/powershell scripted workflow use CLI executed from cmd task runner/NPM task runner
• You want simple typescript experience - use tsconfig compileOnSave or Typescript msbuild task
• You want MSBuild workflow - you've got xplat suport now
• You want CI integrated build - go for it
• You want anything else? Probably your scenarios is also covered.

I can really relate to @gulbanana opinion here. If someone need only minifaction and bundling then Gulp is an overkill and performance degradation of VS is substantial.

In my opinion the direction where VS web-related tooling is going is really good. It is possible to work any way you like, and not forcing (but allowing!) developers to use Gulp is definitely the way to go.

[gulbanana]

@atrauzzi it is due to familiarity and long experience with the npm ecosystem that I and my team have rejected it.

node.js has been a drawn out trainwreck; as a community we lost sight of the fact that using javascript in the browser involves no fundamental requirement to use it outside. we've got excellent alternatives like typescript for compiling to ES5, BEM or css modules for assembling styles, and now dotnet bundle for doing sourcemapped minification. this workflow is so much "lighter" and more reliable than file-watched trees of es6 modules and hot loaders that going back seems impossible.

[gulbanana]

here's how we update, say, react: copy react.js and react.min.js into the vendor/ folder. appropriate versions are bundled into the app at build time along with the compiled .ts, and when working on sites we serve out of the folder with sourcemaps+unminified versions. the compile-on-save workflow makes a trivial problem trivial - and you can still switch to "tsc watch || dotnet watch bundle" if you feel like using vim.

[atrauzzi]

@mkosieradzki - The fact that you're saying "install all the tooling locally to your project" shows that you're straining over details that don't matter in the long haul. Just learn more about the tooling is all I can offer you, it seems like you have a bit further to dig in.

@gulbanana I'm currently using TypeScript, react, JSPM, redux and gulp. I can't really speak to how you're using it as the scenarios and comparisons you describe are much like @mkosieradzki - just a lot of mythology surrounding things I don't dispute may have been your experience. But the interpretations or the decisions you made at the time weren't accurate.

I encourage you both to just go and do better research. Talk to experts and obviously don't assign your frustrations to me here because I'm advocating for better ways. You should have no troubles learning this stuff, it's all online in exactly the same places I found it.

Overall, I don't have to strain nearly as much and I have fully built and minified JS projects that I can debug in development mode. I'm not sure why .net developers are so confounded by what the rest of the community succeeds with every day.

Do you ever ask yourselves "maybe I'm the wrong one?" (and before you mindlessely try to turn that around on me, understand that I got here by constantly questioning my own knowledge!)

[gulbanana]

Man I am not sure what you want here; I've got a pretty nice workflow which is not creating frustration or the "strain" you seem to worry I might be experiencing. I posted in this thread to leave feedback on the inclusion of dotnet bundle in asp.net core; that feedback is that it works well, particularly in terms of performance and reduced complexity.

If you think it's mythological that a special-purpose tool could be more efficient and convenient than a general system then we should agree to disagree.

[ctolkien]

We've already moved on from gulp for our projects - as has a large portion of the industry. I strongly agree that the default templates should not be prescriptive in picking a particular front end tooling system. It's just more noise we'll need to rip out with each new project.

[atrauzzi]

http://blog.reviselabs.com/im-sorry-javascript-2/

[kimbaudi]

Whether or not Microsoft ditches Gulp, it doesn't stop us from using it in our ASP.NET projects. I mean, you can always npm init and npm install gulp for your project and create a gulp.js file and integrate that into your project. If you really want to use Gulp, you still can without it being tightly integrated with Visual Studio IDE.

[madskristensen]

@kimbaudi Gulp and Grunt support in VS is not going away

[atrauzzi]

Arguably in its current form, you're still better off using command line as the environment that the VS tooling runs with installs 32bit NPM dependencies. You get faster access to new things as well (yarn).

[madskristensen]

@atrauzzi VS2017 uses the 64bit version of node on 64bit machines. Yarn support is on the backlog

[PonchoPowers]

2017 is out now and I can't find this functionality, where has it gone?

[peterblazejewicz]

@Matthew-Bonner Do you mean bundling/packagers integration in Core? It's gone with .csproj migration

[gulbanana]

No it isn't. You can use <DotNetCliToolReference Include="DotNetCliToolReference" Version="2.4.337" /> to get dotnet build, and/or <PackageReference Include="BuildBundlerMinifier" Version="2.4.337" /> for bundle-on-build.

[PonchoPowers]

Microsoft.AspNet.Web.Optimization works well in conjunction with Gulp because of relative paths, Gulp has no knowledge of relative paths because it is a compile tool, Microsoft.AspNet.Web.Optimization is executed when the application is deployed so it understands how to map ~ to the relative path, the two work in conjunction with each other and one is not a replacement for the other. Microsoft.AspNet.Web.Optimization lacks good support for Less and TypeScript, so this is why both Gulp and Microsoft.AspNet.Web.Optimization are required together. All this makes the Bundler & Minifier Extension redundant.

[Allann]

What is happening with this, and what is this new LibraryManager I accidentally stumbled onto with the latest install of VS 2017 15.8.0 preview? I don't remember installing the extension but that is where it is appearing. Is this yet another 3rd party installer from microsoft? (https://github.com/aspnet/LibraryManager)

[atrauzzi]

At this point I think any kind of task automator and/or bundler, etc... just doesn't make sense as a default. Let people choose, offer a nice experience around installing them, but don't force any one in particular.

[Seefer]

As Mads says, Gulp support is not going away. This seems reinforced by the fact that when I right click on the bundleconfig.json file and head on over to the Bundler & Minifier menu, there's a Convert to Gulp option :)