Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, your favorite Web design podcast. I'm Dave Rupert. Hi, Chris.

Chris Coyier: Hey!

Dave: And Chris; there's also a Chris.

Chris: I'm here too.

Dave: Chris is also here.

Chris: I promised you last week that Dave and I would be doing another one of just us. Next week, fingers crossed, we'll have a guest again and talk about some special topics there. It's be Q&A again. I know last week our plan was Q&A and then we ended up talking about browsers for, like, 40 minutes.

Dave: Forty minutes, yeah. We did answer one question.

Chris: We did! We got one question in.

Dave: I think that officially qualifies as a question and answer. [Laughter]

Chris: Mr. Dave, let's flip that on its head this time and we won't be firing off our fake shotgun sound, but let's try to get through as many as we can. How about that?

The question, still, to this day, the number one question we get asked on ShopTalk show is, "What do I learn next?" Of course, people just can't get it off their mind. They want to know. They want to be told what to learn.

This one isn't totally different than that, but I like that he's got a goal. Chris Feneer [phonetic] writes in saying HTML, CSS, jQuery: that's his skillset now. He works for somewhere where I feel like that's kind of all he needs. He's reached a ceiling of how useful he feels. He has a very specific goal, and it's just to be more employable. To find a new job maybe that's better or he feels is more modern.

He's looking at stuff because he doesn't have any of these skills yet: SaaS, Gulp, Git, ES6, Vue. He hears these things but doesn't know any of them yet. I would agree, Chris. If you knew all of those things or some of them or whatever, it probably would make you more employable. You'll get past those early interviews easier.

We've said on ShopTalk Show, "Just build websites." That's what's important in this world anyway is that you're actually executing and building websites. Usually, you learn those things along the way. That's the point of our "Just Build Websites" thing here.

It sounds like if you're just constantly working and you're never asked to use any of these other skills that it's not really working for you. Dave, how do you force yourself to get more employable?

Dave: Yeah. The first thing I was going to say is, I definitely feel this, Chris, and I feel that this is just normal. I wish it wasn't the normal. I wish we had infinite time to learn everything. If you work at a WordPress shop or something, you get really good at making WordPress stuff, but then you have your head down for six, eight, nine, ten months. Then you look up, and You're like, "What am I reading on Twitter? I don't even understand any of the words. I'm good at this job, but I don't understand these words."

I guess it's two questions: What do I learn and then how do I make time? If you have a job, you have to borrow time from other places. I think there are ways to work it out within your company to be like, "Hey, I need time to brush up on my skillset. I think any company would want to invest in that, hopefully. If that's not the case, then you've got to do it afterhours, right?

Chris: I like that. I like that. Ask your company if you can level up because you think it might level them up as well. Maybe you could make the case for that. I don't disagree that learning newer technologies is going to make you more employable.

Yeah, like was Dave is probably headed towards is your afterhours stuff. If you really do need to force yourself into this thing, give yourself some table stakes. That's one of my classic talking points.

Tell somebody you're going to build this thing or promise that you're going to build something to them. Maybe pick technologies on purchase that you're going to use. In this particular case, who cares if they're the right technologies exactly perfectly for the job. You're doing this on purpose to learn them, so you can do whatever you want.

Build the dang thing in Vue because you're going to build it in Vue because you're going to learn Vue. Hopefully, the stakes are low enough that it's not tremendously a disaster if you maybe pick the wrong technology for the job or whatever. If it's a website, Vue has probably got the tools that you need to build it. If it's more static, then go Vue Press or Nuxt kind of way. If it's more dynamic, just straight Vue is probably fine.

Just get your way through it with Vue. All of a sudden, you're a Vue developer now and maybe you've increased your prospects a bit. Good luck, Chris.

Dave: Yeah. If you're coming from HTML, CSS, jQuery, the first thing I would maybe try to bite off is wrapping your head around ES6 and what that is because I think it gets tied up into all these modern frameworks and React. But if you really understand just some new methods in JavaScript that make it a little bit easier and more concise to write applications or any kind of logic in JavaScript, I would recommend learning that. I think the canonical resource here is maybe Wes Bos's ES6 course. It's really awesome.

I took it even though I knew ES6, but I just was like, you know, no one has ever given me the full picture. No one has sat me down and been like, "Okay, here is everything in it." I respond….

Chris: I still could use that. I write it all the time, too, but I haven't taken this particular course. I've taken other Wes courses. Yeah, it is nice to get the full picture of things like you're saying.

It's only been in the last three months where I've had any confidence at all in being able to even look at a map function and quickly grok it and be like, "Oh, I know what map does. I know what reduce does.

Dave: Yeah.

Chris: "I understand how this arrow function is structured and that there is an implicit return or a not implicit return. There is one param so it's not in parentheses, but there are two param, so they need to be in parentheses," and just all that little crap that I feel like you see and you can generally reason your way about, but to feel confident and fast in it is totally different.

Dave: Yeah. For me, it just felt like, "Hey, here's what's new. Here's what's new. Check it out."

