Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design, full-stack, JAMstack, development. I'm Dave Rupert and with me is Chris Coyier.

Chris Coyier: Hey!

Dave: Hey, Chris.

Chris: Another day. Another day. We're going to start having guests again, but we only have so much bandwidth for certain things at a time, and we're still redesigning the site.

Dave: Yeah.

Chris: There's some stuff going on there. I was just working on it, Dave.

Dave: Oh, yeah?

Chris: Just doing some fun little bits there. In fact, I moved the -- you know, sometimes during a development time like this, you rewrite something and then you rewrite it again. [Laughter]

Dave: Mm-hmm.

Chris: Sorry. I rewrote the jobs. Dave had taken it off jQuery and put it on -- and then I took into just PHP.

Dave: Ooh, okay.

Chris: Because you know I was doing that on some other site and it works really good. I'm like, why do this client-side when you can do it server-side? It makes a cURL for the JSON file and throws it into WordPress Transient, which is really efficient. It will only ever make that cURL call once every couple days.

Dave: Is that WordPress's native caching kind of--?

Chris: It is. Yeah.

Dave: That's cool.

Chris: It's tremendously easy to use. Dave, it's like seven lines of code or something to do the whole thing. It was great.

Dave: You do a cURL and you're not just hammering the CodePen servers for jobs, so that's great.

Chris: Yeah, you wouldn't do that. In fact, we had a question about that on this show, either last week, the week before, or something like that. Somebody was like, I want to make--

I can't remember the nature of the question, but it was a server-side request for an API's information come back was required to have that page return at all, which is a terrible, bad practice.

Dave: They were getting that white screen, right? It was full error like PHP crashing because the API went down.

Chris: Yeah. You know when people talk about Web performance, there's so much nuance to it. It really is its own career these days, almost. But there are some kind of fundamental truths to it all that you can always kind of -- you know, like reduce requests and gzip stuff and whatever.

The root of it all is that that very first document has to make it back at all for Web performance to even start doing all the fancy other stuff that it's about to do. The browser needs that first chunk of HTML to start doing anything at all. That's the first thing that you should look at. How fast is that coming back? Sometimes it's two seconds. Two seconds is awful.

Dave: Mm-hmm.

Chris: You want it to be two milliseconds. It's never going to be that fast, but if you can get it into the low hundreds of milliseconds for that first document, that's good.

Dave: Well, and the thing I've been thinking about is a server-to-server communication. That's milliseconds. You're in the 40 milliseconds for a server to ask another server for something. The second you go to a radio tower client-side on a cell phone or whatever--

Chris: Yeah.

Dave: --now you're in the seconds, like multiple seconds, like minimum 400-millisecond roundtrip. If we can do whatever on the server, that's great. It saves so much time.

Chris: Especially on its own network. If your server is talking to another one of your servers that are right next to each other, that's fine, generally fine. That's how databases work and all that.

Dave: Yeah.

Chris: But I remember an experiment with WordPress, like let's split up. I thought that this happened to me. I can't remember how this went down, but somebody was like, you know how you might break up a website into different services. My Web server is on this server. My database is on this server. My APIs are on these cloud functions - whatever. Took a WordPress database and put it on another just to split it up, just so that the one server wasn't doing all the work.

Dave: Mm-hmm.

Chris: Then my bill just skyrocketed because it was being charged for off-network transfer of data.

Dave: Traffic.

Chris: Yeah.

Dave: Bandwidth traffic.

Chris: Yeah, it was bandwidth that was being measured because it was not in the same network of stuff. Anyway, it just wasn't that much of an improvement anyway, but you kind of get why people do that. They're like, I want to split all my services up into individual bits and bobs so that they're responsible for less and you don't get the noisy neighbor syndrome and all that stuff.

Dave: You know that's something to consider about JAMstack stuff. I'm sure Contentful and all these services kind of expect you to sort of hammer it or whatever, but you do have a bandwidth bill to sort of think about. I guess if I were doing my own headless thing or something like that.

Chris: Yeah. Yeah.

Dave: That's something to consider that limitation.

Chris: Something feels -- like when you ask for data on the client-side from an API as you load your page, sometimes that doesn't feel great. You're like, I'm loading the page but it doesn't have what it needs. It has to make a call to do it. But it's starting to be very commonplace.

Dave: Yeah.

Chris: It feels especially bad to do it on the backend.

Dave: Mm-hmm.

Chris: For every request to ask, especially an off-network API, oy.

Dave: Mm-hmm. Yeah.

Chris: Don't delay that first-page load. That's part of JAMstack. I don't know. People don't talk about it in those terms, usually, but it is a big deal. When that document comes back in those low hundreds of milliseconds, the base of really good performance is already there, so the temptation is just to keep it that fast, like, don't screw it up.

Dave: Yeah. Yeah, well, and I would wonder what the point is where let's say I deliver a fast document and JavaScript and then I go fetch content or whatever. There's got to be a point where you could move some of that content to the document and make the document bigger and bigger and bigger to where it's actually slower than fetching with the JavaScript, if that makes sense.

The prerender could actually be slower than the JavaScript fetch, depending on how much content. I would be curious to know what that number is in megabytes or whatever. I don't know. Wasn't it Zach Leatherman who tweeted out his eight meg Twitter archive loaded faster than one React component?

