Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. [Using a British accent] You're listening to another episode of the ShopTalk Show. Pippip, cheerio. I'm Dave Rupert. With me is Chris O' Stars & Stripes Coyier.

Chris Coyier: [Coughs]

Dave: Did it. Hey, Chris. What's up?

[Laughter]

Dave: Accents always make a good podcast. What's going on?

Chris: I'm always so ready to do it and then you surprise me of where you're going to go and I can't. I can't. I can't hang. But, yeah, we were just talking that I haven't left yet. By the time this airs, I'll probably be back. Who knows how time works in the world of recording things ahead of time, but I'm headed to London for JAMstack Conf, which should be pretty cool. They're not sponsoring this episode or anything, but Netlify runs the conference. This particular one, they're running in concert with Smashing Mag. Smashing Mag, they have their own conferences; has a whole team for that. We're kind of running this one, but it's kind of brought to you by Netlify. Anyway, it should be pretty cool. I'm a big fan of the JAMstack thing.

Dave: JAMstack is exploding. It seems like people are picking up on it. What does JAMstack mean in your life? Has it impacted it greatly?

Chris: Yeah, I mean kind of. I'm just like a big fan of the approach because I think I've called it "healthy" in the past, which is cool. Of all the things and trends that happen on the Web, a lot of the trends, anyway, push the Web heavier and there are easily identifiable problems with them, not that every Web trend is black and white, good or bad. But sometimes you'll look at things that happened to the Web and be like, "I could see that going wrong."

I don't think JAMstack is absolved of that. In fact, I've heard some pretty fair pushback on it sometimes but, for the most part, I think it's good. I know we haven't sat here and defined it, so we could probably do that really quick. It's one of the acronym things where the acronym is not super great, if you ask me, but it does the job. The momentum and weight behind the movement is already happening.

The same thing with Serverless. The word is stupid. You can be as mad as you want about Serverless as the word, but it's too late. It already has momentum and it's already meaningful. I'm just over caring about it.

JAMstack, the acronym is JavaScript APIs and Markup. The first two are like, well, you use APIs with JavaScript, so it's like, meh. Then the Markup one, it's not prescribed that every single page on your site is prebuilt Markup, but that's what it kind of spiritually suggests, in a way.

What gets associated, I think, with JAMstack is static site generators like Jekyll or 11ty; we talk about on the show because it's Zach Leatherman and he does a good job with it and it's really nice. That's there, but 11ty is as small player in a big pond of static site generator products.

Dave: Mm-hmm.

Chris: That world is blown up. If you just used a static site generator and made a site and hosted it on static hosting, that's very much a JAMstack site. Then people are like, "Well, some sites work for that; some sites don't." DaveRupert.com does that, right? Are you still on Jekyll or did you move it?

Dave: I am on Jekyll, and I love Jekyll, but all my other Jekyll projects are creeping over to 11ty. Speed is a big one, you know.

Chris: You've probably written hundreds of blog posts.

Dave: Yeah.

Chris: There are maybe a thousand pages--who knows--on DaveRupert.com. When that runs, it literally makes hundreds of a thousand of .html files and then it distributes them. Those are shipped, so there is no PHP server that finds the right one. There's no database request that happens to go get it out of a database and then build the Markup and plop it on the page. It's just ready to go. It's done. It's absolutely static files. I think that's the clutch part of JAMstack. That's what really matters. That's a big deal. Static hosting is almost always a part of JAMstack, which is why I made that -- you know, the title was just stupid clickbait, but more like SHAMstack where I'm like static hosting, S.H., APIs, and Markup feels more right to me because it calls out the static hosting thing, which is, I think, kind of a big deal behind it.

Then there are people that, let's say you were to push it to the other extreme, like as far away from the spirit of JAMstack but still have it be JAMstack. Well, you could have one index.html file; it's just index.html. There could be one div in it with an ID of root. You can load up your bundle.

Dave: Your single page app.

Chris: Yeah, you could and that single page app then makes database requests or API calls elsewhere to get all its state, data, and such. Then blasts itself onto the page. Is that still JAMstack? Yeah, I think it is, actually. It's static hosting, and it's hitting APIs for data - rock and roll. That feels very different than a Jekyll site but are connected in that same way in that they're still statically hosted and you've kind of separated the concerns of getting more data and stuff.

Dave: I like that it sort of marries. I guess not marries but does not divide those two concepts exactly. You know?

Chris: Mm-hmm.

Dave: I do think there's a nice undercurrent of performance culture in the JAMstack universe to which I think you want to prerender and then hydrate any kind of single-page app. Although, I read on the Google developer blogs [laughter] that rehydration is a little expensive.

Chris: Hmm.

Dave: Just because it occupies the main thread or whatever, but I like that there's a performance culture and I do think prerender, whenever possible, is totally possible. Your app can't prerender anything. If it did, it would be way too much effort to prerender something versus, I'm going to prerender just an empty app shell. [Laughter] It's like, well, the user gets nothing; maybe some colors. Maybe I guess that is an advantage, but they don't get much. Anyway, I think it's like a cool bit of architecture.

