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.
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.
So multiplayer bubble but more industrial/data-centric, real database (operated out of band) for full data modeling power & operational scale, and use javascript to define business rules with control flow and loops?
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.
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 run [your custom code] inside a wasm-based sandbox, a compiled version of the QuickJS VM (yes, it's JS-in-JS).
I'm curious about why. Is sychronicity the only reason? (And is it really worth it? `await` makes asynchronous code paths pretty unobtrusive.) Mirrors[1][2] are pretty interesting.
(Not sure that I agree that compile-to-WASM makes for JS-in-JS. WASM isn't JS. Why do people keep conflating them?[3])
I imagine that part of it is for security. Figma has a good overview of the different approaches they considered for their JavaScript plugin system, and JS-in-JS was one of them:
Sure, that much is clear. But we're discussing it in contrast with other security-preserving approaches. "For security" only really makes sense we were asking, "Why do any of these things at all?", but we're past that. What we're asking is "Why this thing specifically?"—especially where that thing is expensive.
> Figma has a good overview of the different approaches they considered for their JavaScript plugin system, and JS-in-JS was one of them
First: to reiterate, JS-in-WASM is not JS-in-JS.
Secondly: Mirrors, notably, are not among the approaches they evaluated. I advocated for an evaluation of a similar Mirrors-based approach in the HN thread at the time that the Figma post was published:
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.
