<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>Front in the End</title><description>Lessons in thinking like a frontend engineer.</description><link>https://front-in-the-end.pages.dev/</link><item><title>The network is part of your UI</title><link>https://front-in-the-end.pages.dev/lessons/async/network-is-part-of-your-ui/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/async/network-is-part-of-your-ui/</guid><description>Every fetch puts your interface into one of four states, whether you designed them or not. The ones you didn&apos;t design are the ones your users meet at the worst time.</description></item><item><title>The document is enough</title><link>https://front-in-the-end.pages.dev/lessons/rendering/the-document-is-enough/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/rendering/the-document-is-enough/</guid><description>Every frontend architecture is a workaround for something documents couldn&apos;t do. Know what documents can do, or you&apos;ll pay for workarounds you didn&apos;t need.</description></item><item><title>Store less: state vs derived state</title><link>https://front-in-the-end.pages.dev/lessons/state/state-vs-derived/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/state/state-vs-derived/</guid><description>Most of what we call state is a derivation wearing state&apos;s clothes. Every derivable value you store is a synchronization job you just hired yourself for.</description></item><item><title>The platform beneath the framework</title><link>https://front-in-the-end.pages.dev/lessons/thinking/the-platform-beneath/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/thinking/the-platform-beneath/</guid><description>A framework is an opinion about the platform, not a replacement for it. Build the 20-line version once and every framework you ever meet becomes legible.</description></item><item><title>Race conditions: out of order is the order</title><link>https://front-in-the-end.pages.dev/lessons/async/race-conditions/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/async/race-conditions/</guid><description>The network reorders your responses and your UI applies them as they arrive. The fix is one rule — never trust arrival order — and one integer that enforces it.</description></item><item><title>JavaScript enters: enhancement vs takeover</title><link>https://front-in-the-end.pages.dev/lessons/rendering/enhancement-vs-takeover/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/rendering/enhancement-vs-takeover/</guid><description>The dividing line isn&apos;t how much JavaScript you write — it&apos;s who owns the DOM. Cross from enhancing to owning deliberately, because you can&apos;t easily cross back.</description></item><item><title>Single source of truth</title><link>https://front-in-the-end.pages.dev/lessons/state/single-source-of-truth/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/state/single-source-of-truth/</guid><description>Every copy of a fact is a future disagreement. The fix isn&apos;t better synchronization — it&apos;s making disagreement structurally impossible.</description></item><item><title>Logic outlives views</title><link>https://front-in-the-end.pages.dev/lessons/thinking/logic-outlives-views/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/thinking/logic-outlives-views/</guid><description>The code your framework never touches is the code the rewrite never breaks. Keep the rules of your product in plain modules, and let components be the thin layer that wires them to pixels.</description></item><item><title>Cancellation &amp; debounce: stop paying for stale work</title><link>https://front-in-the-end.pages.dev/lessons/async/cancellation-and-debounce/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/async/cancellation-and-debounce/</guid><description>The race guard protects your UI but still pays for every request. Debounce stops doomed work before it starts; abort stops it mid-flight. Most real inputs want both.</description></item><item><title>The SPA bargain</title><link>https://front-in-the-end.pages.dev/lessons/rendering/the-spa-bargain/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/rendering/the-spa-bargain/</guid><description>A single-page app trades the browser&apos;s free features for control. The trade is real and sometimes excellent — but the bill is itemized, and most teams never read it.</description></item><item><title>Where state lives</title><link>https://front-in-the-end.pages.dev/lessons/state/where-state-lives/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/state/where-state-lives/</guid><description>Component state is the default, and the default is a choice. The placement ladder: as close as possible, as durable as required — and the URL is criminally underused.</description></item><item><title>Make impossible states impossible</title><link>https://front-in-the-end.pages.dev/lessons/thinking/impossible-states/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/thinking/impossible-states/</guid><description>Clean frontend code isn&apos;t about line counts — it&apos;s about interfaces that can&apos;t express nonsense. Every boolean prop doubles your states; most of the new ones are garbage.</description></item><item><title>Optimistic updates: the kind lie</title><link>https://front-in-the-end.pages.dev/lessons/async/optimistic-updates/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/async/optimistic-updates/</guid><description>Showing success before the server confirms is a lie with a budget — cheap when failure is rare and rollback is honest, ruinous when either condition fails. Know the conditions.</description></item><item><title>SSR &amp; hydration: the pendulum swings back</title><link>https://front-in-the-end.pages.dev/lessons/rendering/ssr-and-hydration/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/rendering/ssr-and-hydration/</guid><description>Server-side rendering bolts the document&apos;s strengths back onto the SPA — at the price of rendering everything twice. Hydration isn&apos;t a feature; it&apos;s the bill for wanting both worlds.</description></item><item><title>Server state is not your state</title><link>https://front-in-the-end.pages.dev/lessons/state/server-state-is-a-cache/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/state/server-state-is-a-cache/</guid><description>What your components hold is never the server&apos;s truth — it&apos;s a snapshot, aging since the moment it arrived. Treat it as a cache, because that&apos;s what it is whether you admit it or not.</description></item><item><title>Web components: the component model you already have</title><link>https://front-in-the-end.pages.dev/lessons/thinking/web-components/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/thinking/web-components/</guid><description>The platform grew its own component system while everyone was watching frameworks. It&apos;s not a framework replacement — it&apos;s the interop layer, and knowing where it wins is the skill.</description></item><item><title>Failing honestly: retries, double submits, and idempotency</title><link>https://front-in-the-end.pages.dev/lessons/async/honest-failure/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/async/honest-failure/</guid><description>The deepest async bug isn&apos;t an error — it&apos;s not knowing whether the thing happened. Design for ambiguity with safe retries, and the impatient user stops being dangerous.</description></item><item><title>Choosing a rendering strategy</title><link>https://front-in-the-end.pages.dev/lessons/rendering/choosing-a-rendering-strategy/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/rendering/choosing-a-rendering-strategy/</guid><description>Content or app, stranger or regular, short session or long — three questions decide the rendering strategy. Fashion decides it more often, and that&apos;s why this lesson exists.</description></item><item><title>Designing the state of a feature</title><link>https://front-in-the-end.pages.dev/lessons/state/designing-state/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/state/designing-state/</guid><description>State design is four questions asked per fact — is it state, who owns it, where does it live, is it ours or a snapshot. Run the drill until it&apos;s boring; boring is the goal.</description></item><item><title>Surviving the churn</title><link>https://front-in-the-end.pages.dev/lessons/thinking/surviving-churn/</link><guid isPermaLink="true">https://front-in-the-end.pages.dev/lessons/thinking/surviving-churn/</guid><description>Frontend knowledge has a half-life, and pretending otherwise is how careers stall. Sort your learning into what compounds and what depreciates — then read every new tool&apos;s price tag the same way.</description></item></channel></rss>