<ul>
<li>Being not constraint to a specific domain is one of React's killer features.</li>
<li>In React DOM, you can always fall back to creating custom <code>&#x3C;div></code> elements with your own styles if something doesn't work.
<ul>
<li>There's a maintainance overhead by doing so but it also unblocks so many use cases.</li>
<li>Even at the new Facebook.com, custom containers with with the full fallback to the browser were very common.</li>
</ul>
</li>
<li>Every good design systems that I have seen embraces this and allows their users to forward e.g. custom class names to their inner working components.</li>
</ul>


React’s Escape Hatch

<p>This is a list of non-trivial problems I have come across in the front-end community over the past few years. It mostly exists as a personal reminder. <a href="https://twitter.com/PhilippSpiess">Let me know</a> if you have something that should be added here!</p>
<ul>
<li>
<p><strong>Accessibility:</strong> Making web apps accessible beacuse it’s so easy with the Web fundamentals to break things.</p>
</li>
<li>
<p><strong>Bundle coverage:</strong> A lot of the code that is shipped in today’s bundles (CSS, JS, etc.) is not needed for the first render.</p>
</li>
<li>
<p><strong>Data waterfalls:</strong> Waterfalls is a term used to describe serial loading dependencies. E.g. to render a list of users we first download the list component, wait for it to load, then the list component makes a request to an API, waits for it to load, etc.</p>
<p>This is the number one issue that I have seen causing websites to be slow. It often manifests itself as a myriad of uncontrolled loading states that sometimes end in another loading state popping up. 😵‍💫</p>
<p>An interresting observation: Most applications could be able to resolve all the data needed for the initial page load on the server side based on the URL, params, and authentication tokens.</p>
</li>
<li>
<p><strong>Overfetching/underfetching:</strong> A client should only ever get as many data as it needs to render. Anything more is not needed and everything less is not enough.</p>
</li>
<li>
<p><strong>Interaction delays</strong>: If I interact with an item on the website, it should show an instant response.</p>
</li>
<li>
<p><strong>Layout shifting:</strong> Once the first elements on a website are shown, you don't want to have them jump around. This only causes confusion to the user and results in a poor experience.</p>
</li>
<li>
<p><strong>Developer experience:</strong> I think this term is often overused but the current way we write apps is definitely not the end game. We need constant improvements to the tooling because the cost of building is still way too high.</p>
</li>
<li>
<p><strong>Hydration:</strong> When you have a server-rendered HTML page and it needs to become interactive ASAP.</p>
</li>
<li>
<p><strong>Reliability:</strong> A meta-term that is all about <em>knowing</em> if your app functions. There are many vectors this can be done, however easy mechanisms also have a weak correlation to actual user problems.</p>
<ul>
<li>Error handling/tracking. Unfortunatly knowing that an error was thrown does not often relate to a broken website—Is the error recoverable by a user or is it crashing the whole page?</li>
<li>Browser crashes/freezes/loops</li>
<li>Uptime</li>
<li>Tracking core interaction uptime</li>
</ul>
</li>
<li>
<p><strong>Performance:</strong> This is a very convoluted term that justifies it’s own note. Until then, here are some thoughts:</p>
<ul>
<li>Measuring page loads is usually simpler than measuring interactions (navigations, popups).</li>
<li>You can measure performance in a lab but this will only ever be a <em>proxy</em> to the real-user performance metrics (aka RUM—Real User Monitoring).</li>
</ul>
</li>
<li>
<p><strong>Efficiency:</strong> Another meta-term for a few lower-level optimzations that rarely cause problems (but when they do, they are noticable):</p>
<ul>
<li>Memory usage</li>
<li>Heavy CPU usage</li>
<li>Uncontrollede scheduled tasks (e.g. <code>setInterval</code>)</li>
<li>Browser rendering issues</li>
<li>Network/IO overhead</li>
</ul>
</li>
<li>
<p><strong>Testing:</strong> While software testing is hard in every environment, front-end has a couple of special complexity with things like visual regression testing, accessibility testing, the reliance on a backend API, or the flakieness of browser instrumentaiton.</p>
</li>
</ul>


Modern Front-End Problems

