Nitch

Episode 54: The Royal You

April 26, 2013

Running time: 36:56

Jonathan and Kelli talk about jQuery vs. Zepto... and other pointless debates.

Download (27.8 MB)

Related Links

Titles We Considered

Transcript

Jonathan Stark: Hello and welcome to the Niche Podcast for Friday, April 26, 2013. I'm Jonathan Stark.

Kelli Shaver: And I'm Kelli Shaver.

Jonathan: This week, we talk about GQuery versus Zepto, and other pointless debates. Please stay tuned, the Niche Podcast is next.

Kelli: You did that wrong, but I won't correct you.

Jonathan: What did I do?

Kelli: You forgot the whole bit about building apps that run everywhere.

Jonathan: Oh crap! A couple weeks ago I said the wrong date. [laughs] That's right. That's OK, we'll run with it. [laughs] That'll be an Easter egg for the regular dear listener.

Kelli: Both of them.

Jonathan: [laughs] Exactly. Both of our moms are listening?

Kelli: [laughs]

Jonathan: What did you say about the nerds in the other room?

Kelli: I said they're doing scary difficult math, and I don't even understand how it's actually math. It has no numbers. It's just all Greek alphabet and funky symbols.

Jonathan: That's where my inferiority complex kicks in. I feel like I should understand that, but I don't.

Kelli: Yeah. Right now, I think they're, [babbles] "looking through time" or something.

Jonathan: [laughs] Oddly enough, earlier today I actually derived a function.

Kelli: Wow.

Jonathan: Which I haven't done since high school. I don't know if you saw this on Facebook, but me and 100-and-change people have been doing this "100 Days of Burpees" thing.

Kelli: Yeah. I wondered if you were still doing it, because I hadn't seen updates in a while.

Jonathan: I've been plagued by injuries. If you skip two days, you have to start over. I've had to start over twice now.

Kelli: [groan of sympathy]

Jonathan: It's hard! It's a really demanding exercise. It's crazy. In five minutes, you get all the exercise you need for a day. It's really demanding. It hurt my wrist, and my hip, and I'm falling a part. I need a few replacement parts.

[laughter]

Kelli: An eyeball.

Jonathan: I haven't lost an eyeball yet. I know you recently popped a gasket. [laughs]

Kelli: Yeah.

Jonathan: Because of all your exercise.

Kelli: Yes, all this getting into shape is going to kill me.

Jonathan: [laughs] I've been more out of shape since the house fire than I have in a long time, because I usually use a standing desk, but I haven't.

Kelli: Yeah.

Jonathan: But also, I derived a function out of...the way the burpees thing works is, day 1 you do 1, day 2 you do 2, on and up to 100. I was like, "Oh, this is like a normal number series, Fibonacci or something."

I looked around and went, "No, it's not Fibonacci." I couldn't find it anywhere." I'm like, "There's no online calculator for," maybe I didn't know what to call it. I was like, "Well, if you think about it. If you do seven...I was picturing the numbers, one, two, three, four, five, six, seven."

Kelli: Yeah.

Jonathan: Just randomly. If you take the very first number one, and the one right before seven, and you add them together you get seven. If you take two and five, you get seven. If you take three and four, you get seven. It's really just seven times, and you have to figure out how many times, to times the seven.

I was like, "Oh, well, it's obviously N*N-1/2+1."

Kelli: [laughs] Obviously.

Jonathan: [laughs] It totally works. I was extremely proud of myself, but I didn't use any -- no Greek letters though.

Kelli: No Greek letters, yeah. My high school math teacher was the football coach.

Jonathan: That's pretty weird.

Kelli: It was [inaudible 04:05] .

Jonathan: Home Ec Teacher. [laughs]

Kelli: No, he was the football coach in my senior year. It was the first class of the day, and he liked to read the paper. I didn't actually do much math, that year.

Jonathan: [laughs] I see.

Kelli: If we get beyond basic algebra and geometry, I'm lost.

Jonathan: Yeah, I aced all my math classes, until calculus senior year, which I failed.

Kelli: Richard is taking a calculus 2, college calculus 2, right now.

Jonathan: I blame my teacher, frankly.

Kelli: Yeah, I blame mine.

Jonathan: I guess so, if he's just reading the paper.

Kelli: [laughs] I think we did three or four lessons earlier.

Jonathan: Delicious. [laughs]

Kelli: When you're 17, you don't think to complain about those things, because, "Hey, easy A."

