Automatically minifying .cshtml files in .NET Core
debugandrelease.blogspot.com
debugandrelease.blogspot.com
1. Add package called `WebMarkupMin.AspNetCore2`.
2. Add and configure code in your `Startup.cs` like so.
services.AddWebMarkupMin(
options =>
{
options.AllowMinificationInDevelopmentEnvironment = true;
options.AllowCompressionInDevelopmentEnvironment = true;
options.DisablePoweredByHttpHeaders = true;
})
.AddHtmlMinification(
options =>
{
options.MinificationSettings.RemoveRedundantAttributes = true;
options.MinificationSettings.RemoveHttpProtocolFromAttributes = true;
options.MinificationSettings.RemoveHttpsProtocolFromAttributes = true;
// More options if you like so
})
.AddHttpCompression();
The main difference between this and WebMarkupMin is that WebMarkupMin runs at runtime - therefore it is costing time to minify when you can already minify the files before launching your web application.
Also, this reduces complexity of the project. Both methods are fine, it's just I prefer this one.
To illustrate the point, let's take the current Hacker News front page:
+=================+========+
| Description | Bytes |
+=================+========+
| Original | 43,595 |
+-----------------+--------+
| Minified | 41,368 |
+-----------------+--------+
| Original (GZIP) | 7,350 |
+-----------------+--------+
| Minified (GZIP) | 7,247 |
+-----------------+--------+
Was there a specific case you were referring to?
I mean, it's a cheap shot, but it's frankly so unproductive compared to Django it's basically a running joke. Not that .net core doesn't see a lot of usage, much like angular it's very popular in the european public sector, but it's just such a waste of resources. By resources I mean, man hours by the way, because it's really effective technically, it's just that, all that you can pay for around a million years of AWS/Azure time for the extra wage-hours you need to pay programmers when you use .net instead of something useful.
And in two years it'll be obsolete anyway, because by then Microsoft will have completely changed their direction, again. I say this, as as someone who's running Azure and 365 as our cloud provider for the majority of our services, as someone who's genuinely happy with the services Microsoft provides and having had a great 25 year long business relationship with them, but as far as development goes, .net is just too crazy to be worth it these years.
I also find it preposterous that .NET Core will be obsolete in 2 years, and I'm not sure what you mean about Microsoft changing direction "again" - the .NET Framework was released almost 2 decades ago, and I find the recent move to a cross-platform runtime to make for exciting times!
I've only dabbled with F#, but I always enjoyed it when I do - I just wish I could find the time to spend on it :(
I mean, even .net standard came and went before we even started using it, considering it won't be part of .net core 3.0.
Hah, I forgot about Silverlight - mainly because I never used it (did anyone?)
> razor/mvc
Eh? Razor is very much still alive, and MVC lives on as ASP.NET Core MVC.
> because in the real world, moving people from asp.net classic to .net core costs money.
Yes, I live in the same world, and have migrated several projects from .NET to .NET Core. If you were an early adopter, it could admittedly be a bit painful, but everything "just works" now.
> I mean, even .net standard came and went before we even started using it, considering it won't be part of .net core 3.0.
Really not sure what you mean here, and I can only guess that you've been thrown by Microsoft randomly releasing new .NET Core versions before the corresponding .NET Standard versions - releasing the implementation before the API. I don't like this myself, but it hardly means that .NET Standard has "came and went". Also, just a couple of weeks ago, Microsoft said ".NET Core 3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1"[1].
[1] https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcin...
I agree that's still terrible news though, and I'm not sure how I managed to miss it. This seems like a very bad idea.
You could say the same about the whole industry, also I don't think "obsolete" is a good term, maybe some technologies are not the "new shining thing" out there, but well written systems with "old" and "uncool" technologies are still working perfectly fine and they will keep working fine in the future.
I feel .net core is productive to django, but I don't like using python so my opinion is bias.
Django is at a completely different abstraction layer.
Doing the minification before the application starts saves time from a pipeline minifying on the fly.
That would only affect a cold-start (app pool recycle) or a view recompile before that'd be an performance concern, unless I don't understand how/when views are cached and then evicted from cache.
If you have a lot of views with a lot of partial views inside them, then yeah, you'd only want to run minification once on the final view, instead of for every partial view. I'm not sure if you'd have (or want) that much control over the view rendering process.
Btw it's a cool post if you're the author.
And yes, I am the author.
ASP.Net works by generating an assembly from source files (like .cshtml) that essentially amounts to a whole bunch of `Response.Write("<HTML>")`. If it (Razor in this case) could be made aware of insignificant whitespace, it could omit the writes for whitespace.
https://www.softfluent.com/blog/dev/Enabling-gzip-compressio...
If you have to set up minification once to gain ~3% reduction in page size, I think we would all do it (even though its 3%).
Vue is probably the best general-purpose SPA frontend option for .NET right now, in my opinion, but I'm really hoping that Blazor unseats it. Being able to reuse library code in the frontend would be fantastic! I've got a few use cases for this already that would avoid round trips to the server or duplicating/maintaining logic in different languages.
Very few websites are actually worthwhile doing as SPA, and guess what they are actually fast to deliver static content instead of JS frameworks.
If you're still using Razorscript then you're probably causing more work for yourself than you realize, both from a resourcing standpoint and a functional one.
By modern I mean using a very popular language in a domain that specifically has that language as its primary and first most choice in that domain for every single aspect of that domain's development. From the pool of developers you can choose from, to where those tools and applications can be run, to how you construct your web applications.
On a new project that doesn't have historical roots in using the Razor view engine, again, what is Razorscript bringing to the table that other server side templating languages/frameworks are not? Why would you willingly choose to use a view engine and templating language that costs you in functionality, reduces the flexibility of your views, reduces the amount of programmers that can work with it, and causes really really bad start up times/cache miss hits (lol @ precompiling your views, so you can restart your app pool for tiny little changes)?
You don't need an SPA to move away from Razor. It's quite the opposite: you better have a damn good reason to continue to use the Razor view engine.
Server-side rendering is my default go-to - IMO, this works very well for the majority of needs.
I only bust out a front-end framework if the app is sufficiently complex that it can justify the extra work.
That's not what was stated at all. Razorscript specifically only works in a certain environment. Other templating langues have the ability to be rendered server side and client side, have a wider development audience, and work on a variety of environments.
>I only bust out a front-end framework if the app is sufficiently complex that it can justify the extra work.
That's nice that you have such constraints, but it doesn't negate the fact that when the time comes you now have to work with two different systems instead of just using one. This by itself means you'll have to write more code, and finagle your data to work with two different frameworks and paradigms, AND you'll inherently have a split team.
It's pointless to use Razorscript when you gain nothing from it and it actually ends up hurting your code and your project.
Apologies, I mis-read the comment, maybe I transposed parts of it with another, I don't know, but I thought it was an attack on server-side rendering.
> That's nice that you have such constraints, but it doesn't negate the fact that when the time comes you now have to work with two different systems instead of just using one.
YAGNI - the time invariably never does come.
If you are not dealing with a sufficiently complex app to the point where you don't need to use JS in a web application, then why are you using ASP.NET in the first place? Kind of renders this whole discussion moot when the entire platform isn't a fit for the application.
> why are you using ASP.NET in the first place
Because I need to do normal shit with backend systems - databases, message queues, APIs, ERP systems and the like.
You don't need to. But what if you could just go ahead and use a proven, extremely popular templating language/engine anyways, just in case. At no cost.
>databases, message queues, APIs, ERP systems and the like.
And the web application exposing this data is already not a borderline SPA? I'm surprised.
I don't see added complexity as no cost, and I don't need to add a templating engine when Razor works very well.
> And the web application exposing this data is already not a borderline SPA? I'm surprised.
See, I look at this a completely different way - I wouldn't want clients able to communicate directly with all these components. In particular, I really wouldn't want web clients communicating directly with our (multiple) ERP systems (and neither would our licensing or security people) - it's a lot simpler (and cheaper) to centralise access at the server-side.
I can tell we're not going to agree on this, and thats fine, I like that you're passionate about it, and bid you adieu :)
Where is the added complexity?
>and I don't need to add a templating engine when Razor works very well.
I mean, objectively it doesn't work very well.
> In particular, I really wouldn't want web clients communicating directly with our (multiple) ERP systems
I don't see where I stated they needed to directly communicate with the ERP systems directly. There's still complex state that's being communicated to the client. If you're handling the visual aspect of this purely on the server, that pretty needless and costly. Costly to render, costly to maintain.
Maybe your app is that simple, and maybe moving a lot of it to JS/AJAX would make it more complicated and less accessible to the end user.
They're super fast (HN is a good example!), and dev work is much quicker for basic stuff that doesn't involve too much complex interaction.
If you're using Razorscript still you are doing yourself and your company a large disservice. There isn't anything Razorscript brings to the table that makes it a worthwhile option. And even worse, if you are using Razorscript, you will have to write more code to specifically be in harmony with any other kind of front end framework.
And please I beg of anyone replying to these messages to not get confused and assume that pages not written in Razorscript are somehow specifically trying to be an SPA. They are not. The clear difference between something like Razorscript and say using server rendered react, is that the former will only ever be rendered on the server, and the latter can be rendered on both the server and the client.
Thanks !