Chris: Then I think what JAMstack is trying to say is that, "Okay, now you've got Dave Rupert, a Jekyll site, or you use one of these other dozens and dozens of great static site generators." Do I look at those as a developer and say, "Well, those are only for a certain class of site," like certain brochure sites and blogs or whatever?

JAMstack is trying to say, "No, you're not right. It's not like this architecture is perfect for every site in the universe, but it's much wider than you think it is." That's when the J and the A come in. You know they're like, "You can still use JavaScript here. You can still interact with the Web through APIs. Please don't feel limited by this stack."

Do you want to have a form on the site, which normally needs a backend language to process it and do something with it? You can, but just use this serverless function instead or have some other service that's built for that do that.

Do you want to have auth? You can have JSON Web token-based auth on your site.

Do you want to do e-commerce? Sure. Stripe has ways to take money in that type of situation. You'll probably need some cloud functions to do it.

It's kind of like you still have as much prerendered stuff as possible, but you can do e-commerce. You can do anything. What you can build on JAMstack is really wide and powerful. That's part of the message of JAMstack. It's like, don't feel limited by this. This is still a good thing. Like you said, there is this perf under-culture to it because, when you're shipping static files and static assets and it's already on a CDN and stuff, you're starting from this home base of like super speed.

Dave: Mm-hmm. Yeah.

Chris: Then why don't you keep it? You're kind of encouraged to hold onto that speed as you go, which is nice.

Dave: There are some technologies--I don't know--like Nuxt or Next that sort of want to have a node server underneath. I know Now and Next kind of split it out into a bunch of serverless functions, so it's a little bit different now. They kind of want a node server running to render the string or whatever.

Chris: Isn't that fascinating that you think that these products aren't necessarily in -- like Jekyll doesn't have any multiple modes to run in. It makes a static built site and that's it. But the ones that are JavaScript-powered, like Next and Nuxt, they have different ways you can run it in. You can run it like Jekyll and totally prebuilt everything.

You kind of said they like it. I think you're right. I think they prefer to have a server back behind it so that it's more like a PHP app. It's more like there is a server-side generating stuff or it's capable of doing that and then it spits it out kind of dynamically. It's still SSR, but it's not prebuilt.

Dave: Yeah, it's kind of scripted and stitched together, so anyway. All to say, it's a very cool frontier. Then you mix in GraphQL, which is a pretty cool technology, into all this.

Chris: You see there's a documentary out about it now?

Dave: Oh, really? [Laughter]

Chris: About the roots and early days of GraphQL and stuff.

Dave: Oh, boy. Okay. All right. I'll have to watch it. I love watching train wrecks.

Chris: It's only like 30 minutes long. [Laughter]

Dave: Okay.

Chris: It's like 30 minutes long and it's mostly Facebook people being really excited about what it was like. You know it's funny. The spec was published or something. The first-ever for real spec of it in 2015 or something. Here we sit in 2019 and it's mega hype machine. Loads and loads of huge sites running it in production. That's a pretty big success story really quickly.

Dave: Yeah. I think it's cool. I don't think it's panacea, but one of the reasons you're like, "Oh, I need WordPress," or whatever and WordPress is still good. That's not what I'm saying, but you're like, "Well, I'm going to have a million posts and a million posts on my JAMstack; it's going to take too long.

Chris: Yeah, right. That's why….

Dave: So, you're like, "Let me get a database going."

Chris: It's a great distinction to make there is that you can prebuild some shells if you want to, too.

Dave: Mm-hmm.

Chris: That shell can then hydrate itself. Maybe I'm misusing that word a little bit. You can go halves and halves with some of this stuff sometimes.

Dave: Right, and I think that's good. At some point, you do want a database. I don't know if you're storing lots of products or lots of things. Historically, then you want a language or a server. You want it very tied together or you build out a bunch of rest APIs or whatever. Then if you're like, "Oh, I need one more piece of data," you have to go to the backend team and get a thing. Kind of the promise here of Graph is like, "Oh, I just query. I just tell the database what I want and it gives it back to me."

Chris: Right. It doesn't absolve you of a good database structure, though, certainly.

Dave: Yeah. Yeah, I think one of the reasons you use WordPress is like, well, it's going to be thousands of products and thousands of posts. I just need to fetch that from the database and do all that. The reason for doing that, now, I feel like, is getting less and less because you could still have the content management in WordPress, but you don't template in WordPress. You template outside of that whole app, that whole content management.

Chris: Yeah, it's a huge discussion that you can build JAMstack and still leverage even something like WordPress. Although, there are plenty of people that push back on that and say, "Listen. If you're going to go down this road, why don't you go down a road that kind of treats headless usage as the first-class citizen, in a way?" There are options there, too, which is interesting.

I can see both ways. For legacy reasons, why not keep it there? For comfortability reasons, why not? I don't know. There are a million.

Dave: Well, no. I have a single-page app. It's not out yet but it hit some APIs, like WordPress APIs, and gets back some data. That's great, but I'm pretty divorced from that system, so I have to file a ticket to get something else back from it. That's a little bit of a deal but, yeah, I don't know that it's built for that.

