Kyluke McDougall

Cornelius Weidmann

I recently migrated a project from Next.js to 

 and the first thing I bumped into is the infamous “Dark Mode flicker”. I don’t know why, but even in 2026 it’s still a mild pain to prevent this “flash” or “flicker” because there are so many ways to render content (SSR, SSG, etc.).

In this post I’ll cover how to implement Dark Mode for a server rendered setup (SSR). However, this setup can easily be converted to a statically generated setup (SSG) with minimal changes.

 is available on GitHub if you want to jump right in.

If you need a bit of guidance, then read along. Here’s what we’ll implement:

 enum and zod schema which we can use throughout the app (“light”, “dark” or “system”)

 to manage the styling throughout the app

 when the “system” ColorMode is selected

 to ensure the ColorMode from the cookie gets applied throughout the app

TanStack Start project, with MUI and zod installed.

With this setup, we’ll accomplish the following:

Prevent flash of incorrect theme on first load

We don’t strictly need this, but it does make managing the ColorMode throughout the app easier. We can use this both on the server and client side.

Next we create methods to read and write to a cookie, and set the default value to “system”. The beauty of these methods (server functions) is that we can call them from any component, client or server side.

Caveat: The methods must be defined in a file that ends with 

We create a MUI theme. It’s important to define the 

. We do this so we can pass the ColorMode to the 

Next we need to ensure that MUI uses our theme that we just created. We’ll use MUI’s ThemeProvider for that. We create a small wrapper and ensure to set the 

. By default MUI stores the ColorMode in localStorage, and since we’re managing the ColorMode ourselves we don’t need this out-of-the-box logic.

 double rendering which MUI’s ThemeProvider does out of the box to prevent SSR hydration mismatches. Again, we’re in full control of the ColorMode so we don’t need double rendering.

We need this script, because without it when a user has “system” selected (which is the default) and their OS has dark mode enabled then we’d have an initial flash of the “light” theme until the client is fully rendered.

This might look overwhelming at first, but the changes are relatively straight forward. First we call our 

 in the root loader. This ensures we read the ColorMode from our cookie before any rendering takes place. Next, we define the 

 component to make native UI elements (like scrollbar, form controls, background etc.) also adhere to the correct ColorMode. Then we pass the ColorMode through to our ThemeProvider and the RootDocument, where, in the latter, we attach the ColorMode via the class attribute to the 

 in the head when “system” mode is detected.

To make our lives easier we create a wrapper for MUI’s 

 hook. This ensures that our theme cookie always gets set when the ColorMode is toggled in the app.

How to build the ThemeSwitcher component is really up to you. The important thing here is that we need to

 to ensure that the ColorMode in the app always gets synced back to our cookie.

And with that we now have a fully functional end-to-end implementation of Dark Mode in Tanstack and MUI.

If, you do not plan on using SSR, then take a look at the next step where we make this entire setup work for SSG.

 flag to true, so the entire app gets pre-rendered. Then in our 

 (from Step 3) we need to make the following changes:

 and pass the ColorMode to it and, more importantly, configure it to use the 

 attribute, since that’s what we use on the main 

Dark Mode in TanStack with MUI

When I first sat down to tackle the infamous 1 BRC challenge—a challenge that forces you to process a massive 10GB text file with one billion rows—I wasn’t sure if I’d ever see the day when an AI would be capable of generating a production‐grade Rust implementation. But here we are. Let me take you through the story of how 

, the current latest reasoning model from 

, tackled this problem and iteratively improved on its own work.

The 1 BRC challenge is deceptively simple: read a huge text file containing temperature measurements from various weather stations and calculate per‑station minimum, mean, and maximum values. On paper, it sounds trivial but when you’re dealing with more than a billion rows (and over 10GB of data), every design decision matters. Should you read everything into memory, stream line by line, or use memory‐mapped files? Which data structures guarantee fast lookups with minimal allocation overhead? When using Rust, known for its raw performance and safety assurances, even the smallest inefficiency can add up.

The AI’s Approach: Write, Measure, and Improve

I tasked o3‑mini with writing a Rust application that could not only meet the requirements but would also give itself the opportunity to learn from previous runtime performance metrics. The main question was simple: “Can an AI produce runnable, efficient Rust code for the 1 BRC challenge—and can it optimize itself further based solely on runtime feedback?” The answer, as it turns out, is intriguingly promising.

At the onset, o3‑mini generated a straightforward implementation that processed an input file using conventional methods: reading the file, splitting lines, parsing measurements, and aggregating statistics into a HashMap. But that was only step one. The real magic happened when I fed the output back to the AI with detailed timing results (using Unix’s ‘time’ command stats). The AI, which had been designed to consider iterative improvement, started suggesting enhancements such as:

• Employing memory‑mapping via the memmap2 crate so that huge files could be accessed in zero‑copy fashion, avoiding needless memory overhead.

