Izzo: Dead simple question: what happens when your app just... doesn't work?
Izzo: You're listening to Exploring Next, episode 199. I'm Izzo, here with Boone, and we're talking about something that hit me hard this week.
Boone: The X.com JavaScript wall?
Izzo: Exactly. User tries to load the site, JavaScript's disabled or blocked, and boom — completely unusable. Just an error message and a suggestion to enable JavaScript.
Boone: It's wild that in 2026, major platforms still do this. Like, we've had progressive enhancement patterns for over a decade.
Izzo: Right, but here's why this matters beyond just X. How many apps are we shipping that completely collapse without JavaScript? And who gets left behind?
Boone: Corporate networks, older devices, users with privacy extensions, people on slow connections where JS fails to load...
Izzo: Exactly. So Boone, walk me through what's actually happening here. Why does disabling JavaScript break everything?
Boone: Most modern SPAs — single-page applications — render everything client-side. The server sends basically an empty HTML shell with a script tag.
Boone: No JavaScript means no content. It's like sending someone a TV with no power cord.
Izzo: Okay but that seems... fixable? What would a better architecture look like?
Boone: Server-side rendering as the foundation. Send actual HTML content first, then enhance with JavaScript. The app works without JS, gets better with it.
Izzo: So progressive enhancement. But I'm guessing there's a reason teams don't do this — what's the trade-off?
Boone: Development complexity goes up. You're essentially building two versions: the base HTML experience and the enhanced JS version.
Boone: Plus state management gets trickier when you're hydrating server-rendered content.
Izzo: From a product standpoint though, what's the user impact? Are we talking about a small edge case or...?
Izzo: Because I'm thinking about enterprise customers, accessibility requirements, international users with different technical constraints.
Boone: It's bigger than people think. Privacy-focused users run extensions that block JavaScript. Corporate firewalls strip it. Mobile networks in some regions are unreliable.
Izzo: And once you hit that wall, you're just... gone. No graceful degradation, no basic functionality. Total user loss.
Boone: Right. Compare that to something like GitHub — disable JavaScript and you still get the core experience. Slower, less interactive, but functional.
Izzo: So what would you build differently? If you were architecting this from scratch.
Boone: Start with a solid HTML foundation. Real forms that POST to actual endpoints. Navigation that works with regular links. Content that renders server-side.
Boone: Then layer on JavaScript for interactions — smooth transitions, real-time updates, fancy UI patterns. But it's additive, not required.
Izzo: What about performance? Isn't server-side rendering slower?
Boone: Initial page load is often faster because you're not waiting for JavaScript to bootstrap and make API calls. Time to meaningful content drops significantly.
Izzo: Hmm. I'm giving the current approach a D-minus for accessibility. But I can see why teams default to it — faster development, at least initially.
Boone: The irony is that JavaScript-heavy apps often perform worse on the devices that need the most help — older phones, slow connections.
Izzo: Alright, so what should people actually go build? I want concrete next steps. First, audit your current app with JavaScript disabled. Just turn it off in dev tools and see what breaks. Eye-opening experience. Good reality check. What else? Try building something with Remix or Next.js in SSR mode. They handle the server-client boundary really well. Start simple — a blog or documentation site. And definitely worth exploring htmx if you want interactivity without heavy JavaScrip