Chris: Oh, that was absolutely hilarious. Yeah. I can load all my tweets faster than one tweet.

Dave: Yeah.

Chris: [Laughter]

Dave: Whoop! Whoops!

Chris: That's absolutely nuts.

Dave: Yeah. I think we need to get him back on, actually, because we never finished his manifesto. But I think he had said, either behind the scenes or during his talk at JAMstack Conf last year, that it was maybe -- there was a little bit of unfairness in the test or something like that, like network versus localhost or something.

Chris: I think, yeah, there was one little caveat, but I can't remember what it was. You know I linked to this post from Hugo the other day that feels relevant to this. Let's say you want to build a front-end with GraphQL, so you're going to use Vue and then you're going to use VueX for all your state, and you're going to populate all your data by hitting a GraphQL endpoint. Have an Apollo server thing going on. That's as fancy as it gets front-end wise these days, right?

That's exotic front-end development. Not exotic in a rare sense, but people aren't doing things much fancier than that. That's leveraging all the latest, greatest, cool stuff.

When you're there on that edge, unfortunately, through time, server-side rendering hasn't been a strong part of that story. None of these frameworks. Even Vue wasn't like, "We're going to be SSR first and then other stuff." None of these JavaScript libraries are like SSR first. You know?

Dave: Mm-hmm.

Chris: It's a little unfortunate, but you can get it done. Let's say you have a button and you click that button. It fires off a GraphQL mutation in incremental alike or something. That's a pretty difficult situation for progressive enhancement, too. Even if you wanted to SSR that, chances are SSR is just going to put the button there, but it's not actually going to be ready to use.

That's why I enjoyed this post from Hugo about Apollo GraphQL without JavaScript; even it can be done. First of all, you've got to get SSR going because, whatever, then that's that. But then for every little button and interactive element like that, you can wrap it in a form tag and the form has an action attribute that links to your GraphQL endpoint that does the mutation. It's fine if it hydrates up or whatever. I don't know. I don't even know.

Maybe you don't even need it at that point, but that's the only way a button works in HTML. The only way you can get to post some data, you have to wrap it in a form. That's the only thing. I guess it could be an anchor tag with a get request, but that's not. Then it changes the URL all nasty.

Dave: No, I saw this post and it's clever. It's, hey, I'll just make a form that then enhances up. It's all in React. It just does -- it's clever. It's just the idea that--

Chris: I just don't see people doing that very often. I bet he's one of the few in the world that pick these really fancy, new, exotic, and then took the trouble to progressively enhance all the way down to even a button press. Pretty cool.

Dave: Really clever. No, I mean I wouldn't have gotten here, so it's -- you know what I mean?

Chris: No, I'd be like, "Ah, this is possible, but I'm a little busy, so nah."

Dave: Yeah, yeah, yeah, but I think we had talked about -- what was it, last week? -- AlpineJS, which, you know, once we talked about it, now it's in my feed. I don't know if Twitter can listen to podcasts or whatever, but now it's in my feed and people are doing cool stuff with it. I think it's neat.

I don't have the links here, but I know some people had mentioned, "Here are some alternatives that are very similar," and stuff like that. I forget them offhand but thank you for sending those links. It's always cool to check out.

Yeah, Alpine maybe is not a progressive enhancement framework per se, but it's very much -- I feel like when you have those HTML directives you start with HTML sort of like how Hugo started with a form, right?

Chris: Yeah, at least the possibility is closer. Yeah.

Dave: Yeah, but the delta of getting there is smaller.

Chris: That's what I like about Vue inline templates. That is a core feature of Vue. While Vue isn't necessarily SSR first or something, it kind of is because it's kind of like, well, it can just work on your regular HTML. If you want SSR then do it that way.

Dave: Yeah. Well, that's cool. Yeah, interesting. I'm trying to think. Have you been following all this design system-y speak that's going around? It's very interesting and it's got my brain--

Chris: That's pretty vague. Tell me. Tell me.

Dave: Jeremy Keith wrote an article.

Chris: Oh, I read this one. It's like architecture versus gardening kind of deal.

Dave: Yeah, architecture versus gardening. Man, that's really standing out in my brain because it's been something that I've been thinking about and I'm working on a blog post right now. Who knows if it'll be out either -- it'll be out either today if I just obsess over it or it'll be out in five weeks after this podcast. It's really interesting.

You kind of factor in things like Ethan Marcotte wrote The Hoof and the Horse.

Chris: Yeah.

Dave: Which was a riff on Robin Rendle's Systems, Mistakes, and the Sea, which was really good. Then even in Ethan's talk, he references Jina Anne's There is No Design System post on 24 Ways, which was good, where it's kind of like pulling design systems away from being an artifact or as a methodology, which is something to think about too. It's not this bucket of components so much as like, here's how we build things, which probably gets back to what Brad Frost did, even kind of getting at we just need to build things in this way.

This is how things build up. But then it becomes systematized. Then it becomes industrialized. It's very interesting to me. That's all I wanted to say. Top of my mind.

Chris: You know I don't have a single design pattern or sing design system in production, of all the sites - all of them.

Dave: Hmm.