WordPress's thing is caching. It doesn't ship with a caching strategy. That's an add-on, which probably saves them a lot of headaches. But, for an API, you need a caching strategy, pretty intensely, because if I can write a JavaScript -- [Laughter] I can write JavaScript that hammers an API.

Chris: Mm-hmm.

Dave: Really easily, so you need something that saves it from falling over because you are making PHP hit a database. That is expensive stuff, especially at scale.

Chris: If you were like, "If I don't want to even think about that, maybe I'll just use Contentful or something."

Dave: Right, because they probably have handled scale at some point. I wouldn't be surprised if it's just a big WordPress multiuser behind there.

Chris: No, it's not. [Laughter]

Dave: It's probably something extreme like Go or something like that is really high concurrency. Anyway, that would be one reason I'd maybe look that way, but these are all big decisions. "Okay. What kind of website am I building?" Okay.

Chris: Yeah.

Dave: I think there is still a lot of -- back to WordPress being 30% of the Internet or whatever right now because it works for 30% of at least every website.

Chris: I think the fact that I'm even having and participating in conversations like this. I guess my talk at this conference coming up is going to be, "Oops, I guess we're full-stack developers now," because I feel like that was kind of like, just arrived at my doorstep without me planning to do so necessarily, become full-stack, you know.

[Laughter]

Chris: It's like, hmm, I guess I am now. I don't know. One of the first websites I ever built was a WordPress site. I bought the domain, chucked up the hosting, played around with the CSS. Cool, I have a website. In a stack, that day, I was full stack, too, because I wasn't just limited to just changing some stuff in a CSS file and the HTML or whatever. I managed to do the backend too. There were database queries happening there and stuff. It's like I didn't bring my deep expertise to make it happen, but I made the website happen. That was cool.

I still am, to a degree. If I decide I'm going to use a static site generator, go to the JAMstack approach, maybe I'll put a CMS on it. Maybe the deployment is no problem because I'll put it on Netlify or GitHub Pages or something. I'm still that same person as I was back then. I'm making this website happen. I'm full stack, in a way. I've dealt with the data stuff. I've dealt with the hosting stuff. I've dealt with the pipeline workflow stuff. I'm the designer of the thing. I'm the content maker of the thing. I did all the front-end development, wrote all the JavaScript. Wow! You know?

Dave: You did full-stack.

Chris: I did it, you know. I didn't deal with some traditional back-end stuff like setting up a relational database and spinning up a MySQL server in the cloud somewhere or something. There are things that I didn't have to worry about that some back-end devs do. It doesn't mean that backend devs are not useful, replaced, or anything. In fact, they're probably just as useful or more than they ever were thanks to the growth of the Web. I, all of a sudden, feel very full stack-y, and I think lots of people do.

Dave: I guess you're kind of describing it, but your initial reaction to the term "full-stack developer," what was your initial reaction?

Chris: I don't know. I've never been accused of it. People didn't come up and be like, "Chris, you're a full stack developer." But I guess I wouldn't feel that way right away. I think the vibe for a long time has been, "Those people are unicorns. They're really rare." The people that call themselves that or think of themselves in that way or try to hire for that or something are kind of just fooling themselves in that maybe they kind of do it all, but probably not particularly well. They probably do one or the other better. The people that really kick butt at the whole spectrum of doing Web everything really are pretty rare.

Dave: Mm-hmm.

Chris: Now I guess I still kind of feel that way to some degree. What I think has happened is that some of the stuff just got so much easier that I can be great at hosting by just putting to Netlify. My hosting solution rules now. Thanks. I learned nothing, but I am benefitting from that.

[Laughter]

Dave: Or it's like I made a React app. I'm a front-end developer. I typed react.rendertostring, and now I'm a full-stack developer.

Chris: Yeah.

[Laughter]

Dave: You know? Is that the difference?

Chris: Just by virtue of using Next and using it in the prescribed way.

Dave: Yeah.

Chris: Or Gatsby or something. So much good stuff is happening for me behind the scenes. I didn't have to learn a hell of a lot. Then I threw … now I'm really full-stack. I am so good. I've made all these incredible performance choices, the site works well, and I've chosen accessible components. My gosh! I am not only making this thing happen, but I'm making it happen in an awesome way, no thanks to myself and my skills, but my choices are great.

[Laughter]

Dave: I've made great choices that give me a well-paying job title.

Chris: We used to think of stack like LAMP. We used to think Linux, Apache, MySQL, PHP; that's the stack that I am working on. I used to think in those terms all the time. I used to have a little icon in my doc called MAMP. Instead of Linux, it was Mac, but everything else was the same. I used to think of that as my stack.

Dave: Mm-hmm.

Chris: You look at that acronym. You're like, I don't know anything about any of those technologies. I'm not a PHP developer. I'm a WordPress slinger. I don't know anything about Linux. I don't know anything about Apache other than that's the one that you changed that then you're able to use an htaccess file and that's nice once in a while because it allows you to do a handful of things I need to do like cache assets, do redirects, and stuff.

