I am just reading that there multiple dashboarding solutions in Nodered: dashboard, uibuilder, flexdash (maybe more).
dashboard ( as node-red-dashboard) seems the most used one but it also says that it si on "life support" (as being an angular v1 solution).
What do you advise me to use?
I'd like to visualize some external data, which I'll retrieve from Azure AppInsights, theoretically.
Nothing fancy, but I need a stable, not that complicated to use and long-term solution.
Although the current dashboard may be somewhat outdated, it still functions properly and is not going anywhere soon - a new version is in the works and fingers crossed, it will be a drop in replacement for the old one.
1 Like
The most important thing is to isolate the dashboard from the process logic. My solution for this is to use MQTT as an interface between the two. Anything that has to be displayed goes to MQTT and any operator input goes from the dashboard to the rest of the logic via MQTT. The result is that the UI can be modified with minimum impact on the test of the system.
4 Likes
I completely agree on this. I use this approach with uibuilder too.
Dashboard has been around the longest. It is great at letting people with no knowledge of building web apps get going quickly. It, like Node-RED itself, is a no-/low-code solution. However, it forces you into its own framework and, should your UI eventually start to get more complex, you may well find yourself fighting the framework instead of it helping you. In addition, as you say, it is eventually a bit of a dead-end in that it uses AngularJS v1 which is not being developed and hasn't been for a while now.
Dashboard v2 is meant to be its successor but that is still in alpha at present. Not clear yet (to me anyway) whether/how-easy it will be to migrate from a v1 to a v2 Dashboard.
UIBUILDER has been around since 2017 and slowly continues to develop. It started from a very different viewpoint. That being that it would create the skeleton and building blocks for UI creation but would do its best to give you the greatest flexibility and least lock-in. If you are needing no-/low-code UI creation then UIBUILDER does much less handholding than Dashboard but it is getting more and more no-code capabilities. It remains popular and widely used (if the npm stats are to be believed).
I may be wrong, but I'm not sure that any of the other options are under active development.
So you need to decide which style of approach is going to be best for you. What is the eventual aim of your UI? Will you need a multi-page design (Dashboard v1 is a single page design only). How complex will your needs eventually be? Do you need to work with a specific front-end framework or need to work with actual web developers? Answers to these questions will steer your choice.
2 Likes
Just to chime in, I'm the lead dev on the Dashboard 2.0 project so thought I'd provide a bit more info on what I'm up to, and how I see the other options.
As @TotallyInformation mentioned, it will depend a little on what you're trying to achieve, but the high-level summary:
- Dashboard 1.0: Feature-rich, lots of out-of-the-box widgets, mostly drag and drop, but a little customisation should you need it, generally constrained to the grid/card layout, but as you've stated is on life support due to Angular 1.0 dependencies.
- UI Builder: (link) Steeper learning curve as generally requires more HTML/JS knowledge, but way more customisation and flexibility.
- FlexDash: (link) Is a bit of a middle ground between UI Builder and Dashboard, and focusses on the visualisation of IoT data via MQTT topic subscriptions. It's not quite as easy as drag and drop for setup, but once running can be quite powerful.
Now, for Dashboard 2.0. We are quickly catching up to support everything that Dashboard 1.0 did, and then some (e.g. Markdown support, Mermaid Charts, Notebook Layouts), with a Roadmap of plans exceeding beyond what Dashboard 1.0 was capable of. Some useful resources:
- Dashboard 2.0 Widgets List - Showcases all of the fully released nodes that are available now.
- Dashboard 2.0 Roadmap - Gives you an idea of what I'm working on right now, what I have planned next, and issues opened by community (more are very welcome if you have new ideas and feature requests) that we plan on getting to asap.
As @TotallyInformation points out, we are still "officially" in Alpha, but won't be for much longer, and are already using Dashboard 2.0 internally at FlowFuse for all of our own projects. I will also be writing a Dashboard 1.0 to Dashboard 2.0 Migration Guide next week, which will also clear that piece up too.
Both Dashboard 1.0 and Dashboard 2.0 allow for mutiple pages, but all contained within a single "UI", so you can navigate between these in a side panel.
Also have a few articles about the latest work we've done in Dashboard 2.0 too if you'd like to take a look:
- Dynamic Markdown, Tables & Notebooks with Dashboard 2.0
- Custom Widgets with Templates in Dashboard 2.0
- Charting REST API Data in a Dashboard
Happy to answer any more questions, and advise accordingly. Hope that helps.
Edit: Just noticed that your main requirement was to retrive data and then visualise, we do support hat, but it requires (as with all existing Dashbaord solutions) some data manipulaton. upfront.
I'm actively working on Expose ChartJS "parsing" option to define nested data values for x and y axes · Issue #230 · FlowFuse/node-red-dashboard · GitHub at the moment though, which will expose an option in Node-RED for our ui-chart node, meaning you shouldn't need to do any data manipulation upfront, you can just give the ui-chart node your data, and it'll work its magic. Hope to have that out in the next week or two.
5 Likes
Ah, the joys of being paid to work on Node-RED for a living. 
I haven't really mentioned the future for UIBUILDER. But safe to say that it will continue to be in active development. It is already used by a lot of people in different environments. There is a roadmap that contains all of the thoughts about the future. Check out the v6.6 roadmap for the very latest. In summary:
- More no-code elements - including container layouts (grid/flex/etc). Also ongoing improvements to existing elements, especially forms.
- Helper functions for both Node-RED and client to produce lists of pages - for menus as mentioned by Joe.
- Buttons in the Editor that reference any npm scripts defined - to make it easy to run build steps or other CI steps from within Node-RED.
- More visible indicator on the uibuilder node to show if any installed front-end libraries need updating.
- Extended template handling to make installation of dependencies easier.
- Add a "dev server" style capability to make front-end development easier when editing code outside the Node-RED Editor.
- Ongoing code simplifications and structural improvements - to reduce dependencies and further improve the openness of the code for other developers
- Publish the low-code JSON UI building functions as a separate library so that other projects can use it.
- Templates for easily creating a PWA offline-capable client from your UIBUILDER app.
- Better optional logging of client logs back to Node-RED.
Well hopefully that gives you some idea about the direction of things anyway.
I'm also committed to creating examples both written and video that show how to do things with UIBUILDER. There are already quite a few that show how to use build steps, create tables, charts, etc.
BTW, Markdown is already a feature - you simply add the Markdown-IT library to your html file. Simple tables are already no-code elements as are lists (including nested lists). And not forgetting that you can use a separate ExpressJS web server instance if you need/want to so you can have different settings. And UIBUILDER has a bunch of middleware and local API capabilities built in.
And if you are looking for an example of a hybrid low-code web app using Node-RED and UIBUILDER, you may want to have a look at:
2 Likes
Hey, thanks for mentioning FlexDash. To be realistic: it's completely futile to be developing/maintaining a dashboard when there is an official new dashboard. I am using FlexDash myself and I will be adding more features to support more advanced use-cases but I'm also most likely going to remove most of the deep Node-RED integration because that's a major time sink and source of limitations.
4 Likes
That's a shame. Your flexdash work was very promising and did some great stuff. I think it renewed interest in this area. As well as that, it prompted you to highlight gaps and shortcomings in node-red (always a good thing to understand limitations).
I am sure others will be sad to hear this too.
5 Likes
Thanks for the kind words, but the reality is that it was already difficult to get any traction before dashboardV2 and my assessment is that now it's going to be completely impossible for any other dashboard to gain any traction no matter how good it is.
1 Like
In that sad case, is there any possibility that Flexdash's array widget feature can be implemented in Dashboard 2?
@jbudd I also found that a great feature, and used it extensively. 
@jbudd & @Paul-Reed thanks for you guys' support through the various FlexDash stages!
I'm also using the array stuff. I haven't looked at dashV2 so I have no idea what flexibility there is nor whether the design is extensible, whether the pages/tabs are hierarchical and good stuff like that. Given how it was introduced, using Vue like FlexDash, using Vuetify like FlexDash but without any reference to FD or any communication about the motivation/goals (that I saw) I'm not exactly positively inclined towards it...
1 Like
Hi Thorsten, I am sorry to hear that you feel this way, but please know that my motivation for choosing Vue was taken entirely independently from FlexDash.
I was tasked with building the next generation of node-red-dashboard, and as someone with 6 years of VueJS experience, it was an obvious choice to me. Both FlexDash and UIBuilder use VueJS, it is, in my opinion, an obvious successor to Angular, over React, because of how readable, similar to Angular and how shallow the learning curve is for non-Front End developers, and non-developers alike.
Vuetify was then used because its the most popular, diverse and best looking Vue component library on the market, and no other reason.
As for this request, I wasn't familiar with the feature, but we are always open to new ideas and feature requests (and Pull Requests if you're that way inclined!). Please do raise an issue over on our repo and we can work out how to facilitate it.
Our main driving Motivation for Dashboard 2.0 is entirely scoped to replacing Dashboard 1.0 with an equivalent that uses a modern, supported tech stack as has been written in the "Motivation" section of our GH Readme from the day it was published.
1 Like
Hmm. Surely the designers and developers didn't set out to make a new dashboard without looking at the features offered by other developers' offerings and reaching out to those developers specifically and the community in general for ideas?
In general there seems to be a very close and open relationship between the Node-red professionals and us (grateful) consumers of the product. It's one of Node-red's charms.
I think that's a pity. It's usually easier to add in new features if they were at least considered at the design phase.
@joepavitt, there was a discussion back in September 2021 asking about ideas for new dashboard, I posted and noted that the addition of adding widgets using arrays would be a great leap forward
That would be me (and some help from @Steve-Mcl and regular check ins and guidance with @dceejay), I wish we had a team of Designers and Developers on this, but alas its mostly me for about 3 days a week.
It is my understanding that this did take place (although not with me directly)
We have always been very open in our posts and updates for Feature Requests and issues, and there are active threads in this forum for exactly that (e.g. Dashboard 2.0 Pre-Alpha Available)
Dashboard 2.0 is completely open source, whilst FlowFuse are funding the developement of it through me, direct PRs, ideas, etc. are all welcome.
Apologies, poorly phrased on my part. I have architectured Dashboard 2.0 to be very flexible in this regard. Our first target/motivation is migrating features from the existing Dashboard 1.0, but also prociding flexibility (and already implementing some, e.g
Dynamic Markdown, Flow Viewer and Notebook Layout) for future feature growth, which Dashboard 1.0 was unable to support.
Thank you so much for sharing this. I hadn't been made aware of that post. I will read through it when I am back at my desk on Tuesday and take out any points and raise them into the Dashboard 2.0 issues, and plan accordingly.
1 Like
Just to be totally clear though. That used to be the case. However, UIBUILDER is entirely agnostic to any front-end frameworks. Use them if you want but if you don't, it works equally well with vanilla HTML/CSS/JS. Indeed, that is now my recommended approach for most things as it tends to be a fair bit more future proof.
Of course, very complex requirements or the need to fit in with existing web development workflows and tooling may introduce a need to use a framework and if so, UIBUILDER will still support you.
I want to be totally clear here. I did have a conversation with Steve about the potential adoption of UIBUILDER for a core Node-RED Dashboard solution. The main sticking point seemed to mainly be the fact that FlowFuse (and perhaps one or two other cloud environments) does not provide full access to a filing system and UIBUILDER currently relies on that. While it would certainly be possible to move all of the filing system handling for UIBUILDER to a middleware layer and so accommodate this approach, it would be a lot of work and not something I have the personal time for unfortunately.
The other aspect was that UIBUILDER started off leaning towards a bottom-up approach as opposed to the top-down approach taken by Dashboard (there was no point in reproducing a Dashboard style when I first started working on it). Actually, this gap is now closing rapidly and some additional developer support would have seen that pretty easily closed I think. We already have no-code features which can be accommodated in a common node which is the approach I've mostly been using, or in individual nodes which is the approach that seems to be preferred by Dashboard (there is already an example node in that style).
To be clear, I believe strongly that having multiple solutions to this complex problem (of creating complex, data-driven web apps) in Node-RED is a great thing. Thorsten's rapid and interesting work certainly prompted me to renew my focus on various aspects of UIBUILDER and helped me rework some of the documentation to make things much clearer as well as spurring me on to work more on the no-code and low-code features. Similarly, the work that Joe is doing on Dashboard 2 is an inspiration in some areas. And, of course, the input from various people in the forum is also always helpful and welcome; whether reporting issues, suggestions, clarity in the documentation or fabulous new brand ideas & occasionally even pull requests (could do with more of those!).
Each of the solutions brings slightly or significantly different approaches to the issues we all face and one of the reasons we want to use Node-RED. Each is supported by 1 or at best a small team of people and so, over longer time periods, might fall into stagnation. So in many ways, having multiple solutions is good for the community.
I've no intention of slowing down the development of UIBUILDER but I am aware that one of the things I need to continue to work on is to ensure that it could be handed over to someone should I no longer be able to work on it. One of the big issues in my opinion regarding the original Dashboard was that its code was incredibly obscure - written by someone with a vastly bigger brain than mine. Dave has done a great job of persevering with it when it was handed over to the community. But I would be immensely disappointed with myself if I produced something like that. And in any case, I don't have the brainpower to remember all of the various parts I've written so development would inevitably slow down massively.
Oh, and one final word (sorry about the length of this post!) - about adding arrays of elements to the page. While it would take a bit more flow, it is certainly easily done with UIBUILDER. Or if you prefer, you could easily do it in the front-end - indeed, it seems like my go-to approach for quickly building new UI's right now is a hybrid approach doing some things in Node-RED and others with the low-code features in the front-end. UIBUILDER lets you do things either way of course.
1 Like
Thanks for that besutiful summary Julian. My misunderstanding on UIBuilder's more recent use of VueJS
I'm also in total agreement with you regarding multiple Dashboard solutions, hence my summary above where I point out the reasons for consideration when choosing each of the (very valid) options.
@joepavitt I for one think that you are doing a great job with developing Dashboard 2, and look forward for it's future development.
4 Likes
