ASP.NET has seen many changes during the past decade. What once started as a super lightweight scripting language (Classic ASP), has grown into one of the most robust and mature technologies out there today used by some of the biggest organizations in the world. One of those technologies, is ASP.NET Web Forms.
ASP.NET Web Forms, for those unaware, was Microsoft's solution for creating rapid server-side based web applications with access to the .NET Framework and written in C#. The goal was to pretty much have a natural seamless transition from developing a Windows Form based application to a Web Form based application. You could even use much of the same code and on most occasions only required to make slight tweaks to make things work.
ASP.NET Web Forms also introduced the idea of server-side controls. Essentially pre-built HTML controls that were out of the box ready to be bound to almost any data store and which could be manipulated with server-side code.
Why you might want to use it
Despite what you might read online, ASP.NET Web Forms aren't dying out and they certainly aren't going away anytime soon. It's one of Microsoft's oldest .NET technologies, which means that it's also the most updated and mature as well.
It also means that more companies have built their infrastructure on this particular technology stack than in the newer ones, such as .NET MVC or .NET Web Pages. Just for reference, most of the websites that I have worked on professionally have relied on ASP.NET Web Forms. Most were relatively older websites that were successful financially and still going strong. It makes sense that a website has been around for 10 years, will be more successful (usually) than one which has been around for 1-2 years.
Personally speaking, I still use Web Forms for many of my projects as I have built a very robust and stable library around it as well. And that's because Web Forms get one thing right that many other frameworks fail to succeed in. And that's in the fact that it is incredibly easy to setup a Web Forms project. Which is its biggest selling point to this day. Rapid development is still a popular design pattern and certain frameworks are better at it than others.
Every page in a Web Forms project is comprised of 2 files. The markup file, which contains your HTML along with pre-built web controls as mentioned earlier, and the server-side bounded page that handles any and all server logic and events, like reading from a database or validating API private keys. If for example, you have a button on the page that when clicked validates a login, you can simply create click event-handler and let the framework worry about creating the actual HTTP request and response logic. All you have to do is to worry about coding the server logic.
And best of all, the server-side page has access to the server and to any resource in the .NET framework.
ASP.NET Web Forms are also very hackable, in a sense. You don't have to use the actual Web Form technology if you do not want to. You can bypass all server controls and simply have a regular AJAX-driven app. But if you want to stick to the environment and use the many associated tools, there are also dozens of pre-built components a drag and drop away.
Web Forms also include templating controls through the MasterPage layout system, which means that you can set up generic code and controls by adding a single-file to your project and associating it as the 'parent' of other pages.
And because every Web Forms page inherits from the System.Web.UI.Page class, this also means that you can easily implement your own Page classes with your own logic as well. So needless to say, there is alot to like here. Server controls, rapid development, drag and drop interface and a front-end / back-end file system that ensures separation of logic.
But due to its age, ASP.NET Web Forms have had a difficult time keeping up with the latest modalities in software development. So it might not fit every use case that you encounter.
When to not use it
The one area that ASP Web Forms does not excel in in, is in its ability to separate business logic out from the primary code base. What do I mean by that? Well, take the MVC pattern as an example. With an MVC project, you have the Model which is the structure of the application data and the data itself. You have the View, which is the markup of your application essentially. And you have the Controller, which handles all interaction between the Views and the Model. This is where the business logic essentially gets created.
ASP.NET Web Forms do not have that structure built in. As mentioned, .aspx pages are comprised of the markup and the server-side code in 2 different files. If you want to have a data layer, you will have to build one yourself. Which is what I, and many other programmers, have done for the past decade.
Creating a Data Access Layer (DAL), however, takes time and there is an associated cost in terms of development time and maintenance time. Much of the 'wiring' between the front-end facing code and the business logic is relegated to the developers.
Many of the newer frameworks out today, focus heavily on this MVC style model. Even Microsoft has pushed the focus more towards .NET Core applications during the past 5 years. That includes web apps running as either MVC applications or Razor Web Pages. And that's because there are alot of things that ASP Web Forms simply wasn't designed to do.
One of those things is cross-platform compatibility. Unlike a .NET Core application, Web Forms rely on running in the Windows ecosystem under the full .NET Framework. And from the looks of it, there are no plans to port over Web Forms into .NET Core, at least not anytime soon.
So should you use it?
I will close out by saying that Web Forms are still a valid approach for many types of projects. If you aren't building a complex business heavy application (which most websites are not), then it definitely makes sense to use it as a rapid-development tool.
There is over a decade of online documentation at this point, and enough components, controls and functionality there to keep any developer busy and typing with little interruption.
I would say that it is at least worth it to give it a shot. To create a simple project and to gauge for yourself just how quick and easy it is to have an application up and running.