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)

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.

> 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.

Why is that? You don't view the bytes your text editor generates do you?

ASCII and Unicode are standards. Presumably OP isn't building a tool with enough market share it's going to have an international standard encoding.

What you end up with, if you don't have a standard, and you don't maintain isomorphism... is user "code" that requires a vendor tool to view & modify.

Which sets up some really screwy incentives & business models.

A thing you built. That you paid for the tools to build. That you have to continue paying for, otherwise you'll be unable to guarantee maintainability.

Charge for execution if you want! But IMHO user developed code, in whatever format, deserves to be owned by users. Even if they decide to no longer be customers.

> ASCII and Unicode are standards.

Right, and those didn't just materialize out of thin air. They took time and effort to develop. My point is that we shouldn't keep shooting down visual based tools and languages on the notion that there aren't standards, because there isn't anything (besides preconceived biases) that prevent them. There are many things that text is just not good at describing, such as dataflow, and by claiming everything must be text and isomorphic to text, we're holding things back.

I'd be more sympathetic to this idea if I hadn't seen the tactic executed repeatedly over the last 10 years to ensure vendor lock-in, which ultimately burns the end user. And/or requires them to insecurely freeze a portion of their IT infrastructure in time.

And honestly, if your GUI/designer is standardized, then it's trivial to define a stable serialization to and from text anyway.

You only need to sympathetic because you have let yourself become jaded by your anecdotal experience.

It didn't feel anecdotal when I was the one trying to modernize systems like these in the face of vendor apathy (or active hostility) and business resistance to change, because they had 10+ years of legacy "code" built in these things.

So every other software project for every business ever? Got it, still anecdotal data

Ah yes? and diff, track, and version the bytes with tools like git. Or perhaps I’m misunderstanding the question here?

YAML parsers don’t read the bytes or the GUI. They read the text.

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.

And Home Assistant itself is python so it may be a better fit than the often used NodeRed which is JS based.

Cool, thanks

We ended up using Puppet Relay quite a bit, which is sort of a halfway house between the two ( visual editor, but yaml backed with low code instead of no code).

The main advantage from my side was being able to get adoption from a wider group of people. This included both very junior technical folk who were able to take on more complex tasks than they would have been able to otherwise, and non technical folk who found starting with the UI a lot less intimidating.

Eventually, almost everyone has gravitated to using YAML over time but I don't think I'd of seen the adoption internally that we had without the UI component.

Mileage will vary though. If we had been at a more technically mature place when adopting relay, then I reckon the UI would have seen a lot less use.

Heyo! I used to do a bunch of work for a major SOAR player. I think the biggest benefit to tools like this is that it greatly reduces complexity and barrier to entry into automating various tasks allowing the SME’s that may not know how to program, to automate away their pain points with less risk of things being lost in transition while communicating with developers who may not be.

I know yaml isn’t difficult per se, but being able to visualize it can be beneficial for those that don’t normally think programmatically.

Also bonus points - the diagrams from the flows make great process diagrams for your documentation.

Having worked on a flow based UI for a few years, I would say it very much depends on your core use case and the “standard library”. Since you’ll probably be making a DSL of sorts, there is a balance of simplicity and flexibility.

It really shines in the ETL area. Configuration and generation would be alright.

You can get an idea of where I got with js at [fluxion.app](https://fluxion.app).