2023738764841894352

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