[ ] Great. So our premise is that websites should work without JS, and I wanna start by emphasizing the word “websites” in the premise. There’s an important distinction to make here between websites and web apps. Because the premise is focusing on websites and not web apps, I think that it’ll be a lot easier for our side to argue this premise. We’re talking about websites, which are devoted to mainly conveying content to users, not delivering an interactive experience… So I want to just, in advance, say to our listeners that if our esteemed opponents on the other side try to switch the argument to focusing on web apps, that that’s not the right way to be thinking about this debate. So just in advance I wanted to get that out of the way.

If you’re focusing on websites, then one of the things to think about is default behavior that the browser gives us. If we use just HTML and CSS to build our websites, we get amazing default behaviors, specifically around links. Links will just work. Instead of implementing a link as a div with an on-click handler, where you can to basically then become responsible for all of the various click behavior that the browser does for you, like Cmd+Click to open a new tab, or middle-click to open a link in a new tab, or Right-Click not causing a navigation - these are all things that are really easy to get wrong if you implement a link as a div, for example, that has an on-click handler.

Additionally, if your site works without JS, then it’s probably quite accessible. It may not be perfect, but it’s probably quite good. Building a site that works without JS, so disabling the JS and testing the site out is a great way to see how some accessibility tools will experience your site. So if your links don’t work without JS turned on, that’s a problem; that’s gonna confuse accessibility tools, it’s gonna confuse search engines… So it’s not a perfect way, but it’s a good way to get a sense for whether you’re using the correct semantic tags whenever you can.

And then the last point I wanna focus on in my remaining time is that sites that work without JS probably have better performance - at least if it’s a content site - because you want to think about what the experience of a user is while the JS bundle is loading. On a slower connection, a page will be downloading the HTML, and the browser is really quite good at showing HTML to the user as that HTML is being streamed across the network; it has this thing called a speculative parser that can start to show this content. So while the JS bundle is loading, that’s what the user is gonna see.

So if your site works without JS, that means something is showing up on the screen before that JS bundle has been downloaded, which is good. That’s just like another metric. So if you build your site so that it works without JS, you will have better performance for content sites.

And lastly, another point about the speculative parser - the browser is quite good at firing off requests for resources that it finds in the HTML as it’s downloading that. So if you have resources like images that the browser encounters while the HTML is being downloaded, it will be able to start to do DNS lookups for those URLs, start to open TCP connections, start to do the TLS negotiation, and then eventually fire off HTTP requests for those resources, instead of waiting for this big JS bundle to download to get your app running. You’re not gonna be able to do that, so your site waterfall will just look completely different.

I think those are my main arguments.