Chris: I write some HTML. I write some CSS. I write some JavaScript. I ship the website. It's not that things aren't built-in components because they kind of are, but they're not particularly prescriptive. There's no storybook. There's no pattern lab. There's no fractal.

I've dipped my toes in all of those tools and it felt a little bit more like gardening, I guess. We already have these things so let's just chuck them in here so that we can look at them like a zoo, like, "Look. There are some patterns."

Dave: [Laughter]

Chris: Look, kids! The zebra is eating the grass.

Dave: Well, I think that's a really good point. I think sometimes design systems are a zoo and you need a zoo. How else are you going to teach kids about what kind of animals are in the website? [Laughter]

Chris: Right.

Dave: Here are the kind of animals we have. We divided them up into little zones. Now you know these are the marketing animals. I think a zookeeper is a really excellent analogy as well. I think design systems as documentation machines are great, especially as teams get bigger or demands get bigger.

Chris: Yeah, the teams thing is a big deal. I didn't say what I said to say that design systems are bad. I feel like my teams are small enough that the time commitment isn't as useful. We're not building something and shipping it to somebody else who is going to consume it, for example. I think that's a part of it.

If we were going to onboard three designers and they started just on day cranking out code, if they didn't have a zoo to look at what's already there, the chances are good that bad things are going to happen. They're just going to reinvent a bunch of components and kind of get into that messy state that we've been trying to fight against. Maybe the zoo is nice even though there's just a zookeeper.

Dave: Right.

Chris: Not a zoo master who is like, "You can only use these patterns. I am the master. Anything else shall not be." The zookeeper is just like, "Come on, come all. Look at the elephants. They're over here."

Dave: "Look. I'm going to put my head in the tiger's mouth."

CodePen, it's a smaller organization but y'all still write code. If there were three or four levels of management in between the owners of the company and the people who write the code, well, I think the value goes up too.

Chris: Yeah, for sure.

Dave: I'm talking even if you had the name number of programmers and designers, the value would go up if there was 4x the number of managers now dictating what has to go in the website tomorrow. I think the value of a design system goes up there too because a manager is going to be like, "We need a rabbit with antlers." You're like, "Great. I'll just go look at the rabbits and then go look at the animals with the antlers. I'll smash them together. I did it. I made a new animal." [Laughter]

Or, "Okay, where can we find examples of animals?" Anyway, I'm losing the zookeeper analogy now, but I feel like having that zoo, that sort of, "Here, look at everything we have. This is what we know about the world." I feel like the knowledge documentation aspect of design systems is great. But I think, like what you said, if it becomes you can only use -- like, "We have a squirrel and a penguin. Those are your only choices," you'd be like, "I think I need something different," you know?

Chris: We're saying the zoo is the gardening analogy and the zoo master ruler is the architect analogy. We just made a new analogy, which the world probably didn't need.

Dave: Yeah. Whoops!

[Laughter]

Dave: Whoops! But you know. To the idea of a zoo master, that one job that design systems do well is reduce the number of decisions that have to be made. You've got Team A and Team B. They built five different accordions. Two teams will produce five accordions.

Why did that happen? Well, just whatever: staffing, turnover, no one knowing. It happens, so I've removed five accordions from a site last year, so there you go. Why does that happen? It just does.

[Banjo music starts]

Chris Enns: This episode of ShopTalk Show is brought to you by Clubhouse. Clubhouse is a fast and enjoyable project management platform that breaks down silos and brings teams together to ship value, not features.

Let's face it. A slow, confusing UX is so last decade. Clubhouse is lightning fast; built for today's software teams with only the features and best practices you need to succeed and nothing more.

Here are a few highlights about clubhouse. Flexible workflows: You can easily customize workflow states for teams or projects of any size. Advanced filtering: You can quickly filter by project or team to see how everything is progressing. There's sprint planning; set your weekly priorities with iterations and let Clubhouse run the schedule for you.

It also integrates with the tools you love. Clubhouse ties into your existing tools, services, and workflow. Get notifications or create a story in Slack, update the status of a story with a pull request, preview designs from Figma links, or build your own integration with the Clubhouse API, and more.

It also has enjoyable collaboration, easy drag and drop UI, dark mode, emoji reactions, and more. When you're doing your best work and your team is clicking, life is good.

Clubhouse as recently made all core features completely free for teams with up to ten users and they're offering listeners of ShopTalk Show two free months on any paid plan with unlimited users and access to premium features. You can give it a try at clubhouse.io/shoptalk. Thanks again to Clubhouse for sponsoring this episode of ShopTalk Show.

[Banjo music stops]

Chris: Fantastic. That was a fun way to start. I like just talking about whatever is on our minds and has come up in the news lately.

Dave: Topical.

Chris: We've got one, a question here from Alex who is wondering about equipment, basically. He said his company provided him a MacBook Air, which he likes.

Dave: Okay.

Chris: Plenty sufficient for him to do front-end development, he's saying. He got a chair, a nice chair and a desk. Then he's like, "Well, what else should I ask for, though? I'm starting this new job. Should I ask for a couple monitors? What about a standing desk? My desk is okay, but it's not standing. I would also like a wireless mouse, a beanbag chair, and a rubber duck." [Laughter] I think Alex is feeling like--

Dave: Yeah.

