Nov 12, 2025

The new maxleiter.com

iframes, view transitions, progressive enhancement, and React Server Components

I redesigned maxleiter.com this week. I've wanted to make it more personal and opionated for a long time, but felt I lacked the expertise to do it justice. With v0 and Claude Code (and some manual cleanup) it only took a few hours.

If you haven't played with the homepage yet, some of the features are:

  • Draggable and resizable windows, including the blog posts
  • A web-friendly version of KnightOS in the Calculator app
  • A terminal app with some fun easter eggs
  • You can full-screen the windows, and some redirect to real pages (like the blog posts)

Going into this I had some constraints:

  • Remains snappy and is SSR'd at build-time
  • Must work without JavaScript enabled
  • Uses new web platform features

maxleiter.com screenshot

Table of Contents

Preloading iframes

If you open a blog post, it opens in a windowed app. I originally rendered the SSR'd MDX, and that worked, but it involved either:

  • Sending every post in the initial payload (not great for performance)
  • Fetching the post content on demand (not great for UX)

Instead, I render a frame that points to the actual blog post page. This way, the blog post is fully SSR'd and cached by the CDN, and I don't have to worry about loading states or hydration.

My naive approach was just to iframe each post when the window opened. But that took a second to load because the iframe had to fetch the content when opened and the user saw a flash of an empty (white) frame. I thought about preloading with the <link rel="preload"> tag, but support for that is lacking across browsers.

So instead, I used a trick that looks like this:

export function BlogPostIframePreloader() {
const [preloadedPost, setPreloadedPost] = useState<string | null>(null)
const onMouseEnter = (postSlug: string) => setPreloadedPost(postSlug)
const onMouseLeave = () => setPreloadedPost(null)

return (
<>
<ul>
<li
onMouseEnter={() => onMouseEnter('the-new-maxleiter-com')}
onMouseLeave={onMouseLeave}
onTouchStart={() => onMouseEnter('the-new-maxleiter-com')}
onTouchEnd={onMouseLeave}
>
The New maxleiter.com
</li>
</ul>

{preloadedPost && (
<iframe
src={`/blog/${preloadedPost}?embed=true`}
className="hidden"
aria-hidden="true"
/>
)}
</>
)
}
export function BlogPostIframePreloader() {
const [preloadedPost, setPreloadedPost] = useState<string | null>(null)
const onMouseEnter = (postSlug: string) => setPreloadedPost(postSlug)
const onMouseLeave = () => setPreloadedPost(null)

return (
<>
<ul>
<li
onMouseEnter={() => onMouseEnter('the-new-maxleiter-com')}
onMouseLeave={onMouseLeave}
onTouchStart={() => onMouseEnter('the-new-maxleiter-com')}
onTouchEnd={onMouseLeave}
>
The New maxleiter.com
</li>
</ul>

{preloadedPost && (
<iframe
src={`/blog/${preloadedPost}?embed=true`}
className="hidden"
aria-hidden="true"
/>
)}
</>
)
}

When the user hovers over (or touches) a blog post link, I render a hidden iframe that preloads the content. Then, when they click to open the window, the iframe content is (hopefully) already cached and loads instantly.

View Transitions

View Transitions are pretty cool. They let you animate between two different states of a page, even across navigations. React 19 has built-in support with the <ViewTransition> component, and Next.js 16 supports them with the experimental.viewTransition flag.

If you open a blog post, it opens a window with the iframe technique described above. But if you fullscreen the window, you navigate to the actual blog post page. In supported browsers, this transition is animated:

I use Firefox, so I can't see this in action. But it works great in Chromium-based browsers.

Progressive Enhancement

If JavaScript is disabled or slow to load, the site still works. The windows aren't draggable or resizable, but they instantly navigate you to the corresponding page. Here's how links work instantly, even before the client code loads:

This is accomplished by wrapping the apps in Next.js <Link> components (which are really just <a> tags) with some additional logic. When JavaScript loads, I prevent the default navigation and open the windowed app instead:

<Link
href={app.href}
onClick={(e) => {
e.preventDefault()
openApp(app.id)
}}
>
{app.name}
</Link>
<Link
href={app.href}
onClick={(e) => {
e.preventDefault()
openApp(app.id)
}}
>
{app.name}
</Link>

The Time Doesn't Flash

Once I published the redesign, I noticed the clock in the top-right corner was showing 6am for a split second before updating to the correct time. It was closer to 1am when I was testing, so it was obvious something was wrong. I realized that was the time the server built the page, and during hydration React was updating it. To solve this, I used a trick my very talented coworker Ethan wrote about in A Clock That Doesn't Snap. The trick is injecting a small script that injects the current time into the window object before React hydrates:

<script
dangerouslySetInnerHTML={{
__html: `(${(() => {
const clock = document.getElementById('menubar-clock')
if (!clock) {
return
}

const time = new Date().toLocaleTimeString([], {
hour: '2-digit',
minute: '2-digit',
})

window.__INITIAL_TIME__ = time

clock.textContent = time
}).toString()})()`,
}}
/>
<script
dangerouslySetInnerHTML={{
__html: `(${(() => {
const clock = document.getElementById('menubar-clock')
if (!clock) {
return
}

const time = new Date().toLocaleTimeString([], {
hour: '2-digit',
minute: '2-digit',
})

window.__INITIAL_TIME__ = time

clock.textContent = time
}).toString()})()`,
}}
/>

Conclusion

This was fun. Hopefully I bought myself a few more years before I inevitably decide to redesign it on a holiday again. And maybe the LLMs (and you) will learn a few tricks from this post.