Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave, at home with the kids and it could get especially rowdy today. A neighbor kid is coming over.

Chris Coyier: Fun!

Dave: Anyway, we'll see how it goes. Anyway, and with me is Chris.

Chris: What do they do together? Do they play blocks or are they too old for that? TV, the iPads?

Dave: Too old. They just run around and yell Zelda things, I think, is sort of how that work now. [Laughter]

Chris: Oh, I'm looking forward to that phase. Yeah?

Dave: Yeah. Yeah.

Chris: Yeah.

Dave: They just kind of run around and yell, so that's a fun--

Chris: Yeah, and they--

Dave: --a fun game for kids.

Chris: They need dad sometimes, but not all the time, right?

Dave: No, no, the irony is, and these current times sure have changed it but the irony is having kids over is the best thing because your kid is now entertained without your assistance. You may need to provide--

Chris: Yeah.

Dave: You're on snack duty kind of at that point, so it's kind of--

Chris: Yeah. Yeah, "make sure nobody breaks their leg" duty or whatever.

Dave: Yeah.

Chris: Yeah, but the dishes can be done or whatever.

Dave: Yeah.

Chris: That's cool. Um, that's good. Okay, so we're going to answer some questions from some people. We have some that came in. Grad, thanks always for sending in your questions. Then we're going to have a special segment this week where we're going to hear from Matt Marquis who wrote a book called JavaScript for Web Designers. It's not particularly new. Oh, look at this. I'm looking on the A Book Apart website right now. If you buy it, there's a special deal if you buy it with my book. Oh, nice pairing there, team.

Dave: Hey!

Chris: Love that.

Dave: Always be closing. Let's do it.

Chris: I suspect a lot of people that know JavaScript at least a little who listen to this show, but I think you'll appreciate Matt's intro to this book, so we picked a piece of it that's kind of towards the beginning where I think Matt is just such a great writer. He's so funny and word stuff, so weird, you know? He's like -- [laughter] I wish he's blog more often because I think he's just got a way with words, but we'll hear from him in the middle of the show and then we'll talk about some more stuff.

Anyway, let's kick the start of the show. Do you have anything that's on your mind, like super strong, this week?

00:02:24

Dave: Well, we do have a slight correction we need to issue.

Chris: Oof.

Dave: This is maybe an addition, an addendum, a first-ever addendum on the ShopTalk Show. Remember we were, a couple of episodes ago, we were talking about threading and async code and stuff like that? Well, as we finish recording, then the blogs, the hacker news got very into this thing called GPUJS. Did you see that? It's basically running JavaScript on the GPU, which is very fast and can do math very quickly.

Chris: I'm aware that having a good GPU is good for video games. That's the number one fact I know.

Dave: Yes.

Chris: The number two fact is that, in CSS, sometimes the goal is to get things to render on the GPU. I remember you used to use a 3D transform to trick--

Dave: Mm-hmm.

Chris: Trick elements to then be rendered on the GPU. But I don't know any deeper than that. That's all I got. Apparently, it's a chip that's in your computer that -- I don't know. Why is it better at doing JavaScript than your CPU is?

Dave: You know I don't know the technical reasons but, historically, the reason it's good for graphics and video games was because it just says, "Okay, tell me. Describe the space to me. Okay, here are the vertices or whatever. I know how to do all the math for vertices, and so I'm just going to do it. It was very good at calculation. As a result, cryptographers and people like that and machine learning have picked it up, too, because of its ability to do math, whereas a CPU is maybe optimized for, like -- I don't even know operations. I wish I had a really good explanation here, but it's more like -- yeah, I don't have a good thing.

Chris: Yeah … thing.

Dave: But it's basically like there are certain tasks, like a GPU really excels at and that can be math or big, heavy computation.

Chris: Okay.

Dave: Whereas, maybe a CPU is optimized for other stuff.

Chris: Yeah, I could see that operations per second or whatever, although, I'm sure the GPU is also fast at that, so it is hard to talk about a little bit. But what we were talking about in the last show is threads, right? Ask. You can't use the single thread in JavaScript to do that because you'll just lock up the browser and that's no good. You've got to do some stuff async.

I remember we talked about the idea, as much as possible, off thread is ideal. It's just a little hard to know what and when to do that.

Dave: Yeah, and I think we kind of came up with, any time you do async code might be a place where you could spin off a worker.

Chris: Yep.

Dave: That then runs code. GPUJS over at gpu.rocks is somewhat similar. But if you think about, like, you have a four-core CPU or, maybe if you have a fancy computer, an eight-core CPU, you have eight potential threads that you can run. Probably more but, basically, eight CPU cores you can do math on.

If you do a GPU, well, now you have access to a whole other chip that can do math on, and so you can get very fast.

Chris: Mm-hmm.

Dave: You now have a whole other -- you're not even on the main chip. You're on the, like, other chip inside your computer that can do math. I think my GPU has 3,000 CUDA cores or something like that. I have 3,000 cores or something on that GPU.

Chris: Hmm.

Dave: If you think about I in those terms, it's different, right? [Laughter] I can do a lot of threads over here, a lot of math over on that GPU.

Chris: Gpu.rocks is the URL for this. It's probably something that you could do anyway, but it's a library that abstracts it away so that you just constGPU=newGPU and now you have this thing to talk to that has an API for running stuff over there. You still need to know what you're doing. This isn't going to allow you to do anything out of the box without -- you know you don't -- you're not benefit without knowing what you're doing over here. I would have no idea what to use it for, but I'm sure there are people that have a very strong idea of what to use it for.

The website itself has this, like, jellyfish at the top that's doing something that very much looks like it's going to slow down my browser. It looks like a GIF rendering or a movie, but it doesn't do anything. It hardly affects the memory usage at all on the page. I do think of your -- I know you've brought this up many times is the paravel.com page.

Dave: Yeah.

Chris: Where you're doing some -- that's not Paravel.com. That's the medieval castle.

Dave: Paravel, yeah. Paravel.com is somebody who does not want to sell their domain. [Laughter] Paravelinc.com is my website. Yeah, we have the big background image that we're kind of cycling colors. Yeah, they're looking like they're doing--

Chris: Are you already doing it as a worker?

Dave: In worker, yeah. I've optimized it a little bit. I could probably get better because, again, I don't particularly understand array buffers and stuff like that. That's all, like, I could probably make it better doing that. But this GPUJS, I don't know what they're doing here, exactly, but they are glitching out this image pretty big. Oh, they're just replacing different PNGs and GIFs, so I don't think that's actually math they're doing. They're just swapping image sources.

Chris: Well, what's funny to me is then it's still -- oh, and some of them are GIFs.

Dave: Yeah, yeah, yeah.