MySQL, certainly, I know it's a database, but [pfft] I don't do actual database things. I just know how to import them and export them once in a while if I have to. If I had to do a string replace on them, I maybe could, but very limited knowledge. I'm on the LAMP stack, but I'm a novice at best at everything on there.

Now, we don't really talk about stacks like that. In fact, Shawn Wang had a CSS-Tricks article not long ago where he named the STAR stack, which was Design Systems, TypeScript, Apollo, GraphQL, and React. It was just a lot of people, a lot of big companies have gone there. They're like React Apollo deals, mostly, and they tend to write in TypeScript at scale for all the type checking and the nice things that in can do. The S is interesting in that, because it's already component-driven, people think in Design Systems and such and that Design Systems are almost part of the stack.

That is what people think of as a stack these days. All those technologies are super-duper frontend. What a stack has become has been more about what front-end choices you make than what back-end choices you make.

Dave: Yeah, there wasn't a database, a server, or -- [Laughter] You know?

Chris: No.

Dave: None of that information was in the….

Chris: Yeah. People don't even care. Where's your data? I don't know. Who cares? Firebase….

Dave: Call me later.

Chris: Something.

Dave: We'll figure that out at the end.

Chris: Yeah.

[Laughter]

[Banjo music]

Chris Enns: This episode is sponsored by Datadog, a scalable, full-stack monitoring platform. Get a user's eye view of your front-end services with Datadog Synthetics. You can automatically test your application endpoints with simulated traffic from global locations, allowing your teams to proactively identify and improve issues before they affect your customers. Plus, build multistep browser tests simply by interacting with your application. Datadog will record your actions and automatically execute the tests and intelligently adapt to changes in your UI along the way.

You can build your first test today with a free trial of Datadog Synthetics and receive a complimentary T-shirt by visiting dtdg.co/shoptalk. That URL again is dtdg.co/shoptalk to get a free trial of Datadog Synthetics and receive a complimentary T-shirt. That link should also work in your podcast player right now, as well be on the episode page at ShopTalkShow.com. Our thanks to Datadog Synthetics for sponsoring this episode of ShopTalk Show.

[Banjo music]

Dave: We were talking about it earlier, but you know Xstate from David--I'm going to murder his last name--kpiano.

Chris: Khourshid, I think.

Dave: Khourshid. I think that's right. Xstate is kind of like a state-driven UI.

Chris: Xstate.

Dave: Xstate.

Chris: Yeah. Oh, yeah. I know what you mean.

Dave: Xstate. What's really cool -- I've been fascinated by this, in the last week or whatever, for no particular reason. Not like a reaction to any kind of project or whatever, but I've just been hanging out in the docs just reading all this stuff. I think there's this idea in React that you UI is a function of state, right?

Chris: Mm-hmm.

Dave: That's why you have a reactive UI that responds to the state. Xstate, it's kind of a quasi-store but not really. It sort of maybe helps manipulate it, but it is more like you just write out the states of your application, like inactive, active, for a button or something, but you could be like loading, loaded. It could be whatever.

Chris: Yeah, and then isn't it intentionally limiting you then to those states whereas, like, a React component has state. The state could be name, and the name could be Dave. If Dave changes to Chris, then the component will re-render or do whatever it does with state. Now that state is a string, you have infinite possible states.

Dave: Mm-hmm. Yeah.

Chris: This is saying this isn't that. This is, you name the possible states.

Dave: Yeah, you kind of like predefine what things can be. From that, I guess you'd call it strong typing, sort of, right? You've defined what possible values these can be.

Chris: TypeScript for states.

Dave: Yeah, sort of. You basically said, "Hey, these are the only states the application can be in." You basically do a switch statement as sort of some of the examples they have.

Chris: Mm-hmm.

Dave: You're like, "If you're in this state, do this. If you're in this state, do this. Render this partial. Render this function."

I'm just really into that, a lot of the examples and there's even an Xstate course. When is that course? I have it here. I just want to give credit. Learn State Machines is the name by John Bellah.

Chris: Mm-hmm.

Dave: I've been poking at that. He'll probably get my $60 or whatever it is here. $55 right now. Smokin' deal. A lot of it is in React.

Chris: Something in your brain decided that this matches a way that you'd like to think more?

Dave: I think so. Have you ever coded and then you're just like, "Oh, weird. When I click this button and it goes and fetches something, but then it doesn't get anything back. Oh, yeah, what do we render there?" You know? You can kind of predefine those flows or those options. I think that's maybe a smarter way of architecting a component, if that makes sense - some of your components.

Chris: I can see that. It hasn't really clicked in my brain as well as it did with you, but one nice thing that I've heard is that a lot of bugs, all bugs, maybe, are a problem of state, in a way, that … got into a state that you weren't expecting it to get into. This is not only a way to slow that down a little bit, but almost make it impossible to get into a state that you weren't expecting because not only, these states, are you naming them, but there are allowed which ones they can move to next, which I kind of like.

Dave: Mm-hmm.

Chris: They always use the stoplight as an example, like a red, yellow, green stoplight. Red can't go to yellow, at least a traditional one. I'm sure there are some stoplight in the world where it can do that. But if you think of the most traditional stoplights, red can only go to green. Green can only go to yellow. Yellow can only go to red.

If you kind of set that up in your state machine, you can't cause a bug that gets you into the wrong state or the wrong thing happens. Or if you bold some text and you're trying to un-bold it, but you can't, well, there is something. It somehow got weird double bold or something. No, the state machine defines that text can either be un-bold and the only way away from it is to un-bold it. You're setting up these really firm pathways between state that cannot be violated.

Dave: I think they use it a lot to animate between, too. That's another thing. Everyone wants that cool, like, "Oh, you signed up. Now it turns into a green checkbox." Or you did the "Submit Credit Card" and now it's a checkbox. That's sort of a lot of code and custom events.

Chris: Yeah, well, the state is, you're logged in or you're not logged in. Then that, you can't get into a busted-ass state then. [Laughter] You can't log out if you're already logged out because the state isn't that way. You'll never see that. I don't know.

Dave: Yeah. Yeah.

Chris: I don't know what I'm talking about.

Dave: Anyway, it seems very cool. I'm sure it's not without its problems. Everything has gotchas or whatever. I don't know. You have the state of your dropdown as open or close. But then you have only one dropdown can be open at a time or something. Now you have another parent component that controls the state of those components. It's messy, but as long as your components -- I can either be open or closed. You tell me which one you want. [Laughter] That seems so cool. Anyway.

Chris: I wonder. General component complexity starts to get to me sometimes. I've thought about this in the past. I'm like, holy crap. Sometimes components--I've been living this--"are responsible for a lot. You're like, "Oh, my God. It's this tiny little rectangle on a page, but it's in charge of its own queries. It's in charge of its own styling. It's in charge of its own little tests.

It only accepts certain prompts and not other prompts. It has its own little internal state management and functions. It knows how to talk to other components if it has to. Now, all of a sudden, I have to define what states it's possible to be in or not be in and things like that.

Now, you have this one, like a folder with a dozen files in it that control different aspects of its existence. You're like, holy crap. This one little component is more complicated than some websites I've created.

Dave: Mm-hmm. Yeah.

Chris: Can you reason about that? That's the danger. Does it become complicated to the point where it's not easy to figure out what's happening anymore? I don't know if that's the case here if this is the straw that broke that camel's back. I doubt it, but I just can see that camel's back existing anyway.

Dave: [Laughter] You see the camel's back sagging lower and lower.

Chris: [Laughter]

Dave: There is. It's tough to be like, "This is it. This is the golden calf. We've figured it out," with anything. I guess where I was going was, like, a lot of this stuff is React-based. React is very popular, a huge mindshare but, for whatever reason, my brain has decided maybe React is not the path I want to take. That has probably cost dollars in the long-run, but I've been looking at Web components.

I'm a big fan of Web components, but they have their problems. Rich Harris wrote a really good post on Dev2 about it. He's like, "Why I don't use Web components," or something like that. It was really good. It highlighted a lot of the problems I have with Web components. They still require JavaScript and a lot of it, unless you're using a framework. At that point, if you're using a framework to manage it, then if I have to use Polymer to manage it, well, now I'm in the Polymer ecosystem. Or if I'm using some off-brand Polymer, you know, now I'm in that ecosystem and I have none of the advantages of a framework ecosystem like React.

Chris: There you go.

Dave: I would actually--

Chris: You're already bought in on a bunch of stuff at that point. I totally agree with that being a really weird aspect of it. When anybody builds a component thing that's like, "This is just a little tiny framework to help make your Web components better," or something, you're like, "Well, now you're the thing. You're the buy-in."

Dave: Yeah. Yeah, you're the sugar I'm depending on. Lit-html and LitElement are really cool for me. There's another kind of add-on to that called Haunted. It's by matthewp on GitHub. Haunted, which adds hooks to Web components, so it adds hooks. [Laughter] Sorry. Adds hooks to lit-html or Hyper, hyper-html. People like Hyper a lot, but it adds hooks to Hyper. I like this because I like hooks, but I don't like React. That's a weird thing about me, Chris, that [laughter] You're going to have to just accept.

Chris: I know that. That's nice that they don't. It's not even a little bit like hooks. They're exactly.

Dave: Exactly like hooks. Then my brain is like, "Ooh, if I could squeeze Xstate in here, maybe I have the thing for me." You know? Maybe I homebrewed my own framework that has everything I need. I don't know, though. I don't exactly have the time right now to be like, "Let me just experiment with writing a framework." You know?

Chris: This is cool, though. Is it just use state or is it all the hooks?

Dave: There's a component thing, but it's use state.

Chris: It's got use effect. That's a good one.

Dave: Use effect. Use memo.

Chris: Use reducer. Wow, it's got all the good ones.

Dave: Use reducer. All the hits. [Laughter]

Chris: Yeah.

Dave: You could write your own, too, but I'm just kind of like, maybe this has everything I need here and without the corporate buy-in, if you will. Again, I don't know. I've never built any sort of thing at scale with this, so it could be all theoretical -- it is all theoretical at this point.