Chris: Do I just keep asking until they say no? What's reasonable these days? We both work for ourselves, kind of, so it's hard to know. I wonder what you get if you go to work at Twitter right now. Do you get all that?

Dave: I think you get the laptop and maybe a desktop monitor and a pair of headphones, I think is what you get.

Chris: Ooh, you get headphones.

Dave: [Laughter] Well, because you sit in an open office and they want you to actually work.

Chris: Yeah. [Laughter]

Dave: You get noise-canceling headphones. [Laughter]

Chris: The irony of the open office. It's supposed to be like, "Oh, it's so great. Everybody talks to each other," but really it's just cheaper.

Dave: [Laughter] It's collaboration… and you occupy 0.75% of the space that you normally would.

[Laughter]

Dave: No, I think, for me, what I would ask for, maybe this is because -- whatever. We're chumps and I feel like I'm in a, "I will buy it if I want it," or I have these weird rules about money. I'm like, "If it helps me work and I'm pretty sure, like, I've done the research and I can quantify that it would probably help me work, then I'll just purchase it.

Chris: Mm-hmm.

Dave: For me, there are three things or four things, I guess I'll say, I need. I need an ergonomic mouse. I need an ergonomic keyboard. I like ultrawide displays because it lets me work on one screen without a bunch of window switching. I do a bunch of window switching, but it has the real estate I need.

Chris: Mm-hmm.

Dave: An ultrawide display and then a standing desk as well. I'm going to put a good chair in there and probably some good headphones.

Chris: Five things.

Dave: Six. I've got six things now, but I need those things. I literally need the standing desk. Doctors have said, "Oh, you sit too much and that's why your back sucks." That I need. I feel way more productive on an ultrawide display. I have two displays right now.

Chris: I'll take that one. I have two of the LG 5Ks and I'm eyeing up the fancy Apple one, although I choke looking at the price, so I don't think I can pull the trigger on that. It's incredible. It was way too expensive.

Sometimes I work from home and, at home, I have one of those ultrawides and I prefer it. It's not even retina, so sometimes I get a little bummed out looking at it because I can dramatically tell the difference and it's kind of janky. And it's such a cheap one that if you have a browser window in the middle of it and you scroll it, you can see the split as it scrolls up and down where the two monitors are stitched together, basically.

Dave: Oh… Oh, yeah, yeah. That's tough.

Chris: But I prefer the shape of it so much that I'm tempted to go back down to one, so I feel you, man. One monitor is where it's at.

Dave: The Apple one might be a good choice because it's a little wider aspect than the standard cinema display.

Chris: Yeah, just $5,000 and a $1,000 fricken' stand.

Dave: Hey, for $5,000, we could put you into this puppy.

[Laughter]

Dave: If you think about it, how much are you going to use it? You're going to use it every day for eight hours.

Chris: Oh, my god, Dave. Do not convince me to do this. I'll kill you. [Laughter]

Dave: Well, hey, and then think how beautiful your screenshots will be for your marketing.

Chris: [Laughter] Ahh…! Ah, Dave!

Dave: I know.

Chris: What convinced me not to do it--I was just about to pull the trigger--was that even Apple touts it as not really just for average people. It's what they call a reference monitor for people doing incredible, you know, movie work that have these otherwise $20,000 monitors where black is black and color is exactly as it is on tape. I guess I get the term "reference monitor" because it's exactly what you have as information is what's shown on this thing and so they're really expensive.

This is Apple's play at, like, combatting that market and be like, "Look at ours. It's amazing, too, and a quarter of the price," kind of thing. It's not for me. It's not designed for me.

Dave: It's not for you.

Chris: But it kind of is.

Dave: Yeah.

Chris: [Laughter] You know, it's just a nice monitor.

Dave: I will say LG has 4K displays.

Chris: Yeah.

Dave: They're kind of ultrawide-ish, like a little bit of a wider aspect. That might be something to check out if you're interested in that.

Chris: They're good pixel density or whatever? Do we still say retina? Is that still a thing we say?

Dave: 4K UHD.

Chris: Yeah.

Dave: They have a 5K IPS. IPS is a pretty good panel but it has bad ratings, so I don't know. I wouldn't maybe do that one.

Chris: Hmm.

Dave: But I think you want a little bit wide; you know.

Chris: Yeah.

Dave: But yeah, it does seem like it's more for like--I don't know--video production artists and stuff like that.

Chris: I wish it was a little wider and a little less tall.

Dave: Mm-hmm.

Chris: Can I get three working spaces on it? I usually am a two kind of guy anyway, but it's a little too -- I don't know. Who cares. Okay. That was quite the aside.

Dave: Yeah.

Chris: For Alex, I don't know. Yeah, you work at a company. If you need some stuff, ask for it and see what they say. It sounds like they're kind of hooking you up already, so that's kind of good.

Hey, did you ever work for a client where they give you a laptop because that's what they want you to work on?

Dave: Oh, yeah. It's terrible.

[Laughter]

Dave: I mean it's fine. It's just terrible. I think I've had two situations. It was just like for network security reasons, I needed to use this client's laptop. Then I'm juggling laptops. All my personal stuff is on one and all my work stuff is on the other. It's like, okay, cool.

Then I think when I did the Microsoft site in 2012, they made us do a -- I had to get a Windows 8 machine with a little chip reader to go in, so that was kind of a bit of a burden because not only was it a new platform, but then there's all this different security model stuff and all that, so that was difficult.

