I built a contact form last week that works without JavaScript. In 2026, this feels almost radical. Every framework tutorial starts with client-side rendering. Every job posting wants React or Vue experience. The assumption is that modern web development means JavaScript-first applications.

But progressive enhancement—building core functionality in HTML and CSS, then enhancing with JavaScript—still solves real problems that fully client-side apps don’t.

The Performance Argument

A progressively enhanced form loads instantly. The HTML arrives, the browser renders it, and users can start typing. No JavaScript bundle to download, parse, and execute before the page becomes interactive. On slow connections or older devices, this difference is huge.

I tested my form on a throttled 3G connection. The progressively enhanced version was interactive in under a second. A React version of the same form took seven seconds to become usable. Seven seconds of staring at a loading spinner or blank page.

This isn’t React’s fault. Any JavaScript framework has the same challenge: you can’t interact with the page until the JavaScript runs. If that JavaScript is 200KB gzipped, and the connection is slow, users wait.

For simple forms, this wait is unnecessary. HTML forms have worked since 1993. They submit to a server, the server processes the data, and the browser renders the response. No JavaScript required.

You can then enhance the experience with JavaScript. Validate input before submission. Submit via fetch and update the page without a full reload. Add progressive disclosure or conditional fields. But the core functionality works without any of that.

The Reliability Argument

JavaScript fails more often than we admit. Third-party scripts block or error out. Ad blockers interfere with bundles. Users browse with JavaScript disabled for security or privacy. Content security policies prevent inline scripts. The JavaScript file fails to load because of network issues or CDN problems.

If your entire application requires JavaScript to function, all these scenarios result in a completely broken experience. A progressively enhanced application degrades gracefully. Forms still submit. Links still navigate. Core content remains accessible.

I’m not suggesting JavaScript failures are common for most users. But they happen often enough to matter, especially for critical flows like checkout processes or contact forms. Building the base layer in HTML ensures these flows work even when JavaScript doesn’t.

The Accessibility Argument

Progressively enhanced applications tend to be more accessible almost by default. HTML forms work with screen readers, keyboard navigation, and assistive technologies without additional effort. Semantic HTML provides structure that accessibility tools understand.

When you build everything in JavaScript, you have to recreate these behaviours manually. You need to add ARIA attributes, manage focus states, ensure keyboard navigation works, and test with screen readers. It’s not impossible, but it’s extra work that progressive enhancement handles automatically.

I’m not saying JavaScript applications can’t be accessible. They absolutely can, with proper attention and testing. But starting with semantic HTML gives you a strong foundation that’s harder to accidentally break.

The Maintenance Argument

HTML and CSS are more stable than JavaScript frameworks. A progressively enhanced site from 2016 probably still works fine in 2026. A React 15 application from 2016 likely needs significant refactoring to run on current tooling.

This matters for projects with long lifespans or limited maintenance resources. A small business website built with progressive enhancement can run for years with minimal updates. A fully client-side application requires ongoing dependency updates, security patches, and framework migrations.

I’m not advocating never using JavaScript frameworks. For complex applications with lots of interactivity, they make sense. But not every project is Gmail or Figma. Sometimes you just need a form that sends data to a server, and HTML does that perfectly well.

What Progressive Enhancement Looks Like

Progressive enhancement doesn’t mean avoiding JavaScript. It means starting with HTML, ensuring it works, then enhancing with JavaScript for better experience.

For a search form: start with a standard form that submits to a search results page. Enhance it with JavaScript to fetch results via API and display them inline. If JavaScript fails, the form still works.

For a comment section: build it as a traditional post-reload flow. Enhance it with JavaScript to submit comments via fetch and insert them dynamically. Without JavaScript, users can still post comments.

For a navigation menu: create it as a list of links. Enhance it with JavaScript for animation or mobile menu behaviour. Without JavaScript, all links remain accessible.

The pattern is consistent: build the core functionality in HTML, then layer JavaScript on top for improved experience. This requires thinking about applications differently than pure client-side rendering encourages.

The Tooling Challenge

Modern JavaScript tooling assumes client-side rendering. Create React App, Vue CLI, and similar tools default to apps that require JavaScript to display anything. They don’t make progressive enhancement easy.

Meta-frameworks like Next.js, Remix, and SvelteKit have brought back server rendering, which helps. But they still often require JavaScript for routing and interaction. True progressive enhancement—where the site works with JavaScript disabled—requires deliberate architectural choices.

I’ve found success with simpler setups. Express or Fastify on the backend, rendering HTML templates. Sprinkle vanilla JavaScript for enhancements. Use Hotwire or htmx if you want more sophisticated interactions without heavy frameworks.

This feels old-fashioned compared to modern JavaScript development. No build step for the HTML rendering. No component libraries. No state management frameworks. Just server-side templates and progressive JavaScript enhancement.

But it’s fast to build, fast to load, and reliable. For a lot of projects, those qualities matter more than developer experience perks from complex tooling.

When Not to Use Progressive Enhancement

I’m not absolutist about this. Some applications genuinely need JavaScript to function. Real-time collaboration tools, interactive data visualisations, or complex admin dashboards make sense as JavaScript applications.

If the core value proposition requires rich interactivity that HTML can’t provide, progressive enhancement doesn’t make sense. Build a great JavaScript application instead.

The problem is that the industry treats every project like it needs rich interactivity. A blog becomes a React SPA. A marketing site ships 300KB of JavaScript. A simple form requires a framework.

Most websites don’t need this complexity. They need fast load times, reliable functionality, and good SEO. Progressive enhancement delivers these better than client-side rendering.

Making It Practical

If you want to try progressive enhancement, start small. Pick a simple feature—a contact form, search box, or comment section. Build it with HTML first, test it works without JavaScript, then enhance it.

You’ll probably find it’s faster to build than you expected. Server-side rendering is straightforward. HTML forms handle a lot of logic you’d otherwise write in JavaScript. Validation and submission work without writing any client-side code.

Then add JavaScript for better experience. Fetch API for async submission. Real-time validation. Progressive disclosure. All the nice touches modern users expect. But they’re enhancements, not requirements.

For larger applications, consider hybrid approaches. Server-render initial HTML for fast first load and SEO. Hydrate with JavaScript for interactivity. Make sure core flows work even if hydration fails.

Frameworks like Remix and Astro encourage this pattern. They server-render HTML by default, then progressively enhance with JavaScript where needed. You get the benefits of both approaches.

The Industry Shift

I’m cautiously optimistic that progressive enhancement is making a comeback. The performance problems of heavy client-side apps are becoming harder to ignore. Core Web Vitals penalise slow JavaScript-heavy sites. Users expect fast load times regardless of device or connection.

Meta-frameworks bringing back server rendering is a positive sign. So is the rise of tools like htmx and Alpine.js that enhance HTML rather than replace it. The pendulum is swinging back toward simpler, more resilient web development.

But we’re not there yet. Most job postings still emphasise client-side framework experience. Most tutorials teach React or Vue without discussing progressive enhancement. The default assumption remains that web apps require JavaScript.

For self-taught developers like me, this means making deliberate choices about what to learn and how to build. Client-side frameworks are valuable skills, but so are server-side rendering, semantic HTML, and progressive enhancement patterns.

The web is resilient by default. HTML and CSS work across every device and browser. JavaScript should enhance that resilience, not replace it. That principle is as relevant in 2026 as it was when the term “progressive enhancement” was coined twenty years ago.

Build the base layer in HTML. Make it work without JavaScript. Then enhance it for better experience. Your users—especially those on slow connections, old devices, or with JavaScript disabled—will thank you.