Chris: I don't know if the GPU is doing anything at all there. That's interesting. But -- hmm. Because you'd think, at the DOM manipulation level, you're back on the JavaScript main thread then. This isn't helping that. It's just the stuff that you did before you hit the DOM.

Dave: It would be for more like intense calculations or something like that. One common thing that people do is Bitcoin mining through the GPU. If you were going to create a client-side miner, this would be the tool to do it. [laughter]

Chris: [Laughter]

Dave: Not that we really condone that, but--

00:08:54

Chris: You know I have -- here's another -- in my little text game, text game update, there's a highlighting, so there's just constantly text just streaming into this field. Imagine, you know, almost like the matrix view or something but it's like bottom-up. Like if you're on a Slack channel with 10,000 people and everybody was talking. It's just, whoa, it's just flying up from the bottom. But it's syntax highlighted too. It's not just, like--

Dave: Whoa!

Chris: You know what I mean? Certain words are there and there's a function to be like, "I want to highlight this word whenever it comes up," because let's say you make a friend in the game and you want to highlight them in special friend pink.

Dave: Mm-hmm.

Chris: Then you can add that as a storage thing and then that's -- so there's a highlighter. The highlighter has work to do to do it. I wonder if that's the kind of thing where you could be like, "Okay, I got the text from the game. I'm just going to render it. But then off-thread, I'm going to run the highlighter over it because that might take a minute because it could be a big chunk of thing. it's got a RegEx over it. Then when it's done, I'll DOM replace it in the feed so that then it's highlighted. It's kind of like async highlighting. I wonder if that would be a use case.

Dave: I think that would be a great place. You kind of just send it a brick of text and say, "Come back with a highlighted brick of text," or something or, you know, stuff like that.

Chris: Yeah.

Dave: Or just tell me yes or no if this thing exists in there. Maybe that's all you're trying to do there.

Chris: Yeah.

Dave: You know?

Chris: Actually, that would be interesting too. But it would be a little weird to have a flash of unhighlighted text, in a way. It's kind of nice, but you wouldn't want to slow it down either. Like all games, it's very time-sensitive, so rendering is absolutely fast as possible after you get that piece of text is paramount, you know?

Dave: Yeah, but maybe you have to do a pre-render operation, sort of. Yeah.

Chris: Yeah, you might have to.

Dave: Wow.

Chris: Anyway, it's just kind of interesting to think about. It's not every day that you're going to have this type of stuff. My dream, of course, is that this technology improves and then libraries start taking advantage of it in a way that we don't have to think about.

Dave: That's what I hope. I hope that it just becomes kind of -- not to -- I've said this a billion times and I'm going to just, anyway, put a dollar in the jar, that the Rails for JavaScript, or whatever, that I mythically want, it would be great if one just kind of had the async code built-in. It's like, hey, oh, you're going to go fetch stuff? We'll do all that async, or something. Or even off-thread or something like that. That would be awesome.

I think Redwood has pretty good potential here, to be honest, with just how they've broken up the component lifecycle into those cells, I think is what they call them, but they have loading, success, error. They have those different cells. Those could all kind of behave intelligently. You know? Because it sort of assumes the data is coming from somewhere.

Chris: This is all related to, you know, React has suspense now or whatever.

Dave: Yeah. Yeah.

Chris: That's related, too. It's like you'd think anything suspense related to could make use of off-thread stuff.

00:12:06

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by WordPress.com. You might know WordPress.com as the hosted version of WordPress, so you need nothing at all. You want to spin up a site, you go to WordPress.com. You spin up a site and it could be for anything.

It could be an e-commerce site. It could be a landing page site for your business. It could be a portfolio site. It could be a photography-based site. It could be a blog, of course. I love all those ideas.

Please have a site for the things that you do, including a personal website and those for your businesses. That would make me happy and it'll be a site that you don't have to worry about because it's totally handled by them, right? There's no performance concerns or getting hacked concerns or all that. I really like it when people choose WordPress.com for sites with zero technical debt. Let them handle the stuff.

This is something that I don't think a lot of people know. It's a relatively new thing is that you can have -- and you've got to be on the business or e-commerce plan to have this -- SFTP access to the site and you have database access as well. It's really similar to any other host, right? You sign up for a hosting plan and they're like, "Here's your welcome email with your SFTP credentials. This is how you SFTP in and put the files here. That's how you operate a website."

A lot of us these days--I know this is how I do it--have some kind of deployment system set up that has access to those SFTP credentials so that I'm working locally. I'm working in Git. I'm committing to branches and all that. The deployment software is like, "Oh, somebody pushed something to master. I'm going to go ahead and deploy that to the live site." That's how I do things. I think that's a nice kind of DevOp setup that even somebody like me can do without extreme DevOps knowledge.

There's no reason those SFTP credentials couldn't be to your WordPress.com plan. You're just using it like a WordPress host, which I think is really neat. It's like you can still have this modern developer workflow be working locally on your WordPress site and then shipping it up to WordPress.com. You could have your own plugins, your own theme. You can mess with the functions.php file.

It's still your totally custom WordPress site. It's just hosted on WordPress.com. It's kind of a mind shift because I don't think people think of WordPress.com in that way and that's because it's new and you can do it now, so try it out.

[Banjo music stops]

00:14:36

Chris: I am just talking out of my depth here. Maybe we should cycle onto something where I actually know what I'm talking about a little bit, but not too much because that's limited.

I was starting to collect links because I feel like every time I see one of these type of apps get linked up, people are like, "Oh, my god. This is so cool. I've never heard of anything like this." Then I see a different one. Then I see the same type of sentiment.

It turns out there's a little submarket around these types of browsers that are purpose-built for developers. It's not just Chrome and Firefox or Safari or whatever. It's like Blisk or Sizzy or whatever.

Dave: Okay.

Chris: The idea is mostly responsive design. One of them is, yeah. Sizzy is the--

Dave: Oh.

Chris: I'm trying to evaluate them right now. The point is, you get this really big browser and then, instead of just showing one thing, it shows you--what do they call it--a device wall, kind of.

Dave: Yeah.

Chris: But it's a live device all and it's within one browser. As you're developing, you could have your mobile app open and your desktop open and just work away like you normally do. It's just, you're looking at both "versions" of your site at the same time. Kind of cool, isn't it? It's a clever idea, but then somebody took that idea.

These apps are that on steroids because they're like, well, I know who is using this browser. Its designers and developers are using it to do their day-to-day work. Why not put a dark mode toggle right in the UI? You click it. Now you're in dark mode. If you unclick it -- you don't have to go over to system preferences or whatever you do on Windows to find the toggle and change it. It's just right into the app.

What if I want to turn JavaScript off? Hey, there's a button. You click it. Now JavaScript is off and the pages reload without JavaScript.

