To round trip or to not round trip

Pagedraw is a compiler that translates drawings into code. We ask users to never touch the generated code because if you want to make any changes to the drawing later, whatever addition you did to the previous generated code will be lost.

A lot of people get a bit turned off by this at first. One user — let’s call them “Joe” — emailed us recently saying the following:

I want to be able to decide when to work in Pagedraw vs. in code. Pagedraw could save a lot of time on visual stuff, but some things are just a lot easier to do in code.

(…)

If Pagedraw could output clean human-friendly code that I could also edit (and have Pagedraw pick up the changes), I would be a lot more likely to use it.

The tool that Joe described which picks up the changes to the generated code is what we call a round tripping editor. We definitely see the value in round tripping and whether you should do it is a discussion as old as time for people working on stuff in our space. However, we still much prefer the compiler approach over round tripping and I'll try to lay out our reasoning for that choice.

1. The reason Pagedraw exists today is that HTML and CSS suck. If we round trip, we are forced to take as input any and all HTML/CSS someone writes. This ends up tying our internal model to HTML/CSS way too much. So much so that round tripping editors mostly end up becoming visual WYSIWYG editors for HTML/CSS. We think all such WYSIWYG editors have sucked in the past because a visual editor of a language that sucks probably also sucks.
2. Instead we take the compiler approach and say “let’s come up with the best model for building UIs. Much better than HTML. Then we compile it to whatever god forsaken HTML the browsers expect these days”.
3. A corollary of point 2 is that we should actually be building a browser that natively supports our language instead of HTML/CSS but we don’t think that’d be a great go to market/adoption strategy.
4. By building the right tooling, we believe we can deliver all of the values of round tripping without the hassle of being tied to HTML and CSS. Right now all teams using Pagedraw make heavy usage of the override code and the external components features, where you essentially tell Pagedraw anywhere in the React component hierarchy “this component is owned by my codebase. Let me put whatever I want here” and that achieves the same effect of editing bits of the generated code. This can be used either for replacing a leaf UI component in the hierarchy or for wrapping a pure Pagedraw UI component with a stateful data fetching component.

All of our users have been relying heavily on features like external components (probably for the same reasons Joe wanted round tripping). Moving forward we are also starting to support things like adding your own CSS classnames or custom styles, to give users even more flexibility in tweaking the generated code (at your own risk).

In general we’ve been focusing a lot on making “mix and match Pagedraw + external code” feel very smooth, so round tripping vs not round tripping does not seem like a tradeoff anymore.