I've been a bit absent from the NR forum for a few months due to life happening... I did spend quite some time working on FlexDash earlier this year. I believe it ticks many of the boxes that people have been putting forth in this thread. It uses Vue and Vuetify and stays pretty close to simple HTML/CSS stuff and overall it's not a lot of code. I intend to come back to it soon 'cause I need more of it... In the meantime, I have a couple of comments on this thread about what I learned
The current dashboard has a fundamental limitation, which is the one-to-one correspondence between a node in NR and a widget on the screen. This is coupled with the "fundamental benefit" in the eyes of many (but not all), that one can drag a node into the NR editor and something appears in the dashboard. In FlexDash one drags a widget into the dashboard and then sends it messages, which has a different set of benefits, such as being able to deal with the layout stuff easily and being able to create arrays of widgets programmatically. I don't know how many people that claim they must have the current model have even experimented with the alternate model... I do believe that it would be possible to add "widget nodes in NR" to a FlexDash type of model, I do not believe the reverse is nearly as easy.
When I built FlexDash I wanted to make it easy for others to try it out and give feedback. As a result on can use FlexDash without even installing one thing in NR. I also did spend quite some time with documentation and getting started help. However, in total, I don't think more than one or two people have tried it. Maybe that's just because it's not attractive. I wonder, however, whether it's possible for any 3rd party dashboard to get any level of attention. I don't know what the solution might be.
WRT to being "tied to a framework" I believe that's actually a great thing. The current dashboard is very tied to NR's editor and there's a ton of custom code to implement basic machinery. That makes it very difficult to get into and contribute and it makes it very difficult to evolve it forward. There's basically zero documentation on how it works, it's "here's a big pile of code, figure it out". I'm not saying that to be negative and I'm sure it was the best way to do things at the time. But when you build on a framework you also inherit documentation, tutorials, and a wealth of distributed know-how on how the beast works overall. Sure, each app adds additional abstractions, but there's at least some initial understanding of how stuff is structured and functions.
Let me be more concrete. Do you imagine building a dashboard or any modern web app that doesn't use a reactive model (as in the way react, vue, svelte are at the core)? I hope not. Do you believe it makes any sense to invest another way to implement reactivity in a javascript web app? I hope not. Doesn't that mean you should use one of these existing frameworks and leverage all the know-how that comes with it?
The next step is that if one uses Vue.js, for example, that doesn't mean one has to use Vuetify or Bootstrap. I do use Vuetify in FlexDash because it saved me a ton of time. I think it could make sense to slowly reimplement stuff from scratch, i.e.plain HTML and CSS, but that has to be thought through carefully. A lot of FlexDash's widgets don't use Vuetify, and that's great, but for those that do I'm really happy I didn't have to spend the time reimplementing tree selectors or multiple-select drop-down lists or figure out weird low-level stuff like how to properly size fonts so it works everywhere.
Let me be more concrete again. Suppose FlexDash didn't use Vuetify. It would still need title bars, panes, menus, drop-down lists, buttons, icons, scrollbars, fonts, text styles, yadda yadda. So wouldn't that mean I'd just be implementing a custom framework? That would have the dubious benefit that no-one else in the world uses it or knows how it works? And that most likely would have only the slimmest documentation? In which world is this really better?
Something I really like about FlexDash is that it's actually developed to be completely independent of NR and can in fact be used without NR (although I haven't spent time developing the pieces one would use for that). What this means is that there is actually a an API that defines the interface between NR and FlexDash. It would not take a whole lot of time to write a React-based version of FlexDash (assuming one knows React, which I don't). It has other benefits, which is that one can develop UI widgets very interactively with a standard Vue IDE set-up without needing to deal with NR nodes. But ultimately it seems to me that this type of decoupling is what would allow new dashboards to evolve over time without having to jettison everything. (I'm not claiming FlexDash has the right API or that I've properly documented it, this area still needs more thought and work.)
Please don't misunderstand me. I'm not trying to say FlexDash is it. I'm talking about it 'cause I learned a lot while developing it. I still have a pile of open questions and unsolved issues and am looking forward to diving back in.
It just currently does what I need, so there were no updates....
) Something is only easy if you know how to do it, or if the product guides you in an intuitive fashion through various steps or processes. The learning curve and time required to acquire the knowledge needed to be able to simply jump in and try whatever is the flavour of the moment is completely underestimated by a lot of people who are in the fortunate position of being able to code.
. My experience is that I add a UI node, then mess with property sheets for it to show up in the right place, then mess with more property sheets for a long time for it to look right and show what I want. The whole thing requiring me to redeploy a hundred times and switch between the NR tab and the dashboard an equal number of times.