Why would I want to use UIBUILDER?

Share Your Nodes
1

image

Let's get started! (A 1st walkthrough)

Hi all, sharing the first draft of this entry that is being added to the UIBUILDER documentation. There was some commentary recently from someone asking what benefit UIBUILDER would have over http-in/-out nodes. This is a brief attempt to answer that kind of question.

Note the change from "uibuilder" to "UIBUILDER". :slight_smile: In the actual documentation, this now appears like this everywhere (except in code of course) - many thanks to suggestions from forum members on enhancing the branding - still a work in progress so please feel free to comment

Why would I want to use UIBUILDER?

Node-RED has several ways to deliver web pages already. Why would I want to use UIBUILDER instead? And are there any times I might not want to use it?

UIBUILDER potential benefits

  • Web pages with integrated websockets and other support tools.

    Probably the thing people will notice first. A single uibuilder node creates a very lightweight web application framework leaning on the power of Node-RED.

    Not only do you get a dedicated space for any front-end code that might be needed, you get a dedicated real-time websocket connector to your front-end.

No code is needed for any of this. Even the simplest template gets you going straight out of the box.

  • External libraries.

    When you need the help of additional front-end libraries, UIBUILDER makes it easy to install and manage right from Node=RED's graphical Editor. Under the skin, that uses standard npm tooling that lets you load libraries from the standard npm catalogue, GitHub, or local folders.

    Libraries are made available to the front end using a standard URL path. Making it easy to put in a minor single line of code to load the library. This can even be done via a command from Node-RED if needed (no-code).

  • Templates.

    UIBUILDER has a number of simple, built-in templates. These provide all the code needed to get you started.

    In addition, anyone can define external templates that you can load to your own flows.

    Templates do not have to be simple, however, they can include their own dev dependencies, instance API definitions, source and distribution code, images and other resources as needed.

  • Combine no-code, low-code and front-end code approaches.

    UIBUILDER's philosophy is that it won't lock you in. This holds true when it comes to using its no-code and low-code capabilities. You can mix and match these but you can also mix and match with front-end HTML, CSS, and JavaScript.

    As your web app or dashboard matures, if you want or need to move from no-code to low-code through to a full web development environment, you can.

  • Multi-user web apps.

    UIBUILDER web apps and dashboards have some basic client identifiers built in, these can help with multi-user workflows.

    Also built-in is the ability to filter inputs and outputs not only from a client device but also by page name.

    It also has server "middleware" features both for the web server and for the real-time websockets server. These optional functions allow you to include identity and access management features for additional security where desired.

  • Easier multi-developer workflows.

    The person or people developing your front-end might well be part of a web development team and might perhaps have no experience with Node-RED. UIBUILDER fully supports this by allowing front-end development to use all of the standard tools and methods that a web development team might use. But it does not force you to work that way. As always, you can start simple in Node-RED alone and extend with front-end development later if desired.

  • Not bound to a front-end framework, but can use any of them if desired.

    With its "no lock-in" approach, UIBUILDER will not force you to use a specific front-end framework (Vue, REACT, etc) and indeed, with modern HTML, CSS, and JavaScript, a framework may not be needed or desired.

    But if you want to use one, you can use any of them. If you or your web development team have skills in one framework, then you can use it.

  • Multiple web apps.

    You are not limited to a single web app or dashboard. UIBUILDER lets you have any number of them in a Node-RED instance. All that is required is that each has a unique identifier that defines its URL path.

  • Use different web server settings than Node-RED.

    You can choose to use the same ExpressJS web server that services the core nodes and Dashboard if you like, this is the default. But if you need to have a completely separate configuration, this is possible as well via a very simple configuration setting.

