🌐 UIBUILDER - next development - v7.3.0 - Progress report

[TotallyInformation]

Hi all, unfortunately personal circumstances have recently forced a slight slowdown in UIBUILDER development. But fear not, things are progressing and will continue to do so.

The next planned release is v7.3.0 and should be a small feature release.

The main features will likely revolve around templates. Templates in UIBUILDER are pre-canned sets of front-end code and configuration. When you load a template, it replaces any files that overlap. Typically the src/index.{html,css,js} files that define your basic UI.

Up till now, there have been a 1/2 dozen or so internal templates that demonstrate the basics of the uibuilder front-end library in both standard script as well as ES Module forms. And some VueJS examples for both Vue v2 and v3. There is also an example Svelte template.

In version 7.3 and beyond, most of these templates have been removed from the uibuilder core. It has been increasingly difficult over the years to keep the templates current and since VueJS is now rarely needed and I now very rarely use it at all, I took the decision to deprecate them and remove them from core. They are now relegated to a separate repository and will no longer be updated. Of course, you can still copy the code yourself should you need a head-start and want to use them.

On a more positive note, I have reworked the template handling to make it more flexible. Previously, there was (and still is) the option to load an external template, for example direct from a GitHub repository. This uses the excellent degit tool.

Now, standard templates can also be external. This means that any remaining standard templates apart from the most basic ones, have been moved to their own GitHub repositories and will be much easier to maintain. They will also be maintainable out-of-band from UIBUILDER updates.

When selecting templates, you will now also see a brief description of the template.

The basic code for this feature is already written and tested, I am in the process of moving the templates.

Other than that, there probably won't be a lot more in this release:

• The basic font specification for the default CSS has been improved based on the excellent work of Modern Font Stacks
• Fixed an error in the RED.util.uib.dp helper function (that converts a floating point number to have fixed decimal places).
• Have done a LOT of tidying up and improving the structure of some of the code.
• Done more work on standardising the format and style of log messages. You will see that most are now prefixed with the emoji to make them easier to spot.
• Started being more explicit when naming JavaScript files, using *.cjs for CommonJS files and *.mjs for ES Module files. This should slightly ease the slow migration of code from CJS to MJS.

As always, there is a development branch available on GitHub should you wish to test the changes. And please do reach out if you spot any issues or would like to see something included in UIBUILDER.

[jbudd]

Thanks for your continued development of Uibuilder Julian.
It's very valuable to have a choice of dashboards for Node-red.

It must have consumed a huge amount of your time over the years.

[TotallyInformation]

@jbudd

It must have consumed a huge amount of your time over the years.

Indeed, and hopefully will continue to do so over the next decade or two!

It beats watching too much TV.

Thanks for your encouragement.

[PizzaProgram]

OFF

@TotallyInformation

There is also an example Svelte template.

Wow!
Does it mean, that I can disable Vue completely somehow?

Sorry, that I'm still using the old, standard v1 UI, and had no time to test yours, but I have an old Android 4 tablet,
and the old UI is already taking up to 250MB memory when I open my home-control page,
which sometimes takes up to 5-8 seconds. (Just to switch something ... )
So I was afraid that If I would switch to a newer one, probably it would:

• take even more memory
• and more time to load.

I'm not a web developer, but I know a lot about it (understand html code if I read it) and I've red everywhere that VUE is consuming a lot of resources.

But also red, that Svelte is very fast!
... the question is: is it using Svelte kit v1 or v2 ?
V2 is limited to ES2022+ See here.

Or is it not recommended (yet?) to use Svelte instead of Vue?

[TotallyInformation]

@PizzaProgram

Does it mean, that I can disable Vue completely somehow?

UIBUILDER does not need Vue and does not use Vue - at all!

You can use Vue with UIBUILDER if you like. But no Vue is harmed in the making of UIBUILDER.

But do remember that UIBUILDER != Dashboard (1 or 2)

While there is certainly overlap and all 3 capabilities make it easy to create data-driven web UI's. The Dashboard's purpose is largely to make it easy to get started. UIBUILDER's key purpose is to facilitate lightweight, long-term maintainable, fully flexible UI's.

The 2 Dashboards use front-end frameworks to allow easy starts. UIBUILDER extends native HTML/CSS which each year is getting ever more powerful.

@PizzaProgram

So I was afraid that If I would switch to a newer one, probably it would:

• take even more memory
• and more time to load.

This is a point that is not often talked about. UIBUILDER's full package is 5 times smaller than D2 even though it includes all of its documentation. Last time I checked, these are the differences in sizes between UIBUILDER and D2:

Capability	UIBUILDER	Dashboard 2.0
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

UIBUILDER does not have all of the overheads of a front-end framework (unless you choose to add one of course). So mobile performance should be better, particularly on cheaper/older devices.

@PizzaProgram

