If you disable the editor in settings.js I believe the overhead caused by editor reaources, like the websocket connection and server routes for static assets, will be removed. Would need to confirm in the code. However, I dont believe it would make any significant impact to memory and cpu usage.
Unreal Blueprints have the same issue, even when compiled to byte code. Epic recommends developers to switch to native language for areas that require speed. They implemented a feature that turns a Blueprint into native code. Maybe this could be implemented too for Node-RED/Edgelink
This touches on a point I've made many times in the past. Just because you have a hammer, does not mean that every problem is a nail.
Anything needing serious performance in a production environment should be written in other ways. Though prototyping the logic in Node-RED - absolutely. Thankfully, Node-RED is so good in the interfacing department that integrations between it and other microservices remains trivial.
Personally, I would love for someone to write a Node-RED look-alike in Python. Not because I think it would in any way be "better" but simply that I see that Python has taken over a number of professional sectors such as analytics, data science, etc and it totally lacks a fantastic tool like Node-RED.
1 Like
Again, we've come full circle: only using keyboards and much text can be we get any kind of performance out of CPUs and RAM. Punchcards offer perhaps even better performance, assembler is the best.
That these sentiments are presented in a forum that is about visual programming is crazy. What we should be thinking about is how to get the performance from visual programming that we believe and expect is only possible when code is written textually.
Why use visual programming in the first place then? Oh, only to prototype something. Well then do it in text in the first place. Because that is a massive waste of time. If you create first visually and then textually, massive source of errors and bugs. Use pen & paper but not Node-RED to prototype your ideas. UML is also good for that.
Instead why not think about how to get the benefits of both worlds? How can that be done? Those are the interesting problems to be solved and not "oh, visual programming can't be used in production because it will never have the "performance" of textual code".
Also what "performance" are we talking about?
The performance of the team working on finding a solution to large problem. A team that is inter-disciplinary where not all can understand the solution created in textual representation fed to a computer. <<--- here the performance gain would be obtained using visual programming
Or are we solely talking only about faster, higher, quicker - "apparent efficiency" in terms of computer cycles. <<---- here performance gain would obtained using assembler
Premature optimisation also happens when having ideas. Avoid that just as it should be avoided when telling computy what to do.
EDIT:
Perhaps what could be helpful is to think about high-level languages and what happens to them. A CPU does not execute Rust code. A CPU does not execute C code. A CPU executes compiled assembler code. Even assembler is a human friendly representation of the stuff that a CPU understands.
So how does Rust/Python/Erlang/Go/List/Prolog/Schema/Java get executed? It gets transformed, step by step, to the stuff CPU can understand. Along the way, optimisations are made by the compiler (be it a JIT, i.e. interpreted language, or C-like compiler that generates a single binary) to make the code more "efficient" and "performant". We all agree and accept that no one here wants to be writing the stuff that CPUs really understands, so we have these abstraction layers.
We are so used to having these abstraction layers represented as text. We can't imagine an abstraction layer that is actually an image. The last abstraction layer that wasn't text was punch cards.
Now imagine Node-RED being just another abstraction layer. A visual abstraction layer, not text. Don't think about the Json representation of a flow, think of the SVG representation of the flow.
Now the problem becomes: how to optimise the visual code so that we end up with the "best" performance. Well lets practice some compiler theory and see how they do it. After all, they have been doing for over 60 years, there must be something there.
Sorry, going to have to somewhat disagree here. It isn't crazy at all. There are lots of compute tasks far better and more efficiently done with text rather than visual interfaces. Indeed, it is extremely common to start with visual and eventually compress to text and some logic is far more easily expressed in text than visually.
The two are complementary. Yes they overlap. Yes we absolutely should always be looking to improve both.
Again, I'm afraid I must disagree. And to be clear - this is not about some fundamental principal. Computing must meet the needs of PEOPLE - and people have many different ways and styles of thinking. Some think best visually and others think best through language (think visual arts vs poetry for example). For different people and different tasks, some things may be better expressed visually and some better expressed textually.
Using Node-RED as a platform allows BOTH visual and textual designs which is a massive bonus. It provides a quick start to many projects and is certainly my go-to platform for many tasks.
But it inevitably has an overhead because of its flexibility. This is not a criticism, it is a simple reality. Yes, we all want to minimise that overhead but by definition it can never be as "Efficient" as something custom built for a single purpose. But for a great many tasks, that doesn't really matter at all.
I am very much hoping you are exaggerating for effect here. 
In my experience of moving from visual to textual programming, I find far fewer errors. But I don't do that all that often, usually when the visual part has gotten out of hand and is no longer useful because the logic cannot easily be followed due to complexity. Of course, there are different ways to deal with that issues - some visual - but for me personally, compressing many visual nodes/wires into compact and well structured (and commented) code generally works best. Others will want different approaches.
Again, for me, pen/paper is a write-only medium. Good for a quick ideas session but a pain for anything longer term - where DID I put that bit of paper! And why is it covered in crossings-out! And UML may be useful for formal logic but it is mostly useful in team/enterprise settings, it just gets in the way of thinking when working alone. (remember, this is just my approach - others WILL think differently).
Less formal block diagrams using something like Excalidraw in Obsidian is often all I need for something visual.
As already mentioned. Both approaches have their uses and limitations. And also as mentioned, if we are talking about Node-RED (which we largely should be on this forum ), a generic (and immensely useful because of that) platform is far less likely to have proven scalable performance. Robust, certified security and privacy. Etc. Node-RED carries a lot of weight and complexity so you don't have to. That's great but of course it will have its own issues. No matter how much great people continue to work on it and continue to narrow those overheads, that will always be a potential issue for some use-cases.
We are talking about runtime performance. The need for predictable and scalable resource utilisation that is absolutely required for large-scale, enterprise systems.
Indeed. Some design/development tasks can indeed be done a lot faster visually and a tool that allows both visual design and direct execution (AKA "modelling") is incredibly useful in some cases.
But that doesn't mean that ongoing execution of that model is best kept in the generic visual tool. In many cases that might be fine. It will depend on the circumstances and requirements. In other cases it would not.
You seem to be trying to reduce this down to a binary thing. This is NOT binary. It is complex. One size most provably does not fill all requirements.
As an Enterprise Architect with over 40 years experience - starting with punched cards - I can assure you that it is my professional job to understand these things and recognise the strengths and weaknesses and be able to match the technology to the business requirements.
By all means, lets do that!
But please lets remember that visual is not for everyone. We haven't even begun to talk about accessibility. That is another area - and, I should point out, a LEGAL mandate in many countries. Is Node-RED accessible? Nope.
Even aside from that, is everyone a visual thinker? Nope.
There is room, and need, for both.
Doesn't doing the same thing for 40 years give you a certain amount of tunnel vision? Ever used a Mac? Ever written a song? Ever done something illegal? Ever been scared because you thought you might lose everything? Experience real terror? How does doing the same thing for 40 years give you a broader range of experiences and be able to better judge "these things"?
I don't quite understand. How does that give you better insights into these "things":
Ok that's great. But what are you arguments:
FUD - Fear, Uncertainty and Doubt. Be scared, be very scared.
Could there be a solution tomorrow? Text can be easily understood by the blind? Well thanks to braille it is. Someone had to invent that. So it is with visual programming. A solution needs to be found ok. For some countries. Ok. And?
Yes I know, is that your insight? What is your point? Yes we need both, like this:
Or not like that because that is Node-RED template node.
Ok is its complex. And therefore it can't be done? Therefore don't bother. Ok that's a good argument, convinced me.
"It's complex" until the bombs drop. Suddenly it becomes very simple. It's complex are the current arguments for everything. Why no peace. Why western societies are in decline. Why there is a right wing resurgence in western societies. Yes it is complex.
Nope, that is the whole point of being an Enterprise Architect. I was a consultant and contractor for a long time, always moving to new organisations and new requirements, understanding their business needs and fitting architectures to those needs. You can't be in this job for any time at all if you cannot adjust to changing tech and changing business needs. I LOVE IT!
Yes - in fact, I have Windows, Mac and Linux devices here in my office. And I've worked on Mainframes, mini-computers, and many different OS's. I've worked on maybe 2 dozen different computer languages ranging from assembler through to visual coding and everything in between.
Yes.
I will plead the 5th on that one!
Yes, several times, not only financially but physically close to death as well.
I most certainly have - quite a few times having done various dangerous sports, some extremely dangerous (read stupid) driving.
What made you think that I've done the "same" thing for 40 years? Not at all. For several decades I've had to cut things out of my CV when applying for roles and I've done most roles in the tech world across a very wide range of organisations in several countries.
Now you are deliberately ignoring what I've said.
What are you saying? It's complex.
What? What is complex? Why is it complex? Where do you see the complexity?
I literally saw no sensible approach to other than "both have to co-exist". That's it.
My explicit point is that is is possible to add a new abstraction layer above the textual ones that already exist and you're argument is: it's complex and not possible. And then there are the LEGAL constraints. FUD alert on that.
Quintessence: Don't do anything. Move along, nothing to see here.
That's how we make a better future by keeping the old and claiming it cannot be done.
I explicitly dislike arguments that end with "its complex".
And? It's hard. And? Isn't that the challenge? Just do It - even Nikes knows what to do with its "complex".
For me, when someone says "its complex" they are really saying: "I can't imagine a solution". That's my 40 years experiences so that makes it ok to see it that way.
EDIT:
Ok, I now think that's the point: you're argument is that it can't be done. And that's it. That's what you're are essential are saying. Ok. Then you've convinced me if you can answer this question: why is it not possible? What is the fundamental universal limit that won't allow a visual programming language to ever outperform a textual representation of a solution for a problem? What is the 'C' (speed of light constant) that prevents us from breaking through that barrier?
If you can name me that, then I will stop arguing for a complete visual approach to programming. These arguments:
- "Its complex"
- "They (textual and visual) have to co-exist"
- "LEGAL issues"
- "Not all people are visual thinkers"
Aren't doing it for me. Please be a bit more specific. Especially as none of those are actually against what I'm saying: that it is possible but not quite yet there, just need a few more tools.
Maybe there is some kind of fundamental impossibility that I'm missing and you know about - I don't see it.
It is time for a fine tuned (LoRa) LLM model that can convert our beautiful flows to any language and compile them to any target and language we want and compile by clicking the deploy button :')
Just watched a video of someone creating a webserver in pure bash without external tools - quite a challenge, but it worked quite nicely, out of the box thinking, love it.
2 Likes
Just starting to get my head around offline LLM's - I came across Clara AI Assistant that wraps up a number of AI tools. I'm struggling at the moment, to understand which models to use for offline use.
