Show HN: Flowcode – Turing-complete visual programming platform

> In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code

I completely agree but I think that's a very hard sell. People who write code are often years deep in their preferred workflows and asking them to reconsider how they build things is a very big ask.

> Even if developers prefer textual code when on their own, when they're working with non-developers (product teams, clients etc) there's a big benefit for being able to share and present how things work.

The problem here is that developers lead implementation. The ideal implementation for a stakeholder is rarely the implementation that is delivered, because developers are taking requirements and translating them into the things they want to build. That's why so many products end up bad: developers have too much power by virtue of code being seen as some sort of magic spell that only a true genius can master. Can you imagine a non-technical person successfully dictating that the solution must be built with visual programming?

Low code / no code is powerful because it turns the relationship between product owner and developer on its head, it puts the product owner back in the driving seat (instead of a passenger begging the developer to go in the desired direction and accepting they'll probably end up somewhere... nearby, hopefully). Hiring the wrong developer(s) can be very bad for a company because of how much a developers choice's influence the product and business.

The proliferation of low code / no code in business often comes from outside engineering, many developers, regrettably, love to write code. Often you'll find that non-technical departments of companies have secretly started using things like Make and Zapier and n8n without telling the engineering department because they feel like they finally have the opportunity to make technology work for them.

Developers that exist in service of product are already using platforms like Make and Zapier and n8n because they understand how much value there is in programming without writing code, but for them visual programming probably isn't that much of a differentiator because they already have a vision in their head of how programming works.

Anyway, your product is great, I am sure you'll succeed regardless of the approach you take :)

"No one wants to write ifs, fors and whiles as connected nodes"

For what it's worth LabVIEW presents those structures as container boxes, which IMO works well enough. To put it another way, visual coding has many problems, but when programming LabVIEW I didn't find the representation of control flow to be one of them.

https://labviewwiki.org/wiki/For_loop

OP here.

I'm obviously as biased as one can get here, and have a general sense of agreement with your sentiment, but I think it boils down to 2 aspects: 1. The nature of your code. For a linear, synchronous algorithm, no doubt text is the way to go. For async, concurrency-heavy workflows, debugging it in a linear fashion becomes a nightmare. Take an LLM-heavy backend workflow for example, with calls chained and running in parallel. Horrible to debug using textual code.

2. The experience and features set of the editor itself. Making it reactive and not imperative was exactly our goal. Flyde, the visual-programming language powering Flowcode is a functional-reactive visual-programming language. Control-flow is determined by data, unlike existing tools in that space where arrows represent control-flow and all of the dynamic variables are hidden inside implicit "${{node1.input2}}", making it as far from Unix philosophy as it gets.

Also, Flowcode supports custom code in 3 ways: inline code expressions, custom code nodes (you can even fork any of the "stock" nodes with complete access to the underlying API), and codebase SDK integration, so you could supply it with inputs from your code in a typed way.

> Flowcode is a visual programming platform that tries to combine the best of both worlds (code and visual). Over the years I found myself repeatedly drawing architectures and logic. It was always my dream to just press “run” instead of having to write them in code afterwards. But none of the visual tools I found were flexible and transparent enough for building real products.

Sounds intriguing! ...so why doesn't the website actually say any of this?

When a person visits the site, the only things they can do are log in, sign up, or "get started", without any indication of what they're even getting started with. Can I please know what the product/service is before I have to decide whether I want to try it out?

Thankfully because it loads so much JS I was able to click before it navigated back to the homepage. These are the two examples they link to:

https://app.getflowcode.io/playground/cc12cce1-265f-4c2a-b17...

https://app.getflowcode.io/playground/cc52f949-ec8d-408a-b54...