<ul>
<li><input type='checkbox' disabled /> Set up the <a href="https://github.com/patrick-zippenfenig/us-with-german-umlauts#:~:text=Mac%20U.S.%20keyboard%20layout%20with%20German%20Umlauts,-This%20layout%20is&#x26;text=The%20layout%20is%20a%20modified,option%20%2B%20u%20%3D%3E%20%C3%BC">US-German Keyboard layout</a></li>
<li><input type='checkbox' disabled /> Map <code>tab</code> key to <code>escape</code> in Keyboards settings</li>
<li><input type='checkbox' disabled /> Connect iCloud and enable Find My Mac</li>
<li><input type='checkbox' disabled /> Set up 1Password</li>
<li><input type='checkbox' disabled /> Connect Google account for the Calendar integration</li>
<li><input type='checkbox' disabled /> Homebrew</li>
<li><input type='checkbox' disabled /> Oh My Zsh
<ul>
<li><code>git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions</code></li>
<li><code>git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting</code></li>
</ul>
</li>
<li><input type='checkbox' disabled /> asdf</li>
<li><input type='checkbox' disabled /> Alacritty Terminal</li>
<li><input type='checkbox' disabled /> Raycast</li>
<li><input type='checkbox' disabled /> Discord</li>
<li><input type='checkbox' disabled /> Chrome
<ul>
<li><input type='checkbox' disabled /> Set up two profiles</li>
<li><input type='checkbox' disabled /> Change the UI theme of one of the profiles (Pref. work to blue)</li>
</ul>
</li>
<li><input type='checkbox' disabled /> Firefox</li>
<li><input type='checkbox' disabled /> Spotify</li>
<li><input type='checkbox' disabled /> Flow (new and being tried out, an app for the Pomodoro technique)</li>
<li><input type='checkbox' disabled /> Hidden Bar (tbd, an app to clean up the menu bar)</li>
<li><input type='checkbox' disabled /> VS Code</li>
<li><input type='checkbox' disabled /> tmux</li>
<li><input type='checkbox' disabled /> Sync <a href="https://github.com/philipp-spiess/dotfiles">dotfiles</a></li>
<li><input type='checkbox' disabled /> Set up SSH keys for GitHub and remote servers</li>
<li><input type='checkbox' disabled /> Microsoft To Do</li>
<li><input type='checkbox' disabled /> Obsidian</li>
<li><input type='checkbox' disabled /> Paprika Recipe Manager</li>
<li><input type='checkbox' disabled /> Rectangle</li>
<li><input type='checkbox' disabled /> MonitorControl</li>
<li><input type='checkbox' disabled /> Telegram</li>
<li><input type='checkbox' disabled /> WhatsApp</li>
<li><input type='checkbox' disabled /> Things</li>
<li><input type='checkbox' disabled /> The Unarchiver</li>
<li><input type='checkbox' disabled /> Work Related
<ul>
<li><input type='checkbox' disabled /> Slack</li>
<li><input type='checkbox' disabled /> Loom</li>
<li><input type='checkbox' disabled /> Carbon Black</li>
<li><input type='checkbox' disabled /> Dev Environment</li>
<li><input type='checkbox' disabled /> Zoom</li>
</ul>
</li>
</ul>


New Mac Checklist

<ul>
<li>When working on complex systems, there are often more than one test parameter that changes. For example when working on a component for your design system, you need to test across all these different parameters:
<ul>
<li>Responsive Breakpoints</li>
<li>Dark/Light Mode</li>
<li>Accesibility options (screen reader, mouse-only, keyboard-only)</li>
<li>Different browser versions</li>
</ul>
</li>
<li>A good abstraction to help cope with this increasing complexity is by thinking of combinational matrixes.
<ul>
<li>In code, this can be multi dimensional arrays or nested loops. <a href="https://jestjs.io/docs/api#testeachtablename-fn-timeout">Jest even has a feature for it</a>.</li>
<li>In PR descriptions, it's helpful to draw a table to make sure you test all possible combinations throghoutly.</li>
</ul>
</li>
<li>Increasing the dimensions can make a full test run very costly though, so you can’t just blindly add more.</li>
<li>A very common pattern where this is userful is for manual pull request descriptions where you want to provide proof that you have exhaustively tested a new feature. A two-dimensional table might be used to show screenshots of e.g. different browsers and different responsive breakpoints.</li>
</ul>


Test Matrixes

<p>A collection of my random thoughts. This is a place for me to write down raw ideas, so don’t expect a high bar for quality.</p>
<p>Inspired by Josh Branchaud’s <a href="https://github.com/jbranchaud/til">til</a>, Lee Byron’s <a href="https://leebyron.com/til/">til</a>, and Shawn Wang’s <a href="https://www.swyx.io/learn-in-public/">Learn In Public</a>.</p>


Philipp Spiess

React’s Escape Hatch

Other Notes

About the author