knolleary
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.
It's also what we're working on at https://flowforge.com
(Disclaimer - I'm the co-founder of the Node-RED project, and CTO/Founder at FlowForge)
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.
> 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'.
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)
For example: https://flows.nodered.org/node/openapi-red
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.
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.
Still an area I'd like to improve.
(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.
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.