Sorry blazor is not a JS framework, this is a pretty common misconception as it uses JS for the SignalR comms (depending on WASM vs Server it works a little differently). It also doesn’t have to be one-only either, but can run as hybrid (run the component server-side until the component download is complete then run as local WASM).
To paraphrase the head of web at MS: Blazor is what will will be driving the backbone of all web for the forseeable future. (also fluent ui is now being used for all MS UI)
I would also argue that JS is still a scripting language due simply to the way it runs within the browser and is never compiled nor capable of running separate to that environment, doesn’t matter how advanced or capable it is, it can be modified dynamically within browser that is running it. I’m not saying JS is bad, it just requires different considerations.
But I used blazor as an example as you can use dependency injection directly in components themselves (cutting out a lot of duplicated effort). But as an alternative you could also use pure WASM, html/css/js etc. forcing typescript and lit means 2 sets of parsing/compilation as well as dictating js frameworks, or use angularjs if you want. my original point was that this is starting to feel like around umbraco 6 where there was a lot of legacy from scripting and things you had to do to get any extension working.
Previously I used to implement the IDashboard class within C# to create and register a new dashboard within the code itself, all the views names, icons etc were produced from here It kept duplication to a minimum. I vaguely remember having to have the language files obviously and maybe a manifest but that was it, I’m not . Then 90% of the rest of it was grabbing the umbraco css and just using the correct css3 & html5 to create the dashboard.
I would occasionally use pure JS to provide animations, dynamic endpoint hits etc. but that was it. Didn’t have to use angular at all in most cases although I did use it in limited amounts.
A prior website I have been on the backend on has integrations for runs on-server backoffice UI and is downloading ~20k records 4 times a day with updates to publicly accessible nodes in Umbraco as well as a dashboard list of the downloads that allows editing. This works quite well running on the server and is only on a (what was known as an ) S2 instance on Azure.
Again, I am not saying x needs to be used specifically, but we once again are locked into older js frameworks in typescript and lit and from what I can see in the docs, the route to doing things through dotnet has been blocked. This is the issue I have. Now I am hoping I am wrong, but the quick look around I did last night did not disabuse the notion.
I do appreciate it has been provided for free, I have also previously contributed to the docs as well as answering forum questions and submitting solutions to bugs on the bug report area in git.
I have my own fork which I am testing some stuff out in (abstracting the DB to an interface for NoSql). But the arguments I made back when the idea of moving to EF was first floated are still relevant, the arguments I made back when they talked about updating to use only a particular flavour of JS framework are still relevant. Why not allow all of them and have your c# backend point to what files to use for any dashboard or view and let the devs decide like we do for the frontend views? Then Umbraco can use lit & typescript to generate their backend view & functions and someone else can use blazor, and a 3rd person could use Angular2. Or even AngularJS.
The issue is not what has been chosen, the issue I have is the reliance and locking in of particular frameworks, (TS has been dropped by both svelte, turbo and several other large projects, due to code quality issues and the dupe compile) and that is where the issues started with early versions of Umbraco, I never had an issue with AngularJS because I had the choice to use it and get the built-in Umbraco benefits or ignore it and do my own thing.
Like I said above, I love Umbraco, it’s user interface is excellent for the end-users, the security is generally pretty good and extending used to be an easily doable task. When NPoco was introduced I was cheering, a light-weight ORM that did everything that the schema of Umbraco required.
The original question has been answered @sebastiaan, the followup question was is there a way of declaring a section with a dashboard and setup the path to it’s view like in Umbraco 7-> 12 in code alone? The documents do not mention how to do it.
I may just have to go through the codebase again to see what is grabbing the dashboards and where to see if they are registered in an interface implementation. If I do find I way I’ll update the help docs and submit for review.
)
).