Should Your Website Work Without JavaScript?

Welcome to Syntax on this. I'm Sorry.

Roll with it. Roll with it. Alright.

Welcome to Syntax. On this Monday hasty treat, we're gonna be talking about, does your website need JavaScript? Should it work without JavaScript? All of the things that we talked about in it was a what a potluck, and we had a clip go a little bit all over Twitter where where people had some conversation about, do you need JavaScript to to be available the whole time? Should your website work without it? We're gonna be answering that question very directly in this episode. We're gonna be talking a little bit about the ins and outs of why it matters, when it doesn't matter, why you know, how how you should be thinking about adding JavaScript to your website. My name is Scott Tolinski. I'm a developer from Denver, and with me JS always is Wes Bos. What's up, Wes? Hey. I am, excited to get this out because that clip was obviously, it was it was sucked in a way that it made us us look like,

some sorta idiot that wants to load all the JavaScript.

And people were very angry, and all the replies were were like, no. I agree with you. So we're gonna attempt to explain ourselves of, what we were trying to say there. Like, do do people turn off JavaScript? And the clip was like, there's no chance people are surfing the web with JavaScript turned off. Yeah. And that made a lot of people pretty peeved. So we thought we would explain that as well as the the sort of ideas behind progressive enhancement because, if you haven't listened to the 700 episodes, of Syntax, Scott and I are very much on board with that type of thing.

Yeah. Totally.

And you know what? If you're running JavaScript for anything, you're definitely gonna be wanting to run it for errors and exceptions because, yeah, your your app, no matter what, is probably going to have some issues because let's face it. It. We're writing JavaScript. I know we're gonna be talking about your app not working with JavaScript or working without JavaScript. But let's face it. You probably are writing JavaScript, and you're gonna wanna make sure that your users are not having a bad time if that JavaScript chooses not to load because there's a bug in your site. And, therefore, you can track and log that bug with Sentry, solve it nice and quickly, and make sure your users are happy.

Alright. So, real quick, let's summarize what it was said. The the clip itself said Scott and I were talking about, like, should your website run with JavaScript turned off? You know? And and that was a that that's a thing for a long time. People say, like, yeah. Some people have JavaScript turned off, and your website should still work a 100%. And we were like, really? Like, really? Are people really turning off JavaScript and surfing the web for it? And the answer to that is is no. Most people are not doing that. Most people don't even know how to turn off JavaScript. But what we're not saying is that websites are on slow and spotty networks.

Sometimes there's browser extensions that get in the way, and sometimes JavaScript fails.

And a Scott of people took the clip to think like, yeah. If JavaScript fails for whatever reason, you're blocking it. There's a a network request that went wrong. You went into a tunnel when you're in inside of a car. Should the websites still load? And and my thoughts I had in here is absolutely. Yeah. 1st first and foremost is your website should load.

It should be readable and mostly styled with JavaScript.

Meaning that, like, Wes, you should be able to get to all of the contents and be able to consume the website at least before the JavaScript even has a chance to to run.

Or if that breaks, you should still be able to consume absolutely everything. And I'm very much on that thing as well. Like, go to go to Wes. Go to syntax.fm.

Turn off JavaScript, and you'll notice that you'll be able to experience and read 97.4% of the website and its features without having JavaScript turned on.

So very much, I am I'm very passionate about that because that just provides a fast, good experience regardless of if you hate JavaScript or not. You know? Like, I think a lot of this sorta comes from a spot of people that just hate JavaScript or think that, like, we load too much JavaScript.

And I agree.

I don't hate JavaScript, but I do think that we do we load a little bit too much, and you shouldn't be relying on it. So I do think, Wes, a lot of people brought their own personal biases to that tweet.

Because that clip was not saying what a lot of people read it or list like, I I feel like people didn't even listen to what the clip was actually saying, and they were like, oh, man. These guys are saying you need JavaScript, and and I think that we're already loading too much JavaScript, and therefore, you know, I'm mad about this. So I do think people brought their own baggage to that

