We added a VS Code extension to DronaHQ visual development

Visual tooling: an extraordinary head start

Visual builders dramatically reduce the friction of composing screens, wiring data bindings, and connecting interactions. Engineers, designers and product folks can get meaningful, production-quality apps started quickly.

When the hidden costs surface

One afternoon on a walk with my co-founder and CTO, I found myself putting words to something subtle: the hidden cost of visual development. On the surface, dragging and dropping feels effortless. But under the hood, every micro-edit — moving a button, resizing a card, adjusting a property — forces the canvas to do heavy work. And as the app grows, that cost compounds.

“It’s like we’re re-rendering the world for every tiny change,” I told him. He laughed, but he also knew it was true. That constant recalculation is what slowly erodes the smooth experience developers expect.

That conversation nudged us in a new direction: what if we opened up the meta code behind the canvas? What if developers could not only see it but also edit it directly, sidestepping rerenders for every tweak? That was the seed of the VS Code extension — a way to give engineers both the visual speed and the coding control.

Before we go further — a short detour for curious engineers

I want to take a small detour to explain, for curious engineers, what happens behind the scenes when a live canvas responds to your every nudge. Understanding these internal costs makes the rationale of the toggle clearer: it’s not adversarial to visual tooling — it’s a pragmatic complement.

When the canvas is live, several systems run as you edit:

• Collision detection — making sure components don’t overlap improperly. A naive implementation checks each component against every other, producing O(M²) behavior.
• Resizing & reflow — a change in one container can cascade through the layout tree and force many recalculations.
• Property propagation & bindings — updates to shared properties or constraints can cause many dependent nodes to recompute their state.

“Experience the sluggishness of canvas. start with smaller inital components and then drag and drop components and try and drop them over another component & observe the milli seconds it needs while adjusting the canvas. Repeat this with larger set of initial components and also check on throttled CPUs to appreciate the issue even more”

You should observe that initial experience is amazing and in a few micro seconds canvas does the drops. Also you may observe that even in a optimized canvas a component drop may not always need resizing/ collision detection and work happens in a few micro seconds.

So, just going a step further — here is the Big-O complexity of the operations above:

O(N × M × K + M²)
N = number of screens
M = components per screen
K = edit iterations in a session
M² = pairwise operations (collision checks, naive overlap tests)

ok so here is how DronaHQ solves this — we bring in a smooth toggle to switch between VS Code editor and visual dev

The toggle preserves the visual canvas for composition while giving developers a direct, efficient path to edit the underlying metadata in VS Code. Use the canvas for composition, then switch to the editor to batch changes, run structural edits, or perform large refactors — and publish once.

Roadmap

• Editor ergonomics in VS Code: templates, multi-cursor utilities, structural edits.
• Incremental publish and smarter sync — avoid rebuilding entire screens after every change.
• Canvas performance: spatial indexing and smarter invalidation to cut pairwise work.
• Windsurf / Cursor-enlightened features: ergonomic bulk edits, guided structural changes, and lightweight transforms — make large edits and pattern maintenance trivial.

Conclusion

Visual development is the fastest way to get started. For teams scaling to many screens and use-cases, the VS Code extension provides a pragmatic path: keep the canvas where it helps, switch to code when you need speed and predictability. We acknowledge the complexity of understanding generated metadata today — and we are committed to simplifying that model by ~10× in future iterations so developers can reason about and maintain their apps more easily.