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.

[ThatRendle]

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.