Since a year I’m a retired “fullstack-developer” who participated in building AV consoles and stream switches. During my last three business years I ported several desktop UI interfaces to web interfaces using libraries and frameworks starting with jQuery over AngularJS, Angular from release 2-9 up to Vue.js. Now as a hobbyist I tinker around with IoT and came to MQTT and Node-Red and like that very much, but have to learn still a lot.
Experiencing the dasboard nodes I found, that they are using AngularJS which make it easy to create new UI widgets, but considered using AngularJS can be harmful. When Google invented Angular 1 (now called AngularJS), it was one of the first nearly complete web-frameworks and a great progress and success related to libraries like jQuery (which it still includes as “light” version). But as single page applications (SPAs) based on it grew, many of them became very sluggish and unreliable. So Google sent the developers back to the drawboard and aborted further development on Angular 1. With Angular 2 strong typing and reactive programming (Typescript & ReactiveX from Microsoft) lead to a complete different framework with a deep (but monolithic) component hierarchy, which should also fit the expectations for very large SPAs.
As Angular 1 was quite popular when Google abandoned it, they called it AngularJS and will support it up to end of 2021 with LTS releases. For that it is a dead end not recommended to be used in new larger / nontrivial projects. But is AngularJS really that bad ? No - but like still popular programming languages as BASIC it has a very tempting, but also harmful feature.
Where the GOTO command was considered harmful by Donald Knuth, as it can destroy the (algorithmic) program structure, AngularJS contains something that can destroy the data integrity.
That one is called “Two way data binding” and is a core concept and often advertised feature -but lime-twig - of AngularJS. This develish temptation was not invented for AngularJS, similar “easy-peasy” concepts started with 4GL languages in the 80s, again in the 90s where it was one highlight of Visual Basic, Delphi and ASP.NET forms and different scaffolders, toolkits and frameworks for any platform up to today. Node-Red as “easy peasy” IoT platform is another good candidate for such a poison cookie.
Current leading “reactive” web frameworks like Angular (current release 11), React or Vue doesn’t support or propagate it anymore. So what is so harmful with 2-way-data-binding (and other concepts that copy state) ?
Copying data (or generally called state) to several places of a (maybe distributed) application make it inconsistent - you don’t have a “single source of truth” any longer. You can make it worse with controlling the program flow or decisions based on view states that aren’t longer valid. So updating AngularJS views or making decisions (handle events) based on 2-way-bounded variables may get you in a data-desaster up to never finishing updates due to a circular reference in your GUI event flow. You may know such effects from buggy validated text fields with jQuery-scripting.
So AngularJS isn’t bad per se, just avoid controlling the whole application with AngularJS ViewControllers. Angular is a quite good Model-View-ViewControl - framework, but ViewControllers should control just their view and not other parts of the application - like the data model. All Data-Decisions should occur as a single responsibility in a state-controller bound to a “single source of truth” like a MQTT-broker or database. Modern frameworks like Angular, React and Vue support reactive state controllers out of the box, but existing message based communication in Node-Red may help also.
An article about state management design patterns is Design Patterns for State Management in React and Typescript | Becca Bailey
But there is another problem which can make AngularJS sluggish. As built on jQuery (-light) it directly manipulates the browser’s DOM. This forces the browser to do instant content updating which can be blurry and slow. Modern web-frameworks support (like those I mentioned above) store to a virtual DOM which gets rendered when all update activity is complete. It also makes more browser independent and allows some DOM-manipulation which is impossible by directly writing the DOM.
So what about using another web-framework with Node-Red ? In my oppinion the most popular (Angular and React) won’t fit since being to monolithic for creating a good dashboard - also you can expect a steep learning curve based on different languages like TypeScript (Angular) and JSX (React) and a complicated workflow with lots of different tools.
Quite another thing is Vue (in release 2.x, 3.x is also TypeScript based). It is even leaner than AngularJS, easy to learn and has a fine-grained, POJO-based and extendable architecture like Node-Red, too. Extensions include also anything from routing to state management, so Vue can be used from simple (one-way-)data binding to real large SPAs.
While searching this group I found articles like New home dashboard using uibuilder and bootstrap-vue, showing other developers have similar ideas for using Vue and Bootstrap-Vue as alternative to AngularJS based dashboards. For sure there will be some work on this path, but I would expect more stability, a higher performance and a brighter future on it.