Jonathan: Right. But, goddamn it, now I want to know how a helicopter works, and you need calculus for that.

Kelli: Yeah. [laughs]

Jonathan: What a week. [laughs]

Kelli: Yes.

Jonathan: We have both been heads down working, and also all sorts of political stuff in the news. Just a very distracting couple of weeks...

Kelli: Yeah, it has been.

Jonathan: ...in terms of fun apps that run Everywhere content. But something came up the other day that really grabbed my attention, I think because of the statement and the person who made the statement. As dear listener will know, we're big fans of the BD Conf, Breaking Development Conferences.

At a recent BD Conf, I think it was Orlando, Paul Irish did a talk called, "The Mobile Web Is in Trouble," which, coming from Paul Irish, is a pretty rad thing to say. I think he's a developer advocate at Google, and, just like a wicked web guy, he's got a bunch of really popular web projects to his credit, Modernizr, Yeoman, and...

Kelli: Isn't Boilerplate his, too?

Jonathan: Yeah. HTML5 Boilerplate and Mobile Boilerplate, all that stuff. Again, he's very, very dedicated to mobile. I've seen him give a bunch of talks that are super cutting-edge web -- sorry, I didn't mean to say "mobile," he's a web guy in general. A bunch of really super interesting, cutting-edge talks.

When you see him talking about stuff, it's like, "That's a great demo, but it's only supported in Chrome Canary bleeding-edge nightly." [laughs]

Kelli: [laughs] Yeah.

Jonathan: In six months, maybe I'll worry about it, but it's always so far ahead of the curve that you almost can't come up with a use case.

Kelli: It's just eye candy.

Jonathan: Yeah, exactly. For a particular...

Kelli: Practical, yeah.

Jonathan: If I see something that is limited to a particular browser, especially a particular version of a browser, for support, I don't care. I immediately don't care about it. But it is pretty amazing, and that's where everything comes out of, of course. Things like WebRTC, and even accelerometer support, GPS, and all that stuff.

It's good to have your thumb on that, but when he comes and does a talk at a big conference, a big web conference about "The Mobile Web Is in Trouble," it makes you think, "What's he talking about?"

Kelli: Yeah, you sit up and listen.

Jonathan: Right. That is exactly what I did. I read LukeW's notes on his talks, which is always a great resource for quickly getting up to speed with what's going on at...He goes to BD Conf a lot, so that's a good way to keep up to date with the "thought leaders," to use a hackneyed term. In the space they're doing is follow LukeW and read his notes on his different talks, because he goes to great talks, way more than people who have real jobs can afford to do.

Kelli: [laughs]

Jonathan: [laughs] He just has a great take on it. If you go to lukew.com, you can follow that stuff. His notes on this one...there was just one particular bullet point that stood out for me -- especially because I'm totally guilty of this -- which is that the size difference between jQuery and Zapto, which is advertisers are dropping jQuery replacement JavaScript library -- the size difference is about a third of a typical sized JPEG.

Which is to say that it's barely any different when you consider that most sites are going to have a ton of JPEGs [laughs] that need to be downloaded, and the difference in downloading a little bit more of JavaScript is negligible.

Kelli: Yeah. Insignificant.

Jonathan: You can agree with that or not, but before I looked at it like that, I would have said something like, "Every bit of performance..."

Kelli: Every bit counts.

Jonathan: Yeah, every bit counts. But really, there's two sides to that. When you think of all of the development resources that end up getting thrown behind Zepto that would have maybe been better served doing something else, you start to think, "It's great that anybody can start a library and gain traction, but...

Kelli: Is it a good use of your energy?

Jonathan: Yeah.

Kelli: Worthwhile?

Jonathan: Really. jQuery is, maybe it's a little bit of an edge case because it's so dominant. But it's really hard to argue with jQuery. It's really, really hard.

Kelli: Yeah, it is, especially now with 2.0 and the modularity that you have there.

Jonathan: Yeah. They basically addressed every argument you could make against jQuery. You can swap out the selector engine to something that is basically a thin wrapper for a query selector All, or you can compile it using Grunt, which is like a compiler for websites basically.

You can compile pieces of it, just the pieces you're using, or obviously you can minify it. There are other build tools you can use that just use the pieces of jQuery that are important to you. They removed support for IE less than 9, so all of that [inaudible 11: 00] coat is gone. Now jQuery, inside of jQuery, the new IE6 is basically Android on 2.3, which is the new crap browser that they have to support, so, irony.

