Building static resources

[danroth27]

No description provided.

[RehanSaeed]

This is my wish list, I'd like to be able to do with Blazor:

1. Use a build tool like Webpack, ParcelJS or Gulp so I get the flexibility of being able to use the myriad of plugins and extensions to my build process. I'd like to see Blazor avoid creating it's own build ecosystem from scratch as it's probably never going to be as rich. That said, I can see why some would want Microsoft to add their own simplified build story.
2. I'd like to add a <style> tag to my cshtml file and use my build tool to extract the CSS into a single separate CSS file. Vue.js single file components currently does this in Webpack by providing a plugin called vue-loader which reads the single file components and extracts the CSS.
3. I'd like SASS/LESS support in my <style> tag. I can provide a type="{webpack loader name}" attribute in Webpack to determine which loader is capable of reading this file.
4. I'd like to somehow import images, fonts, JavaScript, TypeScript modules so that tools like Webpack can build a tree and output bundles. The scripts could be files on disk or from NPM packages like jQuery etc.

[mikefayer]

Seconding @RehanSaeed in how the style tag should work. Generally, looking at how Vue does things is IMO usually a good idea.

[chassq]

My notional $.02.... I would like to see Balzor keep the build story simple but pluggable. Make use of Web Compiler, Browser Link, etc. But allow for folks to plugin WebPack, Gulp or whatever they prefer. This is the issue I have with Angular and React making the build so ceremonious and tedious process. Webpack is super sophisticated but is still overkill for most project I feel. Especially for folks just getting started. Also, not having to keep node, typescript and node_modules in sync on what versions work together would be a welcome relief that Blazor can possibly help with. Also, the whole notion of having to build client-side and server-side webpack scripts to provide isomorphic capabilities, for example, is just too much overhead imho. Hopefully Blazor can build a better story here and make this far more seamless.

[MV10]

I'm with @chassq, Blazor needs to be the tightly-focused foundation of the stack, and right now that focus seems to have completely vanished in a haze of scripting-framework-of-the-week influences. I think it's a long-term mistake in the making. Not everyone fetishizes Angular and the many other scripting flashes in the pan.

For many of my colleagues, the attraction to Blazor is the possibility of running C#/.NET in the browser as webasm, period, full stop. Nothing more, we'll take it from there. When you build and maintain suites of multi-million-dollar 100,000-line enterprise LOB systems with 50,000 global users and product lifecycles measured in decades, browser limitations are a severe pain point and JS frameworks that vanish in two or three years are nothing but a cost to be avoided. We need performance, consistency, and control. Blazor promised all of that.

All the noise about SPAs and bundling and other considerations are better left as future tasks for other repos built on top of Blazor, not built into it. I understand it's "experimental" but even experiments have goals, and I'm getting the strong impression Blazor is losing focus by trying to be all things to all people. I was very excited about the original Blazor demo, and earlier today I came here excited that it became an official aspnet repo. Then I saw the nodejs requirement on the main page and started reading the issues and requests, and now I'm just hoping it survives long enough to become a real product -- and one that isn't just javascript-dot-net.

[GoranHalvarsson]

I agree with @MV10, BLAZOR can be something really big here. Don't let it be just another "Javascript Framework" that soon will be forgotten....

[XmlmXmlmX]

This is my wish list, I'd like to be able to do with Blazor:

1. Use a build tool like Webpack, ParcelJS or Gulp so I get the flexibility of being able to use the myriad of plugins and extensions to my build process. I'd like to see Blazor avoid creating it's own build ecosystem from scratch as it's probably never going to be as rich. That said, I can see why some would want Microsoft to add their own simplified build story.
2. I'd like to add a <style> tag to my cshtml file and use my build tool to extract the CSS into a single separate CSS file. Vue.js single file components currently does this in Webpack by providing a plugin called vue-loader which reads the single file components and extracts the CSS.
3. I'd like SASS/LESS support in my <style> tag. I can provide a type="{webpack loader name}" attribute in Webpack to determine which loader is capable of reading this file.
4. I'd like to somehow import images, fonts, JavaScript, TypeScript modules so that tools like Webpack can build a tree and output bundles. The scripts could be files on disk or from NPM packages like jQuery etc.

👍 for SASS

[mkArtakMSFT]

@javiercn how much does Client Web Assets work cover this?

It will work for allowing webpack or any other tool to be included in the pipeline but will not add support for extracting CSS from views or using other tools like Less/Sass inside views. That's not something we plan to pursue.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

Thanks for contacting us.
While this may be a great idea, it is not aligned with our long-term vision to make it part of the framework. For many other ideas which don't belong to the framework we encourage the community to build and ship on their own, contributing to the expanding .NET Ecosystem.

You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.

[mkArtakMSFT]

We're going to do some improvements in this area as part of #52819