Tailwind flowcharts, more state machines & secret iPods

Welcome to the 11th edition of Growing the Stack!

This week we have a Tailwind flowchart, another article about state machines, and what iPods can teach us about dependencies.


🪁 When and how to abstract in Tailwind

Daniel Wentsch illustrates when and how to abstract a Tailwind component in a flowchart.

In short:

  • Build with utilities when possible
  • If additional utilities solve your problem, create them and return to the previous step
  • Create components for the rest


🤖 Build A Confirmation Modal in React with State Machines

Dave Ceddia teaches us the basics of state machines, and how to build a confirmation modal with React and Robot.

Having a state machine powering an interaction reminds me of having good test coverage: it feels peaceful.

I can look at the state machine and know for a fact that there are no bugs lurking: these are the only states it can be in, and I hand-picked them, and all the transitions are accounted for. If the state machine is correct, the app will work correctly. Blissful peace of mind.

The example uses Robot, a state machine library I hadn’t heard of before. The small, composable API draws me in though.

While we ended up using Robot, we could’ve just as easily gone with XState. Both create finite state machines. Both work with React.

In our case, Robot had a couple things we liked: the tiny size (it’s only 1kb) and the concise functional way it lets you declare states. “One way to do things” is a guiding principle of Robot. This can be a pro and a con, because it can take some time to wrap your head around that “one way.”


🕵️‍♂️ The Case of the Top Secret iPod

Before you say “I already read this super-viral article last week!” hear me out.

This story is about how the US government secretly commissioned Apple help them build an iPod with a secret sensor embedded. It’s a great read! But that’s not why I’m sharing it.

I’m sharing it for this paragraph about the history of the iPod:

Apple bought the higher levels of the iPod OS from Pixo, a company started a few years earlier by ex-Apple engineers trying to write a general-purpose cell phone operating system to sell to mobile phone companies like Nokia and Ericsson. Pixo code handled the user interface, Unicode text handling (important for localization), memory management, and event processing. Of course, Apple engineers modified all this code, and over time, rewrote much of it.

This was 15 years ago. When reading that paragraph, it’s hard not to stand still and think about how far we’ve come.

Imagine starting a new project and outsourcing unicode text handling and memory management before you can even consider building something.

I may be biased as a web developer since low level concerns don’t really exist for me. But I can’t help but wonder what problems we are breaking our heads on today will be commodities 10 or 15 years from now.



I wouldn’t have the slightest idea how to modelling fluid in code. This “trochoidal wave” GIF makes it a bit comprehensible.