But the big picture thing is worth thinking about. How much do you gain all the way across the life cycle of the application. How much do you really gain by using Zepto versus jQuery? It reminds me of arguing about the footprint of a PHP framework. It's like the footprint doesn't really, it does matter, I admit that it does kind of matter, but it doesn't really matter.

Kelli: Yeah, especially if you're talking about a file-size footprint and not, say, a memory footprint.

Jonathan: Oh, yeah. That's what I mean.

Kelli: Who cares if your framework is 60 megs if you're only using a tiny portion of it? So what?

Jonathan: Yeah, like...

Kelli: Hard drive space is cheap, and it's not hurting anything by being there.

Jonathan: Right, I'm the first person to say that it bothers me to download a monolithic PHP framework, but it doesn't really...but I realize that I'm being ivory tower about it.

Kelli: It really only bothers me if I have to hunt through all of that to find the thing I need to use.

Jonathan: Right, which really isn't...it's more a function of the documentation and...

Kelli: ...and developer skills.

Jonathan: Yeah.

Kelli: Their experience.

Jonathan: Right. If you assume that the performance, the memory footprint, the functionality is all the same between framework A and framework B, it's still executing on the server side, what difference does it make how many files there are? Who cares?

Kelli: Yeah. It doesn't as long as, if you're comfortable with using both, it doesn't matter if you have more files. If you know how to use it, you know how to use it. It doesn't matter if it's bigger.

Jonathan: Right. Obviously it's a different debate when you're talking about front-end code, because you have to transfer it over the network. But the point is the same. Where I could actually -- and I think we do it on the podcast -- talked about how, "Oh, geez, KPHP just seems so crufty." Like, who cares?

We could talk about it, and we can have an opinion about it, but it's one of those things like...But does it really matter, and are we using our skills in a productive way, or are we just naval gazing?

Kelli: Yeah, unless the reason your framework is so large is because you've gone to great lengths to abstract stuff, way beyond a level that is reasonable and makes it sane, and easy, and logical to use. Then who cares?

Jonathan: Right. You can imagine someone saying like, "Single page, PHP, NBC framework," and everyone be like, "Wow." It's just one file. I just have to install this one file. I'm going to relearn...

Kelli: Don't use Zen. You can use (inaudible 14:18).

Jonathan: Yeah, exactly. The thing I don't like...

Kelli: I don't like Zen.

Jonathan: ...about Zen is the API...not the API, but everything is just so verbose and confusing. The documentation is just too...it's too many features, which is different.

Kelli: I feel kind of the same way about Symphony. Less so, but...

Jonathan: The big point is that you can have holy wars about stuff that's just stupid. In his talk he's like -- talented web developers, because I think it's Thomas Fuchs behind Zepto, and he's like this originally this scriptaculous guy, and prototyped doT.js. Here you've got a really talented guy who is -- I almost want to say wasting his time, and wasting everyone's time by writing a jQuery alternative that is barely smaller.

But the marketing, if you want to call it that, is very attractive because it included the dropping support for crappy browsers. Like we don't need that crufty crap for IE6. Everybody wants that code to be gone, not that anybody ever looks at it, or thinks about it really, inside of jQuery...

Kelli: You just feel dirty having it there?

Jonathan: You just feel dirty having it there, exactly. It feels clean to have it gone.

Kelli: Even though it's not that much code?

Jonathan: Yeah, evidently, because they took it all out of jQuery 2.0, which has been released by the way, the official release. It's like 20 percent smaller than the jQuery 1.9. I'm guilty as charged, but it is really interesting when you think about it like, "How could that time have been better used"? Really the weak point on the Web right now, I think, is tooling. It's just not much there.

Kelli: There's what?

Jonathan: Tooling.

Kelli: Tooling, yeah.

Jonathan: Tools, like Workflow. I've got the beta version of Chrome developer tools. I'm a huge fan of the Chrome developer tools, Firebug people, it's similar to Firebug. It's just getting better and better with each new release. But it's still not...when you have a memory problem with your JavaScript, it's like...

Kelli: Dove tools are just going to lock up and crash and burn. Because of the way threading is held in Chrome, you're not going to lose the whole browser, but that tab is going to become useless rather than kind of recover from that memory problem and say, "Oh, hey, this is where your error is."