If you don't understand it, that's fine. Knowing it exists helps, but there may be things you're like, "Oh, I can instantly use that now."

The big thing about ES6 is, a lot of it does replace jQuery, like entirely, so you might find, "Hey, I can just write ES6 and not use jQuery. Now, I've saved every client like 30 kilobytes. Yeah, every website I build now has 30 less kilobytes and 100 less kilobytes of JavaScript to execute. That's a big difference for your clients.

Chris: Then just replace it with Vue. [Laughter]

Dave: Then, yeah, we'll mess with the other -- I mean I'm specifically saying HTML, CSS, and jQuery go into Vue and now you just -- whatever. You put a poster of Sarah Drasner on your wall [laughter], light a candle, and just read CSS-Tricks and learn Vue from Sarah Drasner. I think that's the best way to do that.

You'll instantly see places where, like, "Oh, yeah, jQuery was actually kind of weird." If you've ever had to inject HTML with jQuery, it feels clumsy and it always breaks.

Chris: There you go.

Dave: You never do it….

Chris: It's gotten a little easier with template literals, but then whatever. You know it's still not great.

Dave: Yeah, you never do it smart, right? It doesn't feel smart. It feels like I'm hacking this to bits. Vue is like, "Oh, you like to inject HTML with jQuery? Well, this is Vue's bread and butter, so Vue would be a great place to step in."

Chris: Yeah. We have a great article. Sarah Drasner also has one, a jQuery to Vue one, and there is a new one coming out on CSS-Tricks that makes this point really nicely, I think. You'd be surprised. I was surprised at how so much translates between the two because I feel like, at a surface level, they feel really different.

You can go back and listen to the Evan You episode of this show that talks about this. It was designed in that way to be able to be sprinkled in to existing websites nicely. Vue does that. It's probably the best at that to get the modern stuff, but also have it be sprinkle-able a little easier.

Anyway, we should move on. Do lots of questions, right?

Dave: Oh, yeah. Here we go.

Chris: Speaking of JavaScript stuff, Shane O'Sullivan writes in. There's been some kind of Webpack versus Parcel drama. I'm not even privy to that drama, but they're both bundlers.

We all know what Webpack is, right? What's Parcel?

Dave: Parcel is a packer. But what's different about it is you point it to your index.html. You say, "Hey, go to localhost3000/index.html, and then just crawl my sight and make bundles. It's like, okay, cool. I'll just go through. Okay, this page has these five JavaScript files. Great. I'll put these guys into one big bundle.

Okay. Let me go to the About page. Oh, that has this seven JavaScript files, but okay.

It does what Webpack does, but it kind of crawls through your site to kind of build it or you can point it to a JavaScript file and it'll just read the imports and build a bundle based on the imports itself.

Chris: Yeah. It's like it's happy to take on anything as an entry point. Then it just starts crawling from there and making your bundle. When it says zero config, there literally may not even be a config file at all.

Dave: Yeah. With Webpack, you have to set an entry and a destination. Kind of like Grunt; you kind of build out these in points and out points. Then you have to add what transforms you're going to run it through and all these steps. You inject that stuff, Babble, everything.

Parcel is like, "Yeah, we have all that prebuilt. We'll detect what you're doing and spit it out."

Chris: We'll see if it actually becomes a true-- I feel like if you're doing any kind of fancy built process stuff, Webpack is way more mature and probably way more powerful and capable than Parcel. It's probably not a world in which you're just looking at swapping out your Webpack for Parcel. You're probably not going to do that.

Certainly, for simple sites, new sites, and stuff like that, Parcel does really look compelling to me for that reason where you're just kind of like, just set it loose. I don't know. Do smart stuff. Make a nice bundle for me, and it just kind of does. It feels like an evolution, like Gulp felt like kind of an evolution from Grunt kind of thing.

Dave: Yeah. I feel like this is me. I'm realizing I don't like the configuration stuff. I would much rather hit a button or type one command and it just runs.

Chris: See. Remember there was evolutions from Gulp, though. There were some of them that were like, okay, we can look at Gulp users. They're all using it to process their SaaS. They're all using it to inject partials. They're all using it to minimize their assets. Let's make a Gulp competitor that does all those things automatically.

I feel like those didn't catch on, though. That's why, when I look at this, I wonder if this "making choices for you" thing will catch on or is worrisome in that way that it does too much without config that people prefer the config. You're straight up saying you don't like the config.

Dave: Yeah, I don't like configs. I don't know. I think it's too much mental overhead for anyone just hopping into a project to be like, "Okay, what the hell happened here?"

[Laughter]

Dave: But the problem is, everything already is built with Webpack: Create React App, Vue, Angular, ng serve or whatever. It runs it through Webpack.

Chris: Yeah, everything is Webpack.

Dave: That's cool and it works, but am I switching my Vue projects over to Parcel? No, because I don't even know how to set it up quite yet.

Chris: Well, apparently, the docs aren't quite there for Parcel yet, too. You might get to a page or the page might even just say, "Docs coming soon, maybe."

Dave: Yeah. For JavaScript I write, I think it works out great. It's like, "Go audit these three files and build some bundles," or whatever. I think that's great.

