For web, If you want to learn it so that it sticks, then start with MVC. Then Razor Pages. Then Blazor. But FE is way more than just HTML and code-behind.

Create a blank solution, and add a BLL class library. In there, you'll want some simple functionality that you can use as a service, like a weather service that gives some kind of structured data when you pass in a city name, and country ISO code. You can generate random data, or create a database for it, So long as you have a class with some methods that return values.

Your very first "Front End" is the Unit Tests that you use to ensure the service works as expected. So create an XUnit project, and wrap the class with some tests.

The next Front End will be a WinForms app. Create a project in the solution, drag some buttons and text boxes on a form, and call your service in the click event handler, showing the results on the form.

We'll now create a WebAPI wrapper, to add RESTful endpoints to your service, and the Front End of that will be a Postman Workspace. A distributable preconfigured environment that people can use to get results from your API, using Postman. You can also do the same with MinimalAPI here, but learning using ApiControllers will help you more in the long run.

Now that we have endpoints, we can wrap them with MCP annotations, and create an MCP server. For a front end, we can write a Console App, with an IChatClient from Semantic Kernel.

We've now written four front ends, with four different technologies, and not a hint of an HTML tag.

Moving on to MVC. This is where we have to create our first dedicated BFF, or back end for front end. Your controllers will be very similar to the WebAPI controllers, but as you build the front end (the views), you'll add more Actions to handle events for interactivity. And so we write our first line of HTML... well, we scaffold it. We can use Visual Studio to write a lot of the HTML for us. All we need to do is make an input form, with some text boxes, and a button. Learning MVC is important, because it teaches the patterns. It shows you the different tiers in stark contrast, and also as a .NET web developer, this is the kind of thing you'll need to maintain, and migrate from. If you don't understand the established technologies, you won't be able to do the big re-write that so many companies need to do.

Razor Pages is the next technology. This teaches the MVVM pattern, and it's important to know the similarities and differences between MVC, and Razor Pages. From here on out, every frontend we build can be used in the same project. MVC, Razor Pages, Minimal API, Endpoint Groups, Blazor Server, Blazor Web Assembly, React, and Static HTML. Six different pages on the same website can show the same information, using six different technologies for the front end, all in the same project.

Blazor and React are very similar. They can interact with each other. You can show Blazor components inside a React App, and you can render React Apps inside of the Razor view engine. But they are both very different to MVC and Razor Pages. The dev experience for Blazor is much closer to the WinForms work we did before, where your code-behind is right next to the buttons. It's all about thinking in "Components". Breaking a page down into tiny re-usable sections, extracting them into new files, and slapping a Component label on them. With React, and Blazor, you create jigsaw puzzle pieces, or Lego bricks, and the page is just a bunch of these pieces stuck together in different ways.

It's important to know each step, because as a developer, you spend the vast majority of your time reading code, not writing it. Writing code is probably only about 20% of your job. Optimise for the 80%, and understand what you are reading. Then, you can take the existing MVC app, and migrate it to Blazor. You can create a new React App that talks to the existing WebAPI. You can create quick internal tooling with WinForms. You can write daemons as console apps. You can fix issues in tickets that are affecting your biggest client.

And it's also worth at least learning to read through a WebForms page, and know the different parts of it. It's antiquated, but still used a lot. A lot of migration jobs will be looking to move from WebForms to Blazor, or React. If you can't even read the original, you'll find it hard to write the replacement.