Chris: It's pretty common, you know, because I think you hire somebody to do some work for you and it's an unreasonable expectation to be like, "Oh, also have a really high-end laptop that we won't support." That's a little funky.

Dave: Yeah.

Chris: At CodePen, we buy all of our employees laptops and, as far as I know, they all use them.

Dave: Mm-hmm.

Chris: Which is, I think, totally reasonable and cool. I don't know how many of them have a separate laptop for their home stuff. I was always a weirdo in that, every job I worked at, I wouldn't allow it. I was like, I don't want your laptop. I just want one. I have all my stuff on this one thing.

Dave: Well, and I think my issue, I have a desktop PC and a laptop that I carry around and stuff like that. I'm building a new office and stuff. I'll maybe set up two desks, to be honest, and I might have a gaming machine that has one monitor and then I might have another, just a plugin laptop that has an ultrawide. I think that's honestly where I'm headed but I haven't quite decided yet.

Chris: Hmm. Hmm. I remember going to Estelle Weyl's house one time. She had a stack of like five MacBooks sitting there because she did some consulting work and each different consulting gig gave her a laptop.

Dave: Yeah, so what did she do?

Chris: I didn't blame her. I was like, that sounds like a nightmare to me, but if they support the machine so you pick up that laptop; all you're doing is that job on that laptop. It still sounds a little nightmare-y to me, but I get why.

Dave: Yeah. No, I get it. Sorry. This might be too personal, but if somebody quits of leaves CodePen, do you ask for the laptop back?

Chris: Yeah. Yeah.

Dave: Is it kind of a gift?

Chris: No.

Dave: Yeah, because it's -- well, tax-wise, it's just weird how it works, right? It's like, "Oh, you're going to depreciate that asset over the next 30 years, 5 years." [Laughter]

Chris: Yeah.

Dave: You can't just -- anyway. Yeah.

Chris: Sometimes when things like that happen, it's like you kind of need it for something else. Maybe like, well, I could use a new one, so why don't I take that one back, take that, and take my new one and give it to this person. Usually, it sets off a little chain reaction of laptop shuffling.

Dave: Oh. [Laughter] It's like a hot laptop, sort of. Yeah.

Chris: All right, so here's one from Jackson.

Dave: Yeah. Jackson writes in, "I recently had taken the position of the sole in-house developer for an otherwise non-technical team. It has a bespoke Web platform as one of its central products. The previous work was done by consultants and they managed to get everything off the ground and making money. They cut some corners and hardcoded plenty of business logic dependent on specific database records existing and followed other similar poor practices. The product is in pretty brittle condition."

Chris: Hmm.

Dave: "I really want to introduce some testing to the codebase for the sake of my sanity, but I don't know where to start. It's essentially two pieces: a Laravel API and a React front-end. What I want to do is ensure the changes to the API or the front-end won't break production."

Chris: Yeah, this was a longer question and I truncated a bit. The deal is, sometimes a change will happen and it'll just break production. Break is what I wanted to home in on because, break how exactly? Does it 500 or does React try to render and fail because it's missing data or some kind of weird JavaScript error happens?

It's kind of different things. It's a little easier to test a 500 than it is a client-side error. You don't have to spin up a browser to know about a 500. You know?

Dave: Yeah. I've been thinking about this. I've been starting some projects or whatever. When you name a field you're like, thing.title. Then the other thing you're like, oh, thing.name, thing2.name and thing1.title. You're like, "Oh, man. I should make those the same. I just wasn't paying attention. But I've already put the code in production, so what do I do?" you know?

Chris: Hmm.

Dave: I've always wondered, especially in a very client-side framework-heavy thing. How do you do this migration? I guess you'd have to update the database, duplicate the fields, update the backend, make sure you're writing to both fields at the same time, right?

Chris: Yeah.

Dave: Then ship the front-end with the new -- you know, okay, now it's all dot title from here on out and then go through and delete the logic in the CMS and then go delete the logic in the -- or go delete the field in the table. I was like, man, that's a lot of effort. Or do people just try to ship these things both at the same time, like a database migration?

Chris: Hmm.

Dave: I was even thinking, what if you accidentally -- oh, I spelled "password" wrong in the MySQL or whatever. It's "passwork."

Chris: Ugh!

Dave: I was like, oh, I need to fix "passwork." How do I fix this with minimal downtime?

Chris: I don't know. You put it in the API first, I guess. Oh, gosh. I don't know. That's a tricky one.

Dave: Right.

Chris: Because there are three layers now that you need to work on. There's the database and the API and the consumer of that API.

Dave: Right. Right.

Chris: There's some -- you know GraphQL handles some of this. At the API level, you leave title alone and put name in. They're just both there. Then the consumer can just start using the new one. In the docs, or whatever, you say, "Title is deprecated. Don't use title, but it's still here, so it's not going to break stuff."

Dave: Sure.

Chris: Then you do what you need to do on the server-side. It's less my forte, but that's why they say GraphQL APIs don't need to be versioned because you can just add stuff.

Dave: Add fields.

Chris: Yeah.

Dave: Yeah, they can be -- they don't -- yeah, I guess they don't care.

