So happy everyone gets to play with this now! Incredibly thankful to @nvh, @edoardomercati, @jonastreub, @hemlok_, @_animify, @blixt, @huntercaron for helping to push this project over the finish line and everyone @framer who helped with testing & marketing. You all rock! https://twitter.com/framer/status/1387783277390573572

Launches are always a good time to reflect and reminisce, so here's the first GIF I posted on the project's progress a while back:

This was early on in a month-long exploration of he behaviors surrounding auto-sizing, which was (unsurprisingly for @framer) a long-lived prototype that helped me build an e2e test suite that codified the what we wanted independent of technical implementation. We still use it.

Once we'd agreed on the behavior we wanted, I dove into the technical implementation. This isn't obvious from using the feature, but the layout infrastructure it runs on is significantly different from how Framer worked before.

ayers in Framer used to store all of the information about their own layout. Even without rendering anything on the screen, Framer could already "predict" where every layer was going to end up.

This makes "offscreen" layout manipulation really straightforward, but it also meant we needed to reimplement layout algorithms (such as flex) from scratch. This seemed like a lot of wasted effort given that we already have a great layout engine at our disposal - the browser.

Framer has always been "of the web", and the new layout infrastructure is even more closely aligned with this idea. We now rely way more on the browser for layout, which means that we can take advantage of new browser features without having to reimplement them ourselves.

If you've used stacks anytime in the last 4 months, you've already been using the new layout system, because we silently swapped the stack implementation. With yesterday's release, you'll be using a lot more of it.

Relying more on the browser comes with its own problems, of course. There was an entire period of development I'll forever refer to as "rounding hell", where I dealt with constant issues around how browsers deal with subpixel positioning.

To give you a simple example, imagine you're centering a 50px wide <div> in a 99px wide container. Where should the browser paint this? And now imagine another 29px wide <div> inside the 50px one. Where does that one go? Turns out every browser does its own thing.

And there's no API to tell you what it chose! Here's a fun sandbox that shows only one of those issues - https://k1t3s.csb.app/ . It's a series of nested containers, each one ending up on a subpixel.

When the containers have transforms, you'll see them offset by a pixel on every nested level. Yet `getBoundingClientRect` considers them positioned at the exact same location as the non-transformed elements! Lies!

In typical web-dev scenarios this usually doesn't matter – the browser is at most a pixel off. Now say you're building a design tool where layer outlines must fit perfectly and this 1px error can be magnified 32x. Even the browser's built-in node highlighter doesn't do this right

I spent a ton of time reading through Blink, WebKit and Gecko source code, trying to reverse-engineer various painting behaviors. I buried days into spreadsheets full of presumed / actual coordinates trying to make sense of it all.

There were more than 100 cases to consider, at 3 different zoom levels, 4 browsers and 2 DPIs. I was a sharpie and a large glass window away from beautiful-minding this problem (this dates me, and I'm OK with this).

Every change had to go through the entire testing matrix, making its way through > 2400 cases. I ended up writing a custom test harness that allowed me to go through all cases in under 2 seconds, because our existing playwright-based test suite got too slow to work with.

In the end I think we ended up with the world's most accurate HTML node highlighter, which is I'm sure an achievement no one should care about, so I'll just leave it buried in this thread here, as a memento of battles fought and lessons learned.