This looks very nice. Hope to see it functional in node-red.
I'm not savvy enough to do a full-fledged ui-builder frontend with user authentication, and Dashboard looks nice for just visualization, but not secure enough to develop a multi-user HMI.
EDIT:
My main problem is that I learned how to program back in the early 90s (when GWBasic, Pascal and ANSI C were all the rage) and literally didn't use any of that in a meaningful way for years. The HTML manual I had at home was version 1.3 or so.
That said, about 8 years ago I tried to catch back with HTML 5, learnt a bit of CSS, and also some scripting with LUA and Javascript. I'm comfortable enough to use JS for the function nodes in node-red (data processing and logic programming isn't a problem), I also use a workaround with standard dashboard Text nodes that receive full static HTML strings to display some tables for a fixed amount of information.
I don't know if I could help in any way to port some of the existing Dashboard nodes to Flexdesk, but I'd be willing to try and learn how to. After all, I'd use some of these for my work, so I may just as well spend some time in developing it.
I'm hoping to do a tutorial on using NGINX with Node-RED and uibuilder to provide the security and user authentication for front-end applications. Should go at least some way to resolving these issues.
I've had to google what NGINX was because I had no idea.
The problem I have is that most of my programming learning was done in text-only UNIX terminals before object-oriented programming was even a thing.
Since then I've learned a bit about methods and objects (for HTML 5, Javascript, and Lua), but I have no idea how new programming frameworks are supposed to work. I used to put text files in a folder and compile with gcc back in the day... the most advanced compiler I used was Borland C (and an early version, to boot!).
I did learn a bit of Java in the early 2000s, but the guy who was supposed to teach me did it so badly that to this day, I still have PTSD and never even think about using it.
Not a problem of course. I mention writing a tutorial for this very reason. To help people implement things simply for simple tasks. That's why I wanted to include security within uibuilder itself but it has been a constant thorn in my side because it is HARD to do right and I certainly don't want people to have a false sense of security when using uibuilder. I know that some people are using uibuilder for professional services and the security for that HAS to be right. Others are just using it to get a nice-looking home automation UI that is wife and family friendly - so there are a lot of extremes and everything in-between. That's why I've taken the difficult decision to pull the feature from uibuilder v5 that is about to be launched. There are other things to focus on and better tools for doing web app security - but I need to create some help for people who need something simple and reasonably secure but don't have the experience themselves.
I originally learned to programme on an IBM mainframe well before personal computers were common (and PC's hadn't yet even been invented!). So I've at least played with most common languages and a few that are far from common I've used professionally as well (such as IBM's APL). But I managed to pick up a few web skills along the years. Still wouldn't class myself as an expert though and it has been a long time (a good couple of decades - actually maybe nearer 3 now!) since I was a professional programmer.
It was learning Python where I finally understood what classes, objects and object-based programming was actually all about.
Haha, I wouldn't blame them too much. Java is an absolute nightmare. I've had various run-ins with it over the years including some battle-royal's with IBM folk when working as a consultant for various customers. Personally, I wouldn't touch it with a barge-pole. It is expensive to develop and even more so to maintain. And it never really did live up to its claim to be a "write-once, run-anywhere" language. Instead it rapidly got the reputation of being a "write-once, test-everywhere" language. And don't even get me started about the licensing issues!
Multi-user has been discussed a lot here, dunno whether you've read some of the threads, but it's not something NodeRed really supports. If all you want is to have per-user permissions on what they can do, for example some may not be allowed to change the heater controls or to see certain data, then that should be in the cards. Beyond that, ...
Can we try to stay on topic? This thread is meant to be about the future of the Dashboard. It is already quite long and having off-topic discussions doesn't help matters.
The main appeal of the current Dashboard is being able to prototype a frontend interface quickly, but it lacks security, multi user support, and it lacks modularity/grouping (you can't create a subflow with widgets that you can use several times to represent different instances of a device).
UI Builder is better at that, but it requires much more coding, and is a little bit out of the low-code approach that node-red is great at.
So if I understood correctly, the two main options being pondered would be to either some kind of low-code editor for UIBuilder that would allow for simpler deployment without so much coding, or create a new dashboard from scratch?
There's also Flexdash and other alternatives being mentioned.
The key point here is to optimize resources, in my opinion. What would require less effort to be deployment-ready?
I assume that starting from scratch with a new Dashboard (that might also have to be retrocompatible, but not necessarily) would need way more resources than expanding UI Builder (which would need to be retrocompatible, unless you fork it).
As I said, if I can, I'd like to invest some time and effort in it, considering I'm using it regularly and putting some work into it would be a way of giving back. Hopefully I'll also learn a bit along the way.
Hey, help with FlexDash is always appreciated . I'm currently discussing with @BartButenaers how to integrate more deeply into NR, specifically, how to make the flow editor side look very much like it looks now. We're currently exchanging private chats, but if Bart is OK with it, we could copy that into a public thread. I could really use help on the NR side 'cause I hate developing in there (sorry). I have the front-end pretty much under control (although there are areas that are not my strength). I have another project I need to drag over the finish line this week, but after that I hope I can get a very first POC hacked up in a day or two... Famous last words...
NB: when you write
I assume that starting from scratch with a new Dashboard (that might also have to be retrocompatible, but not necessarily) would need way more resources than expanding UI Builder
FlexDash is a start from scratch, trying to leverage Vue and Vuetify as much as I could. It does not use UIBuilder 'cause it's a poor fit. I'd like to get to the point where FlexDash offers the same functionality that the current dashboard does and the deeper integration into NR is the last big piece. The thing FD will not do is support the ui_template node. There can be an equivalent where you write a Vue component that gets loaded dynamically, but there is just no support for angular. I believe that just about any new dashboard will have the same limitation.
I have created a new discussion. @OriolFM: in that discussion I have tried to give Thorsten an introduction in how I think that the current UI nodes work in the AngularJs dashboard. That way I hope that Thorsten can get ideas about how to implement an alternative for contrib ui nodes in his FlexDash. If you have time to help him somehow with this, that would be very kind of you!
The discussion is currently focussed on the current UI nodes, but I hope that others join to discuss with Thorsten to help him with ideas to build a decent alternative.
Bart
No decision has been made, but the existing dashboard still works fine, and is still maintained.
You are also able to try the alternative dashboards mentioned above.
I wondered if someone could write-up a "digest" post plus any new info to include;
a brief state of play, as this thread has been quiet for a year. For example, has anyone further considered a roadmap to replacing the native Dashboard? Will it remain indefinitely? Does the fact that Angular v1 goes EOL still pose a concern for the future of Node-RED dashboard in its current state?
what are Node-RED developers' current thoughts on the original post
list of other dashboard systems available for Node-RED, including objective comparisons / level of maturity / how easy it is to get up and running / how actively they are developed / what frameworks they use etc. Overly simplified would be great. Also great would be brief description and links to relevant forum posts for further reading. ā
an honest take from the main Node-RED developers: do any of the alternative dashboard systems have what it takes to become the new "native" dashboard in a future release of Node-RED? What's the best strategy: adapt one of these alternatives, tweak or update existing native Dashboard, or start from scratch?
I concur with this post above back in Feb22 by @OriolFM; it certainly captured my thoughts. And I feel the comment "being able to prototype a frontend interface quickly" is really in keeping with the origin of Node-RED.
As noted by @knolleary there were rather a few off-topic posts and it's very long for to wade through
ā If you go searching, you can find lots of dashboard contribs as well as the main ones I know about like UIBuilder etc. eg. dashbored, mdashboard, not to mention collections of additional nodes for Node-RED dashboard so this could be a useful reference post for anyone looking into choosing a dashboard.
I can only comment on uibuilder really but here is the state of play and my desired forward view for it.
Where we are
It continues to be in active development. It has been in ongoing development for nearly a decade.
It has a published and maintained roadmap.
It has comprehensive set of documentation which is available both from GitHub and Node-RED.
It uses standard HTML, CSS and JavaScript and is not reliant on frameworks. However, it can work along side frameworks when desired.
It reduces code/logic creation by providing supporting features and functions such as automatic creation of dedicated communications channels and easy installation of front-end libraries.
It has a "new" helper library that uses modern JavaScript and removes legacy VueJS framework functions. It has an ESM version as well as IIFE/UMD so that it is compatible with future JavaScript approaches.
All of the templates and examples are about to be updated to use the new library and current standards.
It has a low-code, configuration-driven UI building capability built in. This allows data-driven interfaces to be easily created with minimal code. What code is needed is in standard templates. The same capabilities can be used in your own custom front-end code if desired but code is not necessary.
It is developing a zero-code, config-driven set of nodes. An experimental node was shared in the last release, the next release will get a consolidated node that allows creation of several different UI elements from simple data inputs. A specific update node will also be released in the next release making it easy to update on-page elements regardless of whether that element was manually or dynamically created.
It has comprehensive data and UI caching capabilities. Further new caching capabilities are about to be added that will allow caching at the front-end and/or back-end (Node-RED).
What isn't yet done
We need a layout tool to make it easier to visually create grid/flexbox layouts without the need for code. There are a couple of 3rd-party libraries that could potentially provide this but I don't currently have time to work through this until other development is completed. This is, however, critical to put uibuilder on the same par as Dashboard.
Most likely, this will be slightly different to Dashboard in that it would allow creation of the structure but would not require a load of nodes to define the layout. The layout page would most likely create the majority of the structural framework components. Then uib-update nodes would be all that is needed in order to send data or update configuration based on the element ID's created by the layout.
The layout itself would be sent once to a new client connection and might possibly be cached in the client with only updates to the layout then being resent on change.
We need to extend the no-code element creation node to be able to create more elements.
I would like to create a set of native HTML components to match the no-code element types so that we have the option to dynamically create the elements from the front-end more efficiently. Since these would be pure HTML, they could easily be extended by other people without having to learn a specific framework.
uibuilder remains focussed on not being tied to a single front-end framework - but it still works with them. This approach has been reinforced recently by complexities in frameworks and ongoing changes to frameworks that results in extensive rework and re-learning being required. In addition, HTML/CSS/JS has moved on massively and what can be done natively is now so much more.
I am working on my own dashboard - it is not public/shared.
It takes a different approach than the other available solutions - it is a single subflow node (http endpoint and websocket), in/output goes via that node and context. The complete setup/layout is done from the client (ie. browser) or payload and updates to/from via topics.
It is aimed towards home automation controls/states/values and not necessarily a whole suite of charts and things (there are better tools available for that purpose imho like grafana), fairly simplistic and nothing complex. And most importantly, it needs to look good and read well (ie. no icons, but good font/colors/paddings/margins) on all screensizes. This is where i spend most time. I am using Tailwind JIT and Alpinejs for reactivity.
It slows me down to add specific nodes to a flow that expect specific data and perform the layout inside the node-red editor, which requires several clicks/deploy just to find out I have to redo it again.
I want to be able to inject an object that adds a new item to the dashboard (this way I can inject/create complete pages with some array/objects).
Not a problem of course. I mention writing a tutorial for this very reason. To help people implement things simply for simple tasks. That's why I wanted to include security within uibuilder itself but it has been a constant thorn in my side because it is HARD to do right and I certainly don't want people to have a false sense of security when using uibuilder. I know that some people are using uibuilder for professional services and the security for that HAS to be right. Others are just using it to get a nice-looking home automation UI that is wife and family friendly - so there are a lot of extremes and everything in-between. That's why I've taken the difficult decision to pull the feature from uibuilder v5 that is about to be launched. There are other things to focus on and better tools for doing web app security - but I need to create some help for people who need something simple and reasonably secure but don't have the experience themselves.
. I'm currently discussing with 