Chris: No, you might be onto something here. This could be a little blog post. Even if it was theoretical, I would highly encourage this because people are like, "Well, what are you going to do about templating if you're not using Vue, it's cool modeler, Angular's, or JSX or whatever." Well, you've got Lit and Lit is nice because it's just template literals, so it's very familiar and nice.

Then what about state? Got it covered. I even got lifecycles covered and all kinds of stuff through Haunted. Then Xstate is just kind of a Dave bonus because you like it, but it wouldn't definitely be necessary. Then I guess what would you do about routing and stuff, but I guess maybe you just don't go there.

Dave: Yeah, that's the tough part, right? It could just be static HTML with the elements. You know what I mean? It could be the elements plus -- I think, for me, I'm less boner pants about the routing features. I'm more interested in, like, how do I author? I'm more interested in the authoring experience, if that makes sense.

That's what I like about Vue. The authoring experience is very similar to how I author. I could write a page and just include all my modules at the bottom of the page and it should render. I could write a static HTML page JAMstack style and it should render. A lot of people do just want to do all in JavaScript and inject stuff using a router every step of the way. I don't have that piece solved, but I think that would be an important piece, to popularize Dave.js.

Chris: Would you do it? It looks like all the demos for this stuff are like, "Just import it module style." Would you be tempted to go there? Would you still use a bundler of some kind?

Dave: I think I would just use modules.

Chris: Yeah?

Dave: See, this is where I'm kind of -- not to get too heady here or whatever, but I've been frustrated with the state of Web development. I think I had a lot of misdirected anger at sort of who moved my cheese style anger, like, "Oh, everything has evolved and I haven't. Now I'm mad." You know?

There was some of that, but I think my first initial thing was like, "I'm mad at Webpack because Webpack makes it all harder and encourage you to just put 20,000 files into a thing. You know?

Chris: Mm-hmm.

Dave: I think that was misdirected sort of frustration. I still think there's an enabling there. I think the nodes micro-bundling strategies are kind of poor. Right? I think node encouraged everyone to write single function packages. There are a lot of good ones out there, but that creates dependencies that you don't manage and that's a security risk, which we've seen time and again.

I think, even more so than that, there's a knowledge management issue, almost. It's like, what does this thing do? I have no idea. It's called space pants. What does space pants do? [Laughter] I've got to figure this out. I have to go to the docs. Oh, I have to read the entire docs because I still don't know what it does.

It's sort of like this, unless you're like a heavy working knowledge like fully embedded, fully understand at all, there's a lot of effort to kind of go chase things down. I felt this jumping into React projects and stuff like that. I mean this is cool, but I have no idea what this does, so I'll have to figure it out bit by bit. I think there's that aspect.

The package management system is great. I don't want to poo-poo that, but I think our micro-packaging has been somewhat problematic or just kind of unsustainable in a way. If you create a React app, you now have 1,500 packages in your system. What do they do? You don't know. Some of them, you don't need to know what they do but, man, that's a lot of things doing stuff you don't know. You know?

I guess you lose knowledge of what the code is doing, which we kind of talked about before, like you didn't know what the LAMP stack was doing. For me, I just kind of want to know a little bit about the machine I'm using. All this to say, I feel like I was a little upset about the NPM ecosystem, but it was so easy and cheap to import some small function on the server when NPM was just the server-side stuff, the server-side node.

Chris: Yeah.

Dave: Now that it's in client land or managing the client stuff, I think we do have a problem. Maybe import.html from lit.html is way more efficient because lit.html could have a few dozen functions in there, really, but I'm just pulling out one piece of it. I feel like if we could author like that and then, optionally, use some packaging or some bundling.

That's kind of what Pika is offering, like a Web modules kind of thing. Preact has a hundred dependencies or something like that. Like Pika install Preact and you get one Preact bundle. Does that make sense? It packs up that bundle.

Chris: Yeah, it does. It's cool in that way, but it depends. It doesn't solve anything for you, anything that needs to be built in an ES6 friendly way, as far as I know.

Dave: Yeah. Yeah, like requires ES6, right? Import Syntax to Tree Shake or whatever.

Chris: ES is native? Does native ES6 import? Is it smart enough to only request that little chunk of what it needs from the whole library? No way, right?

Dave: I don't know. I think it was trying to do that, but I think there's too much require code out there, if that makes sense.

[Banjo music]

Chris Enns: This episode is brought to you by Jetpack, the powerful WordPress plugin from Automattic that adds security, performance, and site management tools to WordPress. You may already be aware of Jetpack features like Monitor where you can get alerted any time your site goes down; Protect, which guards your site against brute force login attacks, spam, and harmful malware injections; or how it gives you a free image CDN to allow you to embed high resolution photos on any page without slowing down your site.

Some new features they've added to Jetpack are things like the Repeat Visitor Block where you can roll out the red carpet for a new visitor to welcome them to your site or introduce them to your best selling products. If you wanted to offer something special to the faithful reader who stops by every day, that's what the Repeat Visitor Block is for.