Chris: It's kind of like your HTML is your documentation, in a way.

Dave: Yeah.

Chris: By virtue of linking up a script, you're saying, "Please make this script into a bundle for me, please."

Dave: Yeah. I like it. The experiments I've done with just hand-coded stuff, but getting into frameworks, they already have Webpack, but like to be using Parcel. I definitely would.

Chris: There is some buy-in. Let's say you really want to use CoffeeScript; plenty of users of CoffeeScript, still. Then in your index.html, you write scriptsource=index.coffee right in the HTML, which feels weird to me because that's Parcel buy-in then. That's not valid code anywhere. That'll never work, ever.

But you've written configuration then. You're saying, "Please process the CoffeeScript first and then process both this HTML and the CoffeeScript and give me some kind of final output that does it, in a way." You know what I mean?

Dave: Mm-hmm. Yeah, but would it be better if you could just be like, go this index.html, find all the CoffeeScript files, autocomplete? I don't know how far Parcel takes it, but that would be cool. Anyway -- hey!

Chris: It's like that with STSS too. Link rel, style sheets, style.scss, and it's like, "Oh, I know what you mean. You want me to process this first, before."

Dave: Yeah.

Chris: Anyway, we can move on.

Dave: We were talking about the CSS and PHP thing in the last episode. What if Parcel could do this for you? What if it's like, "Oh, you have these? I see these five link tags because they're in these five components. I'll just build these link tags for you," or, "I'll just build a bundle for you based on these link tags and then edit your HTML."

It's a little different because this is for JavaScript templates, not the output from Parcel as it compiles something. It builds a build folder or dist folder. Anyway, yeah, I don't know. I'm reading a Vue Parcel JS thing and it looks pretty simple, but you still have other….

Chris: …I hope they have a guiding vision, which I'm sure they do, and that they really stick with it. If they goal here is zero config forever, I wonder how long you can hold onto that.

Dave: Yeah. Yeah, I wonder. Yeah, does it just run? I don't know how it all works, so anyway.

[Banjo music]

Chris Enns: We've talked a lot about Netlify Build before, the Gits workflow for Web development where you can build, deploy, and manage modern Web projects super easily with Netlify. They just launched something new they're calling Netlify Dev where you can run their entire platform right on your laptop, or your desktop I suppose, too. You can preview it all: site generation, functions, and edge logic. Imagine the productivity boost of being able to locally test your site generator, API integrations, serverless functions, and edge rules all in a single development server. That's Netlify Dev, a powerful way to build and test modern Web apps on your local machine.

With one simple command, you can install Netlify Dev to use on any project. That's spawn a fully local environment of Netlify Dev that automatically detects and runs your site generator, makes environment variables available, performs edge logic and routing rules, and compiles and runs cloud functions. The extra bonus is that you can even stream that live, so Netlify Dev takes hot reloading to a whole new level, allowing to actually stream your dev server to a live URL, which is great for collaborative development.

You can now share your work as you work and get instant feedback. I could be working on my site. I could have it open in a browser, open on my phone, see the changes live as they're happening, but you could also have it, wherever you are in the world, open on your browser or on your phone. Whenever I update something, the site will update and you'd be able to see it.

Netlify Dev automatically detects common tools like Gatsby, Hugo, Jekyll, React Static, 11ty, and more, providing a zero config setup for your local dev server. Netlify has faithfully replicated their powerful edge logic engine in WebAssembly so you can locally test all the same rules before deploying them to their global infrastructure.

You can write cloud functions in modern JavaScript, adding needed dependencies. Netlify will compile your functions as AWS Lambdas and deploy them as full API endpoints.

Local testing works too. It all comes with Netlify Live, a hosted service that continually runs your dev command, just like you do locally, watching for changes. The result is an instant preview you can share with your entire team with live updates as code and content changes.

Like I said at the beginning, Netlify Dev installs with a Netlify CLI. Create new sites, setup continuous deployment, and push new deploys right from the command line. Netlify Dev is just the beginning. Take your local development to Netlify Build, power collaboration through Netlify's Git-based workflow with deploy previews, branch testing, and more.

Check out Netlify Dev at Nelify.com. Our thanks to Netlify for sponsoring this episode of the ShopTalk Show.

[Banjo music]

Chris: Hey, Dave. George Foster wrote in. He's kind of been on a Windows machine forever, has a Windows machine now, and he's just getting more into the Web dev stuff, and I think feels some kind of pressure or maybe it would be a smart move to get a MacBook. What do you think? Should George just hang it out on Windows? Why do you think he's feeling that pressure? How's it still going for you?

Dave: Windows is fine. Done. Next.

Chris: Next.

[Laughter]

Chris: Don't switch, George. Forget everybody. It'd be interesting to get a little more information from you about why you feel, if you feel pressure, why or whatever. These days--

Dave: Windows 10 is good.

Chris: --just look at Dave.

Dave: I use it all the time. I think, every month or so, more people kind of switch over. Windows, I think we all know, has its quirks. There are also quirks in Mac-land. If you like a working keyboard, I really recommend Windows products. [Laughter] So, hey -- next, Chris.