Chris: That's not totally true because how long do you leave old crap in there? Then who knows who comes along and starts using old crap. Then you're like, "Well, come on. I'm not versioning, but I'm just expanding the surface area of what I need to support," which can be just as bad.

Dave: Well, and it's fine if it's--whatever--blogpost.title and blogpost.name or heading or whatever you did wrong. That's fine. But if it's blogpost.body, now your response, and blogpost.description or something like that. Your response is going to be huge.

Anyway, back to this question from Jackson. How do you test it? I don't know.

Chris: Remember I talked about my dream testing service? I totally want to build this. It's like, all y'all have all your fancy tests. My service has nothing fancy at all. You put a list of URLs in there and all we do is tell you if it drew a hard error or threw a JavaScript error and that's it.

Dave: Hmm.

Chris: I feel like -- you know there was a CSS Wizardry, a Harry post the other day about performance testing and how pragmatic it probably should be to start, whereas the temptation is to put together a very fancy budget and have it testing in CI and blah-blah-blah. He's like, that's almost like next-level stuff, you know? The easiest thing to do is just measure what you're doing now and set up an alert if it gets any worse with, like, "Oh, I made a tool." That way it just protects you from screwing up really bad. I feel like that's the baby step into test too. Just be like--I don't know--did a page totally bomb on production? Write one test that prevents that thing from happening and that's your testing framework now.

Dave: Sort of reactive or, I guess, responsive?

Chris: Yeah, you could go out a little ahead too, but what testing isn't is, like, "Well, we have 350 JavaScript functions in here and only have of them are pure, and so I guess let's start chipping away at writing tests for all these functions."

It's like, "No, dude. Just run an integration test that's easy," because there are all kinds of them these days. Cypress is the big, super easy one because it has their fancy front-end. But we've been playing with just Puppeteer at CodePen. Puppeteer spins up Chrome so super-duper-duper fast, and Headless too.

Then you write these little tests that are just like, "Visit this URL. Await. Click this button. Await. Did this happen?" You know? All that click-y, testy stuff is fine too. I like those tests. But if all the test was, visit this URL, that's cool too because it's implied test that that URL spins up okay. If something is wrong, the test is going to fail. I just think testing can be so easy.

Dave: Right. Yeah, I think I like your idea. You almost need layers of major mess-ups, like major problems. Okay, then test quality and then -- or, I guess, reliability.

Chris: Yeah.

Dave: Robustness and something else.

Chris: What made me think of this is that Jackson is just like -- what was the word -- "It's really brittle, so one little change can destroy all of production." Well, that's the test you write, then. Write the test that just checks if total destruction has happened, not the little nuanced thing that caused the destruction. Just test if the destruction happened.

Dave: Yeah. Well, and he says he's working on an API. Was it Rachel Andrew? I don't know if this was in a private chat that I'm sharing with the world. [Laughter] It was kind of describing an API, but we need to make sure it has certain responses. She was asking for help, like how people do that. I felt like she got a good answer, but I can't remember what it was.

I think it's possible to test an API and just say, "I need to have this A, B, and C back in the response." That should help your React app too. It's maybe not traditional, I guess, unit testing of functions.

Chris: That's a little closer to integration testing than unit testing because you have to hit some URL to get it.

Dave: Yeah, but you could write your own in some ways, you know.

Chris: It could be either way, yeah.

Dave: Or adjusting, like it expected whatever. Fetch foo from bar or whatever. Fetch foo then response.json or whatever to equal or to exist, or whatever. Then that's a good sign that it's going to work.

Your React front-end, that's got a different way to test that code. I don't do a lot of that, so I can't really attest to it, but just, I guess, with React testing framework. You know I think you're going to have to really QA the API, and that's probably writing kind of this weird layer of just test that fetch from the API, like fetch things.

Chris: Yeah, that's going to help you a lot if there's a lot of API stuff. You're right. Then you could write that. I'm sure there's a way to do that in one of the -- Mocha and Jest and there's a whole list of them that are just little node-based things.

Dave: Yeah.

Chris: You'll probably have to pull in some Axios kind of deal. I don't know. Is Fetch in Node now? I guess it is if you're using the newest--

Dave: Node Fetch, yeah. Yeah.

Chris: Yeah, Fetch the JSON. Look at the JSON. Is the stuff in the JSON that you expect? Yeah. I'd fricken' run that one on a cron, dude. Run it ever hour. [Laughter]

Dave: Run it every hour.

Chris: Yeah.

Dave: Now you're into serverless territory there.

Chris: [Laughter]

Dave: No. Yeah, I think that could work. Yeah, it's tough, though. I've been in those where you jump into a database and you're just like, "Whoa! What were people doing? Why is this this? Why is that that?"

It was a thing where, like, I had to VPN into some server to get the config file, like the latest config. People just shipped config changes to the system or they'd just write them directly into the VPN, like the test server or whatever. It was just like, "Dude, what?!" [Laughter] That's why my thing hasn't been working all day? Because I had to go VPN into some server, some IP to get a file. There's a lot of substandard situations out there. I apologize, but it is people just trying to get their job done, I think, unfortunately.

There you go. If it works, people don't want to touch it. Hopefully, if you're the sole in-house developer, you should have a little bit of leeway, I would hope. Hopefully, that will work out for you without breaking things too much.