In Jetpack 7.5, they've added Magic Links, which allow you to log into the WordPress mobile app in one click. No passwords, no password manager, no repeated incorrect logins from typing on a tiny phone keyboard. You just visit the main Jetpack dashboard in your site's admin area and email yourself a magic link by clicking "Log into the WordPress Mobile App." Check your email on your mobile device, click the link, and you're in. You can visit Jetpack.com to find out more and to get started today with Jetpack on your WordPress blog. Our thanks to Jetpack for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: If you're really authoring JavaScript and you write import component from lib.js, only it's not lib.js, it's a whole URL of where that thing is that you'll just write more responsibly because you're like, "I see. I am making a Web request here."

Dave: Yeah. Rather than import jQuery, it's like I know I'm only using jQuery wrap or jQuery selector or something. Wouldn't it be cool if we had that in the jQuery days? You could be like, import tabs from jQuery UI or something like that, which we kind of would do. You'd just download the tabs bundle or whatever. That's kind of the authoring like where tabs is a complete sort of interface; not just like a bunch of references to fourth, fifth, and sixth part of your packages, if that makes sense. That's kind of what I'm looking for, but I don't know. I don't know if I get it. I don't know if I get it.

For me, I want, I guess, less moving parts - sort of. That's kind of where I'm coming from. I want less moving parts and less giganto bundles. We hate monoliths, but we still roll up.

Chris: It's funny because they have the possibility to be smaller. When I see an ES6 thing that says, "Import HTML from lit.html with the full URL, that's not true shakable in ES6 but is true shakable if it's bundled.

Dave: Mm-hmm. Yeah.

Chris: The bundle thing, the tendency is to abuse it and make giant packages. But if you don't use it, its potential is better. There are all these dichotomies like that in Web where we've talked about just recently that just React itself, the tendency is to do a bad job with accessibility, but the potential is to do a better job. It's like, meh.

Did you see Jonathan Snook's post on Why Did I Have Difficulty Learning React?

Dave: Yeah. Yeah, and I really liked it. I think I had a lot of the same feelings. It's snook.ca. He had kind of four categories, all the technologies.

Chris: I get that one. You're like, look at these little -- look at; there's an element and then …props, or something. You'd be like, oh, what React thing is that. No, that's not a React thing. That's just spread or whatever. What's the opposite of spread? [Laughter]

Dave: Uh…

Chris: The other one.

Dave: I don't know. There's an opposite of spread? There's a join operator?

Chris: Well, one of them is thing… and something is …thing, right?

Dave: Oh, really? Oh, okay.

Chris: Maybe I have that wrong. Anyway, don't listen and don't write in to me. I'll just look it up after the show. Sorry.

Dave: [Laughter]

Chris: One of them is like all the rest of the -- I think you'd only use …thing in the parameters of a function as you declare it, which means you accept foo, bar, and then give me all the rest of them as one big chunk - whatever they pass.

Dave: Okay. Okay, yeah, you're like, and the rest. Right?

Chris: And the rest. Yeah. It's not the same as spread or whatever.

Dave: Yeah, yeah, yeah.

Chris: Yeah. Okay, there's that. Then you're like, well, this JSX thing, well, that's not really React. It's just JSX, but it's used in the same kind of place. What's the React part? Well, it's just the class model, but we don't really write classes anymore. It's confusing, like, which thing you're looking at does what? It never comes by itself. It's always, and friends, as we've often said on this show.

Then they're using Redux, so I really don't blame them because any of the times of the projects I've had Redux in, it wasn't set up by me and I never grokked it. I was always just like, "Oh, my cripes." I remember pairing with people time and time again where I'm like, "I just want to click this thing and have this thing open." It's like the number one design thing.

That's what I'm put on earth to do. Click on thing. Make thing happen. That's the Chris Coyier thing. That's why I like jQuery because that was easy. You write .clickon or whatever or onclick and then you just change a class and you're done. You're like, "Well, the change of class in Redux, we really need to first alter the global store so that it's expecting that state and then write a dispatcher that will dispatch it from this component over to this component over to this component over to the global store. Then it will sprinkle that state out into the other components that might need to know about it."

You're like, "Well, I kind of get, conceptually, that's nice. Then there is this global store and other components can react to it." I'm like, "Oh, my God. "Click something; do something," all of a sudden became 80 lines of code and 4 components. What happened?

Dave: No, well, and there's a bunch of jargon that goes with it, too. Now you have mutations, but your mutations go on the store object. You're like, what's the store? [Laughter] This isn't e-commerce.

Chris: Then I realized, through time, though, that because you did it that way, you have protected yourself against stupid bugs and spaghetti code and legit problems that happen to a codebase over time. It sucked to write those 80 lines of code, and I did want to push back on that. In the end, it was a little bit more resilient code. That's why everything is a push and shove-y thing.

Dave: Yeah, it comes with a lot of mental overhead. It's a very clear pattern of how it evolved to, "Oh, I've got a lot of state. I need to share state. All right. Now I need to manage the state."

But if you just hopped in from zero learning to any, you know, to like now I work in this, that's a lot to kind of wrap your head around, especially if everyone is like, "Oh, that's what it is. You don't know?" You're like, "Uh…."

