Capability comparison between UIBUILDER and Dashboard 2

With UIBUILDER v7 just around the corner and with so much excellent development going on with Dashboard 2, I thought it was high-time I did a comparison of some key capabilities that people might want from data-driven UI's/Dashboards.

Please DO NOT use this comparison for any kind of "mine is better than yours" discussion, that will not be welcomed by anyone. Also note that I obviously know UIBUILDER far better than I do D2 and therefore there may be errors or missing information, if so, please let me know and I will fix things.

This comparison is part of the UIBUILDER documentation for v7.

NOTE: Sorry, because this is copied from the UIBUILDER docs, some of the links might not work.

Please do not use this comparison table to criticize one approach or the other, both approaches are deliberately different. Giving greater choice and flexibility for Node-RED users. Also note that I am much more familiar with UIBUIDER as its main author than I am of Dashboard 2.0, updates and corrections are always most welcome.

The following table is not in any specific order of importance.

Capability UIBUILDER Dashboard 2.0
Low-code approaches Has a number of "no-code" nodes, data in, UI building/manipulating data out. The no-code nodes output low-code standard data allowing further low-code manipulation where a no-code element does not quite match the requirements.
The low-code features take the form of a standardised data schema that describes the HTML UI. This allows an effectively unlimited ability to build anything that HTML/CSS supports. The outputs can be "hydrated" into HTML both in the browser and in Node-RED.
There is no visual page layout tool available. However, note that you can use 3rd-party generic page building tools with uibuilder since it all works with standard HTML/CSS.
The default CSS does provide for similar standardised layouts as D2. Customised grid and flexbox layouts can be designed using 3rd-party tools.
Low-code is provided by having a pre-defined node for each widget. This approach is undoubtedly simpler for beginners or users without any HTML knowledge. However, it tends to limit the flexibility for more complex layouts.
In addition, some standardised page layouts are available (grid, fixed and notebook) but unlike D1, there is no visual page layout.
Data cache. New clients may connect to Node-RED at any point, new (or reloaded) connections commonly will need to get the latest data so this requires a cache in Node-RED. Uses the optional uib-cache node. Wired up to the control msg output of the uibuilder node to detect (re)connections. Caching is extremely flexible and can be further filtered by user, page, topic, etc. Cache data can also be retained across Node-RED restarts if required due to use of Node-RED's standard context stores. The cache node can deal with no-/low-code UI data and other data.
In addition, dynamic changes to pages can easily be captured and written to the static page using the uib-save node. Dynamic UI's can even be created by sending no-/low-code data to the uib-html node and then saved.
Each widget (node) has to maintain its own cache. Usage is built-in and therefore there are no options. Nodes have 2 caches, datastore and statestore.
Network disconnection handling Socket.IO automatically reconnects. Uses an extending window algorithm to prevent excessive browser CPU,
Data would be lost during disconnection but the use of the uib-cache node mitigates this. Stored data can be resent on reconnection. Caution is recommended re cache sizes which could overwhelm memory if unconstrained.
Socket.IO automatically reconnects.
Data is lost during disconnection. Reconnection does not currently result in missing data being sent.
Client-side data. Client library uses simple set, get functions to manage client-side data. The onChange function allows for monitoring and action. Get and set functions can also be run from Node-RED without the need for front-end code.
Data can be persisted in the browser to survive reloads if required. Persisted data can be automatically reloaded if desired.
Uses VueX VueJS extension library for state management.
Data is persisted for the current browser session.
Widgets. Pre-defined UI components. Has a relatively small number of pre-defined widgets, referred to as "elements". Defined using uibuilder's low-code JSON configuration data enabling them to be further enhanced by any flow before sending to the clients.
Some elements are also provided as W3C standard web components.
Form and input handling is provided via the uibuilder.eventSend(event) function. This includes automatic file uploads.
New elements can be provided by 3rd-party nodes.
uibuilder can consume W3C standard web components as well.
uibuilder's Library Manager allows easy management of 3rd-party libraries and components as needed and allows for updates of them without having to rebuild uibuilder.
Element List.
Widgets are relatively complex VueJS components however a fairly large collection of core and contributed widgets exist. Requires the D2 package to include a large number of 3rd-party modules. Flexibility is mostly limited by whatever configuration has been built into the node's Editor config by the author.
New widgets require new nodes.
Widget List.
User management. Note that socketId is not stable and will change if the browser tab or client device enters sleep. Has socketId, ClientID, tab id, IP Address, and page name data available to all responses. Can optionally include rich client data in Node-RED output messages.
ExpressJS & Socket.IO middleware available for additional user and session interactions.
By default, only has socketId and socketIp. Requires additional plugins for richer data.
User/client specific information Data sent to a uibuilder node will be automatically filtered by socketId, clientID and page name if provided. Otherwise is broadcast to all clients connected to that uibuilder node.
Some limited provision for dedicated Socket.IO "rooms" also available - this also allows user-to-user comms.
Data is sent to individual ui widget nodes. It is automatically filtered by msg._client if provided.
No known provision for using rooms. None for client-to-client comms (without using a manual flow).
Sending data from Node-RED to clients All messages go via the uibuilder node. Segmented of flows should use core link nodes or the uib-sender node.
Messages are filtered by socketId, clientID and page name if that data is provided.
Front-end code can listen for incoming data manually using the uibuilder.onChange('msg', (msg)=>{...}) or uibuilder.onTopic('topicname', (msg)=>{...}) functions. Incoming data can be automatically processed using the custom uib-topic attribute on any HTML tag or using the custom <uib-var> component. No-code and low-code features can directly update identifiable on-page elements.
Messages are sent to individual ui widget nodes.
Messages can be manually processed using a ui-template node utilising the this.$socket.on() function.
Receiving data from clients to Node-RED Front end code can use either the uibuilder.send({...}) or uibuilder.eventSend(event) nodes to return data to Node-RED. eventSend is specifically designed to be attached to any HTML event but notably input tags, it gathers detailed information about any input and coordinates surrounding HTML Form data if the event happens within a form.
Some built-in uibuilder functions also automatically send data to Node-RED.
No-code elements will automatically return data to Node-RED where that makes sense.
Received messages are output from the top port of the uibuilder node (except for a uib-sender node configured for automatic return).
Dashboard widgets that accept input will automatically return data to the widget node.
Web page layouts No pre-defined layouts. An optional, provided CSS file contains a base configuration for HTML5 style general layouts along with some helper classes for grid, flex and other more granular layouts.
Because uibuilder uses standard HTML, 3rd-party layout editors can be used to create custom layouts.
Has 3 layout types: grid, fixed and notebook. Layout configuration follows Dashboard 1 controls in the Node-RED Editor.
Markdown content Allows the use of the Markdown-IT library as an external (optional) resource allowing library updates separate to uibuilder. Also allows for any Markdown-IT plugins. Could easily be extended in the future to use alternative libraries.
Lots of ways to support static (file-based) and dynamic (msg or code-based) Markdown content. Message and other dynamic content can be included in Markdown text by using the the <uib-var> web component.
The Markdown-IT library can be loaded via a message from Node-RED or included in low-code output.
The optional front-end router library (for creating single-page apps) also fully supports Markdown in the same way. Allowing UIBUILDER to be used as a content management system.
Embeds the Marked library. Updates require a new version to be released. Mermaid chart plugin included but no direct provision for others.
Markdown content limited to the ui-markdown node. Message content can be included in Markdown content using Mustache style {{ ... }} markup.
Front-end frameworks. Typically, large collections of code that support the dynamic management of front-end UI's. Allows any or no framework. No framework is required to work but any can be used if desired. Note that some frameworks require pre-definition of pages (or lots of dynamic processing as in the case of Dashboard) and so some uibuilder features may not be compatible. Fixed at using VueJS v3 with VueX and Vuetify.
Front-end libraries. Additional features that run in the browser and linked to the current page. Built-in library manager enables installation, update and removal of libraries from npm (to allow runtime use without Internet), GitHub or local (server) code. Uses standard npm tooling under the skin. Resulting URL's are all catalogued and shown.
Managed libraries are automatically made into Node-RED web endpoints for easy loading onto web pages. Information is provided on the most likely link URL required to use each library.
Library links are manually added to .html files or can be dynamcially added using no-/low-code features.
No management of libraries available. Any libraries must be manually included onto pages using a ui-template node or pre-built into core or contributed nodes.
For use without the Internet at runtime, libraries must be manually installed somewhere that Node-RED can serve them and the appropriate URL worked out.
SPA Routing. Creating single-page web UI's that simulate multi-page through the use of a front-end router. Optional. Uses the provided uib-router JavaScript library. Updates require a new version of uibuilder.
Routes and other settings are indepentent of uibuilder. The router can actually be used without uibuilder.
uibuilder is a multi-site, multi-page creator by default that also allows SPA creation via the optional router.
Built-in. Uses the pre-integrated 3rd-party vue-router package. Updates require a new version of Dashboard.
Configuration of routes is tied to the Dashboard configuration.
Dashboard 2 is an SPA creator but allows you to create multiple Dashboards.
Dynamic code (as opposed to dynamic data). HTML, CSS or JS code sent to clients Should rarely be needed since static code files are preferred, generally more performant and more secure. However, uibuilder allows HTML, Markdown, CSS and JS code to be sent when needed. It can also update static files from within Node-RED flows.
Charting No built-in chart elements. Any charting library can be used. Chart.js library built-in, chart widget available.
Custom extensions Custom extensions can be built using low-code features without the need for any knowledge of uibuilder core development and not much knowledge of Node-RED development, all they need to do is output messages containing the msg._ui property.
No examples are provided yet however. Some documentation is available. An example using uPlot is started but not complete.
However, W3C web components with uibuilder integration are preferred in any case. Several examples already exist in the form of the built-in components (uib-var, uib-meta, & apply-template) as well as external components including the HotNipi Gauge web component and a set of experimental web components. There is also a list of some useful components in the documentation.
Web components that integrate with uibuilder only require some reusable knowledge of building web components and some knowledge of the functions in the uibuilder client library (which are well documented).
Web components do require some web development knowledge but do not require any specific knowledge of Node-RED or uibuilder.
Some contributed widgets already published. Some documentation here.
Reasonable knowledge of web development, Dashboard 2.0, Node-RED development and VueJS development is required (e.g.). However a starter example is available.
Client size & performance Typically small, efficient pages and minimal data transfer. Use of static data allows for good transparent caching.
Example very simple page:
Uncached = 17 requests, 239kB transferred, 341kB resources, 398ms.
Cached = 17 requests, 5.4kB transferred, 341kB resources, 385ms.
Relatively large and complex resource loading and data transfer required to build the page.
Example very simple page:
Uncached = 19 requests, 2.4MB transferred, 5.1MB resources, 723ms.
Cached = 19 requests, 1,0MB transferred, 5.1MB resources, 569ms
Server (hosting) requirements A filing system required on the Node-RED server.
By default, ~/.node-red/uibuilder/ is used to store configuration and instance data. This can, however, be moved to any location.
FS access is all being moved to a single code library though so in the future, it should be possible to use the same virtual FS as Dashboard.
Because FlowFuse environments do not currently have a full filing system, UIBUILDER currently is not compatible. However, this is shortly to be fixed by FlowFuse. Installation on FlowFuse will automatically set the correct uibRoot folder in settings.js.
No filing system required, can use a virtual FS. Designed to allow use with FlowFuse environments.
Internet access Not required for running.
Library manager can install from local folders or a local repository. Or libraries can be copied into place.
Not required for running.
Offline client use Not as yet, on the roadmap. No.
Installable as an app Not as yet, on the roadmap. Yes.

A few inaccuracies on the Dashboard 2.0 side here, but I'll address them fully once I'm back at the desk tomorrow.

Thanks for the assessment and breakdown

Thanks Joe, I was hoping you would catch up with it and correct me. :slight_smile:

Updated with new info and feedback from Joe.

1 Like

yet - it's top of our list of big, shiny things we want :smile:

Haha, its been on my list of things to do for UIBUILDER for nearly a decade! I even know the library that I would most likely use. But it never quite seems to make it to the top of my list due to other features that seem to take priority over my very limited time.

To be honest, I had to double-check whether D2 had it or not as I assumed it did. But I now suspect that it will be an even harder job to do for D2 than it would for UIBUILDER.

By the way, I should say, by way of some encouragement, that I have picked up on a few design features from D2 that have been added to my backlog for further thought. Also, listening to people's struggles trying to do things helps me think about how to make things simpler and better in UIBUILDER as well. :slight_smile: