All: the point about the name has been made by several commenters. I'm sure the developers will see it. Please let's focus on more interesting things now.
"Visual programming tools are as old as computer monitors."
That's an interesting statement. I always assumed they were much older -- and that the current detour into 'lines of ASCII text' were a mere implementation detail, driven by historical accident.
This[1] sure looks like a simple dataflow program to me, even if Gauss never intended it to be implemented on a von Neumann machine.
I hate writing programs as text, but unfortunately, "text is the universal interface" right now. It's easy to save, and diff and patch, and edit. There isn't a general-purpose format for saving graphs, diffing/patching them, or a decent selection of editors for them.
In 50 years, I'm sure we'll look back on today's programming the same way we now look back on the pre-visual-editor era. You had the technology to create general-purpose graph editors, but you didn't have or use any? Why not?
No arguments here. We should move away from text into more visual domain, but we lack a polished editing tool. Every visual programming language brings own tools, incompatible with each other and lacking basic features.
Here's my wishlist: completely keyboard-driven; automatic graph layout; constraint editing to tree/DAG/full graph; don't allow connecting incompatible types; declutter by showing only N neighbours from current node; support for extensions to integrate different programming languages. Sure it's a tall order, but this is the building platform for future of computing :)
Since this thread is about Nodes, I'll try to give some constructive criticism. Seems like too much manual work is needed to organize the code on screen. Non-trivial programs become entangled because of 2D plane constraint. It's somewhat unjustified criticism though, since text programs also require lot of manual arranging ("architecture") and easily become hard to read. I like the built-in visualization of processed data. Cool stuff.
They beauty of Nodes is that we are not limited by layout or connections. We have successfully used redux for centralised state management with change triggers distributed down the graph.
Rhinos Grasshopper, Revit Dynamo (BIM), Houdini all have similar node based editing. Generally it works great in concept, and then in the real world is gets pushed to the extremes.
I’ve done a decent amount of work with Isadora (node based VFX environment), and by the time I make anything actually complicated I end up wishing I could just write it in one of the many exiting tools we’ve built for describing data flow. (Programming languages)
Looks really nice. Will certainly take a look. Independent of data visualization, I could imagine it being great for general business workflows like some classic flow engines tried to model, but failed to give control to users.
I've been making something very similar to this while I've been looking for a job. A node-graph editor 'framework' in react. It's not as far along as yours, and looks a little different.
My github has hitherto been empty, but my plan is to open source it in a few days when it's at MVP status. Maybe that'll make me look more attractive to perspective employers. Over a decade of experience hasn't kept my resume out of the void it seems.
Cool! I've been wanting to play with Flow-Based Programming and related stuff for a while so I'll definately give this a look. Could someone however explain to me the difference between "node-based" (the term used here) and "Flow-Based" Programming? It seems like the sentiments are pretty similar but perhaps I'm missing something.
Has anyone looked into using this (or a similar tool) for financial modeling? Seems like this has a lot of the "no programming" aspect of spreadsheets while allowing for a more intuitive approach to visualizing how the data flows in a financial model
Does it have a means for outputting things like image files or 3D models, or only packaged apps? Also, is there audio support? And what's the pricing model going to be like?
We have nodes for saving high-res png/jpg images, image sequences for animation/video up to 4k, obj/gltf meshes, csv/json for data and so on that we used for various projects in the past.
We will have more news about availability at a later date.
Anyone know of a framework for building out tools like this one with our own blocks? I have a use case for an internal tool to enable constrained configuration builds.
I think the moment you have "not to be confused with" listed anywhere on your homepage, it's probably time to change the name, no matter what you're building.
This looks really cool. It's like a javascript version of Quartz Composer. This kind of interface has been in my mind for quite some time, there's some really cool things that can be build and visualized in it.
This looks amazing but the performance is a bit worrisome being entirely in JavaScript / web based; if you've ever made a complex Max patch using the native app, it is incredibly memory intensive. Maybe with all the improvements / sick libraries we have now with 3D, audio, processing, etc. will make that moot; but laptop fans go wild on Max (which is mostly Java)..
Memory intensive apps in JS are largely OK so long as they use proper typed arrays and buffers. Besides, looking at the examples, there's a lot of WebGL going on in the outputs so it's not really JavaScript.
This looks - awesome. I'm trying to think of something more constructive to say, some questions about the processes and outputs ... but I'm too busy being jealous at the moment to think of anything.
I used to maintain a set of bookmarks where people just complained about the name of a thing on HN. It seems like a really consistent theme for people who don't have much substance to contribute to threads. Any chance you could make it one of the disallowed/off-topic things?
I have never seen a developer respond to the comments with "Oh gee, you're right, I totally forgot about that, time to rethink the name!"
We could try, but I doubt it would have much effect—humans are always going to react to names. Also, we're leery of making too long a list of disallowed things, since making it longer dilutes it. Better to argue from first principles.
I think there's nothing wrong with a moderator trying to stop too many threads being created with the same criticism (thanks dang!), but names of things can be very important from a branding/marketing perspective. If people can feel free to criticize other business/design decisions, I see no reason why they shouldn't be allowed to criticize names.
People are free to do mostly as they please. It’s been my observation that comments about names have been consistently non-substantive, and virtually never provide any insight into the content of the post. Most complaints are simply “X has this name already” - the author almost certainly knows this and/or it never came up because it doesn’t affect them.
I think complaining about aesthetics is pretty useless unless it’s constructive or about UX, but this isn’t my hill to die on :)