Chris: Yeah. Don McKinnon here; he's looking to build out some projects with server side rendering, like we used to do.

Dave: Oh, back in the old days. I remember.

Chris: But he's doing it in React with Next.js. Next.js is kind of a React framework I'm familiar with that now, all of a sudden, we just had Guillermo on the show.

Dave: Guillermo.

Chris: That was helpful. With our little community JavaScript meetup, we've decided to build a website, too, and we're building it in Next.js. I've had a little bit of hands-on experience with it. It's pretty neat. It has a nice little dev server and stuff for working on it. Then you can run Next build, Next export, and it'll make a straight up static conversion just like you would get with whatever, like Hugo or 11ty or something, like a static build of your site that doesn't need JavaScript to run, which is neat.

Anyway, he's building in Next.js. In the past, he's written CSS with SaaS and SaaS partials and stuff. Precompiled the thing. Made a big, old, giant style.css file, threw down a CDN, minified it, cached it with HTTP headers. Just kind of classic best practices for CSS. Then built the site with that.

Just because you're using React and Next and fairly new things doesn't mean you can't just write CSS the good old-fashioned way. In fact, that's what Don is doing here. Then he's saying he's learning about styled-components, basically, and how popular that is in the React world.

Don says, "Given how I'm already caching the CSS and all that, let's say I switch to styled-components. What do I get out of that? Is it going to be faster still or not faster or slower?" What's the performance story there? I don't know.

Dave: I think the important distinction is, caching is second load only, right? If you wanted to even be super-fast, you could write a service worker and fetch, intercept the request for a CSS file and run it back before even the fetch thing is like, "Oh, I already actually have that file." You could be fast with a service worker. Apparently, it's already processed in byte code and stuff when it's cached. Anyway, that's a cool thing I learned recently.

Where stylized components comes in and why it kind of says, "Oh, it's fast." Your CSS is bundled to the component, the component only ever serves the CSS it needs. You never have more. You never have less.

Chris: There is no link style sheet on your page anymore at all.

Dave: Yeah.

Chris: You're going to gain some speed immediately for that. There is no render blocking style sheet.

Dave: No blocking stylesheets.

Chris: Not one at all, assuming you go all in on the thing. There's that. Then where do you pay for that? Well, you pay for it in your bundle size. There's more JavaScript to be parsed then.

I don't know if there's a great apples-to-apples comparison to this. I built the site two ways and, "Which one is faster?" kind of thing. It'd be interesting to see.

Dave: The high road or the low road? Yeah, or left one or right one? I think there are tradeoffs. You are putting more strings into the JavaScript. We do know JavaScript size and execution on limited CPU devices is more intensive, so you're causing more work for the little crappy smartphone.

Chris: Right.

Dave: I guess I shouldn't say crappy because if that's what people can buy, that's what people can buy. The $200 smart phone….

Chris: Isn't the story, though, it's usually not -- I'm glad we're talking about performance now but, usually, people don't make this choice because of the perf choice. They pick styled-components or whatever because they like writing their styles in JavaScript because they're just more comfortable there anyway, or they like the hot modular reloading they get from it. It's just a little easier to implement. Or they do it because it scopes the styles to the component so perfectly such that if you don't use that component, the styles aren't loaded. There are all these other reasons that are usually quoted more so than the perf story.

Dave: Yeah. Yeah, yeah, and I think it's one of those -- I think it's a feature. If you worked really hard, you could leverage it to be very fast, especially if you server-side rendered your Nuxt app or Next app or whatever.

Chris: I wonder if styled-components plays nicely with Next. It may not.

Dave: I would have to look at how, too. Do you have a bunch of micropauses? When the browser hits that style block, does it go, "Oh, crap! There's a style block. I have to now recalculate and do a recall ping, re-render"? Rather than one calculate, you've now introduced 20 calculate steps, and that's expensive for a browser, right? That's why I like animations without the calculate property, or are faster, right?

I do -- I wouldn't -- I don't -- I'm going to put on my skeptic hat. I think there are going to be micro penalties that may add up to a significant kind of penalty on the client. That said, it's not the end of the world to me if it spits out a style tag.

Chris: JavaScript is making that style tag. What's kind of neat is when these apps -- I've been kind of a proponent of CSS Modules lately, which is old. I was looking at the repo just today. I'm like, "Has there been no commits to this in two years? Is that the case? That's crazy."

I think I'm wrong. I'm looking at the wrong repo or something. This is not new, this CSS Modules stuff, but what's kind of nice about it is that you work in just regular CSS files and the output is just CSS files also. So, you're not increasingly your bundle size. It has nothing to do with your bundle size. It may a little because of class names and whatnot. That's kind of neat if you're getting what you like out of CSS and JS, all the scoping and the hot modular reloading or whatever it is that you're really looking for, and you're paying no bundle size penalty for it because it's just a link rel style sheet like it would be if you're working in SaaS or whatever else.

