AngularJS considered harmful

[ambotaku]

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.

[TotallyInformation]

Hi, the issues with Angular v1 are well known. Dashboard was originally a contributed set of nodes called UI which were gifted to the Node-RED project. They are an amazing piece of work but extremely complex. so not easy to pick apart and re-engineer nor at all easy to even bring up-to-date with newer versions of Angular.

I created an alternative that took an opposing view to the way that Dashboard works when I created uibuilder. With uibuilder, you have complete freedom in regards to frameworks. However, the downside is that you currently have to do more front-end coding to build your UI.

I have lots of ideas for uibuilder and I've started to explore some that will start to bridge the gap between the uibuilder and Dashboard approaches by creating VueJS components and allowing uibuilder to talk to them more directly from Node-RED so reducing the amount of front-end code required.

I deliberately chose VueJS because I saw that it was a much leaner approach even than REACT let alone Angular and so much better suited to the Node-RED style.

However, without other collaborators and with a heavily overcommitted day-job, progress is slow. I know that is true for Dashboard as well. The need to move Dashboard on from Angular v1 is well known but the resources to do it very limited.

So there are plenty of opportunities to become involved with uibuilder and Dashboard. @dceejay is the main Dashboard core contributor at the moment and I am the author for uibuilder. Certainly I'd be more than happy to talk about some of the ideas for uibuilder and what might be done to implement them.

[ambotaku]

Thank You for your info.
I've expected a situation similar to what you told me, but wanted to give some attention to your work since we both seem at least know the problems and have the same idea for an elegant solution.

Unfortunately I'm Node-Red related just a starter who has quite good experiences with Vue, too.
In my job I had to use mainly Angular 6-8 due to team decision and project size, personally I preferred Vue due for its flexibility and scalability. I've even used Vue to get some functionality in Wiki-documents and user interfaces for embedded devices like Arista's IP-switches.

Maybe I can contribute some code after understanding Node-Red and your work on uibuilder - at least I have more time now for such a purpose. With some understanding of our concern more people may get interested or invest some time for further contributions that make Node-Red more popular for sure.

Of course I'm open for any other ideas that help to enhance Node-Red frontend development, since the AngularJS problems can result in bad reputation for the whole Node-Red community, if larger projects fail due to frontend problems (like being "amateur stuff" like Visual-Basic and many forgotten JS-frameworks in times of JS fatigue).

[TotallyInformation]

Thanks Klaus,

We were all once beginners at Node-RED and got sucked into that red hole

By all means become a little more familiar with Node-RED and how it works. Really though it doesn't take long thanks to its logical construction over the top of Node.js and ExpressJS. I think that you will quickly understand the flow of messages.

Understanding the flow of data for Dashboard is a little trickier but at least there are contributed nodes now so it should be a lot easier than when it was first introduced.

uibuilder should be pretty easy to understand in concept. It largely does two basic things.

Firstly, it ties into NR's ExpressJS servers and creates a set of web endpoints. The web endpoints not only serve up your own ui code but also any front-end libraries that you want so that you don't have to rely on the Internet.

Secondly, it provides a front-end library that greatly simplifies communications between the Node-RED server and your front-end web page. This makes it really simple to have a data-driven web ui.

Everything else that it does is bells-and-whistles with the aim of making things easier for flow developers and reducing the need for code and custom logic.

The uibuilder WIKI on GitHub has lots more information and importantly a To Do list Also the docs folder in the package has a bunch of documentation both on usage and on the internals.

Reach out if you want to contribute, there is bound to be something you would find interesting.