Here are some of the things I am taking into consideration.
- Blazor and JS have their own ecosystems with pros and cons, as outlined above.
- Using Blazor makes sense for .NET developers.
- Using [insert JS framework of choice] makes sense for JS developers (and, admittedly, for many .NET developers, too).
- Although Blazor may not have a small footprint like JS libraries do, it's not necessarily a problem to have to download a minified framework the first time. After all, the dashboard isn't typically used to handle high traffic situations. Ease of customisation, extensibility, in other words, productivity, may be more important here.
- There are many users out there that integrate the designer into their own React/Angular/Vue etc, dashboards, and I do not want to forget about that group.
- Some of them chose to build the designer themselves, others rely on the Stencil implementation (which provides a framework-agnostic reusable web component).
- It is important to realise why some teams decided to build their own designer. From what I gathered, and from what I imagine, the main reasons are that the designer is not very easy to customise and to extend, plus it uses its own look and feel that may not fit in a given dashboard.
Considering the above, it seems to me that there are 2 main groups of developers:
- Developers that prefer to use an existing dashboard framework that they can customise and extend.
- Developers who have their own UI into which they need to integrate workflow management features.
For the first group, we can divide them into two subgroups:
a) Developers who prefer to extend the dashboard using Blazor.
b) Developers who prefer to extend the dashboard using JS.
For group no. 2, the dashboard application is useless. All they are interested in is to have a designer that they can embed in a page and interact with programatically.
A big challenge with this standalone designer is to make it customisable, extensible and theme-able without the use of a framework and design system. Even more so when you consider that Elsa comes with increasingly more modules that one might want to take advantage of. Just to name a few:
- Webhooks
- User & Roles
- Email (templates, mailing lists, etc)
- Secrets
- Forms
- Scripts
The above is easily implemented using component libraries, which may or may not support theming.
This is the main reason I want to do a dashboard application, and Blazor seems a fine choice to me. That being said, don't be surprised if I eventually start an Ionic dashboard implementation on the side ;)
Just to try and clarify certain points that were made by others:
Re the rewrite of the designer in Blazor, I wonder if this is really a good idea?
It depends on whom you ask. My initial idea was to wrap it in a custom element so that it doesn't matter what your application UI stack is. However, in order to make it extensible and customisable, being able to use an existing component library boosts productivity not just for me, but for anyone trying to customise and extend. So now I'm wondering the usefulness of a Blazor implementation of the designer outside the context of a Blazor dashboard. Instead, I think there are two main use cases (the two main groups of developers I mentioned earlier).
While Blazor has a decent developer experience, it has very poor performance and extremely large bundle sizes. It's generally recognised that Blazor is a poor choice for anything other than internal/LOB applications.
My personal experience with Blazor so far, is that it offers a great developer experience. Even without having figured out how to do hot reload from Jetbrains Rider. I just love the component model, the way binding works, and, best of all, using proper C#. As for the extremely large bundle sizes, you'd have to define "extreme". A couple of MBs seems not an issue for the average backend system (which, after all, is where most, if not all, workflow designers will end up anyway).
Wouldn't it be preferable from an end-user perspective to have a relatively lightweight web component that can easily be embedded in another application (e.g. created using React/Vue/Solid/Svelte/Lit etc.)?
Yes, absolutely. And I have tried to do this. But I don't think it's enough; I want the designer to be extensible and themeable, and have a solid component framework to build upon. It's possible to do, it currently has a concept of plugins, but for many users I have spoken with, it's a real barrier. And at the same time, there are many existing component libraries that can be reused. So maybe it's best to keep the Stencil component as-is for embedding, and not have it implement other modules, like the ones I listed. Instead, developers would implement those features themselves, and other developers who don't have their own dashboard, can chose to leverage the Blazor dashboard (and possibly in the future, a JS-implementation of the dashboard).
The fundamental motivation for choosing Blazor is to REMOVE incompatibility between the backend .NETCore and the existing frontend designer not based on .NETCore.
Actually, my motivation is a little bit different than that. My main motivation to use Blazor is because it enables me to use C#, .NET and Razor components, which in turn means I get to use component libraries such as MudBlazor, which boosts productivity like crazy. It also means that the dashboard can be made extensible and customisable extremely elegantly, which makes it easy for .NET developers to do.
By harmonizing .NETCore between backend and frontend designer, this opens NEW Innovation not possible before that keeps Backend separated from the frontend developers
@GeorgeS2019 I guess my previous statement puts a stain on this vision. Perhaps you can elaborate a bit on these opportunities? For example, are you talking about shared use of model classes, and/or making the backend and front end environments appear as "one" to the developer?
Let there be no confusion: The Elsa backend is equally intended to be consumable by whatever front-end, be it Blazor, JS applications, Postman automation, etc. At no point will the Elsa backend become tightly coupled with any kind of front end (and if that does happen, it's a mistake).
For a diagram designer I'd expect lots of drag&drop interaction and that translates to a massive event stream crossing the JS-WASM boundary
Actually, the Blazor dashboard implementation relies on the X6 diagramming library, which means that all drag & drop operations happen in JS-space. Except for dragging a new activity from the toolbox onto the designer - that toolbox is done in Blazor. But that's fine in terms of perf.
If the Diagram designer is in blazor, there will be more users here who are Elsa backend developers will engage more regularly and directly with the diagram designer when it is Blazor using c# or c#-JS interop
To be clear, the current diagram design surface is still provided via the X6 library. But, everything around it (activity picker, activity property panel) and even the activities being rendered themselves, are proper Blazor components.
In addition, when using the Blazor dashboard framework, it now becomes that much easier to replace it with a (custom) implementation if you want to, like Azure Design Studio and Blazor Diagrams.
Thanks everyone for sharing your insights!