gabigrin

It's far from ideal but if you search for an album, you can quickly select all of it. Here's a video of Or, my co-founder showing that - https://youtu.be/7gi58SuQ6Rk?si=LQu8fJBDflVR11Rs&t=38 (links to the exact second)

Thanks! Re: links, will fix it. That was the original domain but Google didn't approve it, and we can totally understand why.

Embed - it is a feature we pushed yesterday so still no proper documentation on that. It's as simple as importing images -> clicking on an "embed" button and grabbing the iframe code. Requires some technical understanding. We might improve to be platform-specific (Webflow, Wix) if there's a real need.

And as for the guides you're seeing are complete gen-AI slob, I agree. Not something we're that proud of, but mostly for SEO to be able to acquire users at a reasonable price. We're running ads campaigns but with our low pricing, it'll be really hard to be profitable so SEO is one way.

That's one take I'm trying to take with https://www.flyde.dev. Build that higher-level abstraction that allows LLM to shine and us humans to enjoy a more effective way to view and control its outcome.

I know it's not what you meant, but tbh I don't think going deeper than Haskell on type-system power is the route to achieve mass adoption.

Hello! I'm working on a low-code API builder based on Flyde, the open-source visual programming language I launched a few months ago (https://news.ycombinator.com/item?id=39628285) Unlike existing low-code API builders, one can easily eject to a ".flyde" source file and run the API wherever they want without being commercially vendor-locked

I would love feedback on the new site's direction - https://www.getflowcode.io/ (still WIP) Here's the old one, for reference https://flyde.app/

https://www.flyde.dev allows you to do that!

Merge sort (the first example countering visual programming's value) is a great demonstration of something that doesn't make sense to convey visually. I strongly believe algorithms in general are best conveyed using good ol' textual programming.

However, most dev's work isn't writing merge sort, but gluing up databases, third-party vendors, and internal microservices to perform some business logic. The amount of "low-level" coding done is low, and getting even lower with the emergence of LLMs.

With that in mind, visual programming as a way to orchestrate different components together can shine!

That's why I built Flyde - https://www.flyde.dev. An open-source visual programming language that integrates seamlessly with existing code, and doesn't replace it.

Very cool project. A great demonstration that when you're useful you don't need a fancy interface!

If anyone is interested in a more generic visual-programming language, check out Flyde - https://www.flyde.dev - an open-source visual-programming language I'm working on

Thanks!

I plan to move it to JSON sometime in the future, but it won't remove the need for a webpack loader, at least not the way it is built now. The webpack loader exists to resolve dependencies. If your flow depends on Node1 from @flyde/stdlib and Node2 from @spankalee/flyde-nodes, "something" needs to resolve the code for these nodes.

A possible way around this is to bundle/compile a flow and its dependencies using tooling on Flyde's end, but that's just shifting what the loader does to another end of the pipeline :)

Regarding shipping in a web component - you could always wrap https://www.npmjs.com/package/@flyde/flow-editorin a standalone renderer. It's cumbersome and adds many extra KBs, but doable.

Appreciate the feedback!

I think so, yes. A rejected promise is equivalent to a node that throws an error. Flyde exposes a default "error" output pin for each node. As everything in Flyde is async, any error thrown can be viewed as a rejected promise. Promise.any can be achieved with 3 promises and a throttle node Promise.allSettled translated to connecting the error output pin and hooking it to whatever you wanted the fulfilled value to go.

I'm so immersed in this space that it's rare to find a related project I haven't heard of before. Thanks! Looks interesting.

Caught me there! Fixing :)

Thanks!

I like the "visual abstraction" vs "visual representation" distinction, and agree with your point that Flyde falls into the latter.

Regarding parallelism and asynchronicity, Flyde manages to answer that need. You simply connect 2 nodes in parallel - for example - https://imgur.com/a/GJewFHd this fetches data from 2 apis, maps them and collects them into a new object. It's low-level for sure, but parallelism and asynchronicity are completely spatial. Do you mean it in a different way?

Author here. Not really. I mean, there are tooltips and icons, but not in the sense that you'll be able to grasp what it does just by taking a look at its structure.

Thanks! Fixing

Thank you!