Alternatives to UIBUILDER

  • Dashboard.The original data-driven web app builder for Node-RED.

    Originally called UI and gifted to the community by the original dev. Largely now maintained by one of the core devs. It uses the AngularJS v1 front-end framework but is wrapped in such a way that not all of the framework is accessible to nodes.

    Various contributed nodes now exist and there is a ui_template node for things that the other nodes do not support. Note that AngularJS v1 is now end-of-life and no longer being developed.

    Dashboard is great for quickly getting going. However, like many framework solutions, it is not uncommon to reach a "cliff edge" where you have to start fighting the framework rather than it helping you.

    However, Dashboard is not multi-user aware. While some people have partially worked around this, there will generally be limitations.

    Note that Dashboard's front-end code is very "heavy" which can be a problem with some limited-spec clients. It also has to send a lot of data dynamically to the front-end from the Node-RED server.

  • Core nodes: http-in/http-out/websocket-in/websocket-out/template.

    These nodes can be used in order to create a data-driven web app. However, you are entirely on your own for creating both the back-end and front-end logic/code. It absolutely works but can be a lot of effort.

  • "Dashboard v2" (In early alpha development as at September 2023).

    Developed by the FlowForge commercial organisation, this is positioned as the next replacement for "Dashboard". It will very likely be similar to use. However, it is based on the Vue v3 front-end framework instead of the defunct AngularJS v1.

There are a number of other possible contributions, but none are production ready and most are abandoned.

With the exception of the core nodes, all of the alternatives bind you to a specific front-end framework.

Are there situations NOT to use UIBUILDER?

Absolutely.

  • If you need to get going really quickly and haven't used uibuilder before.

    Dashboard gets you going instantly and gives you a limited layout without faffing.

    Just have a think about whether you will reach the "cliff edge" where you find yourself writing everything using ui_template nodes and fighting with the framework.

  • If you need layout help from within Node-RED.

    Sadly, uibuilder still does not have a GUI layout editor like Dashboard does. Hoping to get one eventually and even before then, expecting to provide more layout helpers to make things easier.

    Remember though that Dashboard's layout editor is a simple grid layout only. It will not help with more complex layouts.

  • If your Node-RED instance is hosted without a filing system.

    Currently, UIBUILDER requires a filing system to work with. There are a few cloud environments (such as FlowForge) that do not provide a filing system . These few cases, it is not possible to currently use UIBUILDER.

  • If you don't need any of UIBUILDER's features.

11 Likes
2

Well if you don't you wasted a lot of time developing it :wink:

3

A point that would be made by my wife!

Though actually, it is a relaxing hobby believe it or not. It is a creative outlet akin to gardening or DIY (both of which I am not very good at :slight_smile: ).

I've learned loads and kept my brain active and it is sufficiently different to my day-job that it continues to be relaxing.

So actually, I'd probably continue with it even if nobody wants to use it! But as it has consistently had just under 2,500 downloads a month over its entire life (since April 2017), either someone enjoys downloading it for the sake of it or someone is using it.

6 Likes
4

I like the topic: Why would I want to use ...

There should be a series

  • Home Assistant
  • ZigBee
  • Mqtt
  • Flowfuse
  • The Catch node
  • Etc
3 Likes
5

Cool idea. Maybe you could get the ball rolling? I think that the FAQ category would be great for this.

6

This will be a real game-changer! I will switch to it too, as soon as it is finished.
Thank you very much in name of all of us, for your time and energy you have invested into it so far.
Keep up the great work :wink:

Edit:

  • you should add a LINK to uibuildier on the top of the page.
  • and maybe a link to a step-by-step "how to start" page / tutorial.
7

Good point - as this started as an extract of the UIBUILDER docs, the links are there - but good point. Will add shortly.

OK, but this wasn't really meant to be a stand-alone page. I will update to point to the right pages here though so people can go direct as well.

I find this quite interesting. My own thinking has always been around a full page designer. Of course, this is very different to what Dashboard provides. And it is pretty complex but certainly achievable - just beyond my current available time sadly.

However, I am starting to design another intermediate capability that would be more along the lines of what Dashboard provides. Though I'm not totally certain yet whether this will simply be a new element type on the uib-element node or whether it warrants being another node.

This is the idea of a layout element. Such an element would define the layout type - grid or flex for example (though probably only grid to start with, same as Dashboard). Then it would have settings available for the grid such as max/min width, number of columns, etc. This is actually a lot more flexible than Dashboard since a layout element would simply be another div in the browser and so you could define a layout at any level, not be forced into a single layout for the whole page.

The uib-element node would also gain a new "width" setting to allow overriding of the current defaults (set by your CSS file) which would allow setting the width in a number of columns out of the layout number of columns - which is how Dashboard also does it.

