I have purchased a professional license of Radzen and I would like to convince my client (large US company) to use it internally. Unfortunately, they will not commit to a product that could let them stranded if the company stops supporting it, and that is a risk with Radzen.
After testing Radzen, I realized that if I use it on a big project, I am stuck with the version of Angular that is supported by Radzen. Is that really the case, or is it just my lack of knowledge about the project?
I have seen interesting improvements coming to Radzen, like code generation templates, which could solve this issue. Does anyone know if these templates will completely cover Angular code generation, meaning that if we need to upgrade Angular, one could change the code generation templates to generate for the new Angular?
Any thoughts about this from experienced Radzen Angular developer?
Finally, does this problem go away if I switch to Blazor?
Unfortunately, I think I might not have stated my question clearly enough.
I am working for a large US company that would like nothing more than to adopt a low code product like Radzen.
The problem is that if they invest in Radzen, and you guys decide to not support Angular anymore, or if you go out of business, they get stuck with their code base which they cannot upgrade anymore.
Does Radzen have a solution for this?
Some companies sign agreements where their code is in escrow and is given to the clients if they go out of business, or they stop supporting them.
Thank you again for your patience with my questions. I am only asking because I would like my client to purchase many licenses of Radzen.
We are not one of those companies and don't sign any additional agreements with our customers. If this is a requirement for you please let us know. We will fully refund your purchase.
Thank you for the offer to refund. I do not ask these questions for my copy of Radzen, which I am glad to keep. I am asking these questions because I would like my client to adopt Radzen, and I know that if I propose Radzen to them, this is what they will ask.
Yes, the application can be built and run without Radzen, but the underlying frameworks (.net core, Angular, Blazor) can not be upgraded on these applications without Radzen supporting the new version, as the new framework might break the generated code.
That's the situation with all Angular and Blazor applications - new versions of the framework often break existing code and need updates. This isn't a problem related to Radzen at all.
When a new Blazor version comes out we do our best to support it. And our experience shows that there are always breaking changes. Of course if Radzen doesn't exist the developer has to do those changes manually. That's what all Blazor developers who don't use Radzen do today (and will continue to do for every new major version). The situation with Angular is similar - their CLI allows upgrades but they are semi-automatic and only upgrade the boilerplate code unless it isn't customized.
I understand your point, but please understand mine: of course if I write the application myself, and the framework needs upgrading, I will have to refactor and fix.
But at least I can.
If the application is written using Radzen, I can't. I have to depend on you guys for that, and if you decided not to support Angular because 80% of your clients are using Blazor, or worst if you went out of business, I am stuck with dead code. As a business, this is a very big risk.
Is that a fair assessment, or am I missing something?
I am not asking these questions to be difficult. It is just a business risk that I need to identify and quantify if I intend on trying to get my customer to adopt Radzen.
You can always upgrade a Radzen application - all the code is available. I've linked the build instructions in my previous reply. The fact that you can build and run the app without Radzen proves that you can upgrade your application. However if you upgrade to a framework version which Radzen does not support you can't continue using Radzen to develop that app - you will have to continue on your own.
Here is an example. You create a Radzen Angular application and ship it. After a few months you decide you need a killer feature from Angular 25 which however Radzen does not support. You can then upgrade the code of the app to Angular 25 (using the official Angular migration guide) and continue developing it without Radzen.
There is a business risk however there is also a clear mitigation plan - to just stop using Radzen and proceed by upgrading/migrating the existing code.
Forgot to address this one. We strive to support the latest Blazor version as it is a lot easier for us to maintain. The problem you are speaking of will not go away if you switch to Blazor though. Again in case of our premature demise you would have to build and run the application with Visual Studio.
Thank you for these answers. I feel like I am going somewhere, finally.
If I get my client to adopt Radzen (2 to 5 enterprise licenses ), can we count on your help to show us how starting with Radzen, we can move to maintaining and growing the applications created without Radzen later on?
I will be trying to generate with Blazor for my next project, as I feel this is probably a better long term solution than Angular. New major versions every 18 months with at lot of third party breakages is getting tiresome. We will just have to test if Blazor provides the same experience or if it is better.
I am not 100% sure what you are asking here. In general we provide support only for Radzen related stuff. Any custom solutions beyond that are considered consulting which we don't have the capacity to provide at this time.
Simple example: I generate an Angular application with Radzen. I have security applied to pages based on the Radzen security model. We decide we want to not use Radzen anymore, and I need to manually add a new page in Radzen, but I need to still apply security to my manually added page, but I can't use the generator anymore. I would then submit a question to your team asking how to do that. I would expect a short response stating what the generator would do so I can do it manually.
Another example: I need to add a field on a generated page, but I can't use the generator anymore, again I would place a request to your team for a quick recipe.
Keep in mind that I have experienced Angular and .net core developers, we just need pointers for where to dig.
Both of those questions can be easily answered by checking the generated files. It is valid Angular code which an experienced Angular developer would easily understand. We may answer simple questions as those particular ones but in general we refrain from supporting custom applications (ones that do not use Radzen or require custom code not generated by Radzen).
Does that mean that if there is an angular component from the @radzen package that needs to be modified for Angular 25, the code is available for us to do so?
I was able to find the code for the Radzen Blazor component library, but I am not sure the code for the Radzen Angular components library is available. This might just be me not knowing enough about Angular.
Does this mean that this is not accurate because of the dependency on the @radzen/angular?
I had just convinced my client to purchase Radzen, and we are about to start the development on 2 projects using Angular. What do you suggest I do? Does this become really true if we switch to Blazor?
My honest opinion is that Radzen is not the right fit for you. We don't plan to provide the complete source code of our IDE which is what most commercial software vendors do.
If you customer already made a purchase do let us know so we can issue a full refund.
I am not interested in the source code for the IDE, I just want to make sure I will always be able the upgrade the generated application to the lasted framework version.
So, to summarize:
If I use Radzen Angular, I might not be able to upgrade the Angular version in the future if I use Radzen to generate the application.
If I use Radzen Blazor, I will always be able to upgrade to the latest version of dotnet core, because we always have access to all the components of the generated code.
Is that accurate?
Sorry to be such a pain about this, but I really want to make the right decision here.