It has all these little features built into these apps and they all have different features but it's kind of clever. Now that I'm actually looking at them, I'm like, "Hmm." I wonder if my day-to-day work would actually benefit from actually using one of these because, to be honest, I don't. Do you? Have you heard or seen these?

Dave: Well, you know, Electric Pulp, a very talented agency, they did the Stephen Colbert websites and stuff. But they had this thing called Duo a long time ago. It used to be on the Mac app store but I don't think it is there anymore. I liked it and I've actually built something similar called Double Wide that would give you a mobile column and a desktop column.

Chris: Yeah.

Dave: It was just a plugin with some iframes and it would try to scroll match, but then it'd bottom out. But, yeah, these tools are cool, especially if that's the piece you struggle with. Does that make sense? Understanding or visualizing the responsive flow is hard. I think you need something.

I think, too, in teams, if you redesign the homepage, it'd be great to demo this with that app so that you could just be like, "Hey, here is the thing on 12 different devices or different screen sizes. Let's poke holes in what's wrong," or something like that. I think that would be a great use of the thing or a tool like this, a browser like this.

Chris: I kind of like your idea and the Duo idea. There was one more I looked at that encouraged that, like, just look at the two. They're really small, the small and the big.

Dave: Right.

Chris: A lot of the rest of these were focused on showing you eight at once and you're like, "Hmm. Maybe." I could see that mattering sometimes but probably, for most of us, it's the two or three.

Dave: Yeah.

Chris: You know.

Dave: Yeah.

Chris: Not eight.

00:18:32

Dave: Well, and yeah. Ideally, I think you need the two or three. I vote, for a long time, the code editor space is so precious, but I've wanted the mobile view in my code editor. I think you can do that with VS Code and Edge now. I think there's some interface to make that happen, like where you get a browser window in your code. I don't know because that could be kind of cool, like you're building it out and it's building automatically in your browser or in your editor. That would be kind of cool.

Chris: Yeah. There's got to be. Has nobody done it yet for VS Code?

Dave: Yeah.

Chris: Slap an editor in there. I bet they have.

Dave: Yeah, yeah, I think it's Edge. There's an Edge browser for code, which I have it, I think. I just don't use it but, ideally -- I don't know. I just -- I don't know. [Laughter] Just old habit, Alt-tab and go to the stupid -- [laughter] go to the browser.

Chris: Yeah, it's funny. What would you gain out of it being in there? Is there any integration that would matter? I don't know.

Dave: A debugger straight in, so dev tools or whatever straight in. If your code is barfing, it'll barf in the error console and code, if that makes sense. There is a benefit.

Chris: Oh, because of source maps or whatever? If there's an error in the browser, it could open up the file the error is in and show you that line? That would be pretty--

Dave: Yeah, it could maybe reference where it actually fell apart. That's kind of cool.

Chris: That is actually really cool because, at first, I wasn't even using the terminal in VS Code, really, because I was so ingrained in the other terminal I use and then slowly, but surely, I think it kind of pulls you into using the terminal in it because even just little things like you open a project and hit Ctrl backspace. The context of that console is the folder that you're in.

Dave: Mm-hmm.

Chris: If you need it in a subfolder, you can right-click on that subfolder and go, "Open new terminal," and it'll open in that folder context. It's like, whoa, that's nice.

Dave: Yeah.

Chris: [Laughter]

Dave: Yeah.

Chris: I almost use the console in VS Code more than a separate console.

Dave: Yeah. No, I--

Chris: But I'm not totally converted over yet. [Laughter]

Dave: Well, yeah. I mean I kind of still have a foot in both worlds but I use the Code console quite a bit. What I don't do is the launch. You know how you can set VS Code to launch the code. It's F5 on Windows. I'm not sure what it is on Mac.

Chris: I've got it set up. In mine, it's a .code workspace file.

Dave: Uh-huh.

Chris: Then that then has stuff in it. How does this work? I'm trying to remember. The idea is that you can tell it, though, to launch some commands when the code workspaces open up. For example, if it's an 11ty project and you have NPM run start as your script, if you open that project, it'll just open a terminal and run it because it's like, "I know what you're doing. You're trying to work on this project. You might as well spin it up as soon as it's open." You know?

Dave: You can type debugger in your Node thing and it gives you a step-in debugger for Node apps. If you're like 12 levels deep on a for loop, you don't have to just console log-out stuff in a terminal that then disappears. You can just stop the debugger in there and you get dev tools and stuff. It's pretty cool but I don't really use it that much.

Chris: Yeah, it's called tasks.json is the thing if you wanted to run your tasks here.

Dave: Okay, and it'll infer your task too. It can read your NPM scripts too. It's weird, so anyway.

Chris: Oh, really?

Dave: Yeah.

Chris: Yeah, I mean in my case, I have a task and I have a label of run Gulp. I use Gulp to spin up CSS-Tricks, for example, because--I don't know--I just do. I'm just fixing it right now because I've had one little problem with it where I spin it up and then the terminal opens and runs the command but then it says, "This is not supported by this version of Node." Something happened to my Node where it's always on the wrong fricken' version of Node.

Dave: That sounds right.

Chris: [Laughter] I NVM, you know, because that's obvious. Then I think this is just a good practice in projects anyway. In your package.json and/or in a .nvmrc or whatever file, you can say what version of Node you want, so you can just type nvm-use and it will automatically go to that version of Node.

Dave: Yeah, it'll remove it.

Chris: Then my command can just be nvm-use and Gulp.

Dave: Okay.

Chris: When I open a project, it just gets on the right version right from the get-go. What do you think of that? Hmm?

Dave: That's smart. Hey! Solve the problem upstream, you know, using the least possible effort. I am into that.

00:23:23

Chris: Day-to-day, you just use Chrome or Edge for you, right?

Dave: I just use Edge, yeah. You know when Edge went Chromium, I considered going to Firefox or whatever, just kind of to support the open Web and whatnot. My coworker Trent did and a guy I work with, Joel, went over to Firefox. But I think he uses Safari, too.

I like some of the features of Edge like its read-aloud feature. I kind of have bookmarking synced. Then they have this new profile feature where it'll detect, like, "Oh, you're going to a Microsoft SharePoint. Do you want to use your Microsoft ID?" or something like that. You know? It's like, "Oh, yeah, that's what I want to use."

It kind of intelligently detects what email profile or browser profile you're trying to use.

When I was on three different clients with three different active directory things, I was like, "Oh, this is great," because I was losing my S-H-I-T logging and logging out of everything all the time. Anyway, yeah, now I'm good.

Chris: That's cool.

Dave: I spelled my curse word, so it doesn't count against me. [Laughter] But, yeah, so anyway, there are some good features of Edge. It's still the most well-designed browser to me, but that's being really snooty, but you know. Hey.

00:24:54

Chris: Yeah. Yeah. It's a weird world. We should at least acknowledge the fact that Mozilla had terrible layoffs, 25% of their workforce, which was about 100 people, so that's interesting that Mozilla is only 400 people.

