# Best practice: custom v. function node

**URL:** <https://discourse.nodered.org/t/best-practice-custom-v-function-node/83222>\
**Category:** Developing Nodes\
**Created:** [27 November 2023 13:55 UTC](https://discourse.nodered.org/t/best-practice-custom-v-function-node/83222 "2023-11-27T13:55:14Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [27 November 2023 17:45 UTC](https://discourse.nodered.org/t/best-practice-custom-v-function-node/83222/10 "2023-11-27T17:45:57Z")

</div>

> [@gregorius](#):
>
> I find the function node to be exactly right - for me

And that is one of the reasons it exists of course. Node-RED is a _general purpose low code development tool_. It can be used for all manner of things and by all manner of people with different experience levels.

As a reasonably experienced JavaScript programmer, I often find things much easier to accomplish in a function node than having to use a bunch of other nodes. Though I might experiment with a flow using nodes and after a year or so get fed up with the number of nodes cluttering the screen so wrap them all up into a function node or two. I also regularly find myself using function nodes as simple wrappers around 3rd-party libraries - especially for things like CSV/Excel file handling.

So I'll use Node-RED both as a prototyping platform and as a live platform because I'm too lazy to faff with all the boilerplate code likely to be needed to stand up even a simple microservice using Node.js or Python.

But of course, for many, people, it is the simplicity of the node-and-wire based approach - avoiding code completely - that attracts them.

And for all of us, having access to thousands of specialist nodes that wrap up a level of complexity, makes life very easy. This is one of the reasons that I wrote UIBUILDER. To hide most of the complexity of dealing with the DOM and with 2-way, realtime communications between the client and the server. But without having to commit to an equally complex front-end framework with all its own quirks and issues and that takes you away from learning about vanilla HTML/CSS/JavaScript so leaving you at the mercy of the development of the framework. UIBUILDER is therefore, I suppose, like the function node of web development in Node-RED. 😀

Anyway, coming back on-topic. BOTH custom nodes and function nodes have their - well defined - place in the Node-RED universe.

However, what I would say, now that I've a number of complex custom nodes under my belt, is that developing nodes, while fairly straight-forwards, is _time consuming_, very time consuming in fact. And on this note, I've been playing with some ideas on how the time and complexity to create custom nodes could be reduced. See some of those ideas taking form in [An idea for third-party UI in ui-builder - Developing Nodes - Node-RED Forum (nodered.org)](https://discourse.nodered.org/t/an-idea-for-third-party-ui-in-ui-builder/83196/4). Where I start to try and go beyond uibuilder to think about how the experience could be improved for all.

Anyway, that is a different topic so I'll stop here.

---

_[View the full topic](https://discourse.nodered.org/t/best-practice-custom-v-function-node/83222)._