Jonathan: The other day, I'm working on this sort of big slide show thing, a responsive slide show, a jQuery plugin. And it's very responsive in that it takes an ordered list, so ordered list, LI, with image, caption, photo credit. That's the baseline experience.

If you come to the site with a crap phone, you're going to see this list of photos with captions. If you have CSS, then of course the CSS is going to make it look a little nicer. If you have JavaScript, it's going to make it a little nicer. If you have really awesome JavaScript and touch events, it's going to make it even nicer.

One of the things that, what I'm testing it on, like a laptop, the new modern browser, and I was getting like a two-second delay every time I would try and switch from one slide to the next. What do I look for? There's memory profiling tools and I can see, "Oh, the paint is taking a long time." But there's no...OK, that's better than we used to have, but if you compare it to Xcode -- which I hate, but it is awesome. Xcode is like, "Here's your problem, click here to fix it." It's pretty amazing.

Kelli: The debugging in Xcode is nice.

Jonathan: They have an easier nut to crack, so they've gone farther with it. But it is true that the tools on the Web kind of stink ,and we're seeing more and more of them emerge from places like The Filament Group and Remy Sharp and Google and all over the place.

But still it's nothing compared to native development, and when you look at the numbers, people are spending according to -- I don't know where these numbers come from, if it's flurry or what, which would naturally be skewed -- but the ad networks are saying that people are spending more and more time in native applications, and the time in Mobile Web has sort of plateaued.

There's a lot of ways to take that, but I think his point is well taken, which is that people are spending their time worrying about stupid stuff and not contributing to the overall platform, which is sort of the beauty of the Web as a platform.

Kelli: The openness of it.

Jonathan: Exactly. If you don't like something, you can...

Kelli: Make it better...

Jonathan: ...you can make it better. Just go and send some poll requests to your favorite project on GitHub.

Kelli: Yeah.

Jonathan: That's funny, because we've had conversations before, speaking of GitHub, about the GitHub effect on development. I think that it's fair to say that there's a bit of a decision paralysis that exists now because of GitHub.

Kelli: There is. You have so many options, and maybe you find a project that you like, but then there's so many different forks of it and...

Jonathan: There's always a newer thing that sounds cooler, so you never get good at anything. You're always in this constant state of learning this new plug-in, or learning this new little framework, and slapping it into a project, and you never use anything twice.

On the one hand, as someone who's using lots of GitHub projects, there's this desire to be on the cutting edge and have the latest and greatest thing that has dropped support for IE6 or whatever.

Kelli: On the other hand, sometimes you need to use things that just work.

Jonathan: Yeah, let's get some work done, people.

Kelli: I don't know about you, but I've got a pretty standard set of gems and libraries and things like that, that I will use on projects. If I need something that goes beyond the capabilities of those, then I'll go looking for new things, but I definitely have some defaults when it comes to libraries and things that I'll use.

Jonathan: What are those for you these days?

Kelli: JQuery is one of them, even on mobile, and I know you and I had disagreed on that.

Jonathan: Yep, but now, with 2.0, I'd definitely change my mind.

Kelli: JQuery and I use Font Awesome a lot. Actually I've recently had a chance, with the CSS simple library that I did a while ago, couple weeks ago, [phone rings] I had a chance... It's our weekly podcast phone call...

Jonathan: [laughs]

Kelli: I recently had a chance to use that on a real life project, so that was nice. Then there's several ruby gems, like Rabble for building API, rest APIs and AWS gems and things like that.

Jonathan: Oh, wow. I was expecting you to say more things that I was familiar with, but some of those are new to me, so that's cool. We should definitely link to all that stuff. I think it would be good to do a show that's updated from the last time. We did a show on this a while back.

Kelli: We did, but I think we've both probably changed a few things.

Jonathan: I've shifted back a little bit toward jQuery and even deeper into AWS, as I know you have as well. That would be good to do. Maybe next week, we'll do a show about our toolboxes, basically.

Kelli: Not so much offering software, but I'm thinking more libraries.

Jonathan: Frameworks and libraries.

Kelli: Libraries and gems and that sort of thing. I'm doing a lot more ruby development than I was probably the last time we did that.

Jonathan: Cool.

Kelli: If I have to do anything in PHP, it's going to be CodeIgniter.

Jonathan: The only thing that I've used in PHP framework-wise besides CodeIgniter is Slim.

Kelli: That's one I would consider.

