lominming
Joined 16 years ago
Joined 16 years ago
We want to emphasize that while Open Node Protocol enables no-code development, it's absolutely not limited to it. The Open Node Protocol is a specification, a set of standards for how these "blocks" (nodes) interact. Developers can build nodes in any programming language and with any framework they choose. The visual assembly is just one way to use ONP; the underlying power comes from the standardized communication between nodes, regardless of how they're built or connected. This means experienced developers can create highly sophisticated, code-based nodes and leverage the benefits of modularity and AI integration at a much deeper level. Think of it as a way to create reusable, interoperable components, regardless of whether you're connecting them visually or programmatically. In fact, in the near future, you can ask AI to assemble the nodes for you.
A great next step would be to check out our tutorial[1] – it walks you through the core concepts and helps you build your first node.
If you need more help, join us at our discord[2].
[1]: https://openexus.com/tutorial [2]: https://discord.gg/uvEPXWrmkp
- React (if you want the largest support, packages, community, but sacrifice on performance) - SolidJS [1] (best performance, composability, low-level primitives, but sacrifice on packages/community)
Every other choice like Angular, Vue, Svelte are just somewhere in between these 2 spectrums which I felt was not worth it. Either choose the one with the largest ecosystem or one which has the best primitives & performance.
- React (vdom, slow) (largest ecosystem) - Vue (vdom, faster than react) (large community) - Svelte (fine-grain, faster) (best dx pre-v5) (composability is still not as flexible in v5 compared to SolidJS) (small ecosystem) - SolidJS (fine-grain, fastest, most consistent) (dx similar to react) (small ecosystem)
My attempt on this is https://openexus.com where the goal is really to create some form of universal plug-and-play building blocks. Your approach is almost very low-level with direct translation to code. My attempt is slightly higher-level (but developers can create as low level as they want). More importantly, the visual diagram build on openexus is a reactive graph (almost like spreadsheet), not a sequential directional flow graph (like node-red, or yahoo pipes).
Would love to chat if you are up for it. m at lominming dot com.
It would be helpful to understand why you feel like version control (git, not github), a programming language (javascript), a browser, a database are all fundamentals? They are not the first in their respective categories, just that they all became popular? I feel like your examples also lean heavily towards developer only tools?
Couple of core differences with what we are building:
(1) Instead of directional data flow, we have reactive data flow. For example, in the simple utility color example, [RGB Sliders] <> [Conversion] <> [HEX Color Wheel] have data flowing bi-directionally where any modules can trigger a change. Users still have the option to decide how data flows, so data flow pipelines are just a subset of what our system can do.
(2) Beyond just data or automation, we focus heavily on UI modules, allowing users to easily express interactive creations.
Besides the common use-cases of creating apps or dashboards, we are excited about: AI apps and workflows, interactive education materials, a playground for kids to start thinking about logic, and hardware interface controls.
Developers can import NPM packages, load external javascript files, use JSX, write CSS, use Typescript, etc. We will provide all the necessary tooling online so that building a module is as simple as using an online IDE like codepen. No need for downloads, building, compilation, etc.
Non-developers can also create custom modules that consist of other nested modules grouped together. We also aim to have a lightweight way for citizen developers to write modules using spreadsheet-like syntax.
During the initial connection, we have to “pick a winner” and determine which of the 2 cells’ values to use. The logic is that the empty cell will be overridden. If both cells have values, the direction of how you connect them determines the winner. Dragging A to B will have B’s value overridden by A’s value.
However, the developer of the module, or the creator have the ability to specify the direction flow when necessary. For example, in the Github example, the Github module populates the (issues) cell via fetch call and is expected to be a read-only cell. This means that any connection to the cell will become a directional data flow out.
The simple big picture is that we are drawing lines to tell the system how we want data to flow among the different modules, very much like how we pass variables around in code.