The latest version of Node-RED, Node-RED 5, has released! This release has some pretty big changes - a brand new UI, additional functionality inside of nodes, and new accessibility features. Also a zoom to fit function - meaning a way zoomed-in or zoomed-out workspace can now be centered with proper sizing, which is a godsend for people working across different monitor sizes.
Let me know what you think! I'm using it as my daily driver and I have to say - huge improvements all around!
Here's a hot take for you: the industrial space needs to be braver. A lot of the conservatism was earned with time and experience - but it's about time for us to be braver in what, and how, we adopt at scale.
Walk into any plant floor in 2026 and you’ll see something that should be shocking - but somehow isn’t. The PLC running the line was likely designed in the early 2000s. The protocol it’s speaking was probably standardised in 1979. The HMI looks like Windows 95 had a baby with a calculator. And somewhere in the back office, a tired controls engineer is gluing it all together with VBA and ladder logic - and, probably, hopes and prayers.
And this isn’t a story about technical debt. Technical debt implies a deliberate trade-off - you took a shortcut, you know about it, and you’re planning to fix it. What we have in industrial automation is something stranger and harder to talk about: a kind of institutional fear. We are not stuck on legacy protocols because they are the best tool for the job. We’re stuck on legacy protocols because nobody wants to be the person who broke the line.
And the worst part about all of this is that the caution I’m talking about has fundamentally metastasised into something much worse - it’s become an excuse. And the people paying the price are not the vendors, not the integrators, and not even the engineers - it’s the end users. Operators, technicians, plant managers, and ultimately the customers downstream who deal with the consequences of systems that should have been retired a decade ago.
The industrial space needs to be braver. Not reckless, not credulous, not chasing every new acronym that comes out of a vendor pitch deck - but braver than the version of itself that has been hiding behind earned caution as a justification for not doing the harder work. I think FlowFuse represents a much braver way forward, honestly - and I think I have a pretty strong argument for that case in this article.
The frontier technologies are here. The new protocols are here. The new providers are here. The end users have been waiting.
I 100% agree with you that in a perfect world the submitter should be doing the review work. But the reality is that we don't live in a perfect world - and just sticking our fingers in our ears and shouting it's not our job isn't going to make data breaches less common or code better quality. Accordingly, if we accept that we can't make vibe coders better stewards (although I absolutely do think we can help in that regard, and I suggest ways to do that in the post), then we have to do our part of improve it somehow.
Vibe coding is in the news these days, and for largely negative reasons. And in many cases, fair enough - vibe coding has been associated with severe lapses in security, both in terms of the products they create and the platforms used to develop them. For many, vibe coding is just not worth what you get from it - and it’s facing huge pushback in dev spaces.
Here’s the thing though - the problem was never the vibe coding. The problem is the approvals process that allows vibe coded content to proliferate unchecked. This may seem a bit of victim blaming, so let me set an expectation here - if you’re looking for a tech bro to tell you that vibe coding is the future and anyone against it is a luddite, that’s not what this article is about. I don’t think vibe coding is the best thing since sliced bread - but I also don’t think it’s the worst thing to happen in development.
What I do think it has done, however, is expose some critical flaws in the way that software - especially open-source software - gets built and released.
FlowFuse has built out an agentic solution for AI-powered flow inspection and development called FlowFuse Assistant - and we just released it to the Node-RED community via an open source node!
FlowFuse Assistant brings a ton of features for Node-RED users, including:
- A function builder
- Function node Code Lens
- JSON generation in all typed inputs and JSON editors (like the inject node, change node, template node, etc)
- Flows Explainer
- HTML, VUE, and CSS generation in FlowFuse Dashboard ui-template nodes
- Context-aware inline and multi-line code completions for functions, templates, and tables
I really think the answer here is human-in-the-loop. Too many people are thinking that AI is a full on drop-in replacement for engineers or managers, but ultimately having it be an augment is the magic. I work at FlowFuse so super biased, but that's something I've really enjoyed with our MCP and Expert Assistant - it's built to help you, not to replace you, so you can ask questions, get insights, etc. faster.
I suppose the tl;dr is if you're generating bugs in your flow and they make it to prod, it's not a tool problem - it's a cultural one.
Was just on a Lufthansa and then United flight - both of which did not have WiFi. Was wondering if there was something going on at the infrastructure level.
I really dislike the focus on graphics here, but I think a lot of people are missing big chunk of the article that's focused on efficiency.
If we can get high texture + throughput content like dual 4k streams but with 1080p bandwidth, we can get VR that isn't as janky. If we can get lower power consumption, we can get smaller (and cooler) form functions which means we might see a future where the Playstation Portal is the console itself. I'm about to get on a flight to Sweden, and I'd kill to have something like my Steam Deck but running way cooler, way more powerful, and less prone to render errors.
I get the feeling Sony will definitely focus on graphics as that's been their play since the 90s, but my word if we get a monumental form factor shift and native VR support that feels closer to the promise on paper, that could be a game changer.
That federation piece is super interesting. I'm actually giving a talk in Sweden this week about machine learning/AI training in the age of data sovereignty, and my suggestion was two-fold - better and more widespread adoption of things like Homomorphic Encryption and more federated systems that can distribute access and data in sovereign systems. This is a pretty important evolution in that direction!
I guess the bigger question is why use two tools when you can use one? Full disclosure I work at Node-RED/FlowFuse, so take that into consideration, but the point remains - if you need to use both an orchestration tool and a flow management/backend management tool, why not use one solution that does both excellently?
I think that's a critical argument that n8n and others will have to overcome - why should users decide to over-specialise one aspect of their stack when they can do so much more and have so much more control elsewhere?
You could, but then you start getting into additional costs, controlling how much of your metrics are surfaced vs. kept internal, etc. At that point, why not just go for another solution?
Like you could make a car like a truck, but why not just buy a truck in the first place?
Yeah, exactly! What's so funny to me is that people who think they want no-code really don't want no-code. Because no-code is built for that - but even novices in coding will really quickly outstrip a no-code native environment, whereas low-code will scale with your learning,
No-code: "I don't need code, this is so easy!" 2 weeks later "I wish I had access to literally any code system to make this work."
Low-code: "I don't need code, this is so easy!" 2 weeks later "Oh awesome I can actually use code here!"
That's how I explained it to someone else recently - a lot of solutions on the hype train right now feel like they're made with duct tape and popsicle sticks.
Well that really comes down to how much control the solution actually gives you, right? I'm a DevRel at FlowFuse, so yes - biased - but something like Node-RED can give you wild complexity or pretty simple flows. I think where other solutions miss the mark is in trying to abstract control away too readily for the sake of simplicity and polish.
It's also just not where the product needs to go. When a lot of users get frustrated and jump back to high-code environments (https://www.reddit.com/r/n8n/comments/1mcm9d2/why_i_left_n8n...), that points to high-friction and not enough control. Iterating in just AI for AI's sake isn't going to fix that.
Let me know what you think! I'm using it as my daily driver and I have to say - huge improvements all around!