I even read that comment that Mozilla put out. Was it Lynn? I'm blanking on the name who draws the comics. Drew a comic about Redux or whatever and I was just was like, "Yeah, I get it even less now that I read a comic about it." [Laughter] But anyway.

Jonathan got into writing JS differently. He was very comfortable with old JavaScript. I think he wrote books on it. I don't know. But then getting into, like, now that all these frameworks--Dojo, UE, jQuery, Prototype--don't exist anymore. Now we're using ES5, 6, 7, and 8. He's just like, "Oh, boy. This is a lot of stuff." Then I think he also mentions the deep hierarchies, just like when you build a React app; you have a lot of context, consumers, and then components that consume components that consume components. Your tree is wild compared to like a DOM tree that you authored by hand.

Yeah, I agree with Jonathan on almost all of these. Yeah.

Chris: I will see how it shakes out. He was emotionally vulnerable with this being like, "I considered quitting my job for this." You know?

Dave: Right. Right because it's just like, this is so much stuff. Thankfully, they are patient with me. Jonathan is not a dummy. He's a very smart guy, but he was just like, "Man, this was hard enough I almost gave up," so that just goes to show, right? What might be easy for you is not the same for everybody else.

Chris: I would say if there are people in that moment. It feels like a bummer to me to lose somebody to Web development entirely just because technology changed a bit. If you're going to leave tech, you can do it for any reason you want to. I don't care, but I'd love it if you left just because you've done what you wanted to do, you're tired, and you just want to move on and do something else with your life, not because you think that the state of tech is so garbage that things like syntax have you quitting tech. That's too bad.

Dave: Yeah. No, but I think, in some ways, something has got to break. I think somebody on Twitter just says, "I agree. NPM, Webpack, and everything is great, but what you can't convince me of is 19,000 dependencies in a folder is a good thing," or whatever. [Laughter] He's just like, "I will say this stuff is cool, but you can't gaslight me and tell me it's great."

That's sort of where I'm at. It's just like, if something is too complicated or unnecessarily complicated, how do we fix it? Are we all solving problems the wrong way or for us, or something? I don't know. I don't know.

Chris: Yeah. You know I work with Alex Vazquez. He's kind of our CTO at CodePen and watches this kind of thing and has been doing a really good job of that lately at CodePen of being like, "If something feels complicated, just know that it doesn't have to be that way. We can fight it. We need to stop, talk about it, and figure it out." You're always right to question things when they start feeling weird to you, you don't get it, or you have that little internal alarm in your mind that says, "This is just getting too complicated."

Usually, there's kind of a way out of it. At least, that's a moment where everybody needs to talk. You don't just press forward and write another library on top of it to uncomplicate it or whatever. Maybe there's just been too much of that that has happened for too long. It deserves some pushback is what it needs.

Dave: Yeah. I'm a firm believer in the 80/20 rule in that, like, 80% of problems can be solved by 20% of effort, basically. You're still going to have a lot of problems, but I'm always like, there's got to be one thing we can do to make this better or one thing we can do to make this 80% better. I'm a firm believer in that, but it's sometimes finding that is really difficult and it's not always a linear process to get there. Sometimes you have to go down a bad path to figure out the good path.

Chris: Yeah, tell me about it. It's almost required. [Laughter] If everything seems fine, you're the rarity, you know. Usually, you have to use tech to find the rough edges. If you don't know what the rough edges are, you haven't used it enough. That's another Alex thing I'm repeating of his because he's smart in that way. It's like if you can't tell me what those rough edges [are] -- it's almost like an interview question. "Oh, do you know this technology?" "Yeah." "Well, then tell me what the rough edges are?" or phrase that in a way that's a little more clear but tell me what the limitations and problems are.

Dave: I think I've heard that from Rebecca Murphy. "Oh, you use React? What do you not like about it?" [Laughter] If you can't answer that question, maybe you don't actually use it.

The converse is also true. Whenever somebody is like, "This is great. It has no problems," I'm like so red flag.

[Laughter]

Dave: Really?! None?! You had no problems with this?!

Chris: Yeah.

Dave: Like, oh, man.

Chris: It's one of two things, and both of them are bad. Either you haven't used it that much or you're just not the kind of person that just thinks about and questions anything. If it's an interview thing, that's a little scary too, you know.

Dave: Yeah. Yeah, I've had that red light go off a few times, and it's just like, I almost can't. I almost shut down because I can't process how somebody can come up with no criticism about a technology. [Laughter] I'm just like, technologies are whatever; they are lumps of decisions and they are lumps of concessions and tradeoffs. How is there no problem? There's got to be a problem.

I think that's one thing with Dan Abramov from Facebook and works on React. I've followed him and watched a lot of videos with him. He knows the problems with React. He's very, like, "I know exactly what is the problem and I see it all the time. I help people with React all the time and there are problems." I think that's really cool to see.

Chris: Nice. All right, well, that's a good place to end it, Mr. Dave.

Dave: Yep. Thank you, dear listener. Tell us your problems. Send them in, audio questions, whatever. We try to crack at them or we'll find somebody who can answer those questions.

Be sure to star, heart, favorite this episode on your podcatcher of choice. 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 ShopTalkShop.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: ShopTalkShow.com.