If you really like SaaS, CSS Modules supports SaaS too, so you're happy there. I just feel like you get a lot of the benefit without having to talk about this bundle size problem. It's just kind of a cool middle ground.

Dave: I would like to see the minimum viable CSS Module's tutorial.

Chris: The problem with that is, when you look at that, it's like, okay, it generates this object of class names from the style sheet. If you wrote -- Dave, if you wrote, "My .post class," it'll read your style sheet and I'll turn .post into .post gibberish stuff. Then it' expects you to just use that object key where you want the styles to be injected into your template.

There's no real good helper for that. If you're writing a standard Web component template or something, you've got to string concatenate the class today, and it doesn't look that nice. When you look at it in a React dev, it looks really nice. Class name just becomes a thing that's just like--I don't know--put the class name here: styles.post.

Dave: Yeah, styles.post. Yeah.

Chris: It looks cleaner. It looks nice in React, I hate to admit. I'm sure there is a Vue story, but maybe there isn't because Vue has already got a nice styling story.

Dave: Mm-hmm.

[Laughter]

Dave: [Star Wars voice] Yes. Come over to the Vue side, Chris. Waving hands; waving hands.

Chris: Yeah, I wish I had a Vue project. I've never done a Vue project. It makes me sad a little bit.

Dave: Oh, man. All right, ShopTalk Show V5 or whatever, we'll call in on Vue.

Chris: Maybe we should. That would be kind of rad. Wow!

Dave: Yeah.

Chris: Like a Nuxt Vue. Well, I'm not opposed to that.

Dave: Hmm. Hmm. All right, Zamina Villa (phonetic) writes in, "We work a lot with WordPress, but we either buy themes or create custom themes then modify them. When it gets to finishing a site as it was designed, there's a lot of additional CSS added. I'm no expert in this, but it seems messy to me. There are always specificity issues and I hate having to use important too many times. Do you have any tips on how to work with WordPress in modifying themes without committing so many CSS crimes?" [Laughter] Oh, man. I love CSS crimes, and that should be a TV show.

Dave: [Laughter] Doing CSS crimes. Yeah, you buy a theme off Theme Forest or whatever, and you slap it up because it's close enough for a client, but you've got to change some colors and some images or whatever.

Dave: Oh, I need my borders to be rounded three pixels.

Chris: Yeah, but I kind of get it. It's easier to just pop into the bottom of their style sheet and do a couple of overrides, regardless of it, than it is to rearchitect all their CSS to be how you would do it. I feel like maybe a couple of CSS crimes is the lowest technical overhead you can do.

Dave: Yeah. Do you want to write all the CSS yourself? You're choosing a shortcut, kind of, but the unfortunate output is, you have the CSS crimes file at the bottom, so what do you do?

Chris: CSScrimes.css is awesome.

Dave: Yeah, crimes.css.

[Laughter]

Dave: The spinoff podcast material here.

This was something that came up recently, pondering a switch. A client was pondering a switch to Bootstrap. I think the idea is, "Oh, we get all these components for free." That's true. But from a style perspective or even a JavaScript perspective, if you need more functionality, you now have to hack core of you have to add import. You have to kind of override the principle style sheet or the principle bootstrap.

I think it's the same situation described here. People can have varying degrees of success here. I'm not poo-pooing any work here, but I think Robin Rendle has a good story of trying to dig out from a Bootstrap app. He was saying that he has Bootstrap, and then the have the Bootstrap modifications kind of sandwiched in there.

Now, when he wants to move something or update something, he now has two systems competing, kind of stapled together. It was enough to where he was like, "Well, I just have to patiently dig ourselves out of this situation." He's doing that and I think it's going well for him, just what he's shared on his blog.

Yeah, you kind of have these -- you end up with two systems: the prefab solution and then all your modifications. I'm not sure there's a good way to clean this up other than maybe injecting some custom classes in the HTML or something.

Chris: Well, yeah, maybe.

Dave: Yeah, or maybe you have to -- if it's a gnarly component and you're like, "I could do this in ten lines," maybe your crime CSS is actually, "I'm fixing. I'm going to remove this one from their thing and add our own." You have a little bit of CSS bloat, or whatever.

I'm thinking the footer on the theme is just weird or not correct. You just copy their styles and put them in your crime CSS. Then you call it footer-v2 or something. Then you opt out of their styles. Then you start using your styles. Maybe that works. I don't know.

Chris: Yeah, maybe.

Dave: That would be my only advice.

Chris: There's a heck of a lot of "it depends" in here. I think the moment where the client is a high paying client and they're saying, "We want you to be our go-to developers on this project, on call. It's going to go through lots of changes over the course of three years." Well, then it's time to get your system in place to help yourself on this thing.

If you're the type of shop that needs to put these changes in place quick, you ship to client, you bill them, you'll never see them again, who cares how you do it. Not to make it somebody else's problem, but the reality is you can't rearchitect an entire site at a certain price point, you know.

Dave: Yeah. Yeah, well, and the tradeoff here is like, we're going to do the shortcut by buying a theme.

