# Node-RED dashboard performance across tablets & mobiles
**URL:** https://discourse.nodered.org/t/node-red-dashboard-performance-across-tablets-mobiles/30330
**Category:** Dashboard
**Created:** [19 July 2020 09:49 UTC](https://discourse.nodered.org/t/node-red-dashboard-performance-across-tablets-mobiles/30330 "2020-07-19T09:49:30Z")
**Posts on this page:** 1
**Showing post:** 19
### Author:  [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)
#### Post date: [21 July 2020 09:56 UTC](https://discourse.nodered.org/t/node-red-dashboard-performance-across-tablets-mobiles/30330/19 "2020-07-21T09:56:21Z")
> [@alex88](#):
>
> My solutions are frankenstein-ian. I am leveraging my home automation systems pre-existing code to build interactive dashboards. In the future I am looking to build as much as possible in Node-RED, but for now leveraging what I have already built in my HA system was the quickest way to get results.
We all started there 🙂 And certainly Dashboard is the quickest and easiest way to quickly knock up a UI and of course, I still use it as such.
> [@alex88](#):
>
> I am now at a huge fork in the road. Do I continue down the path of the dashboard node or do I start learning all over again, and more importantly, re-building my dashboards with uibuilder?
This is always an issue when using any kind of framework, even Node-RED itself. All I can give is advice based on my own experience. That is to say that I generally eventually regret choosing a locked-down framework whether that is Dashboard, Angular (on which Dashboard is built, that turned out to be far too complex for anything I'll ever build). Or even something like EasyESP on an ESP8266 where I generally end up hand-cranking my own C++ so that I can do exactly what I want. Of course, this may well be just the way my brain works!
Node-RED itself has turned out to be rather an exception to that. It is mostly flexible enough for many tasks and has enough freedom to use it as a base framework and delve into node.js if needed. That isn't to say that it is right for every job. I do wish that it (and node,js in general) were better at analytical work since I regularly have to wrangle large interlocking spreadsheets/tabular data for work (mainly identity data, sometimes performance data). But in truth, node.js generally sucks at those tasks compared to Excel, PowerShell or Python. Not Node-RED's fault.
> [@alex88](#):
>
> To give you an idea of how daunting a complete rebuild is, following is what it looks like in the Node-RED
You would almost certainly find that a uibuilder version would be simpler since you feed data into and out-of a single uibuilder node. Of course, you slightly pay for that with more JavaScript code in the front-end. But as you build it up a piece at a time and because uibuilder and VueJS do all the heavy lifting, as long as you take it slowly and logically, it isn't as hard as you probably think.
> [@alex88](#):
>
> buttons + text and colour formatting
Creating buttons is trivial and the default template contains a simple example button. Colour formatting is easy in Vue since it is fully data-driven. Changing colour is as simple as having a variable that contains 1 or more CSS class names or alternatively some CSS Style definitions.
So here are some examples of buttons using bootstrap-vue's button which gives you good control. The first is direct from the default template, the second drives the overal look from a variable and the 3rd gives you detailed control via CSS classes. The final example is a button that triggers a function called `increment` when it is pressed & is also a more rounded format. You can, of course, use ordinary HTML button tags instead but then you get less help from the framework.
```auto
Login
Login
Login
Increment
```
> [@alex88](#):
>
> writing back to my HA system with user updates
So using the last of the above buttons, the following code returns a bunch of data from an on-page form back to Node-RED:
```auto
methods: {
increment: function() {
// Increment the count by one
this.counterBtn = this.counterBtn + 1
var topic = this.msgRecvd.topic || 'uibuilder/vue'
uibuilder.send( {
'topic': topic,
'payload': {
'type': 'counterBtn',
'btnCount': this.counterBtn,
'message': this.inputText,
'inputChkBox': this.inputChkBox
}
} )
}, // --- End of increment --- //
```
Any variable that starts with `this.` are ones that are defined in the `data` section of your JavaScript code and are understood by VueJS so that any use of them in your html is dynamic, if they change, the UI changes - no code required. In this example, you can also see that there are 2 ways that you could differentiate the data you are sending back to Node-RED. The msg.topic and the msg.payload.type could both be used in switch nodes attached to the output of the uibuilder node to trigger different flows. A similar approach is taken to incoming msg's from Node-RED to the front-end. The `uibuilder.onchange('msg', ....)` function is triggered whenever a new msg is received from Node-RED and you can use `if` or `switch` JavaScript statements to take specific actions dependent on the incoming data.
> [@alex88](#):
>
> - all the code I have written in functions
> - all the other nodes that I have used e.g. switch, change, json converted, delays
You can either leave them where they are and send any output into the uibuilder node or move them into your front-end code if it makes more sense to run the code in the users browser instead.
You may also want to start thinking about caching of data. Do you want data to be ready to deliver when a new user loads the uibuilder page? (or reloads the page) Dashboard does some basic caching, in uibuilder you can build a caching function node just before data is input to the uibuilder node. uibuilder has a control channel that includes outputs that let you control a cache in a standard way and there are some examples of how to do that (one day I'll get time to finish a proper node but there are so many edge-cases to caching, it isn't a trivial thing to create, using a function node gives you maximum flexibility).
> [@alex88](#):
>
> the answer to, can i use all my existing components appears to be a big fat YES. From what I can see, the uibuilder needs you to write all of your code for the exposed parts of your webpage
👍
> [@alex88](#):
>
> I can see that the uibuilder node does still have an input and 2x outputs
Yes. A single input as described above. For the outputs, the top one is data output from `uibuilder.send()` in the front-end. The 2nd is for control msg's such as the cache control and for when a new browser tab loads or unloads the page.
> [@alex88](#):
>
> my dashboard has distinct components that interact with each other, it's relatively easy to see the interaction when using dashboard nodes, but not so easy to visualise how it would work with all the processing happening in one node
Yes, here is a big difference. In Dashboard, most of the data goes to and comes from the Dashboard (front-end) into Node-RED and is processed there. This is perhaps easier to conceive visually but isn't terribly efficient since in some cases that data isn't really needed in Node-RED itself, only in the front-end. uibuilder gives you the chance to do the processing in the front-end if you want to. However, you _can_ still pass it back to Node-RED if you like & process it there if it makes sense.
One of the other projects I want to do is to create a set of standard (VueJS) components with standard data interfaces. I've already done 1 example which mirrors the excellent SVG Dashboard node. Other examples would be components for charting for example to make that simpler. Sadly I have to still work for a living and have a family who demand time 🙁
> [@alex88](#):
>
> is it really worth migrating across?
Ah, well, that is indeed the big question. No easy answer there. Though the fact that you are already asking the question tells me you aren't certain that Dashboard is going to be suitable for you in the longer term.
What I will say is that you don't need to take an either/or decision immediately. If Dashboard does what you want then fine, stick with it but maybe start to learn about HTML, CSS and VueJS so that if/when you do grow out of Dashboard, you are ready to start moving over.
Also, having a 2nd actual page (rather than the virtual pages in Dashboard) is easy enough to integrate to Dashboard so you don't have to migrate everything at once. A uibuilder page can appear to an end user as just another link from the Dashboard.
> [@alex88](#):
>
> The last question is one of design, how to design such a beast to work with one node only.
The node is just a gateway. Send data in and it goes to the front-end. Send data from the front-end and it comes out the back of the node. In Node-RED, you can use link nodes to help keeping your flows neat. Personally, I find the single node a lot easier to work with & I think your screenshot shows that Dashboard flows can get rather horrendous.
Just think about your data flows and things will become clear. And that is a key difference. When using uibuilder, it is easier to take a data-centric view which often leads to a more robust solution.
> [@alex88](#):
>
> Where is this example?
>
> EDIT: OK, I guess you mean the examples built into the index.js for if the uibuilder node.
Yup! If you can't find one there, you will generally find something in the WIKI on GitHub.
---
_[View the full topic](https://discourse.nodered.org/t/node-red-dashboard-performance-across-tablets-mobiles/30330)._