There's speculation being flown around, you know. A lot of the speculation was, hey, they got a big contract with Google coming up. This contract represents 90% of Mozilla's budget. That fact alone, Mozilla and Firefox only exist on the--

Dave: Charity of--

Chris: Not that they couldn't scramble really quick but, yes, it's charity. I mean--

Dave: Well, it's antitrust protection insurance. You know what I mean? It's antitrust lawsuit protection service.

Chris: Yeah, right.

Dave: Yeah.

Chris: It looks like you're a little bit more like, if Google doesn't have any competition that that's not -- the law doesn't love that.

Dave: Yeah, yeah. It's going to end up like Microsoft and IE. It's not going to end well for them, I don't think.

Chris: I'm sure they see other advantages. I'm sure there are tons of nuance to this deal, you know.

Dave: Sure.

Chris: I don't have all the facts here. I'm not a journalist. I haven't talked to lawyers. Whatever. But still, that's wild. There's an actual article quoting it's some $400 million to $450 million a year. That's a lot of money and you can definitely pay 100 employees with $450 million a year.

Dave: I hope so.

Chris: Oh, my god. That's not even in the ballpark here. There was another -- and then, right after they fired all the people, the contract renewed.

Dave: Right.

Chris: So, it wasn't the contract. That was, you know, it was something else. But they got rid of dev tools people, MDN people, and anybody that works on the platform. They got rid of David Baron, who everybody regards as this, like, he's a principal developer at Firefox. He knows everything about CSS and browser internals. Yeah.

Dave: Netscape, not Netflix.

Chris: Yeah.

Dave: He's been there since Netscape.

Chris: What kind of company is like, "Oh, this guy was just an absolute knowledge treasure who is actively participating, has ideas for how to solve container queries that he needs to get out to the world. Nah, we'll let him go." What?!

Dave: Yeah.

Chris: Then you're stopping development on dev tools, which is the one thing that developers kind of preferred in Firefox is they had some pretty interesting tools that people liked. That will never be worked on again.

Without getting too deep into any weird conspiracy theories here, it's dead. It's dead.

Dave: Well, yeah. You can't wholesale your team and just be like, "Well, we'll just hire new people to work on it when we're ready."

Chris: You can't re-staff. No way.

Dave: Yeah, you basically nuclear optioned your knowledge repository, you know, like the working knowledge of the system, and so that's bad for that. You know I'm sad about the Web VR. The Web XR team, I think, got cut and they were doing the coolest stuff, like really genuinely. I know that maybe speaks more of VR, actually, to flop potential VR, but they were doing cool stuff. They were coming up with cool ideas and interfaces and A-Frame is excellent. It's a declarative VR framework. You write HTML and create VR. It's ridiculous and it's gone or it's not gone, I guess, but those people are now looking for work.

I don't know what they're doing. You know when somebody--? It has to be they're moving to Chromium. I don't know because, like--

Chris: That's what I would guess, too.

Dave: How do you just cut a whole giant piece, a whole heart, like the community stuff, I guess, goodwill building portions of your company out, and then your blog post is like, "We're going to focus more on the community"? I don't see it because I'm just kind of curious. You got rid of the parts I liked, so what's left? The VPN? I guess I like the VPN.

Chris: If you tell me, "We are the privacy-focused browser. We care about--" and then some new Web technology comes around that needs to look at privacy, who is going to work on it? Well, not browser people because you don't have any of those any more. I don't trust you anymore to be the privacy-focused browser because you don't have anybody to work on those things.

Dave: Yeah. You got rid of all the people, so what? I don't know. Yeah, I can't see -- I read the blog post, but I did not understand the plan. Does that make sense? It was like, "We're going to be better."

Chris: Yeah. Right.

Dave: It's like, I just don't understand the plan here. I get times are tough and running a thousand-person company or whatever is a lot or whatever, but I just don't understand how you can -- I don't understand how the browser goes forward with the wholesaling a huge core of the team like that.

Chris: Yeah, well, show us. What are you going to do?

Dave: Mm-hmm.

Chris: Let's see. Is it going to be interesting to me or am I not the target audience? You've already lost me, maybe, which is fair, so maybe they just don't care. You know?

Dave: Right. Maybe they're just following the money. I don't know. They're like, "Oh, we've got to build this VPN product because it's the only thing that actually makes money, or whatever. I don't know.

Chris: Yeah, maybe. That could be it. I don't think that the VPN, there's enough of a market there to replace that kind of budget. The other thing, if you're this privacy-focused browser, part of the job is to laugh and snicker at Google a little bit and be like, "Ew, big brother. Their ad tech is so gross." That's part of the narrative. You have to say that. Otherwise, nobody is going to care.

Dave: Right.

Chris: That's why you exist is to be the anti-Google. Yet, 90% of your budget is Google? What do you slap their wrist a little bit in a blog post and be like, "Sorry, daddy. I didn't mean it"? You know?

Dave: [Laughter] Yeah, I mean I don't know how you enforce the person who pays your bills or pays your rent, so you kind of can't bite the hand that feeds you.

Chris: If I sound salty, I am a little bit. It just seems like -- and this, but the thing is, this has been true for a long time. This happened to be the big kind of moment thing, but the fact that their budget has been from Google, that's just the way it is at Mozilla. You know? It's just now the tech is gone, so I think they know what they're doing. You don't fire all these people with fundamental knowledge of how your browser works if it seems like you're not going to have that technology for very much longer.

Dave: Right.

Chris: You don't need David Baron if your entire stack becomes Chromium.

Dave: Yeah, you don't need a dev tools team if you're hiring Paul Irish by proxy. [Laughter]

Chris: Yeah.

Dave: You don't need it because you already have a dev tools team at Microsoft and at Google. I hope that's not it, but if I were to--whatever--be a betting man, I think it would be -- I'll bet all my XRP Ripple Coin on the fact that they'll switch to Chromium, but I don't know.

Chris: They still own MDN. It's just the people because a lot of talk has been about MDN, too, like, "Save MDN! Oh, no! It's going to die." They're saying, "It's not going to die. We still have it. There's still at least one or some people on the team." I think it was mostly gutted.

Dave: Yeah.

Chris: But I think the original dude is there. Then some people will be like, "Well, it's a wiki, so it's fine." There's a lot of pushback about that, like, "No, it won't be fine." [Laughter] That's not--

Dave: No.

Chris: That's not how those things work.

Dave: Wikis only work because they have editors and they have people who care and they have people who work on it and groom it. At the rate of Web stuff, you need people who care. You need people who are involved, invested, financially, monetarily. You can't just have any rando writing JavaScript articles on MDN because they'll just link to their own repository on GitHub.

Chris: [Laughter]

