First of all, let’s take a walk in a brief history of the Asp.Net.
Asp.Net Web Forms
In my very beginning journey, the most famous project among the .NET platform was the now hated Asp.Net WebForms, which helped many companies on that time to migrate some legacy Windows Forms application to the Web platform, once the Visual Studio allowed developers to drag and drop web controls in visual design mode, a similar experience that took place for desktop applications. I know that feature usually did not generate the best HTML ever, but I think the idea was good in general and had its value at the beginning of it. The Asp.Net Web Forms had a not good performance in many cases, once everything was rendered in the backend, including the HTML, keeping the state using “tricks” with View State. The payload of each page could be enormous in many cases, but it was pretty easy to develop with.
Asp.Net MVC
After about two years of the Web Forms release, many platforms were starting using the MVC (Model-View-Controller) approach, being largely adopted for many languages, such as Java, Php, and many others. The .NET Framework introduced the Asp.Net MVC project template in order to follow the good practices used in the rest of the market. It was a tremendous success because it was possible to separate responsibilities between the different layers of the application by default and the Visual Studio tools allowed us to easily create CRUD operations using the scaffold option, which creates all the necessary views, database commands using Entity Framework and the logic in the controllers without relevant effort. It was a lot of productive and everyone was convinced of its benefit comparison to Asp.Net Web Forms:
better performance
compliance with good practices of separation of concerns
More alignment with the concept of Web API for the upcoming boom of client-side libraries
Improvements in terms of testability
Security enhancements
The Asp.Net MVC project template had a huge impact on Web development among .NET developers once the majority of enterprise applications to this date still having many CRUD and repetitive operations. Additionally, the use of integration tests was already a popular practice at this point and the use of Controllers for handling the requests became the task much easier.
Asp.Net Web API + Client-side libraries
Web development changed considerably in order to move the payload from the server to the client-side in every case it is possible. With applications being used by millions of users making constant requests, scalability became a key point and, in this context, the responsibility delegation to client/browser was definitely a good idea. The use of client-side libraries got pretty popular with Angular and React leading the market. In order to meet this demand, the creation of an application with only Web APIs in the backend and Angular/React projects in the frontend was a powerful option in order to keep the use of Controllers in the backend and meeting the requirements of the use of client-side to build Single Page Applications. Therefore, the Angular and React templates combined with the Asp.Net Web API project in the backend started being one of the most preferred options among .NET developers for Web development.
Improvements on Razor pages
Among all the improvements brought by the .NET Core platform was related to increasing the power of Razor pages, introducing new possibilities in terms of reusability, giving more options to the traditional concept of partial views. The way to build components started looking like the standard Web components usually built-in Javascript, including the use of parameters, one and two-way data-bind concept, etc. However, this approach still with limitations in terms of performance if we compare the same application built with Angular or other client-side libraries/framework in the front-end. The front-end was still being processed in the server after each request. Therefore, it presented many limitations in scenarios where there are a huge amount of requests. Scalability sometimes represented a huge challenge.
Blazor Web Assembly
This is one of the most exciting additions to .NET since I start working with Asp.Net over the last 15 years. It has great potential in terms of evolution and gives us the possibility of taking the advantage of our full knowledge in C# without having to spend a great effort to learning complex Javascript frameworks or libraries among teams that are not so familiar with Angular, React, Vue JS and others. The use of WebAssembly was a good choice in my opinion once it will become more and more popular in the next years among other technologies. The features available in the browsers have increased over the years and we can surely think of browsers as “min-servers” right now.
I’ve been sharing content, demos and making presentations about Blazor for more than 3 years now and I’m glad to see that it is finally being used by many Web developers already and many big companies are adopting it worldwide considering the potential it has.
Given this overview on the Asp.Net history without mentioning proper dates for them, it is time to answer the main question related to the main topic of this quick article.
Why should I migrate to .NET Core/.NET 5?
The answer behind this question is quite controversial once different companies have different scenarios as well and the analysis of it might be quite relative. Because of that, I’m going to give my opinion based on general situations, not for a specific scenario.
The first versions of Asp.Net applications took place almost 20 years ago, which is such a good time if we think that we had at least one big update every 6 months since it. There is a reason for having updates and new releases in many technologies and the Information Technology business is quite dynamic in terms of competition and innovation. How many companies and technologies that were popular 20 years ago don’t exist anymore?
So, these are the reasons why it is valuable to move to .NET Core/.NET 5?
1- There is no support anymore for really old versions of .NET Framework
2- There are no updates anymore regarding Web Forms
3- Probably, the maintenance of the project built in old versions of .NET Framework is costing more money once it is consuming more server resources
4- .NET Core and .NET 5 contain tons of improvements in terms of performance
5- Improvements in terms of syntax and features in newer versions of Asp.Net and C#
6- Better security is always a good point in newer technologies
7- Over time, it is much harder to find professionals who are willing to working with old technologies. Everyone likes new technologies and it includes getting difficulties in the hiring process by the companies.
8- The sooner the better for updating to the newer versions once as long as there is a delay in doing that, the jump will be too big causing possible instability problems.
9- Opportunity to constantly review the projects to be sure they are following the best practices of software development.
10- Stability is a good point here once newer versions always contain relevant updates and fix the legacy features.
Conclusion
There are many cases where the migration is not recommended or should be considered carefully, manly when the application depends on external libraries and packages that don’t support .NET Core or even .NET 5. Additionally, the risk of migration should be always part of the considerations for any situation. A stable legacy project using old technologies is better than an unstable project using newer technologies. Business and profitability are always the main points behind the decisions of migrating or not a system. So, take those in any planning.
Source: Medium
The Tech Platform
Comments