That's all useful feedback to us. There's always a balance to be had between putting lots of code in Function nodes and the visual complexity of doing the equivalent in pure nodes. Part of that is understanding where users are falling back to JS in a Function node - and what could the core nodes provide to avoid that necessity.
Code reviews are a common piece of feedback and something we need to help with.
In the day job (FlowFuse CTO) we're looking at how to improve the overall developer UX of Node-RED - both within node-red, but also how you manage it within a team and at scale.
If you had any more feedback on your experiences, would love to hear it.
As ever, I think each has its strengths and weaknesses, but I know which one I prefer...
In terms of 'out of the box' experience, I do agree there is space for some improved Node-RED nodes to support some of these workflows. There certainly are nodes in the community to help, but there's space for more. And that's an area I think gives Node-RED an advantage; the open source nature that allows anyone to build in the gaps of what's already there. Node-RED provides plenty of low-level building blocks to connect with pretty much anything - but having higher level abstraction nodes is needed to make it more accessible.
It's also an area we're looking at in my day job (FlowFuse CTO) where we provide a commercial platform built around Node-RED.
Given Node-RED is intended as a low-code programming tool, hand-writing the flow JSON has never really been a requirement - certainly not one I can recall being brought up in the community. It's certainly possible to generate flow JSON via other means as the format is not hugely complicated once you know the format.
It's an array of objects, each representing a 'thing' in the flow. Each object has a unqiue id (which can be any randomly generated value), and other meta data that defines what the object is and what its configuration is.
Given most nodes have been implemented with a graphical UI in mind for configuring the nodes, you'd have to refer to individual nodes to understand what node-specific properties they require.
Node-RED project creator here. The company is FlowForge and we're creating an OSS management platform for Node-RED. We just made our first release public.
(Node-RED project lead here) Some great questions, and not necessarily short answers.
> What are the flaws of Node-RED? The areas that you plan (or hope) to give many, many necessary love somewhere in the future?
It works really well as a single user system. One of the areas I really want to improve is the multi-user/collaborative features available in the editor.
You can certainly have >1 users editing the same flows in parallel, but you do end up having to merge back in each other's changes. That user experience isn't ideal.
I'm also keenly aware the documentation and getting started experience needs attention.
> What is something people use the software for, where you would say they should not do this?
I wouldn't tell someone not to use the project if they had found something that worked for them. As with any solution, you need to make sure it satisfies your needs and requirements.
I would say you need to acknowledge the limits of the system - partly born of the single-threaded nature of the underlying Node.js runtime.
> Is there any ability (or plans for them) to use it locally for desktop-automation, similiar to AppleScript & Automator on MacOS, shell & batch-scripts, Selenium for websites, Tasker on android, etc.?
It isn't something we're thinking about in the core of the project. But the project is designed so that this could all be done via 3rd party nodes created and shared by the community to integrate with those tools. In other words, this sort of integration could be done by anyone - it doesn't have to be the core project that does it.
> How would you see the state of the project generally and feature-wise ?
There's always more to be done.
> Should it reinvent itself every some years and stay fresh and adapting
There's a risk for all software projects that continually reinvent themselves that they sacrifice their existing community in search of something else.
A core principle we have is stability. That doesn't mean stagnation, but it means evolving in a considered way that brings the community with us and doesn't leave users stranded because they depend on something that has since been 'reinvented'.
(Node-RED project lead here) Node-RED is an open-source project and part of the OpenJS Foundation. We'd certainly aspire Node-RED to be comparable at a technical level with other offerings.
But as an OSS project, we aren't looking to create a hosted SaaS offering - the core project isn't trying to compete commercially with those vendors.
But there are companies looking to create commercial services around Node-RED that certainly want to be competitive. (My own company, FlowForge Inc, is one of them)
(Node-RED project lead here) There are a few nodes for dealing with swagger in Node-RED - either generating Swagger doc for your HTTP end points, or on the client side to make it easy to interact with a Swagger documented API.
If you're looking for something that can take a Swagger/OpenAPI doc and generate a stubbed-out set of flows - that would be a neat idea. Sounds like a cool project to create as a pluing.
(Node-RED project lead here) It is not at all limited to prototyping. There are an ever-growing number of companies incorporating Node-RED in their own products and services - you can see a list of some of them on the project homepage.
They span a wide range of industries and technology areas. Quite a few are industrial controller companies who include Node-RED on their commercially available edge devices.
The flow configuration is stored in a JSON file. That can pose challenges when it comes to getting meaningful diffs.
That said, we do have the Projects feature that brings version control (backed by git) into the editor. And when you view a diff of a flow, as we know what it is, we present a structured visual diff of the flow contents, rather than the raw JSON diff.
That's how it started, but it's now an independent project of the OpenJS Foundation. And it isn't limited to IoT - it can be used for any event driven application.
(Disclaimer: I'm the creator and project lead of Node-Red)
The issue template we use does try to steer the user to the forum or slack if it isn't a specific issue. But if they don't read the template and continue to raise an issue regardless, we will generally provide help in the issue and encourage them to use the other channels in the future.
One of the main reasons we prefer the general support type questions to be handled on the forum is the community on the forum is much larger than those paying attention to the github issue list. Someone asking a question on the forum will get a response much quicker than the issue list. It also takes the pressure off the core development team who ultimately, are only human.
Yes we could use labels and have the issue list as a mix of support, feature development tasks and genuine bugs. But we choose not to use it that way.
Hi - would like to hear what bugs you reported to no avail. There may well have been good reason they weren't addressed to your satisfaction - or we may have simple not fully appreciated what you were reporting.
Hi - project maintainer here. Always keen to get feedback, so interested where your 'not commercial-ready' comment comes from. There are quite a few companies using Node-RED in production today within their own products and services.
Hi, project maintainer here. I'm sorry you had that experience - do you have an example of this?
We get a lot of questions raised that are better handled on the project forum, slack or Stack Overflow, and try to ensure the github issue list is kept as genuine code issues rather than general support questions. That can be misinterpreted, but it isn't our intention.
That's all useful feedback to us. There's always a balance to be had between putting lots of code in Function nodes and the visual complexity of doing the equivalent in pure nodes. Part of that is understanding where users are falling back to JS in a Function node - and what could the core nodes provide to avoid that necessity.
Code reviews are a common piece of feedback and something we need to help with.
In the day job (FlowFuse CTO) we're looking at how to improve the overall developer UX of Node-RED - both within node-red, but also how you manage it within a team and at scale.
If you had any more feedback on your experiences, would love to hear it.