Different js scripts for different ASP.NET core environments
When you reference a .js framework or library from your ASP.NET application, it makes sense to use the development version when you’re working on your own machine.
For example, if you bring React.js into your MVC app, you’d want these references…
<script src="https://unpkg.com/react@16/umd/react.development.js" crossorigin></script><script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js" crossorigin></script>Referencing the development versions brings more useful error messages and integration with the React Developer tools.
But, you wouldn’t want to use these in production for performance reasons.
When you run the site in production, you’d want to reference the minified production versions of the React scripts.
<script src="https://unpkg.com/react@16/umd/react.production.min.js" crossorigin></script><script src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js" crossorigin></script>NOTE
Minification 101
Minification is where a text file (in this case a .js file) is shrunk, by shortening the names used for elements in the file, and removing whitespace etc.
This drastically reduces the size of the file, making it quicker for the browser to download.
On the flip side, it’s harder to debug a minified file. You probably don’t want to be reading much of this…
ASP.NET Core Environments to the rescue#
ASP.NET Core introduced the concept of “environments”.
You can have different application settings for different environments…
appsettings.json
appsettings.development.json
appsettings.staging.json
This is handy as you can define different connection strings etc. for each one.
Generally speaking, your ASP.NET Core projects will run on your local machine using the Development environment.
You can see this for yourself if you take a look at your project’s launchSettings.json file (in the Properties folder).
"Backend": { "ASPNETCORE_ENVIRONMENT": "Development"},These settings are used when launching your app on your machine (during development).
In production (unless otherwise specified) your apps will run in… yep, the Production environment.
Varying scripts by environment#
You can check the current environment in your own c# code and execute different logic accordingly.
The boilerplate startup.cs file that came with your ASP.NET Core app may include an example along these lines…
if (env.IsDevelopment()){ app.UseDeveloperExceptionPage();}else{ app.UseHsts();}Turns out, you can use similar checks in your cshtml files.
<head> <environment include="Development"> <script src="https://unpkg.com/react@16/umd/react.development.js" crossorigin></script> <script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js" crossorigin></script> </environment> <environment exclude="Development"> <script src="https://unpkg.com/react@16/umd/react.production.min.js" crossorigin></script> <script src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js" crossorigin></script> </environment></head>The environment tag here is an example of a Tag Helper (new in ASP.NET Core).
Tag Helpers provide a handy way to generate html markup using resources on the server.
The environment tag helper may look like html, but it’s actually executed on the server, where it can check the environment, before the html is generated and returned to the browser.
So, when you inspect the resulting source in the browser, you’ll only see the relevant script references for your environment.
<head> <script src="https://unpkg.com/react@16/umd/react.development.js" crossorigin></script> <script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js" crossorigin></script></head>Summary#
Now there’s no excuse for inflicting massive unminified .js libraries on your users!
Use the environment tag helper to load small(er) .js files and save everyone’s bandwidth.
Legacy .NET web apps causing you grief?
Build modern, reliable web applications, faster with .NET and Blazor.
Build better .NET web apps