Chris: You know I will say too that I find integration tests easier to write these days because the frameworks have gotten so good around them and so accessible, I think, that that's not particularly hard. Check out those.

You know -- no, I'm not even going to go there. But--

Dave: Oh-oh-oh, there's some good stuff hiding behind that.

Chris: Visual regressing testing is nice too, you know? I think that one is important because that's a form of an integration test too. If you spin up a visual regressing testing tool and it loads your homepage and it's a blank white page, well, you've proven that that blew up stuff too and you can prevent that from deploying. Anything high level like that can be so valuable for so little.

Dave: Yeah. It's not going to save you. It sounds silly and maybe this is going to blow our "Safe for Work" title, but I started thinking of testing and automated tools like this as more like a prophylactic--

[Laughter]

Dave: --than something that's going to save you. It's something that's helping you practice safe development, and that's where I'm going to stop it there before it gets too -- [Laughter] don't go too far on this analogy. But it helps you have a safer development experience and gives you some guidelines. Hopefully, things don't go as wrong as they could. I hope that happens. Consider it that way. It's just a way to do things a little bit safer than usual.

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by AWS Amplify. You know AWS, Amazon Web Services. It powers most of the Internet, it feels like.

There are a ton of things that go in the AWS bucket like EC2. It allows you to spin up servers of your choice and has all kinds of configurations. S3 is for file storage. Lambdas is for running cloud functions. All kinds of stuff that, individually, you can set up and use and are great. But there's so much more than that. There are a ton of different things AWS does.

AWS Amplify is kind of a package of tools to help you build full-stack apps for the Web. It's like--I don't know--just give me the stuff that I need that, usually, you need to build an app. Amplify is hosting. You need Web hosting? It's got that. It's got authentication for logins for your users.

It's got GraphQL as a first-class citizen of it. It's got serverless functions, like I need the Lambda thing. I want to run some code in the cloud to hit APIs and do whatever else I need to. And it's got file storage if you need it. It's got some machine learning stuff in there if you need it.

Amplify is this easy to use, full-stack framework for getting started quick with building Web apps. It's really cool. The auth stuff alone is cool. It's just a few lines of code in there.

GraphQL has taken over the world of how to get things from a database, put things back in a database, really front-end development-friendly way to do database stuff. Love GraphQL. It's just built-in as a first-class citizen. It's this scalable API. You don't have to provision your own servers. It just does it up for you. Pretty cool.

AWS Amplify is really cool. Definitely worth checking out, especially as a front-end developer. Check all that out.

[Banjo music stops]

Dave: Next question.

[Laughter]

Chris: Yeah. Yeah, Shelton Clinard heard you were messing around with IntelliJ and got excited. He's a big PHP Web Storm user who would like to hear more about your experience with that. I'm always intrigued by these things too because so many people use free editors, me included, VS Code, and sometimes I just stare at VS Code with my jaw gaped. Not the most beautiful editor in the world but, holy crap, does it do its job. It's just amazing.

But I remember when the craft guys worked here in the office. They all used PHP Storm because all they do is write PHP all day. The promise, I think, the main one is that when you use an editor like that that's specialized for language, it knows how to run it. It's almost like low key running your code while you're writing it to see about problems and stuff in a way that VS Code just totally does not do that. You might have some heuristic stuff it can do but it's not executing PHP.

Dave: Yeah. It was an experience. I'll say that. I was using IntelliJ. A client had a Java project, Java and Spring.

Chris: Was it the same deal? Was it like, execute the Java, to tell you what's up?

Dave: Yeah, and everything is in there, so you have to kind of set up some configs. I think in Web development, you maybe have a docker container if you're lucky. You're kind of just like, okay, let's hope that this stuff is here. Right?

Java isn't there for sure and there are different Javas, right? You have to go in and set up, "I want to use this java.exe," or whatever. It's a binary of some kind. Then, for my server, "I want you to point to this instance of Tomcat." That was sort of the -- I'm sure there are other servers and stuff like that.

Then in the Java ecosystem, there's also Maven, right? Then once it's like, "Oh, you have Maven," a little Maven panel shows up and is like, "Click the thing." Maven is a task runner, basically, sort of like Grunt but XML-based, which is sweet.

Then you just click on the thing you want to run. You want to clean the project; you click "clean." You want to start the server; you click "start." That's how it goes.

Then when you click "start," your console pops -- it detects.

Chris: Yeah.

Dave: Like, "Oh, you started the server. Now the console just pops up automatically and you start seeing all the binaries compiling and transferring. Then you get line errors per, like -- oh, like, whatever. You had a bad type on this Java file. You just click through and then you're on there.

Ergonomically, it is maybe not for me but it is powerful. I think if you are an all PHP shop and an all IntelliJ or Java shop, like these tools are actually pretty good and maybe indispensable. Me, personally--

Chris: Can you imagine working in that environment for five years and then taking some new job where it wasn't there anymore? You'd be like, "What?!"

Dave: Oh, and all your muscle memory.

Chris: Yeah.

Dave: I forget what the search -- you know how you search for files, command-shift-P or control-shift-P, or whatever?

Chris: Mm-hmm.

Dave: In IntelliJ, it's like shift-shift. You type shift-shift or something like that.

Chris: Hmm.

