I think that having default ASP.NET templates free of all this noise (Gulp, node_modules, compiled client-side stuff) is for better! Here is an example how a simple run.js script with under 200 lines of code can handle basically all what would you normally do with Gulp including bundling and optimization via Webpack, deployment to Amazon S3, GitHub Pages with commands such as:
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
One one hand you clearly make progress, on the other hand you spend time on implementing non-critical web dev related features, but neglect major updates to IDE which prevent it from being used by front-end developers.
Like, for example, JSX support. There is currently 5'000 downloads of React.js library per day (from npmjs.org). It's mega popular. But developers can't use it with Visual Studio IDE because Visual Studio lacks JSX support (when you open a React component in Visual Studio, it highlights all the lines as errors). This is the most requested feature on UserVoice, but no any updates on implementing this feature were published for months.
Or, another issue with, is that Visual Studio forcing you to have a pre-defined project / solution structure. But would be nice, if I could just open a regular front-end project and don't need to tweak anything and Visual Studio (as simple as: File -> Project -> Open from a directory). Try to open this project in Visual Studio: React.js Starter Kit
..BTW, I have this assumption, based on the current state of front-end development tooling in Visual Studio, is that ASP.NET Web Tools team is probably listening mostly to the feedback from ASP.NET developers (existing customers). I would personally ignore many feature requests from ASP.NET developers and tried to get feedback and ideas from true front-end developers (new potential customers) which are often not familiar with ASP.NET world, but do know much more about good front-end development workflows and practices.
Nice talk! In overall Web Tools are moving in a right direction. Currently there is one huge problem with web development workflow in Visual Studio - there is no concept of compiling of a client-side code, when you can have all the front-end code of your web application (html, less, typescript, jsx etc.) in one folder, and during a build have them transpiled, re-organized, concatenated etc. according to a pre-defined built logic (with Grunt or Gulp) and saved into another folder from which you debug and deploy your site (currently you deploy your site from a folder containing source files, which is totally wrong from a front-end development point of view). As an example, consider a common web app directory layout:
/build - both 'client' and 'server' projects are compiled into this same folder; client-side files are organized by type after the build; you test, debug and deploy your app from this folder /client - only client-side code; files are organized by feature (see BEM) /server - server-side code (Web Api, SignalR etc)