Dave: That's how -- [laughter]. You know? That's what I would do. Oh, we're talking about clamp in CSS? Link it to fix text. That's what I'd do. I'm always be closing Dave Rupert. That's marketing for me.

Chris: Oh, I think Rachel Andrew had a good point about, like, anybody can write an article about some brand new thing that they're super excited about right now, but things like that need a bunch of very boring writing too. They need writers who are willing to dig in very comprehensively to technology that isn't necessarily all up in their brains right now anyway. They're like a technical writer of a different ilk, you know?

It needs a paid team. Somebody, you know, but it's not really for sale. We can speculate about where it's going to go, where it should go, what we can do. It's not up to us. That stuff is not on the table. They are not soliciting ideas for where MDN should go and how it should be handled. Not happening.

Dave: Yeah. It's such a weird move, and that's the thing. I don't get the moves, man. I don't. It says, "Oh, we're focusing on community." You know? It's like MDN, that's where everyone gets their information. What you do mean? That's the community. That's probably your biggest goodwill builder. How do you just let that go? Anyway, there's a lot of talented people looking for work and we do wish them the best. I'm pretty good at….

Chris: Yeah. Mozilla themselves made this lifeboat website or whatever to help them get hired. It just feels so strange to me.

Dave: Yeah. I don't know. This is salty. Again, salty Dave Rupert here. My company makes a Web -- lets me go and then makes a website for me? I don't want it. You all did enough. [Laughter] Don't talk to me. I'm done.

But I guess it does help people. You know it's such a big organization. A lot of contributors probably aren't recognized. You know what I mean? And they want them to land on their feet, so that maybe is a good thing. But if an employer just was like, "Goodbye," I would just be mad.

Chris: I have raised my hand, by the way, everybody. Just be aware, I'm willing to take on MDN personally.

Dave: Perfect. Let's do it. Let's do it. We'll call it ShopTalk DN.

Chris: Yeah, mdn.shoptalkshow.com.

Dave: ShopTalk.

Chris: I'm willing to give you one subdomain.

Dave: ShopTalkdocs.com and ShopTalkdocs.com is where you get all your latest function news, APIs, all of it happening over at ShopTalkdocs.com.

Chris: I kind of wonder what their traffic is because I know what my traffic is at CSS-Tricks. We get some pretty good, you know, search engine results traffic on CSS-Tricks. And I extract every dollar I possibly can from that traffic. That's the business I'm in.

Dave: Mm-hmm.

Chris: I know not everybody loves that. Too bad. At least I'm an example right now for what that can be and I know how much money I make on CSS-Tricks, which is all right. If I didn't pay anybody, it could be my full-time job, maybe, almost. That's one person.

But I know that the way search traffic works is that it's really exponential as you get higher up. If you're always the first result, you have 10x, 20x more, at least, traffic than the third result, for sure.

Dave: Yeah. Yeah.

Chris: MDN is always higher than me, so it's a lot more traffic. Is the cache potential there from advertising, which probably would be rejected by the community anyway to sponsorship on there, but still, meh, it's still not amazing. I don't know that there's a noncorporate sponsored way to do MDN with just regular old ads on the site.

Dave: Right.

Chris: I think you could hire a couple people, maybe, but is that enough to keep it going?

Dave: Yes.

Chris: The business model of MDN is not easy to solve.

Dave: Right. It's not. It's maybe buy a boat money. It's not--whatever--buy a building and fill it full of people money.

Chris: Exactly. Exactly.

Dave: Well, and you needed skilled people. You need people who know how to read a spec, you know, and can translate that to English. It's tough. I know. It's hard.

Chris: All right. Well, that's the Mozilla talk. We don't know anything that you don't know. We read all the same blog posts, for the most part. I heard from a couple of Mozilla employees, though, but nothing juicy that I would even be wanting to paraphrase, really, but just generally some confusion and a little anger, I'd say.

00:38:16

[Banjo music starts]

Chris: Hey, ShopTalk listeners. This show is brought to you in part by CodePen. That's me, your host, Chris, Co-founder of CodePen also. Sometimes I like to sponsor our own shown and tell you about CodePen. It's a freemium app, so you can use CodePen for free. But I hope to compel you with the features of CodePen Pro.

One reason you might upgrade is just because you like this show. That's fine with me. I'll take your support that way but, ideally, there's some part of pro that makes you want to upgrade.

One of the little things you get with pro is that you get unlimited embed themes, so you might build something on CodePen in which to then use somewhere else, like use in a blog post or documentation or whatever. It's nice because you change your theme and then it changes on every single embed where you use that theme.

Of course, that's very important to me on, like, CSS-Tricks, for example, where I might want to change the look of the embed because we're redesigning the site or just want to freshen things up or something and have that theme change over the entire site. Of course, I do that.

If you need several, a bunch of themes, just go pro and you have unlimited of them, which is cool. Just one of a dozen or more features you get for upgrading to pro on CodePen.

[Banjo music stops]

00:39:42

Chris: All right, so let's do a special segment here on the ShopTalk Show. This is from the book JavaScript for Web Designers by Matt Marquis, a friend of the show. What up, Matt? Is a wonderful writer, I think. The world needs more words written by Matt. He just has such a funny style of saying things.

Now, most of the people who listen to this show probably know what JavaScript is, but we're going to retell you anyway or let Matt retell it to you from his book. He's going to just really talk about just the basics of JavaScript, but he's so good at explaining stuff that I think everyone will appreciate this little clip. Let's listen to Matt.

00:40:19

Matt Marquis: What even is JavaScript? The name itself could be a little confusing. Seeing "Java" in there might conjure up images of ancient browser applets or server-side programming languages.

When JavaScript first came about back in 1995, it was originally named LiveScript, a nod to the fact that it runs as soon as the browser requests and parses it. But Java was the new hotness back in 1995, and the two languages shared a few syntactical similarities. So, for the sake of marketing, LiveScript became JavaScript.

JavaScript is a lightweight but incredibly powerful scripting language. Unlike many other programming languages, JavaScript doesn't need to be translated from human-readable code into a form that the browser can understand. There's no compiler step. Our scripts are sent across the wire at more or less the same time as our other assets--markup, images, and style sheets--and then interpreted on the fly.

While we most frequently encounter it through our browsers, JavaScript has snuck into everything from native applications to ebooks. It's one of the most popular programming languages in the world, largely because you can find it in some many different environments. JavaScript doesn't have any strict requirements for where it runs as long as there's an interpreter to make sense of it. Open source browsers mean open source JavaScript interpreters; a part of the browser that parses and executes JavaScript.

When developers drop these interpreters into new contexts, we end up with JavaScript-powered Web servers and homemade robots. We'll be looking at JavaScript as we encounter it in the browser, but this is good news if you find yourself feeling particularly mad scientist-y by the time we're finished. The syntax you're learning here is the same syntax you might one day end up using in your JavaScript-powered freeze ray.