Dave: Then that -- oh, okay, that's how you find things. It took me a long time to figure all this stuff out. Eventually, you figure that out.

Chris: That one is such a big one. In fact, I've been on Nova, which is like Coda 3 from Panic.

Dave: Yeah, Panic.

Chris: Which is irrelevant to you because it will never be Windows, but still it's industry news, anyway. I was like, "You know, I'll give it--"

The only way you ever can really do it is if you just actually try to switch. You know? Open your actual projects in it and use it. I found this is not -- I think they're asking people not to give straight-up reviews of the software yet because it's not fricken' ready. It's beta.

Dave: Yeah.

Chris: I won't say too much about the experience of using it other than to allude to, like, exactly what you expect. It's better than you think it's going to be but there are little things.

One of the things was, my muscle memory -- it turns out the number one command I use in text editor is that jump to file thing - whatever it is. It was command-T, I think, in Sublime.

Dave: Yeah. Yeah.

Chris: Then I mapped that over to VS Code. It depends on if you map it in the same way or not. I don't traverse folders to get to files ever.

Dave: Right. If you're missing that, that's a huge--

Chris: Yeah, and they totally have that, but it's just a different--

Dave: This sucks. That triggers--

Chris: Yeah.

Dave: That triggers, like, "This sucks," in my brain.

Chris: It does.

Dave: Even though it's like some weird thing I learned from some other weird software.

Chris: Right, and that's just one command. If you're all in on IntelliJ, then you're going to have the hardest time in the world switching off of it because it's doing so much for you. Then it turns out that you can customize the triggers in a really nice way, so I was able to remap it just fine and it worked great. It's sweet, you know, but it's not in the IntelliJ category either. These editors that are language-specific are next-level stuff.

Dave: Well, and I think I've said it before. In 2012 when I worked on the Microsoft site, I had to write in Visual Studio, not even code.

Chris: Yeah.

Dave: That didn't exist yet, so Visual Studio proper, big boy edition. My brain is, like, in overload. I'm just like, "What is going on? How do I find things? What are projects?" It just -- you know. I disliked it quite a bit.

Then every time I hit "save," I watched the compiler spin up. I just was like, "This is the worst way to do Web development."

Low and behold, eight years later, I was sitting around running compilers all the time. That's just how you do Web development now and I'm eating my hat. But then, looking back, inside Visual Studio Code, there was this team foundation server. That's where my bug tickets were. I was like, "Ugh! This thing is so stupid. User stories, blah-blah-blah." It's like, guess what? I'm just using user stories and wouldn't it be kind of handy if all my tickets were inside my fricken's editor? Probably because then I could just reference them or commit files right in the editor. Guess what. That's what I do now in Visual Studio Code. I just commit in the editor and it's just fine.

Chris: That's funny.

Dave: I think there's a lot of high and mighty nerd sniping or whatever about editors. Really, I probably was in that camp for sure, but it's so much about finding something that works good for you. I think a lot of people have success either -- you know it comes -- in some ways, this is like bootstrap versus rolling your own design system. Some people want to start with the toolkit that has everything and use the parts they want. Some people want to start with nothing and build up to what works for them, right?

Chris: Ooh! Yeah. Sure.

Dave: They may be missing out on features because they didn't Google well enough or whatever, but I feel like, you know … code, sublime.

Chris: But you're almost safer at the bottom. I'm not going to judgment call either one, but the one that has everything, maybe they're just more productive right out of the gate. But the other one is less fragile. If you start with nothing and only add a little stuff, that means you're competent and can do your job in just a notepad. [Laughter]

Dave: Yeah. Yeah.

Chris: Which is kind of cool.

Dave: The big one costs thousands of dollars a year. The other one is free, so what do you want?

Chris: Well, there's that too.

Dave: You've got to think about that. I think you have a build-your-own and a framework, the whole kit and caboodle, and I think there are different people and they like different things. But for me, I think I gravitate more towards the build your own system. Although, that's a pain in the ass. Have you ever tried to set up ESLint, Stylelint, and Prettier in one project?

Chris: [Laughter]

Dave: God help you. [Laughter] It's almost impossible. I think Wes Bos gave up.

[Laughter]

Dave: It's almost impossible.

Chris: I got that going. That's a requirement for me.

Dave: But it's difficult. It's two days of work to get it all going.

Chris: [Laughter]

Dave: In some ways, Shelton is like, "I found the easy way out. I bought the big tool and it does it for me and I literally don't care. I just get to type into it and it'll even tell me what to type and that's great."

Anyway - hey, guess what? I have a hard stop literally in one minute, so we need to wrap up.

[Laughter]

Chris: Yeah. Yeah. Go quick. You got it.

Dave: Well, thanks, everybody, for downloading this in your podcatcher of choice. Star, heart, favorite it up. Really, we do appreciate your listenership. We are having fun with this show this year and we will be redesigning the website and launching that pretty soon, so bear with us on that.

Then… yeah, follow us on Twitter, @ShopTalkShow, for tons of tweets.

If you hate your job, ShopTalkShow.com/jobs. It'll be even faster in the future.

Chris: Yeah.

Dave: Milliseconds. Then, Chris, do you got anything else you'd like to say?

Chris: That's it for me. ShopTalkShow.com.