Node-RED: Low-code programming for event-driven applications

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

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

Just a massive fan, that's all. You've changed the world.

This software is great on the esp8266 and esp32 series of microcontrollers for those who like to tinker.