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.
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.
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.
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.
<b-button type="submit" variant="primary">Login</b-button>
<b-button type="submit" :variant="btncolourvariable">Login</b-button>
<b-button type="submit" :class="btncolourclassvariable">Login</b-button>
<b-button pill variant="primary" v-on:click="increment">Increment</b-button>
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:
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.
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).
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.
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 
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.
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.
Yup! If you can't find one there, you will generally find something in the WIKI on GitHub.
