• You want to start a new Blazor project from scratch.
  • You want the bare minimum amount of code to get started.
  • That means no Counter.razor, SurverPrompt.razor, Boostrap, extra css files, etc.
  • You use the Visual Studio or dotnet CLI out-of-the-box Blazor project templates to create a new project.
  • Now you have to strip out all of the sample code the template provides.
  • You waste time ⏱. You get older 👴.




Create Blazor projects with the bare-minimum amount of code in no time.

Install CleanBlazor

dotnet new — install FriscoVInc.DotNet.Templates.CleanBlazor

Create a Blazor project (dotnet CLI)

dotnet new — install FriscoVInc.DotNet.Templates.CleanBlazordotnet new cleanblazorserver --output <my…

The Boy Scouts have a rule: “Always leave the campground cleaner than you found it.” -Robert Baden-Powell-

Kermit the frog as a boy scout

For us software developers, campground = existing code.

So when fixing a bug or adding a new feature, we clean up all related code right?

Yes, but…

If we do so, we end up “polluting” our pull requests.

As a really trivial example, let’s imagine we’re fixing the bug below, followed by a Pull Request.

Bug 🐛: Notice that person.LastName is not set, therefore we get a NullReferenceException in line 12.

Also notice how the IDE warns us of potential code cleanups. E.g…

The Introduction Before the Introduction

Last time, we started off by explaining the core concepts of WebAssembly and how you can try it for yourself with little to no setup. If you need a refresher, please refer to this link.

This article is more of a how-to on getting up and running with a production-grade web project which incorporates Rust (or any other language for that matter) and WebAssembly into your web pages.


Nowadays, as front and back end developers we’re used to having tools save us time and avoid human errors by performing mundane tasks such as code compilation, style checking, code organization, optimization…

Leveraging Base Controllers and Dependency Injection to stick to the DRY Principle


In most medium to large web API’s, most controller classes tend to use common services such as ILoggers.

Even though ASP.NET Core makes most services easy to access via dependency injection, sometimes initializing controller classes can get repetitive, and thus making it difficult to stick to the DRY principle.

Take the below snippet of code for instance. Out of the five services being injected, probably four of them will be re-used in other controllers. This means each of these controllers will have to be initialized in the same way.

Arguably most speedy developers would agree that it’s best to keep your fingers on the keyboard and away from the mouse.

That said, let’s go over the traditional way of adding files or folders on Visual Studio:

Francisco Vilches

Software Developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store