We’re trying a brand new segment called YepNope, wherein your intrepid panelists engage in a lively debate around a premise. In this debate, Feross and KBall argue that websites should work without requiring JS and Divya and Chris say, “Nah!”
Please let us know if you like this style episode! We had fun recording it, but that doesn’t matter much if y’all don’t enjoy listening to it.
DigitalOcean – The simplest cloud platform for developers and teams Whether you’re running one virtual machine or ten thousand, makes managing your infrastructure too easy. Get started for free with a $50 credit. Learn more at do.co/changelog.
CrossBrowserTesting – The ONLY all-in-one testing platform that can run automated, visual, and manual UI tests – on thousands of real desktops and mobile browsers.
Click here to listen along while you enjoy the transcript. 🎧
Hello world, and welcome to an interesting edition of JS Party. We’re trying something new; you know how we like to experiment around here, and we have a brand new segment that we’re calling YepNope. YepNope.js was an awesome by our very own Alex Sexton back in the day, but this is a debate. No, it’s not inspired by the current United States political debates, it’s an idea from Feross to come up with a premise and talk about it, and have people take different sides, and see what happens… So we’re gonna see what happens here.
We should state upfront that we aren’t necessarily representing our own beliefs, we’re representing the side that we were assigned… And I’m your humble moderator and the assigner of sides. We have two teams - team Ferball, made up of one part Feross, and one part Kball. What’s up, guys? You’re teeing me up.
How’s it going?
Yep! We’re gonna find out how it’s going real fast. Team Shortskull, made up of Divya and Chris…
…representing the Nopes. What’s up Divya, what’s up Chris?
I mean, Nope…! [laughter]
You have to be way more negative here, Divya…
By the way, we would love to hear from you. If you love this segment and you want us to do it again, let us know; if you hope it disappears and never reappears, ever again, in the history of humankind, let us know. You can comment on the discussion page on Changelog.com, you can let us know on Twitter, you can send a carrier pigeon - we don’t care; however you’d like to let us know, we would love for feedback, because we are very much experimenting… So let’s get on with it.
And it’s super-simple, right? They just have to say Yep or Nope.
That’s right, you can Yep this episode or you can Nope it. But we’d appreciate a little stronger – what do you call them…? Arguments, than just Yep or Nope.
So let’s start. Segment one - this is going to be starting with team Ferball. Person one is Feross. Feross, you’ve got four minutes to introduce your side of the argument, “Websites should work without JS”, and you are gonna say Yep. Go ahead.
[04:11] 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.
Good job, you squeezed that last one in. I believe you had four minutes and eleven seconds, so I gave you a little bit of a break there. Alright, so there is your first argument from team Yep. Let’s hear from team Nope. Who do we want, Chris or Divya?
Um, not – not it.
Not it. [laughs]
They’re already saying Nope.
[laughs] He’s already saying no.
You’re representing team Shortskull. Yeah, well - he’s representing the Nope side, so I think he’ll say nope to the response. But go ahead, Divya, with your Nope.
I know that I said I wasn’t gonna address the rebuttal part of it, but I want to make the distinction between websites and web apps, which I think is a ridiculous distinction and difference, because a lot of the times it’s really hard to define what exactly a web app is, versus a website. So I’m just gonna throw that away. But… [laughter]
Throw it out.
You have 15 seconds. Anything else to say?
I think I’ll stop there, before I start a new thread.
You can’t start a new thread in 15 seconds.
Okay, very well done. Very well done. So there’s your first round on the Yep and the Nope. Let’s turn it over for the backup, team backup. It’s gonna be Kball backing up Feross. You have four minutes to disagree, or to state your side, whatever you wanna say. You’ve got four minutes, go ahead.
Excellent. First, I’d like to thank Divya for making our case for us by talking about progressive enhancement.
I think that makes our statement pretty well. Coming back to progressive enhancement… This is pdkl95, on December 27th, 2015: “Progressive enhancement is easy. Your framework or development tools should do most of the work for you. Maybe try different tools? Leaving out progressive enhancement is just lazy. Why would you prefer to show people a broken website as a first impression? Do you even know how many people see a broken website?”
Additionally, we can make an appeal to professional sensibilities, because gosh, web development pros - we’re all so professional. Donnatj on January 26th of 2015 states: “Professionally speaking, this is one of the most important tests of the quality of a site. When I see an Ajaxed site on a resume (this is dating them a little bit), it’s the first thing that I check, as it is a sign of a true craftsman taking care in their work. Ajax should ALWAYS degrade gracefully.”
Okay. I assume that’s your time right there.
I don’t know, I wasn’t timing. Were you timing me?
I was timing, but it sounded like a good place to stop. You had probably 45 seconds, similar to Divya…
I can look for more Hacker New comments, but I think my case has been made.
On the one hand, I wanna give you points for the research that you did. On the other hand, I wanna dock you points for just pulling in Hacker News trolls to state the case for you.
Yeah, I would question those… Appeal to authority. [laughs]
Yes, the place of all authority is the orange website.
I just figured, if we were gonna dive down into ad hominem attacks, I would put the Hacker News people out there as the targets.
There you go. Don’t attack Kball, attack the people he’s cited.
Yeah. That’s not in the spirit of debate though. I would never attack any of my opponents…
Well, let’s see what Chris will do. Chris, would you like to attack your opponents? Would you like to retreat into a cave? [laughter]
I know you’ve passed it to Divya once already; I hope you’ve got something up your sleeve.
Well, it was a heated debate. We’re gonna continue this, a little bit shorter spurts, passing it back, team-to-team… I know team Shortskull took issue with the website/web app distinction. I know team Ferball loves that distinction, but do they really believe it? I don’t know, we’ll find out more. Let’s let Shortskull speak more about that distinction, or any points you wanna make in rebuttal to the Ferballs.
I thought it was their turn.
Yeah, it is. Why Shortskull?
You’re saying Nope again. Come on now!
Come on, I just gave you the floor and you just batted it back to me?
I’m the moderator here, I make the rules. Go ahead, Shortskulls.
Time. Okay, Ferballs.
That sounds like a wonderful taste for progressive enhancement.
Yeah, but progressive enhancement – okay, I’ll just wait.
I think he stopped, you can go ahead. Get into it.
So it’s not about making your site work without JS for the Hacker News trolls, it’s about doing it because it actually makes your site better. Requiring JS to show some simple text on a page makes your site more complicated and more brittle, and as programmers, our entire job is to reduce complexity. The biggest challenge we face is this creeping complexity… And requiring JS to show some text is the very clear form of complexity, and complexity is the enemy. It makes it so that if something slightly goes wrong with the way the page is loading, then the entire thing is completely broken… Or the site just doesn’t work until the JS arrives. I rest my case.
Uh… I had a thought. Come back to me.
[laughs] He’s always trying..
“I would just like to quote Hacker News one more time.”
No, no… I’m gonna quote Divya’s article that she posted. It’s a wonderful article, talking about the distinction between websites and web applications being a false distinction… And I just wanna read this paragraph. It says:
“In my experience, there’s an all-too-common reason why designers, developers and product owners are eager to self-identify as the builders of web apps - it gives them a Get Out Of Jail Free card. All the best practices that they’d apply to websites get thrown by the wayside. “Progressive enhancement, accessibility, semantic markup - I would love to do that, but this is a web app, you see… That just doesn’t apply to us.”
Let me hop in here real quick, because I just can’t stay quiet any longer…
No, you’re supposed to be neutral! What is this?!
Yeah, you have to be in the middle. You’re the moderator.
Wait, so can’t you HTTP post the message up and then reload the page to see the new message?
You laugh, but if you look at–
Literal LOLs there…
Have you seen Gmail’s simple HTML interface? If you’re on a really slow internet connection or you’re on a really crappy phone, you can actually still use Gmail. You click the name of the email and then it just loads a new page with the email in it. And you can type into a box and hit Send and it posts it.
The nice thing when websites like Slack - or I guess web apps; whatever - web things…
Thangs. Web thangs…
Yeah, web thangs…
I build web thangs…
Yeah… I have no idea. Sure. [laughter] Was that an argument? I thought you were just commenting.
I don’t think that we’re disagreeing on that. The browser already knows how to create that experience for its built-in stuff, right?
One nice thing you can do, by the way, is just use a select element, and then the JS can see the select element there and then replace it with something at runtime… So if the JS doesn’t actually load, you still have the select element; it might not be as nice as your fancy little component widget-thingy-majigger, but will still work.
Yes, it’s standard. It’s fairly standard.
I’m going to appeal to authority and read some quotes at this time. [laughter]
“I’ve lost complete control of this panel.” Go ahead, Feross…
Okay. The first quote: “No code is faster than code.” Okay. Second quote “The code you write makes you a programmer, the code you delete makes you a good one, the code you don’t have to write makes you a great one.” The next quote…
Are you getting these off of fortune cookies, or where are these coming from? Confucius says…?
I can’t disclose… [laughter]
Is the copyright available such that we can put them on T-shirts?
Whoever said this is going to be objectionable and we’re going to disregard them?
Yeah, authority doesn’t work as well when the authority is anonymous.
Alright, last quote, last quote… “Inside every large program there is a small program trying to get out.”
And this was a positive thing…?
Yes, very positive. Very, very positive.
A hundred percent. It’s a huge statement.
You heard it here first.
Alright, we’re back for the behind-the-scenes of the debate. The post-debate - you know, I have to talk about who wins and who loses… Well, we’re not gonna do that. We want you to do that maybe, if you like. If you’re on team Ferball, let us know, if you think the Ferballs represent. If you’re on team Shortskull, holler back. The Yeps versus the Nopes. You can click on the show notes, there’s a Discuss on Changelog News button - it will all be on that commentary - or hit us up, @jspartyfm on Twitter if you prefer; let us know what you think.
Now, let’s actually represent our real thoughts, versus the pre-assigned ones that you were forced to represent. I’m curious what you all really feel about this. I’m firmly in camp “It depends”, which is the moderate camp… But I do think the distinction between web app and website is sometimes worth making. Especially in extreme cases such as a Slack, I do believe it is not in Slack’s best interest to build in a progressive enhancement way or to simultaneously have an HTML-only version of Slack that they’re keeping up to date with their other code. That’s my own opinion.
I do practice these things when they’re easy, or maybe just a little bit more effort, but if it’s orders of magnitude more effort, I tend to be a little bit more of a pragmatist. That’s where I stand, that’s why I say it depends. I’m curious what you all think about this in reality.
Yeah, I totally agree. I think obviously we have a limited about of time to work on stuff, and we have to prioritize the most important features that benefit the most users… It’s the same thing as prioritizing features that you’re gonna focus on building. You wouldn’t focus on a feature that benefits a really tiny fraction of your users while you have other features that you could build that would help a lot more of them. So it’s sort of like once you’ve taken care of all the easy stuff, then maybe if you have time you can think about making things really perfect and helping the edge cases. That’s at least how a lot of businesses operate.
But on the other hand, accessibility is an example where you actually do take a lot of time and energy potentially to make a site work for a very small fraction of people… So I don’t know; maybe we should be thinking of the JS crowd as just another smaller group of users that we should focus on. I don’t know. I really don’t know.
Divya, you represented the Nopes. Do you believe in the Nopes or were you just representing the Nopes?
So in general, I think it’s kind of a ridiculous conundrum that way, and I’m very much of the opinion – I believe in progressive enhancement, as everyone has so far mentioned, just because I think that that’s the ability to make sure that your site works in all scenarios. Because ultimately, you want the content to load, so people can at least see what’s happening on the page… But of course, you also want to optimize for the time to first interactive, because it’s really frustrating if everything loads content-wise, but then it doesn’t work.
Kball, you were strongly on the Yep… So are you strongly on the Yep?
Well, engineering is all about tradeoffs, so as everyone has said, we make tradeoffs and sometimes it’s the right choice, sometimes it’s the wrong choice.
I do wanna highlight something along this domain… There was a post on Brad Frost’s blog recently; we should probably put it on Changelog News, it would be great… But he was reacting to a tweet somebody posted; actually, somebody who was on our show at React Amsterdam, Kitze… He said “You’re working on a front-end project, and you can install max five dependencies. Which ones do you pick?” And everybody’s weighing in with their tools of choice, and yadda-yadda-yadda… And Brad Frost raises a really interesting point - if you were to say “You’re working on a home-improvement project and you can choose max five tools, which ones do you pick?” Your question would be “What’s the project?” Am I repairing a toilet? Well, I probably don’t need my saw.
I liked your response though, because I could tell your gears started to turn, and you started asking yourself “Well, what could we provide somebody in that case? Maybe a read-only version.” Feross said you could do an HTTP post - you definitely could do that. I wonder what – Gmail is the example there, where they do have the HTML-only version; I wonder if that’s because they’ve built that first and then they went – I don’t remember… Does that exist? I would love to know if they’re continually working on that, or if it’s just like “Well, this thing still works, because we haven’t changed our back-end APIs.”
I would guess there’s some segment of users that are getting some value out of it, or else they would have deleted it, like they delete so many of their products.
Right. And if you have just so many million people using it, then that small percentage is still a large amount of people.
[44:03] But if you think about an email client, it really isn’t a thing that should require – I mean, the fallback is you load a page, you read the stuff, you enter stuff into a form, you push submit, it posts it… It’s a very normal web flow. Whereas something like WebRTC is a dramatically different web flow. Anything that’s socket-based stuff - dramatically different.
So that’s where it’s like “Okay, is there a progressive enhancement?” If I’m building a collaborative video tool such as Appear.in, which we tried and it works pretty well (it’s WebRTC), is there like a fallback for that? Where it’s like “Hey, we’ll give you an ASCII version of what you guys look like…” [laughter]
So that’s why it does depend… And I think Gmail even has a more obvious fallback than a Slack, or a video tool.
One interesting thing about the Gmail example is maybe a better experience for you, Kball, when you’re traveling, would be if they actually got their act together and added a service worker to Gmail. Then all the resources that it actually takes to load up the Gmail UI would have already been on your computer.
Yeah. And then it would just be one API request to the server to get the new emails. I guess they do have Gmail offline now, right?
I think so.
I forget it if – it used to require a browser extension, or something…
Chrome-only, probably. Only works in Chrome.
[laughs] Actually, you can even enable – I guess you have to enable offline email for it to work, and it has to be on Chrome.
Okay. Yeah, it should just work out of the box. It’s too good.
Alright. Well, any other thoughts on this topic? Go ahead, Kball.
I think we also have an over-emphasis on cutting-edge and latest-and-greatest. I think about Cragslist… Every developer and every designer is like “Oh, I’m gonna build a better Craigslist. Craigslist is a piece of crap. Craigslist is using this old whatever… Millions of people still use Craigslist every day, and if they’re over the age of 40, many of them like it better than the other options.
Isn’t that more of an argument for first-to-market and network effects, versus quality tooling? They use it because they’re used to it.
It’s an argument that simplicity of use is undervalued in our industry. If we have a design and it’s two years old and we say “Oh shit, this design is way out of date. I’ve gotta update it.” My mom has not updated – I mean, now she’s got Alzheimer’s, and whatever… But even five years ago when she was still functioning, she could not understand anything that changed fast. She was baffled anytime something she was using changed… And that’s not uncommon.
I’m frustrated with the new Twitter interface. What the heck…?! The old one was fine. This new one adds zero value to me, and it’s… It’s change for change’s sake.
She wouldn’t like LinkedIn very well. Every time I log in, LinkedIn looks different. I’m like “What happened…? How many people are working on this?” It shows how rarely I log in, I guess…
Can you imagine if physical products worked the same way that tech products do? Especially cloud-based ones, where they can change out from under you at any time… Imagine if your toaster’s buttons suddenly were on the other side, rearranged, and you didn’t even decide; you just wake up one day and you can’t find the buttons. The manufacturer is like “Oh yeah, we changed them around. You know, following trends…”
[48:08] But I think that’s the argument with microwaves and ovens, right? Having all these extra settings that you don’t need, where it’s like “Oh… For popcorn and for chicken nuggets.”
Oh my gosh, I totally agree. I’ve always wanted to have a microwave that just has a +30 seconds button and nothing else.
Yeah, exactly. That’s all you need.
That’s all you wanna find, yeah.
Yeah, you just go plus, plus, plus, until you get to the thing you want, and you’re done. Maybe if you wanted two buttons, you’d have +30 seconds and +1 minute.
Or a dial.
Yeah, that’s even better.
Yeah. Simplicity is very valuable, and we as an industry dramatically underestimate that.
I think it’s similar with how we build websites and web apps (web things). The way we build things today is just this concept of how will it make the developers happy, and as long as they’re happy, the decision is a good one… Which I think is a false association.
Yeah. And none of this is to say that we shouldn’t have any emphasis on developer ergonomics, or that there’s never a reason for a more complex interface, or that we shouldn’t have any change. It’s just that all of these things, as everything in engineering, are trade-offs; they have consequences, and it is my belief that most people in the industry right now are not looking at closely at some of those consequences as might be valuable.
One last thought back on simplicity before we call it a day. We mentioned making things simpler is better; I think it’s Einstein quoted with “Everything should be made as simple as possible, but not simpler.” I don’t know if he actually said that, but remember the “not simpler” bit, because… You know, maybe you’re a chair manufacturer and you have the magical ability that Feross just mentioned, of changing products; and you think “You know what’s even simpler than a chair with four legs? It’s a chair with three legs. Because that’s one less leg, so that’s simpler… So that’s better, right?” And then you pull a leg out from underneath your customer.
So it depends. Don’t make it too simple.
That smug smile… You’re like “I made it funny.”
It’s just… Go off! [laughs]
I’m just imagining somebody fall over…
I’m just saying, you just constructed this whole statement in order to just say that one part… [laughs] Like “Let me construct this entire statement…” [laughs]
We see what you did there.
And at this point, I will start quoting random jokes.
This is quite a call-out. As an appeal to authority, I will now start reading jokes. [laughter]
What do you call a cow with three legs?
I don’t know, you’ve gotta tell us.
A tri-tip. I can keep going. What do you call a cow with two legs?
I don’t know… Tenderl– I don’t know.
Oh, my goodness…
It keeps going. One leg?
This is an appeal to carnivores…
You’re being exclusionary…
What do you call a cow with one leg?
Oh, gosh… It keeps going.
I can do dad jokes all day long.
Well, tell us.
Do you know that thing about “What can you talk about for 30 minutes with no prep?” “Bad jokes.” 100% there.
Okay. Well, finish the logical conclusion. A one-legged cow is what now?
Oh, that’s good. And then no legs?
[laughs] On the spot…
Ground beef…! Golf clap. We have to end the show, folks, before it ends itself. That’s JS Party this week. Do let us know if you like our new segment, YepNope. We had fun, and we’ll probably do it again, unless you all hate it, so… Holler at us. We hope you enjoyed, and we’ll see you all next time.
Also suggestions about maybe how to make the format better; if there were parts that you liked, parts you didn’t like… That would be really helpful.
And additional premises. We have to come up with a format and come up with premises. We have some ideas on other premises, but as Feross points out, if you misword the premise a little bit, he’ll use it to his advantage and undefine a part of it in order to win…
…and that’s very tactical, but not fair. So help us out with premises. We’d love to hear from you.
Our transcripts are open source on GitHub. Improvements are welcome. 💚