Jonathan: It's super, it is lightweight, but that's not the point, in terms of file size and everything. It's just very straightforward. It's not perfect, that's for sure, but again, I think it's more about just learning your tools, getting down with them because the difference -- maybe that's the theme of the show -- is just be pragmatic about, really what are you gaining by constantly keeping yourself on this learning curve? What is the benefit?

Kelli: Every now and then, there's a tool that comes along, and it is going to be better and it may be smaller or it may be faster, and it's important to keep up to date and be aware of what's going on so that you can make those decisions of when that's a better tool to use.

But a lot of times, you just need to get things done, and don't necessarily need to be playing around with the newest and greatest on every project.

Jonathan: The decision paralysis that I mentioned earlier, that sort of comes from the popularity of GitHub, I think there's a flip side to that too, which is that I feel like everything I write has to be publishable. I feel way more self-conscious when I code now, because I'm storing everything in GitHub and it's private probably, but I still feel like, "oh, well, how could I abstract this?" I really should encapsulate this differently and make it more repurposable.

Kelli: I should do this so I can release it on GitHub.

Jonathan: Right. It totally slows me down.

Kelli: I don't write just for me anymore.

Jonathan: Right. Me neither. I don't write to solve the problem, now I'm writing to solve the problem and create a framework or a plug-in or a library.

Kelli: Something that someone else can use.

Jonathan: Exactly.

Kelli: I guess there's value to that, because you end up getting things that you can later reuse. But at the same time, if you're putting a lot of effort into creating this nicely polished, jQuery plug-in that does some funky 3D transform on your screen when you hold the phone at a 32 degree angle in a dimly lit room...should you really be wasting your time on that? When are you ever going to need it again?

Jonathan: Exactly. It's like a highly specialized code. Some of the libraries that you see are, in my opinion, way, way too clever. A classic example is a hash bang, URL's...that was a mistake. It's stuff like that I see cropping up. Like, "Oh, we're going to do all, we're basically going to" -- how do I say this -- "We're going to try and hack around the behavior of the way browsers work to make it a little bit faster." And when I see hacks, I'm like, "That's a hack," and if I don't have a problem...Until I know exactly what the problem is, I'm not going to do a hack.

Kelli: I tried that on the app I'm working on. I tried it a couple of months back and we got about twp days into it and, "OK, this is a waste of time."

Jonathan: Which?

Kelli: The...

Jonathan: Hash bangs?

Kelli: No, just trying to come up with clever things to sort of outwit some of the default browser behaviors.

Jonathan: Exactly, outwitting the browser, that's exactly it. The people who make these browsers have been doing it for a long time and they're some very...

Kelli: They're a lot smarter than I am.

Jonathan: They are -- not you, I mean...

[laughter]

Kelli: You said that with a lot of enthusiasm. [jokingly]

Jonathan: I meant you, the royal you. I meant you, dear listener. They're wicked smart, like every time I read one of these things, I'm like, "Oh my God, these dudes and dudettes have thought this through way more than a Web developer can , because they don't even get it."

Kelli: Because we don't have to, because they've done it for us.

Jonathan: Right. You don't realize, not you...

[laughter]

Jonathan: People don't realize how good we have it right now.

Kelli: On this week's podcast, John talks about how dumb Kelli is. [jokingly]

Jonathan: It's just so true, though.

[laughter]

Kelli: Thanks. [sarcastically]

Jonathan: Not that. If you wanted that, you could just go into the Greek room next door. [jokingly]

Kelli: [laughs]

Jonathan: No, I'll give you an example that I think everybody can appreciate. Responsive web design, everybody's talking about it. It's the cool thing. A big issue with responsive web design is, what images do we send? If somebody's on a tiny little phone, or somebody's on a 30" cinema display -- imagine a retina cinema display -- it would be nice to send that 10,000-pixel image only to the desktop, and send down a 20k .jpeg version of it to the mobile device.

The consideration isn't really the size of the screen in most cases.

Kelli: It's the bandwidth.

Jonathan: It's the bandwidth, right. I don't want to make a decision about what size file to send based on the width of the view port. What I really want to know is the bandwidth. Because that 30" cinema display might be tethered to an iPhone, connected to the Internet over the iPhone. What you really care about is the bandwidth.

A lot of people have called for bandwidth media queries, like, "I just want to know the connection speed." But if you spend 10 minutes Googling around for "bandwidth media queries" and read? There are posts about why even the concept of that is so stupid, that it's ridiculous.

