kristopherleads

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!

I'm at the point where I might start professionally using a voice changer. I mean what in the world, my guy?

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.

It’s time we stopped making them wait.

Read more: https://kristopherleads.substack.com/p/heres-a-hot-take-for-...

Don't we already have this in HTML5?

Funnily enough, I only use the phone bumping feature when AirDrop is broken and won't detect I'm literally right next to my spouse.

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.

So let’s talk about that.

Hey all,

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 recently did a video highlighting the release - you can see that here https://www.youtube.com/watch?v=Osgli5cdWPY.

Try it out, and let us know what you think!

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.

What's the inclusivity reasons? I'd be interested in understanding a bit more about that.

This is o-fish-ially my favourite post on HackerNews today.

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.

Is open-core a sub-genre of post-hardcore? I generally prefer midwest emo, to be honest.

Some might argue this confusion is intentional and injected by people trying to obfuscate that their fav is in fact not open source.

Full disclosure, I'm incredibly biased here as I'm a DevRel at FlowFuse, but there's a reason I joined them instead of n8n. On the surface they're comparable, but I think Node-RED (and FlowFuse) is a better solution for a lot of reasons:

First off, Node-RED handles real-time event data much, much better in my experience. Because of where Node-RED came from, there's much better support for IoT, MQTT, Modbus, OPC UA, edge protocols, etc. n8n is much more limited in this regard, and the fact that the Node-RED and FlowFuse community has literally thousands of custom nodes makes the calculus pretty clear.

I also think that FlowFuse/Node-RED has better integration of AI workloads. In theory n8n is designed around AI, but it treats it the same way OpenAI's AgentKit does - as sort of opaque connections. FlowFuse/Node-RED instead treats it as an actual message payload (both in terms of how you connect to the APIs and how you interact with what's generated), so instead of throwing your request into the void and hoping for the best, you can control every minute part of the flow.

That also makes for much more transparent debugging and visual data flow - the whole idea of these low-code environments is to give you the same control as high-code without the headache. Abstracting that away too much gives you less control, which is sort of the antithesis of this approach.

Like I said though, SUPER biased here.

What makes it feel harder to you for non-technical users? I'm a huge fan - it's what brought me to them to do DevRel stuff - so I'm really invested in making sure that the onboarding/use pathway is really clean and well laid-out.

Love to hear you love using Node-RED!

That package looks pretty cool! I'll check it out - I'm super in the weeds today with a flow so I'm in deep-dive mode.

It definitely can! Full disclosure, I'm a DevRel at FlowFuse, so I'm definitely biased here - but there's quite a lot of support for AI workflows, from lightweight automation to fairly complex pipelines.

For example, I'm currently building a flow that connects device monitoring data to a central reporting structure, compares the incoming values against internal spec docs, and uses OpenAI to summarise overall operational status and any drift/out-of-spec issues. The summaries (along with the raw JSON objects) are then sent over MQTT for multi-site compliance and operations. Once you map it out, it's surprisingly straightforward to build.

What makes Node-RED and FlowFuse stand out on this particular use case IMO is that AI flows get treated just like any other message payload. That means your AI output becomes a first-class data object in the system - you can remix, transform, mutate, or extract from it the same way you would any other JSON payload, making it pretty portable and easy to integrate.