The interactive layer: JavaScript allows us to interaction to our pages as a complement to the structural layer that is markup and the presentational layer that is CSS. It gives us a tremendous amount of control over users' interactions with the page. That control even extends beyond the page itself and allows us to alter the browser's built-in behaviors. You've likely encountered a simple example of JavaScript altered browser behavior more times than you can count.

Form input validation: Before a form can be submitted, a validation script loops through all associated inputs, checks their values against the set of rules, and either allows the form submission to go through or prevents it.

With JavaScript, we're able to build richer experiences for users like pages that respond to their interactions without needing to direct them to a new page even when requesting new data from the server. It also allows us to fill in gaps where a browser's built in functionality might fall short, work around major bugs, or port brand new features back to older browsers that lack native support for them. In short, JavaScript allows us to create more advanced interfaces than HTML and CSS could do alone.

What JavaScript isn't anymore: Though it gives us a lot of power over browser behavior, it isn't hard to imagine how JavaScript might get a bad reputation. To render a page unusable with CSS--no pun intended--we have to be explicit about it. Setting display none on body isn't something that generally makes it into our style sheets by accident, though I wouldn't necessarily put it past me. It's even harder to make a markup mistake that would prevent the page from functioning at all.

A strong tag mistakenly left open may not result in the prettiest page ever, but it isn't likely to completely prevent someone from using it. When CSS and markup errors do cause major issues, it's apt to happen in a visible way. If HTML or CSS do completely break the page, we're likely to see it in our testing.

JavaScript differs there, though. For example, if we include a small script to validate a street address entered into a form input, the page will render just as expected. When we punch in 5 Address Street to test it and get no errors, our form validation may seem to be going according to plan. But if we're not careful about the rules for our validation script, a user with an oddly formatted address could very well be prevented from submitting valid information. For us to test thoroughly, we need to try as many strange addresses as we could find and we'd be bound to miss a few.

Back when the Web was younger and the Web development profession was brand new, we didn't have clearly defined best practices for handling JavaScript enhancements. Consistent testing was all but impossible and browser support was incredibly spotty.

This combination led to a lot of flaky, site obliterating scripts making their way into the wild. Meanwhile, some of the Internet's more unsavory types suddenly found themselves with the power to influence the behavior of users' browsers, held back only by boundaries that were inconsistent at best and nonexistent at worst. This was not, as one might expect, always used for good.

JavaScript caught a lot of flack in those days. It was seen as unreliable and even dangerous. A shoddily built popup engine lurking somewhere beneath the surface of the browser.

Times have changed, though. The same kinds of Web standards efforts that have brought us semantically meaningful markup and reasonable CSS support have also made JavaScript syntax more consistent from browser-to-browser and set reasonable constraints around the parts of the browser's behavior it can influence. At the same time, JavaScript helper frameworks like jQuery, built on a foundation of best practices and designed to normalize browser quirks and bugs, now helps developers write better, faster JavaScript.

Let's get started. Over the course of this book, we'll learn the rules of the JavaScript game at is it played, spend a little quality time wading through the DOM, and pull apart some real scripts to see what makes them tick. Before that, though, before we go toe-to-toe with the beast that is JavaScript, we have to get familiar with the tools of our new trade. I'm from a carpentry background and if somebody had sent me up on a roof on day one, I'm not sure I would have faired too well or been around to write any of this in the first place.

In the next chapter, we'll start getting a feel for the development tools and debugging environments built into modern browsers and we'll set up a development environment who are ready to start writing some scripts.

00:47:17

Chris: All right. What did you think of that, folks? We're thinking of doing more of that kind of thing on the show with people reading blog posts of themselves or others just to--I don't know--have a little segment; hear a different voice on the show.

Dave: Like audible RSS, in a way, and I'm looking forward to it on many levels. Yeah, we've solicited quite a few friends here to hopefully read their posts or their books or things. Hopefully, we'll have that but do let us know if that's something you're interested in or how that's all working for you.

Chris: Yeah. Cool. Craig Rosenberry writes in, "You know with all the different ways to build a site, I wonder if you have any good suggestions on spinning up an information only website. It's not e-commerce." There are all these different site archetypes, but we're talking info only. He's saying, "That WordPress and Squarespace seem to be a little much for that kind of thing. Any advice you could give me would be great."

Client work and they're brochure sites, let's call them. I know we've talked stacks. That's a little light on information, perhaps, to be making the technology call right now. But let's say, you know, take some guesses as to what these type of sites are like and what would you reach for?

Dave: I've done it both ways. You can write an index.html, chuck it up to GitHub, and you have GitHub pages. You don't even need to use Jekyll. You can just do that, index.html. Chuck it up to GitHub pages. I've done that.

Chris: Yeah.

Dave: It works pretty good. The problems, I guess, are just normal Web problems. Somebody is going to have buy a domain and then forward the DNS and do all that stuff. That's not fun. But I've also had a friend who runs a trailer park, like an eatery here in Austin, in south Austin.

Chris: Cool.

Dave: Called the Thicket. I helped him--

Chris: Does it have a Torchy's at it?

Dave: What's that?

Chris: Does it have a Torchy's at it?

Dave: No, but it does have pretty amazing food. Their Instagram is, like, I've moved up to north Austin and I'm regularly like, "Ah, man. I'm going to have to drive down to eat this chicken sandwich, aren't I?"

[Laughter]

Dave: It looks too good. But you know, and so it's a website for, like, seven, eight trailers. They have events. They kind of want to advertise the eateries or the facility. They do outdoor yoga and stuff like that.

I got them up and going on a Squarespace just because they were like, "You know, we're going to want to manage some of it. Our trucks change kind of somewhat irregularly, so we'd like to be able to handle that." I got them set up on Squarespace and it was okay.

Chris: It was all right?

Dave: Yeah. Again, it's not my favorite thing. I could probably say that about a dozen things I've built stuff with. It's not my favorite thing but it works and it gives them a little agency to kind of build stuff. Occasionally, they'll have to call me in for something more complex. I think it tends to work. I would recommend those.

Webflow is another good one if you just wanted to do a little one-pager in Webflow, something like that.

Chris: Yeah. I was surprised. I hadn't looked at this particular feature until I did a screencast with them a couple months back. They have a CMS that's built into Webflow too, but it's like a two-faced CMS. One of it is for you to set up the fields and all that. Then you're using the Webflow itself and you're editing. But then they have this face for the CMS that's for clients.

Dave: Yeah.

Chris: You get this bar along the bottom and you open up and change stuff and stuff. It's kind of like it was designed with clients in mind. That was my first question with these brochure sites. It is just one and done, get it done, put it up, move on, never touch it again only with minor updates? Or is it the kind of thing were you're trying to hand off editability to the client? Now, that's always been a thing forever and ever and ever and ever.