I've red everywhere that VUE is consuming a lot of resources.

Indeed.

@PizzaProgram

But also red, that Svelte is very fast!
... the question is: is it using Svelte kit v1 or v2 ?

Svelte is a build-only front-end framework that follows HTML standards more closely than most. It also has one of the only dev servers that can play nicely with UIBUILDER. The resulting built app(s) are relatively lightweight compared to Vue/REACT/etc.

The main downside right now (other than still being a framework with the overheads/limitations that might bring) is that it requires a build-step. So it is slightly more complex to get going. I do have some things on the backlog for UIBUILDER that will surface npm scripts into the Node-RED uibuilder node config panel to help remove some of the complexity. Not sure I'll get that into v7.3 but maybe int 7.4.

But for now, moving most of the templates to external repositories means that I can improve them without needing a new version of uibuilder to be published.

You can use any version of Svelte with uibuilder. But you should probably use the latest. Front-end framework versioning is one of the reasons I often try to steer people away from them unless you are working on a large team, complex app.

@PizzaProgram

V2 is limited to ES2022+ See here.

There may be ways to work around that. For example, I now use ESBUILD to allow myself to use the latest versions of front-end JavaScript but build to a version that targets early 2019. I could produce versions even earlier if there is a requirement but early 2019 seems a decent compromise for now. Not sure if that could be applied to Svelte but I imagine it could.

But again, it demonstrates the potential dangers of working with a framework.

@PizzaProgram

Or is it not recommended (yet?) to use Svelte instead of Vue?

If you are going to use UIBUILDER, why use either? The real question is: What advantage do you think you would get vs how much effort will you have to put into learning and working around the framework?

Personally, if I were to use a framework, I would use Svelte or Lit. But nothing I've built over the last few years (other than some specialised things that already use Vue) inside or outside of Node-RED have needed a framework and would have taken much longer to develop with one.

[AllanOricil]

@TotallyInformation @joepavitt
What makes dashboard 2.0 download 2.4mb/5.1mb resources? Do you know which major dependencies and their sizes?

[TotallyInformation]

Just to note that I've uploaded a finalised version of the new uibuilder svelte template. It will be available directly in uibuilder v7.3 but can be loaded manually in v7.2.

GitHub - TotallyInformation/uib-template-svelte-simple: A simple Svelte template to use with...

It is a much improved and modernised version of the old built-in template.

[TotallyInformation]

@AllanOricil

What makes dashboard 2.0 download 2.4mb/5.1mb resources? Do you know which major dependencies and their sizes?

Been I while since I ran that test. There may have been dev resources in the build?

Just ran this on my dev instance (which does have some D2 content loaded):

You can't really see the individual resource sizes since everything is bundled.

---

For comparison, here is the new Svelte template resulting page loaded without cache as well:

The odd load time of 2s is because of an errant live reload script that isn't loading because this is a production build - which means that script shouldn't have been referenced and there is a bug in the build! Load time would have been 200ms otherwise.

This is the page:

[TotallyInformation]

That's better, after a production rebuild:

[AllanOricil]

Dashboard 2.0 has a huge entrypoint and several milliseconds iddle. Maybe there is room for improvements.

[TotallyInformation]

@AllanOricil

Maybe there is room for improvements.

Yup, get rid of VueJS

Sorry, couldn't resist.

I'm sure there will always be room for tweaks.

[AllanOricil]

Vue is not the problem. When a project is minified and tree shaken it gets smaller than this

vue ❘ Bundlephobia

[TotallyInformation]

I think that there is a lot more than Vue bundled.

