Hi Everyone, this has been on the horizon for a little while, so is unlikely to be a surprise for many, but the original Node-RED Dashboard is now to be considered "deprecated". We will formally mark the module as "deprecated" on npm in six months time, but as of now, there will be no more development activity on this project.
Node-RED Dashboard is based on Angular v1 - that has not been maintained for a long time, and this has lead us to having Dashboard in "maintenance" for some time too.
You can still install and use the “old” Dashboard and your Dashboards will still be functional, but we strongly advise seeking alternative solutions moving forward.
When asking questions in the forum about dashboards, please remember to be clear which dashboard you are using. Moving forward, we will encourage users to migrate to one of the alternative options.
Alternatives
As of writing this article there exist two major alternatives for building out dashboards in Node-RED:
Node-RED Dashboard 2.0 - Built on VueJS, it is heavily modelled on the original Node-RED Dashboard and carries the vast majority of the same features and appearances, even extending functionality and available widgets too. Maintained by the FlowFuse team.
UIBUILDER - A tool to allow Node-RED to deliver data-driven web UI's. Focusing on flexibility and extension of HTML standards rather than the use of a single framework. Use HTML standards and/or with any (or no) UI framework you like to create highly customised and optimised dashboards and other web apps. For further details see the UIBUILDER online documentation.
Both are actively being developed and provide a stable base for the future
If you are looking to try out Dashboard 2.0, it's worth noting that there is a "Crash Course" workshop being run by FlowFuse (the primary developers of the project) next Tuesday - you can find out more details here.
The original Dashboard has served us well over the past (how many?) years, and has inspired many users to create something unique and special with Node-RED.
Thank you @dceejay for all of the time and energy that you have commited over the years, making it a success.
As noted, it’s not so much goodbye. More being parked on the shelf to gather dust, but be looked at now and again and think “ah - those were the days “ ….
And will probably rear its head in 10 years time when someone discovers it still in use in some now utterly critical system originally implemented by a summer intern and now running a multi-billion dollar global corporation!
As you say, this did not come as a surprise, but I'm still sad to see it I invested a lot of time learning the intricacies of the framework and building my complex dashboards - even contributing a few bits & pieces - and frankly cannot see what was missing from Dashboard v1. It really comes down to one single issue, doesn't it: the deprecation of the JS framework upon which it was built. I think there's a very important lesson here, for developers in general and web-developers in particular: stick to the standard APIs as far as possible and don't depend on libraries that you have no control over.
Personally, I can't be bothered to start over again, which is why I've been absent a few years. I just don't see the point in chasing a target that can never be reached. Dashboard v2 currently lacks the maturity and refinement we had with v1 and also suffers from potential dependency issues. UI-builder seems a better option but would require a complete re-write of my applications. So I'm stuck with the legacy.
I completely see your point. I am currently also trying to migrate my dashboard, but need to create pull requests all the time to implement missing features. And after that I need to migrate all my ui nodes, which is a huge work.
And I am not going to defend the choice of using VueJs, because I am also struggling a lot with it...
But when saying we will never reach the target that is quite a demotivating speech. Joe is even working tremendous hard on the dashboard, even after his working hours. Don't remember this is open-source software that you get for free. And the more people that help (code, documentation, ...), the better it gets. And since currently only very few people are willing to help him in their spare time, it will take longer before your free software will be ready. It is as easy as that...
Will try to continue tonight to get a little step closer to the (unreachable) target, by trying to solve 1 issue from the long backlog. One step at the time...
Hopefully my feedback doesn't trigger too much extra demotivational speeches, otherwise I am just going to watch television tonight with the familly like most of you
Maybe you should also add this link more prominent in your first post, as the question of "how to migrate from v1 to 2.0" will pop up in the minds of all v1 users instantly, won't it.
You are 100% correct, and I apologise if it sounded like I wanted to pour cold water on Dashboard v2 - I salute the effort and understand how much work it takes. The "target that can never be reached" refers to constantly replacing your toolset with the new shiny "because this time..."
I've been through so many hype-cycles and have accumulated so much redundant knowledge (VBScript, anyone? Perl?) that it sometimes feels like my head is going to explode. The older I get the less enthusiasm I'm able to muster, because I know that this too shall pass, and one day we'll look back and wonder what the hell we were thinking (Single-Page Applications). It is possible to build for the future (Linux), but this requires pragmatism and restraint - qualities which are rarely appreciated by young start-ups who aim to change the world.
Edit: I understand that my opinion is only just that, but my advice to Joe would be to ditch Vue.js, acorn and core-js and work directly with the browser APIs (please read). Use native UI widgets when available, or roll your own when absolutely needed. Leverage the modern standards, ignoring browsers that do not comply (who the *bleep* cares about IE14!?). It will mean doing less and going slower at first, but will pay handsomely in security, performance, agility and debt freedom down the line.
I do appreciate the feedback, but the choice of VueJS has got us this far considerably quicker than we would by using native APIs, and I'm still getting regular complaints that Dashboard 2.0 isn't delivering fast enough
I will also add to this, architectural decisions were made for Dashboard 2.0, which means the Node-RED/server side is completely agnostic to the front-end technology rendering it, which was not the case with Dashboard 1.0.
I really have no desire to be whipping any deceased equine, but have to ask: why is this considered important, or even beneficial? I'm all for loose coupling in general, but a Node-RED dashboard is a Node-RED dashboard - it will by definition be very firmly coupled to the back-end, and must track that to remain relevant.
When re-writing Dashboard because of Angular 1.0 deprecation, I also had re-write the entire server-side work too because of the ties into Angular events/architecture.
Now, if someone wanted a React-fronted Dashboard, or tool-agnostic Dashboard, they could re-build the widgets, and not touch the server-side at all, and it'll just work
This is exactly why UIBUILDER does not require any front-end frameworks.
Yes, there is a small front-end library, but this simply adds a few enhancements and comms simplifications, even the no-code outputs use a JSON schema that is very close to standard HTML so learning it still helps you learn HTML or if you know HTML, you will easily pick up the schema structure.
This has mean that, even though UIBUILDER is over 10 years old now, it's occasional breaking changes have been minor, mostly simplifications of the way things work. Code from 10 years ago, if you hadn't touched it, would need only a couple of tweaks and simplifications for it to work with the latest release.
As Bart says though, this doesn't take away the great work being done on D2, but I also personally don't see any point in having to learn Vue and Vuetify (or indeed any other front-end framework) and the D2 complexities just to get a pre-built layout.
None-the-less, it is good to have choice.
I get the point you are trying to make and there is some truth there. However, the front- and back-ends do not need to be tightly coupled. For example, for work (where we don't really use Node-RED) I've used some of the core features from the UIBUILDER front-end library, including doing rapid UI creation using the low-code json schema and the brand css completely independently of Node-RED. I used Node-RED on a dev PC to help generate the required business data but then simply saved that to json/csv files that I fetch in the browser and do all the necessary work there.
Yes oh so true. I must admit that I have also entered the phase of my life where I look at new technologies: oh no, there we go again
Not sure if it helps, but it is not really required to use VueJs in dashboard D2. Joe has added an example in the documentation, how to do it with raw javascript/html/css. Of course under the hood it is Vue all the way...
Every time I see your commit history of a single day, I am wondering how on earth you develop stuff so fast. So please don't get the impression that you are not going fast enough...
I invested a lot of time learning the intricacies of the framework and building my complex dashboards - even contributing a few bits & pieces - and frankly cannot see what was missing from Dashboard v1. It really comes down to one single issue, doesn't it: the deprecation of the JS framework upon which it was built. I think there's a very important lesson here, for developers in general and web-developers in particular: stick to the standard APIs as far as possible and don't depend on libraries that you have no control over.