Chris: Yeah, the price point is already low. We already know that because you're already just buying a theme and slapping it up.

Dave: Yeah, so then now it's like, okay, if you're just doing that then, yeah, my care level would be kind of low.

Chris: Yeah.

Dave: I think, at some point, it sounds like you want to graduate onto something kind of more bespoke system-y, so you should look for opportunities to do that.

[Banjo music]

Chris Enns: This episode was sponsored by Jetpack from Automattic, the folks behind WordPress. Jetpack is the ultimate toolkit for WordPress. It gives you everything you need to design, secure, and grow your site in one bundle. With Jetpack, you can fully customize your site with free themes, image tools, and rich content; increase your traffic through automatic social sharing, related content, and faster load times; and get a safer, stronger site through secure logins and protection from bruit force attacks.

Recently, Jetpack has been adding blocks for the new WordPress editor, so you can easily add cool things to your websites like a repeat visitor block--Automattic uses this on the job posting page where, after a certain number of repeat visits by the same IP address, they put a notice up encouraging people to apply--an ad block that allows you to insert ads from Jetpack's word ads program in your posts and pages; a business hours block that easily shows your business opening and closing times, a contact info block that not only makes it easy for visitors to know how to get in touch with you, it's also set up so search engines pick up the data as well; and a whole lot more like blocks for MailChimp, slideshows, videos, and more.

If you're like me and just dipping your toes into the new WordPress editor, be sure to check out Jetpack at Jetpack.com and try out the new content blocks they've added on your business or personal site. Our thanks to Jetpack for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: Sure. Diego Hernandez writes in saying, "I'm kind of clashing with some other team members on our coding standards.

Dave: It never happens. Sorry, Diego.

Chris: [Laughter] I know. You're the only one, bud.

He says he likes using BEM in CSS, and he's usually the person kind of calling out inconsistencies and requesting that other team members make changes to their code, "So it sticks to what I perceive to be our standards. I don't like doing this because I come across as nitpicky and difficult to work with. It feels like kind of a waste of time because if no one else is calling these things out then no one seems to understand the benefit of the standards."

I totally get you there. I think there are some red flags, though, wouldn't you say Diego? Dave? Daviego?

Dave: Yeah, Daviego. No, Diego, two things: you probably would not like working with me because I'm terrible. [Laughter] I do faux BEM and it's just the worst. Second, I would actually love to work with somebody like you who cares about it and is just like, "This is what we're doing," because I can fall in line and just be like, "Yeah, okay. If that's what we're doing," because I don't care what it's named, actually. I mostly care how it works and what the user interacts with.

I think that's good, but I also know it's never fun to be the curmudgeon in the office, the nitpicker. I think it's about learning how to pick your battles or maybe you go through a process and formalize how you name stuff.

I don't know if you've seen Brad Frost. I'm sure we talked about it, but Brad Frost has this front-end Web developer guidelines repo. It's basically a questionnaire, a 25-question questionnaire, and it's just how do we write CSS, basically, or JavaScript, or what's our process? How do we do all these things? You just document it.

If somebody commits something that's wrong, you just paste a link to the document you guys created together. You could be like, "Hey, let's try to abide by these coding standards we already decided on. Here's a link." It's a little passive aggressive, a little dicky, but you just kind of….

Chris: Well, if there are no -- that's what it seems like. You perceive them to be standards, but nobody has agreed to them. There are no standards if there are no standards. You don't just get to decide there are standards. Then they're your standards. You know?

Dave: Yeah.

Chris: Standards are standards. Then if there aren't any, then you need to back up and be like, "Hey, can we implement some standards?" It sounds like that maybe won't go well because it sounds like nobody really cares, so you have to put the pitch together like, if we had standards, then X, Y, and Z would be better somehow.

Usually, what's better is less bugs. Is your team inundated by bugs? Maybe then your presentation is, "Hey, remember this bug when this happened? That could have been avoided through a better naming situation. Remember this bug? That could have been avoided through this. I just think it will be better. Developers leave and come in, and now we have this set of standards. Things will just be better for us."

If you can make that pitch, that'd be great. If you can't make that pitch, like you're unable to do it because you don't have things to point to that are a problem, maybe there isn't a problem then. That's tricky too. It's weird to say, "Hey, there shouldn't be standards," but whatever. The Web is a big place.

If you're just this picky guy who is picking on people's commits even though they're not really a problem, that's not good either. The fact that you're a ShopTalk Slow listener and writing in, I'm on your side here, man, but we've got to consider all the possibilities here.

It's also a problem. The person on the team who just does nitpicky commits for no reason is also a problem.

Dave: Yeah. Yeah, I mean -- yeah, there's a management kind of thing or even, is this your responsibility to judge code? Were you given that authority to enforce the style guide or the linter? I think that's kind of a big question. Maybe you're out of your lane and the reason people are not hopping onboard is because you don't have the organizational authority to do that, if that makes sense. That's something to consider. I hate to say that but, yeah, it's something to consider, like, "Who is this clown?"

Chris: Yeah.

Dave: "I'm not going to do what he -- BEM is stupid. I'm not doing this. I've made websites for 12 years."