Author here. Agree 100%. While Flyde allows you to group visual nodes together and create new ones with a "visual implementation", I foresee that code-based nodes will still be the majority.

Thanks! And yes, definately something I am considering exploring. It's right after auto-layout, and "zoom to view grouped nodes internals" (a-la https://xai-primer.com/tool/)

And I was planning to submit a PR for your codex soon! I've visited your codex dozens of times in the last couple of years. Big fan :)

Open Nexus looks great! The UI design is super clean, and the open-ness of your nodes give it true Bret-Victor-ish vibes!

I started closer to this at first (but still lower-level) and slowly got "down to earth", taking a https://www.dreamsongs.com/WorseIsBetter.html approach.

No, not at all. I'm not trying to build a better NodeRED. Moreover, I can only hope Flyde gets to the popularity of NodeRED one day and believe that while there is some intersection between the projects, each can excel in non-conflicting use cases.

Haha glad you found this comment! Love your dedication to the amusement park theme, it's rare to see web products take such a "game design" approach.

Author here. Diffing is a great example. The first incarnation of Flyde had naive version control built into it and had such diff features!

Diffing from VSCode already makes a bit of sense (see https://imgur.com/a/WXj89tx). Next step is to color it differently, and finally, add a browser extension to render diffs nicely from GitHub/Gitlab's UI as well :)

Hey, author here. Did you try tools like Make or Pipedream for this use-case? Curious about what was missing for you in them.

With Flyde you can do that, and one of the monetization strategies I have planned for Flyde is Trigg - https://www.trigg.dev, a "visual serverless" platform based on Flyde, that can run the work flows for you and expose them as APIs. And for "ejection" purposes, one could always download the flow and use the lower-level Flyde to run it self-hosted.

There should be one :o Perhaps it took time to load on your end?

Enso is super cool, been following their work since the time they were called luna :) Flyde is TS to start with, but Python is the next candidate in language support. Eventually, the plan is to rewrite the core/runtime layer of Flyde to a more performant language (Rust/Go) and enable interoperability, so you could potentially even mix and match node implementations. One node could be built with Python, the other with JS, and the flow itself will be agnostic to it.

This is something I ponder about a lot.

For those proficient in writing textual programs, a tool such as Flyde as-is might provide value by enforcing modules to be stand-alone and well-defined; the premise of https://en.wikipedia.org/wiki/Flow-based_programming as a paradigm that promised value even without using a visual editor, and just by adhering to the concept.

But for those who lack the understanding of coding syntax and grammar, a visual tool, even in a not-much-higher level of attraction, could make all the difference. I've personally mentored dozens of entry-level developers many struggled with concurrency and asynchronicity. (callbacks, promises, etc). these are concepts that become a no-brainer using a nodes-and-wires editor.

Regarding prepping - fair point. I'm sure it's not what you meant, but here's a grep in a Flyde flow (the second example) - https://imgur.com/a/V9u1ETl

Hey, author here. Does this happen in the playground, home page or extension? Will look into it!

Thanks! this means a lot, as I've been through many iterations with this one. Each affected some other revelation in my journey with Flyde.

PS: Here's an older one - https://web.archive.org/web/20230313081811/https://www.flyde...

Thank you! 1. Nodes with custom logic, structure (inputs/outputs etc) and custom configuration editing are definitely possible. But I assume you mean custom nodes as in nodes that render the data passing through them, like in litegraph.js, right?

If so, it's not possible, as IMO it's less of a value for "production" use-cases/application level layer. But if the community's interest will slide in that direction, I will consider going that route.

2. It can be used as a library, either Node.js (via an npm package) or the browser (using a custom webpack loader)

It's a question I get many times and while the point makes sense, I think that the value of translating a piece of code as-is to Flyde isn't that high. The resulting visual representation will resemble the AST of the transformed code and be less of a value. It's like converting assembly to C and vice-versa. It might be useful, but data will be lost and a 1 to 1 conversion doesn't really exist.

On the other hand, you can easily take a single piece of your code, say a business logic of a controller in an MVC-based web service, and transform it into a Flyde flow and call it from the original controller.

With that being said, I have no doubt that for Flyde to be truly mass-adopted I have to invest more in easier onboarding and safer ejection.