ABP natively supports 3 UI frameworks: MVC / Razor Pages, Angular and Blazor. When we create a new module, we create the UI layer for these 3 UI types separately. This increases our work significantly and decreases our motivation to create new modules (also remember the maintenance cost for all these UI layers).

As a solution, we are considering if we can reuse UI layer of one technology inside another one. For example, can we reuse the MVC UI inside Blazor and Angular applications? If we can do it, and if it makes users feel native, we can have an important advantage.

Benefits of this approach:

• Create the UI layer only once in a UI framework and reuse it in other frameworks. This will decrease the UI layer building and maintenance costs for the ABP Team.
• We think that this will increase contribution by the community since it is hard for most people to build 3 UIs for every module (maybe they are only experts in one of them).
• In that way, we can ship new modules more quickly (without waiting to complete all UI options) and complete other native UI implementations later (typically if this new module is liked and used by the people)
• It can open the road to build new UI Framework integrations for ABP Framework, like React or Vue. Introducing a new UI integration has three parts: Framework level integration (like authentication, permissions, localization, settings, ...), UI theme integration and module UI implementations. The last one takes so much time, and if we add more modules in the future, it will be harder to introduce a new UI Framework integration. In this way, at least the existing modules will be usable.

There are a few drawbacks to this approach, of course;

1. Whatever we do, a hybrid used module may not make us feel completely native.
2. When a developer wants to customize the UI layer of a module, they may need to deal with two or more technologies.

For the 1st problem;

• We will do our best to make it as close to native as possible.
• Most of ABP's modules (identity management, language management, tenant management, etc) are already admin-side modules. They are typically not used by end users. For these kind of modules, it is more acceptable to have minor UX differences from the main application. You know, some companies even using external systems for these kind of requirements (like Keycloak or Azure AD). In that case, these external systems' UX is totally different and not integrated into the main application.

For the 2nd problem, to be honest, nothing to do. However, this is a natural result, and I think it is acceptable. Because the alternative way is not to have a UI for these modules and rebuild it from scratch for your application if you want to use that module.

So, we will work on such an hybrid UI system to allow developers to use UI of a module in case of that module has no native UI package for the technology they are working with.