that tweet for sure. I I people are are Scott exhausted at the state of some web apps. There was there's even one where someone's like, you're committing a crime against this person. So I went to the link in the person's bio, and it literally says it was a link tree.

List of 8 links.

The whole website does not load without JavaScript turned on. That's like yeah. That's the ideal situation for a website that should work without JavaScript. Yeah. No kidding. Right? Come on. It's a list of links. So it's a it's a WebRing. Right? We used to do that stuff. Yeah. For sure. So

but that that also just goes to show how many people are actually not experiencing the web with it. And, also, like like, when the pandemic hit and I went up to my Scott, and I remember we did a couple shows on on me having, like, very spotty and poor Internet, that really brought a lot of the, like, oh, yeah. You have a fat pipe of Internet to your $8,000 cell phone, but there's a good chunk of North America or not even North America. There's a good chunk of the world that has spotty, slow, unreliable, networks. And having stuff rely on

6 megs of JavaScript to download first is is gonna be a bad time. Yeah. I also do wanna say, like, let's maybe even talk about how hydration fits into this. Because if we're talking about a website that Yeah. Works without JavaScript, pretty much the way that is happening is the information the HTML is written on the server. It is being loaded via a request and then parsed into the Dom and then loaded as just straight up HTML and CSS. Right? Mhmm. And then along comes the hydration step, which is what all of these Next. Js, you know, SvelteKit, all of these full stack frameworks are doing for us Wes the JavaScript then runs and kind of reconnects to Mhmm. How the HTML is being brought from the server. And, therefore, the JavaScript is handling all of the work after that point.

But if your application is written in a way Wes it gets to use these browser standards and that HTML is coming from the server, if that JavaScript never hydrates and you have link tags, you have forms, and all those things, your applications should still function as HTML and CSS. Right?

Yes. At least most of the features, especially at at the top of that is access to the content and interaction via forms and links on the page. So that kinda brings me to the next point here is that it's it's web standards first. You should be building your website with standards first. If it can be done without JavaScript, it should be done without JavaScript. If it can provide a, a good enough experience. You Node, there's some stuff in in CSS and HTML where it's just like, yeah, it works, but it's it's not as good. But there are most of the stuff we've gotten in the past 3 or 4 years in, HTML CSS land have been awesome. So looking at page transitions from 1 page to another. Right? Doing that with CSS is awesome. Why? Because if if the CSS doesn't load for some reason, and that's actually kind of an aside I had a question of, like, nobody in that conversation was saying, should your website work without CSS? You know? Like, what happens if the CSS doesn't load? Nobody talked about that. And Nobody doubts. Kinda understand that because, like, the CSS is not inhibiting any of the functionality of the website, but

that could also fail as well, and that'd be a bad time. Most websites Wes be very hard to use without CSS. You say it's not inhibiting the functionality, but soon, it will be. Right? Popover or I guess popover is an HTML. Popover is an HTML thing. Yeah. But I guess with the view transitions and stuff, those aren't necessarily yeah. Those are just kinda sprinkling.

I I had this whole thing working on this. I was like, is there a part of CSS where if the CSS doesn't load, the website wouldn't work? You know? Like, a navigation no. Navigation, the links would just show. Pop over, oh, that's t m l.

Like, scroll snap. It just becomes of ESLint of content. Yeah. Yeah. That's the whole idea behind we'll talk about this a second. That's the whole idea behind progressive enhancement is that you start with something that is is accessible, that is readable, that is is just the content first, and then you add on top of that to make a better experience for your users.

Yeah. Totally. And and and, I think along with that so we have these these new web standards that are coming to give us more functionality.

Yeah. It is funny that we had that response to that that tweet when I did a whole talk about not writing JavaScript at a JavaScript conference. I I went to a JavaScript conference, and did a talk about how to not write JavaScript stuff? Yeah. So I'm I'm definitely of the mind that you you should be using less as much as possible. But with these new APIs, you're getting so many great things Yeah.

