Separating Delay into Wait and Throttle nodes improves clarity, reduces user errors, and makes flows self-documenting, while each node’s icon reinforces its distinct behavior.
This would need to be 2 totally separate extra nodes (which could as easily be contrib nodes), with the delay node staying as is so as not to break existing flows.
We could not remove the delay node until at least NR 6.0 (assuming it was deprecated as part of NR 5.0)
Without having telemetry on who uses the current node in each configuration, it would be highly disruptive at least to make this change. Certainly I couldn't tell you whether I'm actively using that node in either config even in my own flows.
Having to open a node's config to see what it does is hardly confined to the Delay node.
It is of course possible to change a node's name but if we can't indicate it's function in a reasonable number of characters, we can now see a badge when a node has a description.
Rather than creating new node types, would it be useful to tweek the recent "has description" badge so that it displays a tooltip on hover?
The tooltip could be restricted to show only lines from the description which use the h1, h2 or h3 buttons:
It is fine if it is released in v6.
Another issue I found is related to the Trigger node. Its name is confusing because other nodes also trigger flow branches. A better name would be "Pulse" or "Signal". You can fix this in v6 as well.
To be clear, this is not a commitment, it is purely stating what the minimum timeline could be to remove a deprecated delay node (and that is assuming we choose to remove the delay node and not just keep all 3), the additional nodes would need to be available and have large amounts of community buy in long before then we ever decided to deprecate.
And we would still need somebody to create these extra nodes (which as mentioned could be contrib nodes to test them out before they are potential adopted by the core team).
Also this is in no way meant to suggest that the Delay node can not be improved to make it easier to use or to show how it is configured
Full disclosure I have a strong emotional attachment to the Delay node, as it was the first node not written by the core team (Nick & Dave), but by me....
No problem. I know how it feels.
Even if it was ever deprecated we would probably leave the existing one there but hidden somehow as we still don’t want to break flows if we don’t have to. The original delay node was enhanced to add rate limiting early on as it was all considered to be just “shifting the message in time” so it seemed sensible for them to be together. I guess the icon could be changed to be more representative based on the current mode - but the text/label clearly identifies it imho.
PS there is already a node-red-contrib-throttle if you want to use that instead.
Chatgpt and Claude Sonet 4 think like me. I see the same reasoning and maybe it is because I only have less than a year using node-red. This is a UX test that that guy working for Flowfuse could run to prove this hypothesis
I cant upload the last print. So this is its conclusion.
"Naming Confusion: "Delay" really only describes one of the two functions accurately.Your preference actually reflects standard practices in many other systems. For example, in programming frameworks, you typically see separate functions for sleep()/delay() versus throttle()/rateLimit().
The current design might have been a pragmatic choice to keep Node-RED's palette smaller, but from a pure design standpoint, your instinct for separation makes perfect sense. It's good design intuition, not bias!"
Maybe both AIs are just being "sycophantic" even when I asked non biased questions. Can't be sure.
They both argue they could be separate - or could be combined. It is a design choice… we chose to combine them. Both options are right. Currently the humans are in control…
After I asked Claude to be honest it agreed with the current design. Now im not sure if it was really being "honest" or if it decided to follow my instructions literally.
So... forget about this proposal 
But if you have capacity to test my hypothesis with users (new and experienced) it would be better
They try to please, and are indeed led by the questioner.
Yes 
I saw that a kid killed himself because of what chatgpt was saying
I asked Claude if it was being really honest or just disagreeing with me because I asked it not to be sycophantic
Personally, I really enjoy working with compact and clean palettes. For me, splitting this node doesn’t add much value— in fact, it can sometimes make it harder to locate the right one quickly. I find that the node descriptions already provide enough clarity about their function, so extra separation feels a bit unnecessary.
P.S. AI is a great tool for many things, but be cautious with its reasoning. It doesn’t actually think—it just generates the most satisfying response based on the prompt. So always use your own judgment and critical thinking when interpreting its answers! 
"Danger, Will Robinson"!
When you ask any of the current generation LLM's whether they agree with you, they pretty much always will. This is because they are programmed to PLEASE, not to give an objective answer.
I'm not even sure that the current gen models CAN be honest. There seems little evidence that they can.
That doesn't make them unuseful. But it does make them dangerous, especially for opinions.
That doesn't make them unuseful. But it does make them dangerous, especially for opinions.
A statistical word generator can not have an opinion
An AI model is a little more than that. But, no, it does not have innate opinions, but it DOES express opinions. Once that it has synthesised from online texts and ones that are statistically likely to make humans come back for more interactions.
When you ask a model for an opinion, it will certainly generate one. It doesn't really matter whether it "has" them or not. 
@AllanOricil If you had included the actual text, I might have been temped to see if would agree with itself or not 
PS - You already persuaded the team to "break" the click outside node to close and save Grrrr
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
