Live data from Hacker News

PyFlow – Visual scripting framework for Python – NodeRED alternative?

github.com

11–20 of 54 posts

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#12
post #9

Very cool. We're designing an open source automations engine for Kubernetes ("Zapier/IFTTT for devops") and have thought about adding a UI for automating stuff visually. So far, simple YAML configurations have won out and we're still debating the benefits of a UI. Does anyone have experience using tools like this at scale or for technical domains? (E.g. devops.) Would love to hear a convincing case why a UI is better…

Look to HomeAssistant, where there is a lot of both YAML and NodeRED. I am hoping there could be a Python alternative to NodeRED build into HomeAssistant, to make it easier for beginners.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#13

Interesting, came across https://ryven.org/ recently which looks in the same domain. Any practical use cases of either being used? Huge fan of NodeRED, always thought the paradigm could be leveraged for other heavy workflow applications

A lot of users is using NodeRED for home automation within HomeAssistant.

HomeAssistant is build in Python, so this could be more included part of HomeAssistant.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#14
post #9

Very cool. We're designing an open source automations engine for Kubernetes ("Zapier/IFTTT for devops") and have thought about adding a UI for automating stuff visually. So far, simple YAML configurations have won out and we're still debating the benefits of a UI. Does anyone have experience using tools like this at scale or for technical domains? (E.g. devops.) Would love to hear a convincing case why a UI is better…

Look to HomeAssistant, where there is a lot of both YAML and NodeRED. I am hoping there could be a Python alternative to NodeRED build into HomeAssistant, to make it easier for beginners.

Cool, thanks

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#15
For something like this to be successful, I think it has to have some kind of domain focus. I've been working in bioinformatics-adjacent jobs for the last couple decades and I've seen things like this get used when there were a lot of integrated, domain-specific tools. Even then, the users were a curious slice of the population that could think like a programmer, but had not bothered to learn a language.

It also has to have a lot of buy-in and support. As everyone here is fully aware, a lot of problems get solved by Googling for a Stack Overflow answer. That's tough to do with a niche-y tool.

Not saying this isn't a good thing; it's just that it'll be difficult to be successful as a general purpose tool.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#17
post #10

Is it just me or are these things harder to write, read, understand and modify than plain old code?

Like comparing Word to Latex. Latex is faster when you know it.

I don't think that is the primary benefit of latex.

Latex is exceedingly expressive and lets you be very precise about exactly what you want on the page and how it is typeset - much more so than Word is capable of. This comes at the cost of learning the language, which isnt user friendly - e.g. I've never had a word document that didnt compile.

Turing complete code, by contrast, demands a high level of language expressivity to do everything beyond the most basic tasks.

Using a GUI to write code becomes like using Word to professionally typeset a an academic textbook very, very quickly.

So quickly I'd argue that there's almost no point even starting.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#18
post #9

Very cool. We're designing an open source automations engine for Kubernetes ("Zapier/IFTTT for devops") and have thought about adding a UI for automating stuff visually. So far, simple YAML configurations have won out and we're still debating the benefits of a UI. Does anyone have experience using tools like this at scale or for technical domains? (E.g. devops.) Would love to hear a convincing case why a UI is better…

I think the key here, as a responsible developer, is ensuring isomorphism between the GUI representation and the generated code. To the extent that the development method could be swapped without repercussion.

Most GUI tools, presumably in speed to market, skip this. But as soon as you've created something that can only be viewed & modified in a visual editor... you've become part of the problem.

So I'd approach this from a "If my tool is successful, and users use all the editors we give them, what will their support story for a 10 year old codebase look like?" (If you care about the greater good)

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#19
I tried a pyflow a couple years ago. It was very confusing and not intuitive at all, which is what I think one of the biggest advantages of these types of GUIs is supposed to be. Doing simple things like adding inputs and operations to the graph were very difficult.

I ended up developing my own tool based on the flowchart editor in pyqtgraph. The GUI for that was quite intuitive and the code to modify it was also far simpler. That said there are a few features from pyflow that I wish the pyqtgraph editor had, like subgraphs.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#20
post #18
post #9

Very cool. We're designing an open source automations engine for Kubernetes ("Zapier/IFTTT for devops") and have thought about adding a UI for automating stuff visually. So far, simple YAML configurations have won out and we're still debating the benefits of a UI. Does anyone have experience using tools like this at scale or for technical domains? (E.g. devops.) Would love to hear a convincing case why a UI is better…

I think the key here, as a responsible developer, is ensuring isomorphism between the GUI representation and the generated code. To the extent that the development method could be swapped without repercussion. Most GUI tools, presumably in speed to market, skip this. But as soon as you've created something that can only be viewed & modified in a visual editor... you've become part of the problem. So I'd approach this…

I like this. SaaS platforms typically don't want to do this precisely because it limits vendor lock-in, but I think it's the right approach.
Post reply on HN