Chris: Well, BEM is definitely going to fail unless it's strictly adhered to, in my experience. What's the point of BEM if it's not sticky? Whatever. Anyway.

Dave: Yeah. Well, that's probably why I've never used it because it's never strict or it's strict and I don't really abide by that. Anyway.

Chris: We've got time for another couple here, probably.

Dave: Yeah. Let's go. Mike Mills writes in, "Recently, I had a couple of high school students approach me about how to learn Web development. I want to help them and mentor them in the field, but I also don't want to reinvent the wheel and create a Web dev curriculum when there are so many good options out there. I would like to point them towards a code camp or academy where they can work through some basics and I can help them on the curriculum when needed."

Chris: That sounds fair because you don't have a lot of time, right?

Dave: Yeah.

Chris: Why reinvent the wheel if you don't have to for time reasons? I feel like sometimes curriculum is reinvented not because "it's not invented here" syndrome or something, but more like, "I can't just pull curriculum off the shelf and teach it," because you're not familiar with it.

Part of inventing curriculum is inventing something that you're familiar with. I don't think it's problematic, necessarily, to put a little mini curriculum together yourself because then it matches your mental model. You're the teacher here, so you need to know what's going on. Throwing together a little mini curriculum for yourself might not be the worst idea, unless you just don't have the time or wherewithal to do that. Then certainly reach for something.

There's stuff out there. We've had sponsors like Treehouse. We've had sponsors like OneMonth.

Dave: Mm-hmm.

Chris: Of course, there's Khan Academy here, Wes Bos's course, whatever else.

Dave: Yeah. I would say I think the big thing is accountability. Maybe just pick something.

I just found this Khan Academy, HTML, CSS, or whatever. You just say, "Hey, we're using CodePen, so get a CodePen account. Talk to your parents but get a CodePen account. Then get a Khan Academy account. Go through chapter one, HTML." You'll have to do a little bit of research but offload all this curriculum to somebody else or Code Academy, and be like, "Hey, we're going through this."

I feel like it was a Rebecca Murphy thing, JQ Fundamentals. Yes! This is old. This may be outdated because it's all jQuery but find something and go through it with them. Then ask them questions about what they learned in that section. Make them recall the information they went through.

With high schoolers, don't cut them slack. Make them do it. They're smart. They're adults, or mostly adults - young adults, we'd say. Make sure they are applying themselves. I think that's all you need to be is, like, "Hey, open up your computer and learn this. Read this, go through this, and then I'm going to ask you questions about it." I think that's about all the prodding you need to do, in my opinion. I don't think you need to sit with them and correct every single thing.

Chris: I always like to give the table stakes as my favorite talking point. Maybe walk them through the process of buying their own name or their own domain name. You could probably get one for $0.99 these days.

Dave: Mm-hmm.

Chris: Sometimes you've got to invest in somebody else's life. Then hook them up with that so you're not like, "Well, you better do a good job because this is going up on your personal website." [Laughter]

Dave: Yeah. Yeah. Yeah. Work with them. Teach them some fundamentals, but then kind of be like, "Hey, here's the end of your project," or, "Here's the big project. We're going to do whatever learning for three months and then we're going to do an end of the year project. You can make a portfolio or," I don't know, "your band's website," or whatever.

Chris: Yeah. That's the thing. We all work on websites. Work on things that are on the Web. I don't know. I feel like that's always so crucially important.

Dave: Yeah.

Chris: Get familiar with that idea that you have a URL and the things go to there.

Dave: That's a good point. Share it.

Chris: Let's end with this little one. It's about websites, this question here.

Dave: Okay, very good.

Chris: [Laughter] Andy Harrison writes in. It's kind of like trying to pick a CMS, which is the biggest topic in the world. We could have a whole podcast on it, practically. I love thinking about CMS and stuff because it's just a fascinating world to me.

Andrew feels like he's in this position. He feels like WordPress is too much for what he needs. That's not what he wants to do. He wants to do something -- I'm not sure what it is, but it's for a franchise company. Imagine it's--I don't know--a burger company with 15 locations or something, so there'll be home page, surely. Then each location has a custom landing page.

It's like -- I don't know. That's what he's in for. Static-ish, it sounds like, but extensible. It sounds like something that should have a CMS of some kind.

Maybe a headless thing would be cool, but he's finding headless and build my own front-end however I want to isn't a user friendly enough situation to deliver to the client, maybe. That's how he's feeling about that.

But he's like, "Well, I'll just use Wix, Weebly, Squarespace, or whatever the heck, then why would I tell them to do that? They've come to me to build the website. I'd rather take their money than point them at some build-your-own website scenario." He wants a CMS that feels like it fits that vibe.

Dave: Yeah. I have a little experience here. I've built a friend's -- he has a trailer park called Thicket here in Austin. You could probably find the URL there just by those keywords. I built my friend a Squarespace site. I basically found some theme, modded a theme, and build the Squarespace for free just because I like the guy or traded yardwork because he's a landscaper as well.