Like the pop over, those types of things that you you would always having to reach for JavaScript before, and it it just is going to keep going in that direction.

I can think of so many UI elements. I used to always reach for JavaScript for that with these new new things, even with old things like, accordions and stuff like that. How many people are still out there building accordions with JavaScript when you don't need it? I'm sure too many. Another topic on that regard, we said linking, you know, reading the content, interactivity via forms. A lot of folks in the JavaScript world, one of the things they do that I've never loved is they just throw a button on a page, unclick on that button, run a JavaScript event to do a fetch and do some stuff. You wrap that button in a form element. Bingo. Bango. That should work without JavaScript, as long as your form JS, working correctly. Right?

Yeah. No. This is why I'm so excited about, React finally taking a stance via Yeah. Form actions because every other framework for a long time has had this this idea of a form should have an action, and that action should get or post that data to the server and then come back. And then we should use JavaScript on top of that to make it a little bit of a better experience where when you submit it, maybe it doesn't refresh the page entirely, but maybe it submits the the request via AJAX and comes back and just replaces, a success message. Right? That's a that's a better experience than a whole page reload, but it still works with without it. And, honestly, that's that's ideal to me, not because JavaScript is bad, but because, like, if there's a way to do it with web standards, we should be doing it that way first and then adding a bit of JavaScript on top of it. Yeah. And that's exactly what the the SvelteKit folks got so right about their form handling.

You write off you write interactivity to the the server as a form. You set it up like you would as if it were to work without JavaScript, and then you just sprinkle on a use enhance on top of it. And that makes it so it executes with JavaScript if JavaScript is available, but does not break it if JavaScript is not available. So

in my personal opinion, that's that's the API to use. Links, I put duh beside this one, but, like, the amount of websites I've been on where you can't open something in a new tab when it's clearly a link to something. You know? Like, you wanna, like, you're filtering on a website, and you you say, oh, I wanna view all the red ones in a new tab. And you right click and open a new tab, and it doesn't filter for the red ones. Like, Totally. Come on. That's a that's an easy link.

And that goes along with something that we did on the syntax site JS anytime you're doing those things like that, you're using query parameters in the URL instead of internal state.

I think it was Dan Abramov had a post a long time ago that was like, your URL is your state or something to that degree. And, like, I I so much vibe with that, that outlook of things where, like, if I have a state change in my application, it should be able to be shared that way. And the way that that is accomplished is via query parameters in the the URL.

Yeah. Form data and query params are the 2 major pieces of state management that people a lot of people are ignoring. And even on the Syntax website, when we initially had built the filtering for the type of show, and there's there's a bunch of filters when you're on the syntax website for the shows. And, I think I I don't know if I edit I rewrote it or edited it at some point, but it I just wrote a whole bunch of JavaScript to just generate links.

You know? And, based on the the current URL and the filters that you would like to to add, it simply just changes the links. And then in the popover is just a bunch of regular links, which you can click on, and it will change the page.

In our case, it doesn't actually do a full page reload.

Yeah. Totally. Next 1 we have here is server render if possible.

A lot of this, like, should it work with JavaScript or not, is is kind of becoming a moot point as well because of the swing back to server rendering.

I thought I would tell a, a good example of a story I had with 1 of my aunts at a party where we showed up to a Sanity, and everybody was to bring a dish. You know? And a lot of everybody came with their dish that was prepared because it makes sense to come with a bowl of potato salad versus bringing all of the ingredients to the party and making it at the party. Right? Like, that's kind of what client rendering is is that you have to bring the API. You gotta bring all of your libraries. You gotta bring all the rendering steps, and then you're basically waiting for the page to load and then saying, okay.

I got all this stuff.

I'm going to put the page together. Whereas, like, server side rendering is you make it at home first, and then you simply just bring the end results with you.

And we had a party once like that where somebody did show up to to one of the parties with all of the ingredients, and everybody's just like, and just asking people to help her and whatnot. And she's like, okay. Maybe, you should have server rendered this dish.

