What if your website could delight every visitor, no matter their device or connection?
Why Progressive enhancement in Remix? - Purpose & Use Cases
Imagine building a website that looks great and works perfectly on your laptop, but when someone visits it on an older phone or with slow internet, the site breaks or becomes unusable.
Manually trying to support every device and connection speed by writing separate code for each case is confusing, slow, and easy to forget. It often leads to broken features and frustrated users.
Progressive enhancement lets you build a simple, working base first, then add extra features that improve the experience on better devices or browsers, so everyone can use your site without problems.
if (browserSupportsJS) { loadFullApp(); } else { showError(); }
<main>Basic content here</main> <script>loadExtraFeatures();</script>
It enables websites to work well for all users, no matter their device or connection, while still offering richer experiences where possible.
A news site that shows readable articles on any device, but adds interactive maps and videos only if the browser supports them.
Start with a simple, functional base everyone can access.
Add enhancements that improve experience on modern devices.
Ensure your site never breaks for users with older or limited technology.
Practice
Solution
Step 1: Understand progressive enhancement concept
Progressive enhancement means starting with a simple, working version of the app that works without JavaScript or advanced features.Step 2: Compare options to this concept
Make the app work with basic features first, then add extras matches this idea by focusing on basic features first, then adding extras. Other options rely on JavaScript or complex frameworks only.Final Answer:
Make the app work with basic features first, then add extras -> Option AQuick Check:
Progressive enhancement = basic first, then extras [OK]
- Thinking progressive enhancement means only using JavaScript
- Believing all data must load on client side
- Confusing with single-page app behavior
Solution
Step 1: Identify HTML tag for no-JavaScript fallback
The <noscript> tag is the standard HTML way to show content only when JavaScript is disabled.Step 2: Check other options for correctness
Options B, C, and D use invalid or non-standard tags or scripts that won't work as fallback content.Final Answer:
<noscript>Your browser needs JavaScript enabled.</noscript> -> Option DQuick Check:
Fallback for no JS = <noscript> [OK]
- Using custom or invalid tags for fallback
- Trying to detect JS with scripts inside fallback
- Not providing any fallback content
export async function loader() {
return { message: 'Hello from server' };
}
export default function Greeting() {
const data = useLoaderData();
return <div>{data.message}</div>;
}Solution
Step 1: Understand Remix loader and server rendering
The loader runs on the server and sends data to the component before rendering the page.Step 2: Consider no JavaScript scenario
Since Remix renders on the server, the user sees the server-rendered HTML with the message even if JavaScript is off.Final Answer:
The message 'Hello from server' is shown -> Option BQuick Check:
Server data shows without JS = message visible [OK]
- Assuming no output without JavaScript
- Confusing client-side hooks with server data
- Thinking loader runs only on client
export default function Page() {
React.useEffect(() => {
fetch('/api/data').then(res => res.json()).then(console.log);
}, []);
return <div>Loading...</div>;
}Solution
Step 1: Analyze data fetching method
The component fetches data only inside useEffect, which runs only in the browser after load.Step 2: Check progressive enhancement impact
Without JavaScript, useEffect never runs, so no data is fetched or shown, breaking progressive enhancement.Final Answer:
It does not fetch data on the server, so no content without JavaScript -> Option AQuick Check:
Client-only fetch breaks no-JS support [OK]
- Thinking useEffect runs on server
- Ignoring no-JS users
- Assuming fetch URL alone fixes enhancement
Solution
Step 1: Identify server-side data fetching
Fetching items in the loader ensures the list is rendered on the server and visible without JavaScript.Step 2: Add client-side filtering
Using useState and input events for filtering adds extra features for users with JavaScript, enhancing the experience.Step 3: Evaluate other options
The other options fail to show data server-side or rely only on client JS, breaking progressive enhancement.Final Answer:
Fetch items in the loader and render them server-side; add client filtering with useState and input events -> Option CQuick Check:
Server fetch + client filter = progressive enhancement [OK]
- Fetching data only on client side
- Not rendering initial data server-side
- Ignoring progressive enhancement principles
Ready to prove it?
Pass the test and this pattern moves unknown