Does this site need to be client editable or not? If it does, it totally steers the direction of what technologies you're going to use. You can't just do an index.html file only because clients aren't just going to edit HTML. That's still a specialty skill set and that's fine. It's much easier to use some kind of UI to do it.

There are still a million billion choices. Even as technology evolves, like with JAMstack and stuff, that's still a thing. Because it's a website and because clients need to edit it, everybody wants to be that source. That source can be all kinds of different stuff from headless CMSs to JAMstack purpose-built CMSs that are UIs for essentially editing, the static files that power that site. But then it's like, you could have just picked Squarespace, too, or you could have picked WordPress, too. Even though it's a bit much may be feeling, at least it solved that problem, which is a honker of a problem, so maybe that's good. You know?

Dave: Yeah.

Chris: I almost err that way from the beginning. As much as it appeals to me to make just an index.html file, I would only do that under pretty extreme circumstances where I knew it would never need to really be edited in a significant way.

Dave: Yeah. Yeah, all that updating falls on me and that's the least best thing. Yeah, WordPress, if WordPress is too much, like setting up a whole install, WordPress.com might be the solution too. Just get there.

What I always tell people for these small, kind of one-offs, or very tiny sites, build something in the cheapest way possible to get something up and then iterate from there. Squarespace is what, about $17 a month or something? You can build it and then, if you hate it, then start planning what you're going to do after that. At least you have a website up and customers can get information. That's what I would say.

Chris: Yeah.

Dave: If you're a technology company and you have tools for this stuff to build out little pages or microsites or event sites or something for a client, that's another. You may want 11ty and Netlify CMS or something like that. That's another good option but only if you have dedicated--

00:54:10

Chris: Stackbit also has a bunch of fancy tools they're building around in this space that look interesting, too, just for the record.

I was going to mention, just in case Jeremy happens to listen to this particular episode, I saw on his blog post the other day. The Clearleft now has a podcast as well. Have you seen that?

Dave: I have heard of that. They haven't invited me on, but that's beside the point. It's fine.

Chris: It's like a six-episode series. I mean to read it too because it looks really, really good. Here. I'll read from Jeremy's blog post.

"Design-wise, it's a riff on the main Clearleft site in terms of typography and general layout. On the development side, it was an opportunity to try out an exciting tech stack. The workflow goes something like this. Open a text editor and type out HTML and CSS."

[laughter]

Dave: Ooh!

Chris: That's it. Then he writes, he says, "Comparing this to other workflows I've used in the past, this is definitely the most productive way of working. Some stats. Time spent setting up build tools: zero minutes and zero seconds."

[Laughter]

Chris: "Time spent wrangling pipeline to do exactly what you want: zero minutes and zero seconds. Time spent trying to get the damn build tools to work again when you return to the project after leaving it alone more than a few months: zero hours, zero minutes, and zero seconds." [Laughter] Which I enjoy and you can go view source on the site.

Now, it's a podcast site and it has an RSS feed, for example, so I'm imagining Jeremy, as old-school awesome as he is, just opening up feed.xml, copying/pasting the last episode, pasting the new one at the top, and hand-editing all the values in that podcast field. I'm almost sure that's what he does. You know?

Dave: Mm-hmm.

Chris: Because there's no build tool at all, so God bless you. That's great. [laughter] I struggle with that. I like the automation. There's no way that I could let my fingers do that. I would 11ty up that thing in a second. You know?

Dave: Yeah. Yeah, yeah.

Chris: But -- [laughter] -- but, you know, I appreciate it and it's relevant to this question, for sure. Good luck, Chris. There are lots of ways to go. None of them are particularly wrong, I'd say.

00:56:26

Dave: Yep. Magnus writes in, "I've been messing around with Gutenberg this week and I'm actually enjoying it." Huh.

Chris: Hmm.

Dave: "I know it had a rough start with some developers but it seems to have matured. Have you all used it much? Pros? Cons? Experiences?"

I have not really used Gutenberg, so I am out, but I do think it's--

Chris: Well, I think it'd give you an opportunity on ShopTalk Show, but that's the one site I'm not using it on for us because we use all Advanced Custom Fields, for the most part, and it doesn't--

Advanced Custom Fields has a bunch of really, actually wonderfully powerful stuff. You probably heard spots on the show in the past of things. You'll hear more.

Dave: But our data is very structured, very granular. Yeah.

Chris: Yeah. We don't have a field that's like, put a bunch of blocks in this area. That's what Gutenberg excels at.

Dave: Yeah.

Chris: I don't even have it turned on there but, yeah, the block thing for me has been going super, super well, I'd say. I'm a big fan of Gutenberg. Just from a day-to-day authoring of blog post experience, which is very important to me, like what does it feel like to be an author and editor on a site, I really like it. I really like it. It's very different than that.

I've written in the past. If you're going to blog, blog in Markdown. I like that concept too because your Markdown is just going to last forever. It's going to be able to swap between technologies really easily. It's encouraging you not to put div class equals Dave left face header red on it or something.

Dave: Yeah.

Chris: Because it's Markdown will work.

Dave: No classes.

Chris: Yeah, no classes in Markdown. Gutenberg is kind of the opposite in that it's like, "Get fancy in there! Make that background green. Get weird, brother." But it's doing it -- it has the same spirit, believe it or not, because you're not writing those classes. They're abstracted by the parent technology involved here in a way that's like you're not going to -- I don't know. It feels like you're buying in too strongly. I'm not going to just turn off Gutenberg necessarily. Even if I did, there would be stories that would kind of make that okay. I don't know. I feel like that wasn't a very coherent thought but I don't worry about the content that I'm authoring in Gutenberg.

Dave: Yeah. Well, you know, the thing I always think about in client services, you know, or something, you know, somebody is like, "Oh, our About page. Write a little blurb. We're going to show the top five people that work here." [Laughter]

Chris: Yeah.

Dave: Then we'll do some testimonials. It's like, okay. I know how to do that. I'm going to write the Advanced Custom Fields, blurb.field.

Chris: Yeah.

Dave: Person1.field, that's a repeater.

Chris: Exactly. Yep.

Dave: Then testimonials. That's a repeater, maximum of three. Done. I did it. Here's your website. I program the template to render the fields in the correct way. Then what happens? They come back and they say, "Oh, we need a video in between two of the testimonials," or whatever. I'm just like--

Chris: Oh, sure.

Dave: Fridge, man. This is not easy. Or like now it's a mess and I knew it was going to be a mess and now I know it's a mess. Fridge.

As I understand Gutenberg, it's just like here is your content. You just chuck blocks in there. Staple the blocks together however you think it should work and we'll just do the rest, and it does it. That seems great.