Because elements are chainable, you would simply put the layout node before any of the elements to go into the layout.

So the result should be something more flexible than Dashboard but with the same basic concept but different execution. It wouldn't have the visual sidebar that Dashboard has but changing the position of "widgets" (elements in uibuilder speak) would simply be a matter of swapping the order of nodes in the flow.

Would also need a group element to match the group Dashboard node.

image
image1344Ă—896 55.3 KB

Thoughts and feedback welcome as always. This is not a finalised design but is my current thinking.

No problem, thanks for the thanks :rofl:

8

I don't consider this a negative note. On the contrary, it gives you absolute freedom to build your site GUI as you want, no constraints!

2 Likes
9

:wink:

But some people do want this so certainly still looking at the right approach. I'm currently thinking that the approach outlined above would be a decent compromise. And it has a number of other benefits. It can be implemented in stages if needed. It can be extended beyond a grid layout. It retains the ability to mix-and-match no-code, low-code and full-code designs.

A proper page designer is something I'd love to have in the future but I suspect it might be a full-time development/maintenance job in its own right. So probably won't happen unless someone else steps up to help. But this approach is close to what Dashboard already provides, just does it in a slightly different and much more flexible way.

By the way, I haven't forgotten that Dashboard has "Page" and "Theme" sidebar tabs as well. Those are actually pretty simple to achieve with UIBUILDER and certainly also on the roadmap.

In fact, I already did a theming PoC quite a while back and it is still available in the experimental Web Components library - it pops a configuration window at the top of the page. Of course, one of the advantages of UIBUILDER is that you can do things both in front-end code (as that was effectively) and from Node-RED.

1 Like
10

I keep seeing your post title and thinking to myself, why wouldn't you want to use UIBUILDER? I'd be crazy not to for some of these projects.

1 Like
11

:rofl: I'd agree but I'm possibly slightly biased?

1 Like
12

I have taken a quick look through the documention and tried the first steps, it certainly looks very impressive and has great potential. That is from someone who knows nothing about HTML, CSS, Vue etc. and very little Javascript too. The one issue that has been discussed recently and no one knows the answer is when Node-RED runs under Home Assistant for either ui node-red tried to open the ui at port 8123 not port1880. If I manually enter port 1880 UI builder opens perfectly as does 'dashboard'.
I'll have to get round to asking on the HA forums. I cannot believe that someone hasn't solved this issue with HA and Node-Red.

13

Thanks for the feedback.

re Home Assistant. There is something extra you can do with UIBUILDER if you wanted to. It allows you to switch to using an independent web server on its own port. It is easy to do simply by changing some settings in the optional uibuilder section of settings.js. That might save confusion with Node-RED's port.

14

Thank you for the suggestion. I'll look into it but I really would like to get to the bottom of the problem with HA. I have an instance of NR running on a seperate Linux machine, I can't remember if it is native, in a Docker container or running under IOTsensor (was IOTstack) which will be in a Docker container anyway. On that instance clicking the dashboard icon goes to the correct 1880 port. I may well install uiBuilder on that PC to learn how to use it. I also have NR running native on my Windows 10 PC and the ui works correctly on that machine too.

15

This topic is about uibuilder, if you have a problem with HA, maybe asking for help in the HA support forum would be a better option.

16

I am well aware of what this topic is about and I have indeed raised the issue on the relevent HA forum. The sole purpose of my post was trying to be helpful and highlight an issue that other people, feeling thier way as beginners with UI builder, will come across. If I do suceed in finding the solution I will share that too!

17

You need to remember that when you run NR under HA you are actually firing up a docker container - i am pretty sure they do not expose that file system to you as the end user.

You would be better off installing Node Red on a different box/VM and then install the Node Red Webhooks add in that provides the link between NR and HA - you will get all the same functionality out of the box and not be tied into their release schedule or limitations.

Craig

18

Hi Craig, thanks for the reply that all makes sense. I can run Node Red on a seperate box (Linux) and it could be dedicated to Node Red. I am not clear about the webhooks add in, is that done in Node Red or HomeAssistant?

19

Sorry guys, but could you take this conversation to another thread as it isn't directly relevant to UIBUILDER. Thanks.

I can move the posts to a new thread if you want me to. It is an important conversation.

1 Like