Congrats on the launch! One of the positive byproducts of the open web platform is that products like this are possible. Much of what I share in other communication tools are links to things on the web, but sharing ends up forcing a context switch cost on both my end and the receiving end. Love that Muddy is exploring this problem space since I haven’t felt like other neue-browsers have gone far enough in making browsing itself a more collaborative and in-context experience.
This is an interesting and deep topic, which we plan to share more about in an upcoming technical blog post. We are still experimenting with the best ways to constrain the LLM's output such that it always compiles as expected and "knows" when to use certain Dynaboard-oriented features like {{ bindings }}. At a high level:
- Code refactoring works through a recursive refinement loop of: fetching any relevant DB schema or existing component data -> initial generation prompt -> LLM output -> using tsc (or equiv) to detect errors -> feeding the errors back into the LLM recursively until a fixed point is reached -> format. In our experience it works really well for both simple and moderately complex prompts.
- UI components are first generated as an outline/scaffolding of components which map approximately 1:1 with HTML equivalents in an initial prompt, before being populated with their respective component properties in a subsequent prompt. There's a subset of properties that seem most useful to generate which we focused on for this initial release, but we are looking to expand that list over time.
Congratulations on the launch! I've been impressed by Momento's cache infrastructure during its private beta — the team's execution around developer experience makes integration painless so you can hit the ground running. I've seen first-hand how hard operationalizing instance-based caches think the serverless approach is a great fit here.
One note: we have some lightweight persistent data stores built-in for convenience, like a key/value store. However, you're always able to build on top of your own database / API and most of our early users do.
Thanks for the report. We're now shipping a polyfill for ResizeObserver on the landing page. Drop me a line at alex AT dynaboard DOT com if you're still running into trouble.
Yes we do — everything in the editor interface and the apps you build with it have light-and-dark modes by default. We didn't have the bandwidth to make the landing page have a light-theme, but the product itself supports both modes already.
We will not be pricing per developer or per user, but rather usage-based. We aim to be affordable for applications at scale, because we believe the cost of an internal app should not increase linearly with your headcount.
We’ve designed the system for a few deployment configurations, with independent single-tenant and multi-tenant support on the control plane and data plane. The goal is flexible on-prem deployments that balance customer convenience with regulatory / privacy requirements. At the moment though, we’re focused on our multi-tenant cloud environment and making that as top-notch as possible.
You’ll also be able to eject your app out of Dynaboard. The code is yours, we aim to have the best editor available and convenient serverless hosting so that’s why you’ll stick with us.
We're decidedly a "low-code" or even “yes-code” tool. You use the drag-and-drop interface to design the app, while all of the app's logic is written in an in-browser text editor environment. Everything is multiplayer from day 1. It's an IDE in the style of VB6 / MS Access / FileMaker Pro, but built with modern web technologies at the foundation.
We're building for early-stage technical teams and independent developers that want to reduce the iteration time on prototype -> production apps.
Hey HN, Dynaboard founder here. Sharing a bit more about how we built Dynaboard, since I think this audience will appreciate it. More will be shared in future blogs :)
Multiplayer: We used the YJS project (https://github.com/yjs/yjs) as the baseline for our multiplayer system. We created a thin harness around the client and ended up implementing our own server-side architecture to handle relaying between the various WebSocket servers. More on how we do this soon.
WebAssembly: Rather than running your custom code in an iframe, we run it inside a wasm-based sandbox, a compiled version of the QuickJS VM (yes, it's JS-in-JS). This approach gives you synchronous access to most of the DOM APIs without sacrificing safety. We do some fancy ES6 Proxy management to implement the FRP-like data binding system inside the VM. In production, the browser runs the project's precompiled bytecode. In the future, we plan to support other languages with a similar architecture (Python via Pyodide, Rust, Go, etc.).
Code editing: We use Monaco, the same editor that VS Code uses. We've had to create a handful of custom extensions, including a few custom language servers, to get it to be aware of the VM environment. I'm a vim-er so we will definitely have a vim mode.
We're looking to make Dynaboard really affordable, especially for smaller teams, and entirely usage-based (no per-seat cost). Our goal is to price it more like a cloud infrastructure product and not charge for things that do not cost us money. We don't want to post something and promise something that we can't deliver on, and so we decided to table announcing the prices until we figure it out over the next 2 months. You can find the approximate structure of the pricing on the pricing page.
Stacked changes are an essential QOL feature when working with large monorepos. Kudos to the Graphite team for expanding the visibility of this development pattern and making it more accessible to teams of all size.
Hey Mark, thanks for taking a look and appreciate the feedback.
You can think of Cleargraph like a proxy for geth with some bonus features. You can point a local instance of Cleargraph to your own JSON RPC API endpoints using the helm charts we provide: https://github.com/dsys/charts. We're looking to make it even easier to use, so if you have suggestions please let me know.
We think it's important incorporate decentralized systems where it is practical (i.e. ENS). I'm aware of projects building the Ethereum blockchain secondary index features (for things like transaction filtering) in a decentralized manner, but haven't seen one live just yet. Maybe when they're live we can switch to them, or if you have ideas regarding Gun, would love to hear! :)
The primary "centralized" component is the privacy-preserving contact discovery, which we believe is a necessary evil. Afaict, any decentralized hashing scheme is susceptible to pre-image attacks due the space for phone numbers is small, which makes publishing the entire hashed address book leak everyone's info. Signal has a good write up on an improvement we may eventually incorporate that uses SGX: https://signal.org/blog/private-contact-discovery/
It allows you to query the blockchain using a consistent API and offers some features not present in the standard JSON RPC API, like ENS domain resolution. Makes it useful for building decentralized apps.
Author here: we noticed consistent sources of duplicated code when designing cross-platform dApps and built Cleargraph out of necessity. We thought it would be broadly useful as a generic dApp back-end, so we polished it up and open sourced it!
Right now we're working on some dApp/smart contract templates that use Cleargraph, and want to know what y'all would think is useful. Maybe something along the lines of a CryptoKitties clone, a token monitor, a todo-list with staking, or a graphical transaction explorer. Open to any ideas! :)
FilePizza creator here! I hear you—the dependency on the broadcast servers has been giving me issues. I'm planning on going back to a home-grown file transfer method over simple WebRTC, rather than using WebTorrent. Hopefully will get a fix out in the next couple days.