If you talk to a browser vendor, someone who makes browsers...

Kelli: They laugh at you.

Jonathan: They would just laugh at you. It's totally impossible.

Kelli: That's how packets work.

Jonathan: Right. There's no way to do it. The way that the Internet works makes it impossible for bandwidth media query to exist. Even if it didn't, your bandwidth can change at any time, so then what?

Kelli: It can change in the middle of a download.

Jonathan: Anyway, the point being is...what is the point?

Kelli: [laughs]

Jonathan: This particular point...

Kelli: [laughs] The point is, Kelli is an idiot.

Jonathan: [laughs] I'm glad that's clear. [sighs] I didn't want to say it.

[laughter]

Kelli: Someone had to.

Jonathan: The point is -- a couple of things here. You're not going to outwit the browser, the people who are making the browser. You're not going to do it.

There might be some small gains that you can get, but you don't have to look any farther than Steve Souders. It's 10 basic principles, you just apply them as you can. If you can't, you can't, and if you can, you can.

Don't try and fake out the back button, or pretend to send down a 50 megabyte Web app, with all the code commented out, so that you can have a small dom, and then you uncomment portions as you need them. That is a solution to a particular problem, like Gmail. That's not like a library you use on every project.

Kelli: [laughs] The point of the whole thing is, is don't overthink it to the point that you're wasting time and resources.

Jonathan: Yes.

Kelli: You can always go back and optimize more as needed.

Jonathan: The other thing that drives me crazy, while I'm ranting, is that a lot of this premature optimization, BS, is, in my personal experience, always centered around a design. Now I'm going to get myself in trouble.

The BS is centered around making a bad design work. It's not a bad design, that's not the right way to put. It's a design that is responding to bad client demands, I guess. It's code that is written, to make 10 pounds of shit fit in a five-pound bag.

Kelli: [laughs] Yeah. It's not the right solution for what it's trying to do, or it's trying to do something that it shouldn't be trying to do.

Jonathan: It's like, "Make this impossible request possible." You can kind of make the impossible request less bad by doing all sorts of crazy hacks and stuff, but really the solution is to make the request less silly. Like, "How do we fit more stuff onto an iPhone screen?" You can't.

Kelli: You can't.

Jonathan: You make it smaller. That's what you already have. You already have your desktop site zoomed out. That doesn't work, so you have to pick some stuff to not put on the screen.

Or, let's use a carousel, so we can have everything on the screen in the carousel. But it's not on the screen. It's still not on the screen. So why not just prioritize your content and not put it on the screen...

Kelli: Yeah, prioritize your content.

Jonathan: ...since you're not anyway. [laughs] Then we don't have to write a carousel. [laughs] Which is going to be wonky and buggy on all different platforms. What's wrong with a scrolling page? Can someone tell me what's wrong with a scrolling page?

Kelli: Nothing is wrong with a scrolling page.

Jonathan: Thank you.

Kelli: Nothing.

Jonathan: [laughs] Scroll the page.

Kelli: Scrolling on a mobile device is ridiculously easy. It's a flick of the thumb.

Jonathan: It's very stable cross-platform.

Kelli: It is, and it's very fast.

Jonathan: Then all that content is not on the page, so let's pretend it's on the page by putting it in a carousel.

Kelli: Just put the important content on the top of the page.

Jonathan: [laughs] That would force us to decide what the important content is.

Kelli: [sarcastically] Oh.

Jonathan: That's not happening. We'll put it all in a carousel at the top of the page.

Kelli: That requires more effort than scrolling.

Jonathan: Which should be the first slide? It should be randomized, and then it should change every time.

Kelli: Automatically.

[laughter]

Jonathan: I'm not sure if we've made a point.

Kelli: I think we've made a lot of points in disguise. We've made fuzzy points.

Jonathan: We did start out by saying it was about pointless debates, right?

Kelli: Yeah, and the whole podcast has been a pointless debate, so...

Jonathan: [laughs] Exactly.

Kelli: Mission accomplished.

Jonathan: I won't try and sum up because that would just lead to another pointless debate. So I guess that's our show for this week, dear listener. I'm Jonathan Stark.

Kelli: I'm Kelli Shaver.

Jonathan: We hope you join us again next week for the Niche Podcast. Bye.

Kelli: Bye.

Thanks for stopping by! Please feel free to say hello :)