That's that's hilarious, Wes. I've never thought about it like that. Yeah.

Let's talk about progressive enhancement.

So progressive enhancement is this idea of, at a baseline, your content should be built on web standards so that it works for absolutely everyone. That includes people with slow and spotty connection, includes people with assistive technologies, include those people on low power Vercel, and then you add on top. You sprinkle on top the enhancement.

You make the experience better for the Sanity of your users who are on fast connections and modern browsers, things like that. And you can sort of say, okay. Well, if this were to break, if something were to go wrong, or if somebody was using it in a way that, I'm not expecting, it will still, at a baseline, give them the content and allow them to submit forms and change pages.

And then on top of that, we can start to add a whole bunch of the the fancy stuff on top. So I thought we'd go through just maybe a couple examples of progressive enhancement.

Yeah. I and and a lot of folks, first approached progressive enhancement from a a place where it was a CSS thing a lot of times in the past. Because before we were writing most of our applications in JavaScript, and JavaScript was just sprinkling on interaction here and there, A lot of us came to progressive enhancement from alright. There's all these cool new CSS features. How can we make sure the site still looks okay without these cool new CSS features? And and so a lot of us have been, like, bringing progressive enhancement with us for a long time, in in terms of, like, something that is important in our work because you want your application to look its very best for the people who can get the very best. But you also want the people who aren't getting that, whether it's slow Internet connection, whether it's an old browser, all of those types of things. You want those people to still have an experience worth using, as much as possible.

So yeah. So progressive enhancement, you could think of, like, right Node, CSS page transitions is a great one because CSS page transitions.

If you don't have JavaScript going on those because right now, the single page application version of them needs JavaScript to run. If you don't have JavaScript and you maybe don't have support for CSS page transitions, the fallback is that it just works like normal. It just It just allows you to navigate the page without an animation. That is progressive enhancement. Yeah.

Same with the, animating to height auto.

I posted a little video on TikTok the other day, and half the comments are, it's not gonna it's not Safari yet. It doesn't work as Firefox.

Get waiting 6 years for it to be implemented in IE. Like, all of these and it's just like, brother, do you understand that if this is not enabled on the user's browser, it simply just will be it I always think back to the what is it? Mitch Hedberg? The escalator is temporarily stairs. You know? Like, if it does not work, it still works. It just works in a different way. If the escalator stops working to go up the stairs, it's still stairs.

You can still use it at the end of the day. It's still temporarily stairs.

Yeah. For for sure. That's yes. Perfect. Let's see. The the most apt metaphor I think I've seen for progressive enhancement. Yeah. Except for the whole accessibility

point of,

stairs Yarn not very accessible. But besides that But it's still it it's enhancing it. I mean, stairs are inherently not accessible, so it's not like you're you're degrading the stairs experience.

Exactly. Yeah. Good point. I thought, like, let's just go through a couple websites with JavaScript off, and I'll show you a few examples of, like, something that is progressively enhanced. So I'm on the the Sentry syntax shop here, and I've got JavaScript turned off. This is, first of all, that little, whoo, that little animation, that still works with CSS, which is pretty nifty.

And you go here. If you want to change the change the, size that you have here. That still works, because that's probably a checkbox. Let's take a look here. Yeah. Input type oh, it's a radio. Yeah. But it's a radio button.

So that still works. Right? Like, that's not a fancy JavaScript button. When you click it, you set some state. No. It's simply just a radio button, and there is a form around this whole thing. Now if you wanna increment the quantity here, that's not working. Why? Because those plus and minus buttons are hooked up to JavaScript. So, oh, no. Does this experience broken now? No. It's been progressively enhanced. Guess what? It's a input. I can just type it with my with my keyboard here. I can add 2. Now I'm gonna add to cart. Normally, you get, like, a little animation, and it'll bounce into the into the cart here. Wes JavaScript turned off let me make sure I actually have my dev tools open. Add to cart, it just submits the form to the server and then does a server side redirect