["./dagre-OKDRZEBW-B0mwdAlD.js", "./graph-Dhlq-UIg.js", "./_baseUniq-CF5cXlPW.js", "./layout-BnWan_nx.js", "./_basePickBy-Ck690Cpp.js", "./clone-Dx_fNVmR.js", "./c4Diagram-VJAJSXHY-B2760zx7.js", "./chunk-D6G4REZN-CjDZvXT3.js", "./flowDiagram-4HSFHLVR-BVrXnQkW.js", "./chunk-RZ5BOZE2-Clp-NZOf.js", "./channel-Bjodxr7n.js", "./erDiagram-Q7BY3M3F-D-ak4WNa.js", "./gitGraphDiagram-7IBYFJ6S-CeoU4aJm.js", "./chunk-4BMEZGHF-qqPm7v8W.js", "./chunk-XZIHB7SX-D3ZxtkBp.js", "./radar-MK3ICKWK-CFy2_6Cq.js", "./ganttDiagram-APWFNJXF-BoChmNeY.js", "./linear-QicFDJSh.js", "./init-Gi6I4Gst.js", "./infoDiagram-PH2N3AL5-CdKma-sX.js", "./pieDiagram-IB7DONF6-DL362_74.js", "./ordinal-Cboi1Yqb.js", "./quadrantDiagram-7GDLP6J5-BaFBs2-L.js", "./xychartDiagram-VJFVF3MP-CxaRa2z3.js", "./requirementDiagram-KVF5MWMF-CNDqyBls.js", "./sequenceDiagram-X6HHIX6F-DysbprK3.js", "./classDiagram-GIVACNV2-Bb-zT7-T.js", "./chunk-A2AXSNBT-B4cVkN9u.js", "./classDiagram-v2-COTLJTTW-Bb-zT7-T.js", "./stateDiagram-DGXRK772-JZYcfFGL.js", "./chunk-AEK57VVT-DSwAu7hl.js", "./stateDiagram-v2-YXO3MK2T-CDqlFzpi.js", "./journeyDiagram-U35MCT3I-BTEKciTf.js", "./mindmap-definition-ALO5MXBD-yPmyjQte.js", "./cytoscape.esm-otp_DSkq.js", "./sankeyDiagram-QLVOVGJD-TSvF9rm5.js", "./diagram-VNBRO52H-vcxX5g9X.js", "./diagram-SSKATNLV-DG1OUbLa.js", "./blockDiagram-JOT3LUYC-CRhieMUH.js", "./architectureDiagram-IEHRJDOE-BzaJ5kxb.js"]

["workbox:window:7.2.0"]

Google Analytics

That's just some quick things pulled out of dev tools.

[TotallyInformation]

I had hoped to publish 7.3 today but I'm afraid I got side-tracked (again!) with some late documentation updates.

The silver-lining though is that the templates, which have long contained a <div id="more"></div> empty element used by all the examples, has now been updated to:

<div id="more" uib-topic="more"></div>

Which now means that you can send a message like this to the uibuilder node:

{
  "topic": "more",
  "payload": "Hello 👋 from <b class='error'>Node-RED</b>"
}

and the content of that empty div will be updated with the content of the msg.payload.

Absolutely no coding required!

I will be updating all of the templates accordingly but enough for today.

---

The other update is for documentation. There is a new section called "Creating Web UI's". Not complete yet and won't be for v7.3.0 but it contains a growing list of how-to articles for creating userfull stuff.

Drop a note if you would like to see something specific in this list.

[oldie]

uibuilder is so good, I want to use it for all my solutions going forward. Is it time to create governance and developer teams in order to keep up with new and emerging technologies that could further enhance this great product? Happy to contribute as payback in some way, I'm sure others would think the same?

[TotallyInformation]

Hi, thanks for that.

UIBUILDER has been a passion of mine for over 10 years now and shows no sign of ever being "finished". Since its very inception it has been averaging around 2-3,000 downloads a month though I can't imagine that is actually representative of real users! If it is, then it must be widely used and usable since I rarely get questions or issues raised.

I've always warmly welcomed and acknowledged any input and I am happy to do so. I've also occasionally put out queries and polls - to be honest though, they get very little engagement.

I am more than happy to take ideas on future governance and development. This forum is the place to start the discussion, just use the uibuilder tag. There is also GitHub with both issues logs and a discussion board and a WIKI. The WIKI isn't used as much now since I moved all the documentation into UIBUILDER itself. The discussion board gets occasional use but this forum is where everything really gets discussed.

There is also a Discord, here is an invite to it that anyone can use and share: Node-RED UIBUILDER.

If you are interested in helping to develop UIBUILDER, I suggest following a similar route to Node-RED itself. Start with a discussion here in the forum. Use the "Developing Nodes" category and the "uibuilder" tag. Developer documentation for UIBUILDER is, I will admit, a little sparse right now though there is a section in the docs (not always exposed though so do check the raw docs folders, there is a /docs/dev and a /docs/processes folder. You will note, if looking at the code, that it is typically very heavily commented. I will happily do a conference call (or maybe a live-stream? Never done one of those!) to take people through the structure and style of the code and the tools I use to develop it.

If you would like some inspiration, check out the "Coming Next" and "Roadmap" documents, those are rather stream-of-consciousness bullets of thoughts and ideas. Coming next is what I use to document ideas and in-progress/to-do items as I'm coding, the roadmap contains the longer-term thoughts, inspirations and ideas.

If people wanted to contribute but aren't coders, the documentation will ALWAYS need improvement I've no doubt. And, of course, ideas and needs are also always welcomed. Drop suggestions here in the forum tagged with the "uibuilder" tag.

In addition to UIBUILDER itself, I have another repository, this time of web components. This also has a large backlog of ideas. Again, I would welcome anyone wanting to contribute. But, in this case, you can always create your own web components elsewhere - I would be more than happy to help with any UIBUILDER integrations. https://wc.totallyinformation.net

@oldie, by all means have a poke around and see if anything inspires you. If so, lets have a separate discussion about collaborating.