• Replacing the default line‑splitting loop with an approach using the memchr crate’s memchr_iter for quick detection of newline boundaries, significantly reducing per‑line overhead.

• Using lexical_core for fast floating‑point parsing—an obvious but crucial change given the heavy workload of parsing billions of measurements.

• Leveraging Rayon for parallel processing by slicing the input file into chunks based on worker thread count and using Rayon’s fold/reduce paradigm to merge per‑chunk hash maps efficiently.

These improvements weren’t just cosmetic. Each commit (as you might see in the git history) revealed micro‑optimizations. For example, caching the byte slice of the file content to avoid repeated calls, adjusting chunk boundaries to line breaks, and even changing the final result’s output formatting to reduce console I/O overhead. One later commit mentioned that the overall execution time was being driven down to around 16 seconds—an impressive performance for processing over a billion rows in Rust.

Iterative Self‑Improvement: A Glimpse Into the AI’s Mind

What’s fascinating is how the AI was able to iterate on its own code. After a run, it would review the performance metrics and compare them with previous attempts. Over multiple runs the changes were subtle and smart. It learned to minimize intermediate merging overhead by employing a fold‑based approach in Rayon; it switched strategies to avoid allocating new Strings when it could instead use references by “leaking” the memmap, thus providing a 'static lifetime to reduce allocation overhead. Each iteration was a snapshot of the AI’s evolving understanding of low‑level performance, eventually culminating in the final code we see here.

Down-to-Earth Engineering and the Final Code

What really stands out about the final version is its technical elegance without being overly esoteric. The AI adopted a zero‑copy parsing strategy: it maps the file into memory, then “leaks” the memmap so that its content survives with a static lifetime. This clever trick allows it to use slices (&'static str) as keys in our high-performance AHashMap without incurring cost of owning strings. The code uses memchr_iter to quickly iterate over line endings and a combination of memchr and lexical_core to both split and parse each line efficiently.

Here’s a breakdown from the final code that sums up the core logic:

– The function process_chunk takes a slice of the leaked file content, replaces expensive functions like .lines() with memchr_iter, and uses unsafe UTF‑8 conversion (safe in this context) to minimize overhead.
– It aggregates statistics using an AHashMap keyed to the weather station names.
– The main function divides the file into chunks by scanning for newline boundaries. These chunks are then processed in parallel using Rayon’s fold() and reduce() methods.
– Finally, the computed statistics are sorted and printed, with only a summary (first and last 10 records) if there are more than 20 stations, reducing I/O overhead during display.

What does this experiment tell us? Not only can an AI like o3‑mini produce competent Rust code for a highly performance-sensitive problem, it can also iterate upon its own solution based on runtime feedback. It shows that with the right guidance and feedback—that is, letting the AI see the execution times and prompting improvements—a machine can hone its approach quite like any human developer refining an initial prototype.

Yet, there are caveats. The AI’s iterations sometimes produce changes that are very fine grained or context‐specific. Understanding the entire trade-off analysis when dropping allocations or altering lifetime details still requires human insight. But for many performance–critical applications, having an AI as a coding partner that can suggest and validate micro‑optimizations is a promising glimpse into the future of software development.

The journey from a naive implementation to a highly optimized, production‑grade solution was not linear; it was an iterative process of feedback and subtle improvements. The experience was like watching an experienced engineer refactor code, but with the surprising twist that the “engineer” was an AI capable of understanding and acting on performance feedback.

When I reflect on the iterations, it's important to note that not every
improvement came without hiccups. There were several iterations where the code performed worse, or did not even compile. In a couple of cases, I had to inform the AI that the generated code would not compile—a stark reminder of the need for human oversight. At times, the AI produced code comments instead of actual code, which, unsurprisingly, had no impact at all. While the AI can be extremely helpful and demonstrate a keen sense for performance, continuous supervision from an engineer remains vital for ensuring true production-readiness.

For those passionate about systems programming, this experiment is both a showcase and a challenge: the future may soon see AI-generated code that not only works “just runnable” but one that continuously peers into performance metrics and optimizes itself—one commit at a time.

And if you’re interested in tinkering or benchmarking the final version, check out the GitHub repository. 

*The code and this blog was written by o3-mini

We're product and technology specialists

We build products and services for web and mobile.

Latest projects

Our interests

From our blog

Dark Mode in TanStack with MUI

We're product and technology specialists

We build products and services for web and mobile.

Latest projects

Our interests

From our blog

.css-1mm9aqi{-webkit-text-decoration:none;text-decoration:none;-webkit-transition:all .2s linear;transition:all .2s linear;color:var(--mui-palette-primary-main);border-bottom:3px solid transparent;}.css-1mm9aqi:hover{border-color:var(--mui-palette-primary-main);}Dark Mode in TanStack with MUI

Dark Mode in TanStack with MUI