Show HN: Openexus – Building blocks for the internet
13 comments
I don't understand how you make blocks, all of the demos seem to "just work" but it doesnt really make sense how some values are overrode and others have a default that auto updates?
The logic is actually quite simple. Once 2 cells are connected via a line, their values are kept in-sync. If one cell changes the value, the other cell will be informed of the change, and the module will react accordingly, very much like a reactive spreadsheet.
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.
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.
What are your favorite use cases?
We actually did a mini internal hackathon among ourselves to see what we can do in 1 hour. We created a codepen (multiple code editors hooked up with iframes), spotify + lyrics + translation mini app, and a mini-dashboard.
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.
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.
Is this like Yahoo! Pipes? https://en.wikipedia.org/wiki/Yahoo!_Pipes
Yahoo Pipes (or NodeRed) are what I consider “data flow pipelines” editors. These tools have very distinct characteristics: (A) usually a single piece of data or message that (B) flows through a system in one direction with (C) distinct start and end points.
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.
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.
This is not obvious. I would show an icon, maybe a question mark, that explains what it is. Or embed the editor in a regular home page and let users go full screen or open a new window.
Thank you for the feedback. Did you by any chance manage to connect the first 2 cells? Once you do that, it will reveal a lot more content, with a more "regular" home page that you can scroll down.
Very cool demo! I can see the potential here! Couple questions:
1. How do you compare yourselves to other WYSIWYG web app builders? Why would an app- or module- developer invest their time into this platform vs. others?
2. What are your plans for monetization, if any? An app developer might be hesitant to build anything meaningful on top a free tool, fearing that its business model might change at any time.
1. How do you compare yourselves to other WYSIWYG web app builders? Why would an app- or module- developer invest their time into this platform vs. others?
2. What are your plans for monetization, if any? An app developer might be hesitant to build anything meaningful on top a free tool, fearing that its business model might change at any time.
Pretty cool! I would really like to know how would I go about creating my blocks in the future? That is a feature I'm really interested in
Developers can create modules in Javascript very similar to writing web components or React components. The only addition is to write a declaration of the connectors (e.g. value, data, location, etc.) and use provided functions to subscribe to cell value changes.
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.
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.
Clickable link: https://openexus.com
Oh nice, sent an email for access--looks like a great extension of APIs.
The idea is to build a platform and community for composable building blocks where anyone can easily create, find and connect different modules to create dynamic and interactive apps, sites, dashboards, and docs. This can be done without using a single line of code.
Key principles of what we are building:
1) True composability that enables infinite possibilities — Modules today are either too complex to be used only by developers (e.g. NPM packages) or too simplistic where they are usually used as an embed in isolation. We are establishing a modularization foundation that is powerful enough for developers to express functionalities, simple enough for anyone (even kids) to use, and flexible enough to build sophisticated creations.
2) Smart connect without code — All logic can be clearly expressed by simply drawing lines. Depending on the data type and other characteristics of the connector, we can figure out how the connection should behave. For example, triggers can only be connected to actions, and data connectors that fetch from APIs can be defined as directional read-only connectors.
3) Open-connections for instant forking — Forking today is a time-consuming complex endeavor. Even a simple change requires many layers of code understanding. Instead of open-source code, we see a future of open-source connections, where remixing simply means adding new blocks and re-wiring them.
What we are building can be described as NPM for non-developers, connectable Lego blocks for the Internet, or Minecraft for non-game creations. Our focus is to create a community where we can share ideas and innovations.
We are super excited about the possibilities of this platform, especially when we incorporate AI. We will be releasing tutorials, opening up the playground, and sending out invites in the coming weeks. If you are eager to try out our tooling and create your own building blocks, drop us an email! We would love to hear your feedback!
Website: https://openexus.com
Email: [email protected]