Chris: It's kind of nice. Then you can hand it off to him and be like, "You need to change that copy down there in the footer. It's all you. You really can do this."

Dave: It's all you, man. Don't call me. I'm too busy for that, so it actually works out. It's working.

That said, this isn't a slight, but the modifications he's made on his own have not ended up so well, so I end up having to come in. It's like, "Oh, hey. Look, Squarespace has a gallery feature. I can just put all his trailers," which is his inventory, like franchise locations, "his trailers in a gallery and just spit out logos and pictures of trailers.

Then I gave him a photo gallery. You could see he was just like, "Oh, I didn't know I could do a photo gallery," and so now he has a photo gallery of photos and that's more engaging. All of his customers are like, "Oh, I saw all the photos. That made me come by," so there you go.

Don't underestimate your skills there for these boxed websites, big box website things. I wouldn't underestimate your skillset there. I think you still offer value but give them an ability to update. Then just say, "Hey, let's do a checkup. In six months, let's do this."

If WordPress is overkill, I've got one more for you, Chris. Are you ready?

Chris: Yeah, what's that? I'll take it.

Dave: Have you heard of Vapid CMS?

Chris: Never heard of it.

Dave: Check it out. It's a weight shift design agency joint. Scott Robbin and Naz Hamid created Vapid. It's pretty sweet. I'll write a tutorial for CSS-Tricks for you. How does that sound?

Chris: Oh, my God.

Dave: Have a marketing website in five minutes. You ready? Are you ready for that?

Chris: Wow! Yeah, I'm excited about that.

Dave: It's a Node-based thing. It's pretty hot.

Chris: TypeScript.

Dave: You write templates and it generates the CMS based on your templates.

Chris: Oh, like Perch! Perch did that.

Dave: Yeah.

Chris: Yeah, I was thinking, oh, there'd be kind of a fun little excuse to use Contentful, maybe, and then just get all these pages as JSON and then just build on the front-end however you want. Then you can invite your client into the Contentful thing and they still have a nice editing environment to change pages, make new pages, and stuff. That's what I'm focused on here is this idea of, you don't want to be called when all they want to do is, they're opening a new location in Dayton, Ohio. They should just be able to do that.

Another one I would think is, build the site with 11ty or something. Build it. Use a static site generator thing where you can just build the homepage however you want to and then have a locations folder, but the locations are dynamic, in a way, that they just require a new Markdown file to exist, like daytonohio.md. With any kind of static site generator, that plus Netlify CMS or Forestry is pretty sweet because it's like a CMS on top of your static files.

You don't have to teach a client, "Hey, go into the GitHub repo. Make a new file in this directory. Call it this name. Then save. Do a pull request to the repository." It let's you work in a static site generator situation, but there's a CMS layer on top of it, which has all the nice UI that has drop-down menus and header fields, so they can still create the content. But when they hit save, what happens behind the scenes is a Markdown file gets created. It gets pushed to the repo. The Netlify build gets built, et cetera, which is pretty rad.

Dave: No, Netlify CMS is kind of on my "stuff to checkout" list just because, yeah, you want a static site, but then you want just a little bit of, "Hey, you edited it." That's what you want.

Chris: Yeah. I use it on my CSS-Tricks conference's site because if there's a new conference -- if somebody emails me and is like -- because I'll accept PRs for new conferences, no problem, a little 11ty site. But some people are like, "I don't want to do a PR. I don't know how. I just run this conference. Can you just put it on here for me?"

Sometimes, I don't really feel like pulling my repo and adding the file. I'm perfectly capable of doing that. It's how I built the site, but sometimes it's nice to open a new browser tab, fill out some form fields, hit save, and have it be live on the site. That's what CMS is. I like CMS. [Laughter]

That's what Netlify CSS is for. It's one file you put on your site, Dave. It's incredible. It's the CMS that's all file. It's two files because it's an index and there's a CSS file that goes with it.

Maybe there even isn't. No, there's not because it pulls it off of CDN because who cares, you know? The file is a config file that tells the CMS how to behave. This is what my content looks like. Otherwise, it's a little SPA. It's one file, and you teach it. Yeah, it's incredible.

You teach it, authorize through Netlify autho or whatever. That's a one-off thing too. There are auth. You click and you log in. It gives you this nice, little UI based on your config of how you've described your content to work. I think it's frickin incredible. Anyway--

I could invite a client into that easily. You just say, "Oh, this client has access too." What it doesn't do, which is coming, I think, really soon is that anybody could log in and do it. But then it becomes the PR that you then have to approve. I think that would be nice to totally open it to the community. Do you want to add a new piece of content to the site? Sure. Just authorize here, fill it out, click the save button. Great, now your thing is a draft and I can, as an admin, then approve it. I think that's coming.

Dave: No, that would be cool. That's cool.

Chris: Ooh, that was a lot of words. We should probably wrap up.

Dave: Yeah, let's wrap it up. Thank you, dear listener, for sending in your questions. Oh, we want more questions. Thank you. We really appreciate it.

Thank you 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.

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

Chris: [Purr] ShopTalkShow.com.