TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: Flowcode – Turing-complete visual programming platform

176 点作者 gabigrin16 天前
Hey HN! I’m Gabriel, and I’m excited to share a project I’ve been working on for the last few years. 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.<p>I think that visual programming fits perfectly with modern backend dev tasks that revolve around connecting different services with basic logic. Flowcode is meant to speed up and simplify those tasks, leaving more time to think about design and solve design problems. Visual programming also works really well for developing workflows involving LLM calls that are non-deterministic and require a lot of debugging and prompt tweaking.<p>There are many other visual&#x2F;low code tools, but they all offer limited control and flexibility (no concurrency, loops, transparency) and most suffer from the same problems (vendor lock-in, hard to integrate with existing code etc.).<p>Flowcode is built on an open source visual programming language (Flyde <a href="https:&#x2F;&#x2F;github.com&#x2F;flydelabs&#x2F;flyde">https:&#x2F;&#x2F;github.com&#x2F;flydelabs&#x2F;flyde</a>, which I launched last year here on HN - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39628285">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39628285</a>). This means Flowcode has true concurrency, no vendor lock-in (you can export flows as .flyde files), is Turing-complete (loops, recursion, control flows, multiple IOs etc.), lets you fork any node, integrates with code via an SDK and more.<p>I’d love to hear your thoughts and feedback.

38 条评论

