Eventually, I arrive at the lowest level with ridiculously simple utility functions.

I get those low-level tests passing, then climb back up (inside-out).

I go up a level, use my new functions, get tests passing, and keep climbing until my top-level functionality is done.

(4/4)

Instead, I start with top-level functionality and write tests for what the final expected output/behavior is (outside-in). These tests will fail.

To get these tests to pass, I descend down, writing failing tests for simpler and simpler pieces of functionality.

(3/4)

Outside-in means writing high-level tests about the expected functionality, then testing and extracting smaller and smaller pieces of functionality.

Inside-out means testing and writing the smaller pieces of functionality and composing them into larger functionality.

(2/4)

I was originally thinking of the implementation process, but both could be interesting. I've learned a little about the prioritization process, but I hearing the approach to gauging feasibility and how features are spec'd (such as test criteria/acceptance tests) would be great as well.

I would love to learn more about the process of developing features for browser engines. What are the languages? What is the testing approach?

Read the full article on 10 things I've learned from 10 years of studying lean manufacturing: luhr.co/blog/2025/07...

This is the core tradeoff of using a custom rendering and layout engine in Figma vs. building a tool directly with the web: it's going to be extremely difficult and costly to partially replicate features that entire browser teams spend years on, and there will always be a substantial lag.