to the the form here. Right? And, Wes, I wonder too if that experience could be enhanced. I know this is a Shopify thing. If that experience could be enhanced because those plus and minus buttons, the fact that they don't work without JavaScript, to me, that says those plus and minus buttons should probably be disabled or hidden in a way if JavaScript has not been loaded. Now you're gonna get a flash of of content if you don't, but, like, maybe you have them disabled. The JavaScript loads and they become enabled so that way you can actually use them.

And to me, that that's like a whole thing because if you're presenting a UI element to the user and it's nonfunctional, like, that's a broken experience.

I bet I bet the decision there is 99.999% of people visiting this page will have no problem. The JavaScript will load just fine.

And if they do have to do that whole enabling step, they're either running some blocking JavaScript very high in the page, which slows down the page, or, yeah, like you said, they're gonna you have that flash of content where everything everything pushes down and then your then your rendering scores, start going down the drain.

But, yeah, I I even wonder. You could put, like, a, like, a fade in. You know? Just

I don't know if I would worry about it too much. Here's what you do, Wes. You just hide that the plus and minus JS, and you just have it be like a wide input box.

Oh, yeah. Yeah. And then they just fade themselves on in. Yeah. So the other thing is that, like, could should this be a form in itself? You know? Should that just submit the form Oh. And refresh the whole page? Oh, I don't know. Maybe. But then But that Node Then you're getting into, like, state management. Wes. Probably not worth it. Anyways, that's Shopify. I wanna go on the syntax website because I found a spot where we can do a better job at progressive enhancing.

So let's go turn off JavaScript and refresh the page. Oh, look at that.

You can't even tell. JavaScript is not enabled on this page because it's there's nothing needed on this page. You know? Okay. I'm gonna go I'm gonna go to a a thing. It's not gonna transition itself.

Node. Temporarily stairs. It's just a regular full page reload instead of the fancy zoom. You know, like, the the title will page transition up here.

However, do you do you know what the the thing that won't work without JavaScript on this page? I absolutely

believe I do. What is it? I believe it's the audio player.

Yes.

And you play this, and I don't expect the whole audio experience that we have to work without it. Sure. But I do think that this should be, instead of a button, should it be a link to the m p three that opens in a new tab? You know? And then we could hide it. Yeah. Not even hide it. You just you just listen for a click on on the screen. It, I think. Yeah. Yeah. Intercept it and then play it. Because this button a good idea. Is not a form.

You know? It's not submitting anything.

But with JavaScript turned off,

it's not it doesn't do anything. Here's an idea too, Wes. This is how, I I worked at an agency back in 2011, and we had an audio player on our site that we wanted to be persistent while the user browsed pages. And in a pre JavaScript framework world, that wasn't possible. So what we did is we popped open a window that was a fully styled player. So you could have the fully styled player pop open in its own window.

That way you could still navigate this site while the player is playing. Oh, yeah. Just like a a player URL. So you could have it be a link that pops open a new u r or a new window. Yeah.

But then you couldn't you can't you can't run the player without JavaScript, though. It would just need to be an audio element.

You could have a styled audio element that looks more similar to the player. Like, it doesn't have to be

a Can you you can't style the audio element, though, can you? CSS,

can you not? No. Yeah. Yeah. But can't you no. You're right. Yeah. I I don't know. I haven't really used the audio element without JavaScript in a bit. Yeah. You just Yeah. You can't. There's not any,

like, maybe there's, like, a you can you can set the accent color, but that's about it. But, anyway, so, like, I think there's probably what about the search? The search search search as well could be,

Yeah. Probably not work in my mind because it it it's not a popover, I don't think, when we wrote it.

It's not done server side either. It's it's all client side. It loads a file that can then search it. But Yeah. Other than that, decent. Netflix, nothing.

Nothing. Yeah. That's that's a that's a obvious nothing to me. Yeah. And I was thinking about the even the sign in to a lot of these things. A lot of these sign ins won't even work if you are blocking Google Yeah. Because they're all using recaptcha. You know? And Yeah. If you can't generate a client side recaptcha token, Although, could you? Can you can you generate the client side

