Here’s Part 2 of a guide for developers to familiarize themselves quickly with the overall idea of ASP.NET Web Forms and Blazor, and what Telerik has to offer for both technologies.
(Check out Part 1 here and Part 3 here.)
In the previous blog post we covered the ASP.NET Web Forms and Blazor web platforms, some of their pros and cons and features. Now it is time to review what Progress/Telerik offers as UI components for both technologies and whether or not there is compatibility between them.
Read: A Beginner's Guide to Blazor
Telerik UI for ASP.NET AJAX
Over 100 components. Everything you are looking for under one roof. Top stability and utility.
This is the product which elevated Telerik to be a first-class renowned brand around the globe, trusted and chosen by Software Developers galore: ASP.NET AJAX Controls.
You will find all the functionality you need to be already provided built-in by this suite. And even if you have a really specific scenario, there is a big chance that you will discover a possible implementation via custom code somewhere in the plethora of forums, resource base and library samples.
Many users choose this product for building enterprise-level projects and improving existing ASP.NET Web Forms applications. Having such large variety of UI components at hand, you are enabled to implement a professional, fully functional and accessibility compliant application in no time and without hassle.
Telerik UI for Blazor
An edge as sharp as it gets. The solid fore of the Telerik ship arrived with Blazor to take web development by storm.
I want to begin immediately with the facts for Telerik UI for Blazor since they speak for themselves:
- Earliest adopters of the technology
- In constant contact and feedback sharing with the Blazor team since the beginning
- Mentioned in the official Microsoft Blazor page in the “UI component ecosystem” section
- Mentioned in the Blazor WebAssembly Official Release Statement in the “Ready-made components” section
- Regularly showcased in webinars and conferences by the Blazor team
- First on the market to provide native components from the ground up
- Top-notch support experts to back this up
- Unique openness and listening to customers. Have a feature requirement? Based on demand, it is very possible that it will be implemented in one of the next two releases (happening not every four months, but every six weeks).
You can also follow our Blazor Week Events.
Anyone who has experience with Telerik controls knows that the functionality provided by the controls will be top class. For newcomers, here is just the tip of the iceberg: Built with mobile in mind, CRUD operations, templates, file upload, charts, themes, Excel exporting, and many more features demanded and enjoyed by our users. Feel free to follow our Release Blogs to catch up with what’s new:
Telerik UI for Blazor: 40+ Native Components with Telerik R2 2020 Release.
We are particularly delighted by the fact that our customers appreciate the native essence of our components. They are built natively for Blazor from the bottom, which frees our users from additional dependency on frameworks or libraries, and also gives ease of mind that no drastic change will be required in the future if this kind of nativeness is implemented in the middle of the lifespan of a given toolset.
Are these two toolsets compatible? Can there be automatic migration?
Let’s make one thing clear from the beginning—you will need to start from scratch for the UI part. Web Forms and Blazor are not only different technologies themselves, but they also target and use different .NET frameworks, which are not compatible. The easy part is that both the technologies use C# event logic massively, so you can still use the same C# code which is not related to UI controls specifically—database queries, conditional statements, authorization checks, etc.
It can be still possible to re-use your Data Layers, libraries with business logic, models and some classes if the dependencies they are using are also present in .NET Core 3.0+, especially if you can build them against .NET Standard 2.1. But a complete rewrite will be needed in the UI part.
One key point is that Web Forms is not supported by ASP.NET Core, which is the new focus of Microsoft as a complete rewrite over .NET framework:
Choose between ASP.NET 4.x and ASP.NET Core.
Then, why are the Web Forms people so excited and eager to join the Blazor community? The reason is the bucket of similarities between them. Although they have quite different processing under the hood, building a Blazor app pretty much resembles Web Forms from a developer standpoint:
- C# code
- Very similar event-handling
- Web User Controls in Web Forms vs Components in Blazor—both technologies leverage a heavy use of reusable piece of UI
- MainLayout.razor resembles MasterPage.master
“Cool, but what about VB? Some people are still using this language.”
The answer is clear once again: switch to C#:
“.NET Core does support VB such that you can create and build VB based projects. VB based class libraries can of course be used from ASP.NET Core and Blazor apps as they compile to .NET IL just like any other .NET language. Razor, however, is based on C# in .NET Core. Razor is used for authoring MVC views, Razor pages, and Blazor components. The Razor SDK compiles Razor files into C# classes. This means that Razor files need to live in a C# project to get an appropriate tooling experience. Maintaining support for Razor for just C# is already a significant expense as it involves being able to parse a mixture of C# code and markup. We have no plans to add Razor support for other languages because of the added cost involved.”
—Daniel Roth, program manager on the Blazor team (source)
As for the technical specifics in transition, these resources would be very helpful in providing the details.
Big kudos to the Microsoft’s Blazor team, who have taken the time and efforts to prepare a full-blown ebook on the matter: Blazor for ASP.NET Web Forms Developers.
And here is the dedicated section on migration: Migrating a code base from ASP.NET Web Forms to Blazor.
Read: Part 1 of this blog series
Read: Part 3 of this blog series