[slightwinder]

What are the flaws of Node-RED? The areas that you plan (or hope) to give many, many necessary love somewhere in the future?

What is something people use the software for, where you would say they should not do this?

Node-RED seems so far optimized for IoT and online services. 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.?

How would you see the state of the project generally and feature-wise ? Is it still growing for the next decade? Or has it reached it's peak and will move to settle down at its optimum somewhere in the next years? Should it reinvent itself every some years and stay fresh and adapting?

[knolleary]

(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'.

[zeroflow]

I can on reply from the perspective of a multi-year user:

It is primarily functional programming. This means, you have an input, that is processed through blocks (functions) and does some things.

This is GREAT for things similar to IFTTT (If this then that) applications. E.g. you receive a datagramm via MQTT, and then format it, add some info, and upload it into influxdb.

You can also easily add a small dashboard with some buttons and labels for easy home automation.

What needs some working around with context store are side effects, or persistance. I have two examples that can be worked around, but are rather hacky:

1) Reading a list from a homepage, and only sending updates for new items. This is the prime example for context - you save a list of seen items in the context of the function node, so the next invocation can filter out the existing ones

2) Using a switch in the dashboard for selecting between automatic and manual mode. E.g. I want to have my rack fans controlled by the temperature, but with an override to set it manually. This needs a bit more hacking with context where you have two flows into one node, and you have to set the internal state of the context depending on the override button.