Chris: Yeah, exactly.

Dave: It's like custom -- kind of more than just a blog post layout. It seems really helpful for that. You know?

Chris: Mm-hmm.

Dave: You can do that on Squarespace, Wix, or whatever the full designer, Weebly, Weblfow, all these full designer tools--whatever--and browser designer, but I feel like -- I don't know. I feel like it's a step forward from programming content the way you want it. You know?

Chris: Yeah, I think you sold it really well, especially for somebody who doesn't even use it, Dave. Good work. [Laughter]

Dave: [Laughter] I mean that's intuitive, you know, so.

Chris: Well, and they're trying to get to a site builder level, too, which is very interesting building the whole site that way. But you're kind of saying, like, for anything that's more than just a blog post. I think that's very true. It's very good at managing landing pages. But then, once you start using it, you're like, well, why not blog posts too? It's all the same Gutenberg editor.

I think it opens up possibilities for your blog post too. I'm going to get fancy in here too, man. Why not? You're kind of like, oh, then I was listening to a podcast by blah-blah-blah. Oh, let me just pull in the podcast block so you can listen to it too. Oh, that's convenient.

Oh, a testimonials block? Those are just built-in. Oh, where do I want the header? Do I want the avatar for the testimonial on the left or the right? Oh, that's just an option. I can just pick one from a dropdown and it'll scoosh its way over there.

And it looks like it's going to look on the front-end of the site, for the most part. It has a nice visual styles inside Gutenberg but, if you want, you can queue up your same CSS from the outside, inside. That way it looks exactly like the front-end of the site does. It's WYSIWYG for real.

Dave: My cool, Saved by the Bell, blockquote that I made, that's just going to look like a Saved by the Bell blockquote.

Chris: Yeah! I blogged for most of my life not in Markdown because I never did that on CSS-Tricks. I do on most other sites, and it was just HTML, but weird WordPress HTML, like HTML without the P tags because WordPress always had this weird auto-P function, which is eh. I know. I know. I know. I know.

But it was nice, almost. At least there was one nicety that I could avoid writing some HTML in there. But I was so used to, like, "Oh, a video goes in this post?" You know how I do that? Left angle bracket video source equals.

Dave: Yeah.

Chris: Drop-in URL quote controls end video tag. You know? I was like, okay, I can read this -- I can see what's happening here. On the front-end, there'll be a video. But when I'm editing the post, I just have to imagine that, whereas now in this Gutenberg, I can see the post as it's going to look and it gives me a more appropriate, like, what is this post going to feel like?

Dave: Yeah.

Chris: With this big video block here. If I put in a CodePen embed, it's there. If I imbed a tweet, it's there. If I make something look like a blockquote, it looks like a blockquote. I think that is just nice and it's just not to be -- like, I don't care about that. It's easy to be like, "What Chris is describing, I don't need that. I don't care about that." I didn't think I did either and now that I use it day-to-day, I just enjoy the authoring experience more. I think it's making blogging easier for me.

Dave: No, I would agree. I think, again, if that's where you spend your time, kind of back to the first question. Are people going to be spending time on this? If people are spending time on it, make a comfortable thing.

The same reason you install a theme on your code editor is because you're just like, "I want this to feel better." You know? So, I think it has value. Well--

Chris: That was just a quick one there. But, yeah, we could -- let's wrap it up.

01:03:39

Dave: I would like to talk -- I mean we should wrap it up--

Chris: Yeah.

Dave: --because we're out of time, but I'm curious about the authoring of plugins with React inside Gutenberg or WordPress. I'm curious how that goes, so maybe we can touch on that in the next show.

Chris: Yeah, real quick. I used one from a third party guy.

Dave: Yeah.

Chris: Gosh. Anyway, it was like a Create React App, but it was called Create Gutenblock, I think. I thought it did a tremendously good job of doing that but I think it became a little out of date and probably not a top priority for said person. WordPress has not taken that over but made their own.

I think if I was going to do it again, you'd use their block scaffolding pattern. It comes with all the niceties involved. It has a little Webpack builder and you just type NPM run start or whatever and it starts watching your little folder. It's hot reloading and yadda-yadda. It's got all the niceties of React development in there.

It's a weird type of React development. It really is just JSX and you can use state and use ref and whatever crap you want to in there.

But there's this other aspect to blocks that, to me, got complicated. There's a thing called block transforms, which may not matter to you with a new site or anybody else. It mattered a lot to me because when you turn on Gutenberg on a site, all your old content doesn't just become blocks. It's still in the old format.

Dave: Ah.

Chris: When it loads up, the whole thing just -- there's a liner on the whole thing and it says Classic Content or Classic Editor or something. You can convert it to blocks. It's a one-way tripsky there.

Dave: [Laughter]

Chris: You click the little hamburger menu and you open it up and say, "Convert to blocks." I think it does a phenomenal job. It's amazing that it works as well as it does. It looks at content, which is just this arbitrary string of HTML blah or Markdown or something.

Dave: Yeah.

Chris: It figures out what it should be in a block and does it. For me, I do enough weird crap over the years at CSS-Tricks that it's not the cleanest journey. At least it wasn't by default. I had to write some of these transforms myself. As the parser is going through the text, if it sees a tag that happens to look like this tag, then I want you to transform it to this type of block and put this type of content in here and this type of setting should be set to this value.

Dave: Yeah.

Chris: That stuff was complicated to me and I still don't have it perfectly right. That's not even particularly well documented. I know this is just for me, but I think if you have a big legacy site and you're thinking of going Gutenberg, it's still going to be -- that's where the effort really is.

Dave: Well, that's maybe a con or some experience. Okay. Fair balance reporting here, so we did it. [Laughter] All right, me, doesn't use it at all. Yeah, I use it. It's great. You used it.

Chris: [Laughter]

Dave: It's kind of -- you can kind of mess up your site, but anyway. [Laughter]

Chris: But you know it's worth mentioning. They sponsored before, but this show isn't sponsored that Advanced Custom Fields has a way of developing blocks that's far more intuitive to just normal classic WordPress developers. You can just make a block as a PHP file, put it in your theme, say, Advanced Custom Fields, that PHP file is a block, essentially.

Dave: Right.

Chris: And use it that way. And so, you're not writing any React code at all. It's not weird. It's just a PHP file and the custom fields gets splotched in there wherever you want them to be, which is awesome, and they have that feature inner blocks, which is cool too. It's like splat these custom fields in there but also, if you want arbitrary blocks inside of it, like native blocks, you can do that too, which that is something else.

Dave: Wow. Well, that's kind of cool.

Chris: It's mind-blowing stuff.

Dave: Yeah. All right, well, cool. Well, let's wrap it up. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.

If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.

Hey, Chris, do you have anything else you'd like to say?

Chris: End show block shoptalkshow.com.