collingreen16 天前
I love your premise here. I think visual programming has such untapped potential even though it has been tried and tried and tried so I hope you crack the code a bit (lol).<p>I think you&#x27;re exactly right on the idea of &quot;I just diagrammed all the control flow why can&#x27;t I just push run&quot;. It&#x27;s kind of crazy to introduce a point of failure (and a menial translation step) by writing code to match the diagram.<p>Another huge benefit that I learned when reading about drakon (obvious in retrospect) is that good visual programming makes the software development process more accessible to other smart people involved instead of locking it away behind computer jargon and tools (the drakon example was rocket scientists able to now work on, review, and validate the logic and control flow instead of having to just hope it ended up right).<p>I hate that I&#x27;m saying this but this would actually make me feel a lot better about the vibe coding going on right now. If the control flow was right, hand crafted, and easy to review I&#x27;d feel a lot better about throwing the implementation details of many individual nodes over the wall to the ai without worrying about the house falling down.
评论 #43831331 未加载
评论 #43830873 未加载
mdaniel16 天前
What is the error handling story? I&#x27;m shocked that Control Flow doesn&#x27;t contain Try-Except<p>Anyway, I ask because Write File returns nothing &lt;<a href="https:&#x2F;&#x2F;docs.getflowcode.io&#x2F;docs&#x2F;reference&#x2F;file-system&#x2F;write-file#outputs" rel="nofollow">https:&#x2F;&#x2F;docs.getflowcode.io&#x2F;docs&#x2F;reference&#x2F;file-system&#x2F;write...</a>&gt; but there&#x27;s also no discussion on that page of what happens when one cannot Write File (and the ways that can fall over are <i>almost</i> unlimited)<p>Also, please fix the inputs bullet list, that&#x27;s a pretty glaring &quot;no one reads these docs&quot; bug. While you&#x27;re there, never, ever, ever, ever, ever just have the documentation for anything be a repetition of the input variable&#x27;s name. I can read, what I can&#x27;t do is know what the domain of possible encodings are available (base64? base85? uuencoding? gzip+base64 &lt;<a href="https:&#x2F;&#x2F;docs.cloud-init.io&#x2F;en&#x2F;24.3&#x2F;reference&#x2F;modules.html#write-files:~:text=gz%2Fgzip%2Fgz%2Bbase64%2Fgzip%2Bbase64%2Fgz%2Bb64%2Fgzip%2Bb64%2Fb64%2Fbase64%2Ftext%2Fplain" rel="nofollow">https:&#x2F;&#x2F;docs.cloud-init.io&#x2F;en&#x2F;24.3&#x2F;reference&#x2F;modules.html#wr...</a>&gt;?)
评论 #43845957 未加载
hermitcrab16 天前
History shows that visual programming can work very well in particular domains (data wrangling, signal processing, 3d image rendering etc) but has never really been successful for general purpose programming.<p>A lot of the issues related to visual vs text based programming have been debated here <i>many</i> times. As someone with a foot in both camps, I tried to summarise the various arguments here:<p><a href="https:&#x2F;&#x2F;successfulsoftware.net&#x2F;2024&#x2F;01&#x2F;16&#x2F;visual-vs-text-based-programming-which-is-better&#x2F;" rel="nofollow">https:&#x2F;&#x2F;successfulsoftware.net&#x2F;2024&#x2F;01&#x2F;16&#x2F;visual-vs-text-bas...</a>
评论 #43836329 未加载
mattfrommars16 天前
We use an internal &#x27;no code&#x27; tool to do complicated data transformation logic. Our flow has become so large and convoluted, it is extremely difficult to put feature and debugging is absolute nightmare.<p>You have no idea how many times we had wished all this data transformation was in vanilla Java&#x2F;Python. Our life would have been so much easier. But at this time, it is too large to ignore.
评论 #43836431 未加载
评论 #43836308 未加载
redkoan16 天前
IMO, Complexity is still best tackled with text. Low-code for lunch, spaghetti for dinner.
评论 #43831455 未加载
_pdp_16 天前
I just want to make an observation based from previous experiences.<p>These styles of programming environments are not new. We have seen many such tools in the past. I think they are useful (to an extent) when dealing with high-level compositions such as orchestrating a video pipeline, shaders, simple logic.<p>They start to fail very quick when you need to implement more advanced algorithms and processes that are not yet abstracted in reusable blocks. Needless to say, it is easier to write code at this point. Just less cognitive load and frankly the visual model does not help when you have a solid mental model - you can keep more information in your head in abstract forms than the eyes can scan and process.<p>I am lurking in the n8n community and I have noticed similar patterns. The more elaborate workflows are just not as robust as they could be if you write code - and they happen to be very difficult to maintain too and full of bugs.<p>Other than that... these types of framework have their place and as I said, overall I think they are useful as long as they are used in the right way.
评论 #43831482 未加载
评论 #43832633 未加载
danfunk16 天前
Visual workflow tools, particularly those that are able to support a human-in-the-loop, MUST exist for the world to adapt and effectively use LLMs.<p>Literate Programming - coined by Donald Knuth and at the heart of Jupyter Notebooks - is powerful means of making software development a tool in the pockets a lot of people. I agree that just pressing &quot;run&quot; is critical to making a tool like this accessible.<p>I&#x27;m one of the core contributors to SpiffWorkflow. We are also visual programming platform and echo your belief of the power of combining visuals with programming. I shared this article here a few months ago that delves into our methodology. - <a href="https:&#x2F;&#x2F;medium.com&#x2F;@danfunk&#x2F;5-ways-bpmn-python-will-simplify-your-business-workflows-2e4d67a07c77" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@danfunk&#x2F;5-ways-bpmn-python-will-simplify...</a><p>conartist6 mentioned elsewhere in the comments of a need for a common standard for editors - I think BPMN could be that standard, or new revolutions of it, such as POWL.<p>collingree mentioned &quot;good visual programming makes the software development process more accessible to other smart people&quot; -- I think this maybe the MOST important long term benefit of these tools. More people in organizations need to understand what the hell is going on - and stop shrugging their shoulders when it turns out all the business logic is buried in 100k lines of code. Important shit should be easy to find and change.<p>As many others have mentioned here, visual tools are not likely to see wide adoption by software engineers for all of their work. But as middle groud in which to plant business rules, so those rules can be cultivated - it could change the world and the way we collaborate on software efforts.<p>Would love to talk to you both sometime, share war stories, dreams, and go to market strategies.
beders16 天前
Re: HTTP Flows.<p>As we know networks never fail, read timeouts aren&#x27;t a thing and error handling is not necessary as networks never fail and read timeouts aren&#x27;t a thing and error handling is not necessary as networks never fail and read timeouts aren&#x27;t a thing...
评论 #43834664 未加载
tturchi15 天前
Love the idea!<p>I’ve been exploring something similar: combining visual programming with LLMs to teach computational thinking by hiding most of the syntax.<p>- Paper <a href="https:&#x2F;&#x2F;www.computer.org&#x2F;csdl&#x2F;proceedings-article&#x2F;vl-hcc&#x2F;2024&#x2F;661300a353&#x2F;215yozPta3S" rel="nofollow">https:&#x2F;&#x2F;www.computer.org&#x2F;csdl&#x2F;proceedings-article&#x2F;vl-hcc&#x2F;202...</a><p>- Related demo <a href="https:&#x2F;&#x2F;flowpilot.trx.li&#x2F;" rel="nofollow">https:&#x2F;&#x2F;flowpilot.trx.li&#x2F;</a><p>I poised that we could merge Visual+LLM to teach Computational Thinking skills by abstracting the code syntax.
评论 #43846062 未加载
abxyz16 天前
Looks very good, I believe this type of product is the future (instead of vibe-coding that produces heaps of junk new code). A few thoughts:<p>* Flowcode is a clever name but since you are positioning yourself as an alternative to code (&quot;Code is messy and complex&quot;) the name is contradictory, just call it &quot;Flow&quot; (or &quot;flows&quot; or &quot;Flower&quot; something)<p>* You are replacing the legacy of code with something new, embrace new ideas that get out of the &quot;one running process&quot; paradigm, e.g: durable functions. There are a bunch of companies in the space (inngest, DBOS, trigger.dev) who are doing very interesting things, copy&#x2F;steal&#x2F;leverage all the great things they&#x27;re doing -- your product&#x27;s value is the visual programming<p>* Most developers today are already writing code so getting out of their code flow to do something visual might not fit well, whereas there are lots of non-developers who would love a product like this (see: the success of Make.com, Zapier etc.) because you&#x27;re offering the AI integration for creating workflows which gives them confidence to go beyond what Make, Zapier etc. offer<p>If I were marketing this product, my pitch would be reframing programming as something anyone can do when it doesn&#x27;t involve code, i.e:: your users can become a developer without writing code, AI-assisted visual programming builds production-ready systems without a single line of code. Code is archaic, (visual) programming is the future. Vibe coding is faster horses, AI-assisted visual programming is flying cars.
评论 #43832123 未加载
remon16 天前
So far there are zero data points on the success side of the fence when it comes to visual programming. The exceedingly rare times I come across it professionally it&#x27;s a toy project or something that&#x27;s basically in the state of &quot;We wish it was just code but we don&#x27;t dare touch it&quot;.
评论 #43834609 未加载
评论 #43834288 未加载
评论 #43836634 未加载
评论 #43838767 未加载
评论 #43834258 未加载
somethingsome16 天前
That reminds me of a very beautiful flow based language years ago, Luna-Lang[1] but it seems that the website died and it is no longer maintained.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;binary132&#x2F;luna">https:&#x2F;&#x2F;github.com&#x2F;binary132&#x2F;luna</a>
评论 #43832522 未加载
EGreg16 天前
Have you seen Bret Victor&#x27;s talk? You might want to contact him: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=PUv66718DII" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=PUv66718DII</a>
评论 #43846152 未加载
threecheese16 天前
Looks very interesting. I am currently researching node-based developer tools and libraries, and after a quick look at your code I wonder why you chose to create your UI from scratch instead of using a diagramm-ish utility (react-flow and many others)? I know there are some tradeoffs with each, like one might be geared toward drawing, another for graph visualization, another for lots of nodes etc, and so maybe you didn’t like these tradeoffs?<p>btw, <a href="https:&#x2F;&#x2F;deepwiki.com&#x2F;flydelabs&#x2F;flyde" rel="nofollow">https:&#x2F;&#x2F;deepwiki.com&#x2F;flydelabs&#x2F;flyde</a>
评论 #43834830 未加载
gwbas1c16 天前
Would be nice to see some screenshots instead of needing to jump into the demo. Sometimes I like to skim a bit to understand what I&#x27;m getting into before I &quot;do.&quot;
webprofusion16 天前
Reminds me a little of Node-Red, for me coding is just easier than connecting boxes but it would be cool if someone cracked the visual programming route.
edweis16 天前
Congratulation on the launch! I definitely see a future in visual scripting, the best candidate I have for my next project is <a href="https:&#x2F;&#x2F;luna-park.app&#x2F;" rel="nofollow">https:&#x2F;&#x2F;luna-park.app&#x2F;</a> but I&#x27;ll be experimenting with FlowCode&#x2F;Flyde.<p>What use cases do you target with Flwocode? As I see here it seems general purpose.
评论 #43831284 未加载
dave8416 天前
Unrelated to <a href="https:&#x2F;&#x2F;www.flowcode.co.uk&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.flowcode.co.uk&#x2F;</a>
totallyinfo15 天前
Node-RED is mentioned deep in the thread. But just to say that Node-RED is over a decade old and is very widely used. Including some very large organisations like Siemens and Hitachi. It has thousands of packages and is Node.js&#x2F;JavaScript based and so relatively easy to expand.
评论 #43845982 未加载
robertlagrant16 天前
Worth noting that Software AG has an integration product called webMethods Integration Server (now all owned by IBM, I believe) that has visual language called Flow[0].<p>[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;WebMethods" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;WebMethods</a>
hamid_ra16 天前
This is very cool! I’ve used workflow builders for AI-based workflows before, but the ability to add custom code as work blocks is incredibly useful. A great idea would be to include a CLI to visualize the existing code. It might not be trivial, but current-gen AI could help extract modules from the code.
agumonkey16 天前
Lovely visual and ergonomics from the few I&#x27;ve seen of flyde (your link is still returning a 404)
f_devd16 天前
Just to let you know, the name conflicts with Matrix TSL&#x27;s Flowcode[0], which is for simpler embedded programming.<p>[0]: <a href="https:&#x2F;&#x2F;www.flowcode.co.uk" rel="nofollow">https:&#x2F;&#x2F;www.flowcode.co.uk</a>
criticalsec16 天前
Congrats on your launch! Looks very good! We are building a similar product at www.midio.com and it seems you have come to some of the same conclusions as us about visual programming.
评论 #43846393 未加载
sampton16 天前
I&#x27;m starting to see line-of-business folks start jumping into Python using LLM. It&#x27;s going to be hard to compete with that with your custom flow diagrams.
whattheheckheck16 天前
If you can&#x27;t write the software that runs the flowcode with flowcode it kind of makes it simply a different notation and not a revolutionary paradigm shift?
评论 #43846520 未加载
starfezzy16 天前
The mobile site is pretty seriously broken in multiple places. This does not inspire confidence in the project.<p>One major breakage is that I can&#x27;t watch the demo video on a modern device (S24U, firefox).<p>If I press play, the video comes up and begins playing with a massive play button over it. If I press the maximize button, the video goes away and it locks the view into a horizontal orientation centered on apparently some random part of the webpage.<p>Other broken parts made me think I hate Dark Reader installed (I don&#x27;t), and the testimonials at the bottom overlap—maybe they&#x27;re meant to be swiped through, but that doesn&#x27;t work.
anonzzzies16 天前
I remembered Flyde : looks interesting, will definitely try.
conartist616 天前
Let me know if you want to try to collaborate.<p>I&#x27;m working on the same idea, but I&#x27;m trying to take it several steps further by letting any syntactic programming language be rendered, edited, and run as no-code.<p>This is a response to my observation that the limit to the growth of these things is that they always have &quot;meh&quot; editors because the editor and the programming language are tightly coupled -- right now if there are ten visual programming languages there are ten different visual programming language editors.<p>This is probably the biggest reason these tools don&#x27;t catch on professionally: you can&#x27;t learn the editor tool and take that skill with you to a new language&#x2F;project as you can with a text editor and syntactic languages. Fortunately this is the problem I have solved.
talhof816 天前
Pretty cool! Congrats on the launch.<p>Would love more built-in templates. Might be useful to plug this to Zapier, or support MCPs.<p>Edit: And built-in logs please!
miravmehta16 天前
Are you similar or competiting with <a href="https:&#x2F;&#x2F;icepanel.io&#x2F;">https:&#x2F;&#x2F;icepanel.io&#x2F;</a> ?
评论 #43846131 未加载
qwertytyyuu16 天前
I swear it would be harder to make a non Turing complete visual programming platform
tonnydourado16 天前
Sigh.<p>Firstly, and to be fair, this is more for the comments than OP, can we please stop kidding ourselves? People have been trying to make tools to allow &quot;non-developers&quot; to code without coding since COBOL, and they all either failed, or end up requiring that users learned how to code anyway. Except maybe Excel.<p>Secondly, this has some good ideas, but makes the same cardinal sin of, seemly, all visual programming tools: try to encode control flow visually. No one wants to write ifs, fors, and whiles as connected nodes. It sucks. Text is MUCH better for that. You probably are very, very rarely writing flowchart diagrams in real life. I know I don&#x27;t. I write state machine, architecture, data flows, etc., unless I&#x27;m being forced by some braindead tool to write control flow logic with little boxes and arrows.<p>The thing that is actually interesting here is the boxes that provide higher level abstractions, like HTTP requests, LLM calls, etc. Give me one or two different nodes in which I can just write some code to process input and return output, and maybe some dispatch and map nodes, and focus on providing higher level abstractions out of the box, and allowing me to build my own abstractions too (i.e., parametrised graphs). Think more functional, less imperative.<p>As is, that doesn&#x27;t look like a tool I&#x27;d be excited to use, but I won&#x27;t deny it has some potential to be interesting.
评论 #43832542 未加载
评论 #43832589 未加载
评论 #43834533 未加载
caboteria16 天前
The main link returns a 404 - maybe a griefer deleted example1?
评论 #43833450 未加载
crq-yml16 天前
I was imagining this kind of product the other day, in the context of building content creation pipelines(I was looking into extending Blender to call out to ffmpeg and similar tools), and now here&#x27;s a full example of where it could go - I&#x27;m on my phone but I&#x27;ll dig in later.<p>My thought is that flow graphs are a great fit for the AI wave since the weakness in the graphs is mostly around &quot;random access&quot; problems that need to model a broad technical vocabulary, while the weakness in using the AI is in it not knowing the boundaries of the problem space and just generating endless text slop instead of using it to generate a configuration or remake a common algorithm with a small tweak. Tying the two together into a system that looks like &quot;human oversight over automated coding details&quot; should be a major step in the right direction.
danwills16 天前
Really cool! I love programming with nodes and this seems like an awesome start!<p>One thing I didn&#x27;t like much was when dragging a node that has an input connection, to the left: The shape of the connection snakes behind the node and has some very sharp corners on it. Apart from being a bit of an ugly shape for a spline to be in (personal opinion) I think going far behind the node like that might have the potential to obscure the connection in certain cases. Legibility of the network should be a top priority for a project like this in my opinion (and you&#x27;ve already done very well! this is more of a niggle, not a real criticism!) Good old adage says that reading code is much harder that writing it and node-networks don&#x27;t really revolutionize things on that front even though they can help a bit in quite a few cases.<p>I&#x27;ve used SideFX Houdini a lot and am very familiar with Vops: Node-based Vex code editing in Houdini (to see an example get inside (doubleclick or Enter-key after selecting) a &#x27;Point Vop&#x27; inside a &#x27;Geometry&#x27;&#x2F;Sop subnetwork). I&#x27;m a massive fan of the way that Vops works! Plus you can inspect the actual code that the overall network is generating by RMB-&gt;&quot;Vex&#x2F;Vop Options&quot;-&gt;&quot;View Vex Code&quot; on the containing node. Ah I see flowcode has &#x27;View&#x2F;Fork Code&#x27; for the code of individual nodes, which is awesome!.. but is there a way to see the code of the &#x27;overall network&#x27; too? (ie what the wires become in terms of calling, if the nodes are like methods).<p>So yeah, I think Vops is great, and super fun! If you haven&#x27;t played with it a bit I think you should! (and you totally can check it out for free!)<p>I&#x27;ve added a LOT of additional accelerator&#x2F;helper tools to Vops that I think make the overall workflow much more pleasant. Would be happy to go into what they do in an email or something. I think Vops really shines when you want to quickly belt out a small data processing&#x2F;generation task quickly without heaps of typing&#x2F;syntax. The results are generally great too I reckon (certainly run very fast when processing huge batches of similar things).<p>It&#x27;s not good for future editors when the number-of-nodes+wires gets too large inside any given subnetwork-level though! I think it&#x27;s totally fine if there is heaps of nodes&#x2F;substructure inside loads of &#x27;subnetwork&#x27; (slash Houdini-Digital-Asset &#x27;.hda&#x27; (&#x27;.otl&#x27;) levels as long as the function of the node is well &#x27;encapsulated&#x27; (just like a good function&#x2F;method should be!). Once networks get too big and complex it can become a bit of a maintenance burden, and it can often be sensible to switch to editing Vex as text instead, and putting things in headers&#x2F;libs and so on when Vex things get reeeally big.<p>Aaaanyway I shouldn&#x27;t go on about it I just want to make one main point about the wires in Vops: There are 2 &#x27;wire styles&#x27; (Shift+S to toggle): Rounded (my preferred style) and &#x27;Default&#x27; (which I think is maybe also called &#x27;Straight&#x27; in some places but it certainly isn&#x27;t straight lines, just as straight as possible!). With both of these wire styles, if you have two Vop nodes stacked vertically, and an output on the right of the upper one is connected to the first (uppermost) input on the left of the lower one, you can move either of the nodes vertically about as close as you like to each other (without touching) and the wire will still go through the gap! This is especially so for the &#x27;rounded&#x27; style as the line can literally go straight-horizontal through the gap! Of course it&#x27;s still perfectly possible to make a wire to go behind a node, but in general I think they&#x27;ve done it very thoughtfully! I haven&#x27;t really stopped to appreciate how well-done it really is, but I think it&#x27;s top notch and encourage you to check it out, wire then drag some &#x27;null&#x27; nodes around and see how it behaves and maybe it might yield some inspiration for flowcode? (And I&#x27;ll feel quite silly indeed if you reply with &#x27;yeah I know Vops plenty well myself&#x27;, so apologies if that&#x27;s the case!!)<p>Edit:Clarity
artemonster16 天前
Wow, I used to hate myself, but I hate this even more! &#x2F;j.<p>Jokes aside, congrats on the release! why choice of DOM for nodes instead of canvas?
评论 #43830702 未加载
doodpants16 天前
&gt; 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.<p>Sounds intriguing! ...so why doesn&#x27;t the website actually say any of this?<p>When a person visits the site, the only things they can do are log in, sign up, or &quot;get started&quot;, without any indication of what they&#x27;re even getting started with. Can I please know what the product&#x2F;service is before I have to decide whether I want to try it out?