recaptcha token on the server and then pnpm that in the HTML, and then check the Deno a request back. Think you can. Yeah. Yeah. But here's here's for people who might be wondering why something like Netflix wouldn't work without JavaScript. Right? You think, oh, we have the the video element. You can just load a a video. The the way that video works for something like Netflix is that what you're loading is the m three u eight file or whatever that extension is. And what that file is is essentially a map to all of the chunks of video that it needs to download.

And this is the way that video streaming works. It downloads 1 chunk, and as it's down as it's playing that chunk, JavaScript goes and fetches the next chunk, and then they're constantly fetching the next chunk. And sometimes, you Node that the the quality can degrade from chunk to chunk, which is why you sometimes see occasional, like, quality dips, and then it'll go back up on your network condition. Because at that moment, it's making a determination of which quality version to grab based on your network connections. But if you don't do it that way, before a video plays, it would have to download that entire video to your your site. Not not to mention that, like, browser supports all over the place for videos. Yeah. And

there's DRM on on Netflix. You know? Exactly. DRM. It's actually interesting that there's no there's no browser standard for m three eight u a, whatever that is. You know? H o s JS what they call it. Yeah. H o s. Yeah.

So, yeah, that one's out the window. And, also, the other thing is that, like, a lot of times people expect websites to work without JavaScript, but people don't expect web apps to work. And, actually, it's it's kinda the other way JS if you want your web app to work without JavaScript, often Vercel solution to that is load a bunch of JavaScript first so that it works with the service worker. It works offline. Go back to all the episodes we've been doing on, local first. You know? All of that good experience for being offline and spotty connections are remedied by loading a bunch of JavaScript first so that it works in in all those scenarios.

That's funny. I have a note here that's like a wrench in this conversation. What about service workers and loading your scripts locally? Because you're loading a cached script locally. Therefore, you're not having to wait for the network. Now granted, you might still have to wait for a hydration step if your hydration step is slow.

But, like, I I think the the big rub there is that you're not getting any accessibility help, with client side JavaScript based things that, that you just have to pay more attention to it. But again, if you're using HTML and JavaScript, that JavaScript is coming directly from your local cache.

Like, that feels pretty I don't know. That feels pretty good to me. I I would like for somebody to poke a hole in this logic. Because to me, it does feel like a lot of these comments get negated if we load the JavaScript from our local cache.

Yeah. Yeah. Exactly.

I Or, like, even even if you don't have I guess I guess if your if your connection is Scott, that was the the big question is, like, if your connection is spotty, then you're you're still online.

However, requests will fail intermittently.

Right? But for JavaScript, a lot of that is just gonna be in your cache anyway, and the browser's not even gonna try to to go get it from, from the server because it already has it in its local cache, and that's without service workers or anything.

I also tried TikTok. The whole page doesn't even load. Nothing. Like, it's just white. It shows the header and then just white a white experience. Another good example was GitHub, where GitHub will load most of it. You can still load the source code, and you can still load Readme and things like that, but things like, the emoji replies in discussions or your own personal feed will not load if that's the case. So that's a good example of, like, most of the content and the search will still work because it's server rendered. It uses web standards. However, a lot of the, like, nice experience, the will not work without JavaScript if until that's loaded. Right.

But that's what we got here. So the answer, should your website work with JS? Yes.

Mostly. Without without JS.

Oh, yeah. Sorry. Should your website work without JavaScript? Yes. Mostly.

It it should.

If only because building websites via web standards makes your life easier at the end of the day, and you don't have to worry about loading a bunch of JavaScript on there. Are people actually turning off JavaScript and and surfing the web? Very, very few. And most of the people that are doing it are developers because they know how to do that type of thing.

But the people are not turning off JavaScript, but you should still be aware of situations that we talked about.

Yeah. For sure.

Alright. That's it. Thanks, everyone, for tuning in. We will catch you later.