Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, holiday editions. I'm Dave 9ty Rupert and with me is Chris 10ty Coyier. Hey, Chris.

Chris Coyier: Hey. [Laughter] Thanks for giving me 10ty, you know.

Dave: Yeah.

Chris: Like my interns 7ty and 8ty are here too.

Dave: Yeah. Yeah. We love them. They're big contributors. Anyway, hey, Chris, who do we got in the studio today? [Laughter]

Chris: Well, we have a good friend Zach Leatherman on the show today. Hey, Zach. How ya doin'?

Zach Leatherman: Hey. Good. How are you guys?

Chris: Fantastic. Fantastic. Zach is known for all kinds of stuff that we'll get into. We, of course, are making 11ty jokes. Zach has been beating the 11ty train for a while here. It is a big, open-source project that you run, Zach. Would you call it a static site generator? Is that the moniker it deserves?

Zach: I would, yeah. I know some other competitors might shy away from that but, yeah, I'm comfortable calling it a static site generator, for sure.

Chris: Yeah. I wonder why they do it. I guess it makes so much sense for 11ty. It really doesn't try to do much other than that, right? It takes some templates and it processes them. That's it.

Zach: Yep, it's a classic static site generator. The competition would argue that their tooling is more deserving of the modern moniker, but I would say that 11ty has definitely some modern aspects to it in that it works with modern JavaScript, like some ES6, ES7 features built-in.

Chris: Yeah. Yeah, yeah, so if you're a Dave Rupert and you have a folder full of Markdown files, a template for those blog posts, maybe a template for the homepage, and some stuff like that, it would be a perfect fit for that kind of thing. Not peer pressuring you over there, Dave. Just saying it's a good fit.

Dave: Hey, well, I guess, full disclaimer; I am an open collective backer for 11ty, so I am an investor, month-to-month, five whole dollars a month here, but that's where I'm at.

Zach, I don't mean to sell you on pitch much but, as an investor, I do feel like I have some input.

Chris: Mm-hmm.

Zach: [Laughter]

Dave: My favorite feature of 11ty is, you don't even have to install it. [Laughter] You click – you can run it from NPX.

Chris: Can you NPX it? Can you really?

Dave: Yes, you can!

Chris: Oh, that's cool.

Dave: It's a static site generator. You don't even have to install.

Chris: That's pretty impressive. I didn't know that worked.

Dave: Not to poo-poo all the work that the Jekyll folks have done, but it's very much, coming from that world, installing is 90% of the battle. This is just -- well, I'm not going to say it just works, but there are configs and things you do.

Chris: It's pretty close, though. If anybody out there is familiar with Jekyll--I bet a lot of people are--you have to install it, right? There is a bunch of Ruby stuff going on to get that.

Dave: There is four days of Ruby.

Chris: Then it's pretty opinionated about what templates you run in. Okay, well, what if you could change all that? What if, instead of Ruby, it just ran in Node like literally everything else you do, probably? It was way less opinionated about what languages you're trying to run and stuff. It probably has a bunch more modern features that I'm not even aware of. That's 11ty.

How is our pitch doing, Zach? Do you want to try one of your own so that our listeners understand a 11ty a little better?

Zach: No, I mean that was pretty good. The big features to 11ty is that it doesn't really try and tie your content into a proprietary content templating system. You can use just raw JavaScript. You can use liquid templates, which is what Jekyll uses.

Chris: Mm-hmm.

Zach: You can use Handlebars, Mustache, Nunjucks, and you can wrap them all in Markdown if you want. It kind of just lets your content live in templating languages that are independent of 11ty, as much as possible.

Chris: Mm-hmm.

Zach: I would say the other big feature is performance. We really try and make it as fast as possible. I know Dave mentioned that you don't need to necessarily install it to run it, but it is quite a bit faster if you install it first.

[Laughter]

Zach: If you want something that's more on par with some of our competitors' build times, then maybe you can install it every time you want to run it. I think you probably want, really want, that local install so it runs faster every time.

Chris: Yeah. It's not much of an ask anyway, right? [Laughter]

Zach: Yeah. Yeah.

Chris: Just NPM install it. Big deal. Cool, so there are all kinds of things that you can build with it. Static site generation, it's bread and butter, in a way. I use it. Dave uses it for stuff. It's pretty darn cool. Congrats.

It's a great project and it really seems to be gaining a lot of steam thanks in no small part, probably, to the rise of the JAMstack where people are looking for excuses almost to make their sites into static things because there are just so many clear advantages there. We've gone through this a million times, but the speed of it all, the security of it all, and the kind of longevity and resilience of it all is all part of JAMstack stuff, so there are just more and more people, "Maybe I'll just slap this thing on GitHub pages," especially if I can prebuild a bunch of pages ahead of time. Maybe I'll use Netlify like the rest of the world and 11ty fits into that world just like a glove.

Zach: Yeah. We've been kind of riding a couple of different waves there. The Netlify one and JAMstack is definitely one of them. I think another one is just the rise of JavaScript and Node, generally speaking.

Chris: Mm-hmm.

Zach: Yeah, people like Jekyll, but they don't necessarily want to do Ruby, so we've gotten a lot of people switching there too.

Dave: I would say, too, in addition to that, for me, the advantage of 11ty -- I'm a Jekyll diehard, but the advantage of 11ty is it's all one build process. More or less, it's a build process in itself, I guess, but I have a package.json that manages everything. I don't have a Gem file. I don't have a special Ruby thing. It's just Node and then I'm probably going to do some static asset compilation of some kind with some Node-based tool like Grunt, Gulp, Webpack, or even NPM scripts or something like that. It fits in that ecosystem. You don't have to install another big thing. It just fits.

Chris: Mm-hmm.

Zach: Yeah. I would say that some arguments against 11ty have been that it's very similar to a Gulp or a Grunt. Maybe some common, in my mind, I would consider it sharing a lot of sort of real estate with Gulp and Grunt in that a process is files and outputs process files from that.

Chris: Mm-hmm.

Zach: You do get a lot more power when you have integrated the templating with the tooling in this way. You can do a lot more because you can basically inject content right into your templates, which is, I think, very powerful. I'm exploring some more tighter integrations with that--

Chris: I see. I see.

Zach: --so the project moves forward.

Chris: These people are like, "Why do I need 11ty when I can just write a Gulp process that just runs Nunjucks anyway?"

Zach: Right.

Chris: Yeah, but that's short-sided, perhaps. Another wave that I wonder if you're not riding or could be or are and I don't know about it or what is this kind of idea that maybe I don't have all my content in my repo, locally, or whatever. I want to hit somewhere to get it. I want to use Contentful, Sanity, or whatever, like a cloud CMS or even just a GraphQL endpoint, something to cough up this data because that makes sense for my workflow, but I still want to prebuild.

Zach: Yeah.

Chris: Yeah. Possible? Have you seen people doing it?

Zach: Yeah, absolutely. Yeah, we've seen a lot of -- it's sort of like a giant rise of CMS solutions that are coming out right now. There's a lot of competition in the CMS space. 11ty works great with all of these because we just do raw JavaScript data files. Anything you can fetch in JavaScript you can fetch with 11ty. Yeah, you can basically integrate with any data source that you want. You just have to manage that code in a JavaScript data file. You can write any arbitrary JavaScript to fetch any data from any data file.

I sort of built something recently. There's an 11ty site documentation search. One of the integrations that I want to work on in the future is pulling in all of our GitHub issues onto that as well so we can have a single point of search for both our docs and our issues in one place.

Chris: Nice.

Zach: That would be kind of cool.

Chris: Like on a cron? That kind of thing? It goes and gets that data and then has it locally in which to search. That's going to change because there'll be new issues that open and old ones that close and stuff like that.

Zach: Yep, and the docs basically build every morning. They're hosted on Netlify and we just have a little task that runs and updates the docs every morning.

Chris: Nice.

Zach: We can very easily integrate that in. I think that's really one of the very cool things about JAMstack is that you can have these dynamic data sources appear or you can have static representations of your dynamic data sources and it's all dynamic depending on how often you run your build.

Chris: Yeah.

Zach: I think that's a super powerful thing.

Chris: That's one of the most exciting things of all. It forces you to look at a page, for lack of a better word, and be like, "Okay, how static is most of this? Is it really static or is it daily kind of static, weekly kind of static, or not static at all; this needs to come from a live source right away?"

It kind of doesn't matter what the answer is. None of them mean, "Don't use JAMstack."

Zach: Yeah.

Chris: You can be like, "Well, I'm going to prebuild this shell," or whatever, like you do. "I'm going to run a weekly, a daily, or an hourly." Great. Or I'm going to do that, but then this little part in the header or whatever is super dynamic. Well, then, fine. Then fetch it in the client.

Zach: Yeah, absolutely.

Chris: You can still use JavaScript. [Laughter]

Zach: Yeah.

Chris: JAMstack doesn't mean not JavaScript. As a matter of fact, it means heavily use JavaScript, in a weird way. Hopefully, as much on the build as you can. Even if not, so what.

Zach: Yeah. Yeah, lean as much on your build as you can. For everything else, use client-side.

[Banjo music starts]

Chris Enns: This episode was brought to you by GiveWell. Imagine that you want to help children. You found two trustworthy organizations but they run different programs. One can save a child's life for every $300,000 donated while the other can save a child's life for every $3,000 donated. If you could tell the difference, you'd donate to the one that was 100 times better at saving children's lives.

But in reality, it's often hard to know what charities will actually be able to accomplish with your donation. GiveWell spends 20,000 hours each year researching charities. They review academic studies, charity budgets, and visit charities on the ground to figure out which ones are the best at saving or improving lives. All of their research is public and free on their website.

Go to GiveWell.org/ShopTalk to find out more or make a donation. First-time donors will have their donation matched up to $1,000 if they donate through GiveWell.org/ShopTalk. Our thanks to GiveWell for sponsoring this episode.

[Banjo music ends]

Chris: This is all fun stuff to talk about. Let's keep talking about it. One of the reasons that I had the idea for this show to have you on is, ages ago, I don't know what the year is, but I just came across this, you've been thinking about the good ways to build websites and ways to think good about the things that we build for users manifested itself in a manifesto--

[Laughter]

Chris: --called a Front-end Engineers Manifesto. It really was just last month or something, I saw this. I'm like, "Well, this is interesting. Clearly, Zach put it together a bunch of years ago," so maybe you could tell us the origins of the thing. I thought, after you do that, let's go through it and see, all these years later, if Zach's Front-end Engineers Manifesto held up over time. Where did this thing come from? Did you give a talk around it or something?

Zach: Yeah, it was maybe my first conference talk ever and it was for a local conference that was just put on in my area. I remember just putting this thing together just to speak at a conference, just a local conference. It was my first one ever, and I remember being so incredibly nervous and sweating profusely as I'm preparing my notes for this presentation.

It's a little bit different than maybe nowadays because I've done a few more talks since then. Yeah, this thing was my very first conference talk in 2011. Yeah, eight or nine--

Chris: 2011, okay. Yeah, eight or nine years ago.

Zach: Eight or nine years ago.

Chris: You bought a URL for it, a nice four-character dot-com, F2EM.com. You can tell it's so long ago because it's not even https. Whoo!

Zach: Oh, no. [Laughter]

Chris: [Laughter]

Zach: I need to move it over to Netlify.

Chris: Yeah, yeah, it's like you don't even have a choice anymore these days.

Zach: [Laughter] Yeah.

Chris: It just is automatically. What do you think, Dave? Are you ready to go through this?

Dave: Yes, sir. [Laughter] Yeah, we should maybe start at the end, the last tenant is, "I will strive to create secure applications."

[Laughter]

Chris: Oh, that's wonderful.

Zach: Anyway, I knew we were going to go over this and I made it a point not to update this code just so you guys could rip through it. It's fine. It's fine.

Chris: Enjoy the past? Oh, there's lots of fun stuff. There is some kind of thing that runs on words that Zach is trying to emphasize, so it's like a sentence.

Let's just do the first one and I'll set the scene here. I guess the first manifesto thing, it says, "Most importantly and above all, I will put the needs of the user first over my own needs as a developer." I said user first in real life bold because, if you can picture this, the rest of the sentence is all small font but "user first" is in big, all caps, condensed gothic thing and the font size is, in my browser window, 10.38M. I think Zach perfectly calculated the M value that would make sure the left and right side of the thing is perfect. Maybe there's a little JavaScript that calculates it or something.

Zach: Yeah, this is one of my first jQuery plugins called Big Text. I know Dave and I have competed in that responsive text plugin world. I know Dave calls it--what is it--jQuery Plugin Horcrux or something.

Chris: Fit Text, I think.

Dave: Horcrux, yeah, Opensource Horcrux.

[Laughter]

Dave: You give a piece of your soul and then you have to work on it for the rest of your life. It's great.

Zach: [Laughter] Yeah, it's just sort of like a way to auto-size text because, if you resize your browser, it will resize the text too.

Chris: Wonderful.

Dave: It's really good. It's really about getting the exact left and right sizes, right? Fill up the available space of the font size. That's Big Text's thing.

Chris: Yeah.

Dave: Then the Fit Text thing was just, eh, whatever. Scale, almost like vector text or something. It'll just be a ratio resize.

Chris: Yeah.

Dave: That was the difference. It's so funny. I have so many bugs on Fit Text. It's just like, "This doesn't fill up the whole size of the parent container." [Laughter] I was like, "Oh, you actually want Big Text."

Zach: Oh, no. You've been shoveling people my way, huh?

Chris: Oh, that's hilarious.

Dave: Yeah.

Zach: [Laughter]

Dave: Well, you know. People, at some point when they're getting into open source, jQuery plugins, or whatever, they didn't understand what it was actually supposed to do or read the docs at all. Yeah, so I was just like, "Oh, actually, what you do want." Then there's another one called Slab Text, which is pretty cool.

Chris: Oh, my gosh.

Dave: It was … different.

Chris: What was the mood tools one? We should almost have a jQuery segment every week.

Dave: New text.

Zach: [Laughter]

Chris: I was enamored by your ability to remember the jQuery BBQ, which was just an incredible plugin, the very earliest possible days of ajax history.

Zach: (Indiscernible)

Chris: Yeah. Okay, anyway, we really derailed ourselves here. Before even this manifesto, which I'll read again in a moment, is a beautiful Google+ sharing button.

Zach: [Laughter]

Chris: I'd like everybody to notice there, too. It's just setting the time period.

Zach: Does that not exist anymore?

Chris: [Laughter] No. No.

Dave: Uh, no. Nope.

[Laughter]

Chris: Okay, one more time. "Most importantly and above all, I will put the needs of the user first over my own needs as a developer." I think I would vote that that holds up pretty well. Where did that come from, Zach?

Zach: Yeah, I think the classic argument that developer experience and user experience are at odds has been happening for--I don't know--since the beginning of time, I would guess. We've always had these two opposing viewpoints that don't necessarily need to be all that opposing when it comes to solutions. A lot of times people will try and advertise good developer experience and, classically, some of the solutions have deprioritized the user experience. The original one that I'm thinking of is client-side rendering versus progressive enhancement. That one is still going on today, [laughter] which is kind of funny.

Chris: Is that a good example of prioritizing a developer need over a user need?

Zach: That's the argument that has been made. I don't really buy that argument, I guess, that you need to choose one or the other. That's maybe one of the origins of the 11ty tool as well is that you can have good user experience or good developer experience and good user experience at the same time, as long as you're prioritizing the correct things.

Chris: Mm-hmm.

Zach: Yeah, I think a lot of people have tried to sell tooling that is, I guess, less tied to a back-end and more tied to the front-end. A lot of that comes with more client-side rendering and a slower user experience.

Chris: The one that I always think of is those date manipulation tools because they're so classically heavy, like Moment.js or whatever. That's the one that everybody poops on, so let's just use the one that's in reality. It's just a developer tool. No user is like, "Oh, I really want to download 30K so that this date stamp says two hours ago instead of March 13, 2019."

Zach: Yeah. Yeah, it is kind of a hefty library for that kind of a thing.

Chris: Yeah, so what's the alternative? I don't know. Do something on the server and send it over in the right format anyway. But then you're like, "Well, what about time zones?"

I'm not trying to say to take a side over the other. It's just that this is a classic butting heads, right? If you're following this manifesto or thinking in that way--I don't know--it's not a zero-sum game. We're not trying to say you can only have one or the other, like you were saying. You think of 11ty as having both. If they do come to hit each other in some way, then choose the user.

Zach: Right. Yes, always choose the thing that makes the user's life better. That's why I like working with designers as closely as possible because their work and their mindset is more focused on the people actually using the code that we write. Yeah, tighter integrations with designers can really help in that sense, too, because it can get your mind in the right spot.

Chris: Mm-hmm. I would say the most staunch person against this would say that, "No, always developer needs first because, if we just have this amazing developer experience that that will automatically trickle-down economics to the website because our developers are so productive and doing such a good job. It's not that they don't care about the users. They're just caring about their own life first so that their work can percolate to the masses." Would you say that's entirely bunk?

Zach: I think there is something to happy developers writing good code and being productive. I don't think that there's necessarily as much overlap with effect on end-users as has been sold in that argument. I think there are benefits there, but I don't think they really affect the end-user as much as people have said.

Chris: Okay. Dave, are you going to put this in the "holds up pretty well eight years later" category?

Dave: Yeah, I think I still agree with this. I guess my question might be just a bit of a twist. People are like, "Oh, the user needs that position sticky thing in IE11, so we're going to chuck 48 kilobytes of JavaScript at it to get it." Does that fall into here too? That's the user.

You know how people can kind of, "Oh, the user needs it," or the classic, "As a user, I want P2P integrated marketing and bitcoin mining on my machine."

[Laughter]

Dave: You know these kind of bunk user tests. What's your thought there? How do you keep it centered on the user first?

Zach: Yeah, I think that's a good question. I don't know that there is a good answer to that. I think every project probably has its own priorities and its budget. Generally, when I work on stuff as a side project or nonprofessional stuff, I will certainly prioritize more modern use cases. Yeah, I don't have to do as much tooling. Again, when I'm working on stuff for side projects, a lot of the users that are using my applications are using more modern Web browsers. But when you need to serve things to a wider audience and you want that first-class experience to maybe some older Web browsers, then you really need to sort of rewind your development practices to serve the users that are using your website and not the other way around.

A lot of sites will use analytics-driven development, which we develop our code based on what our analysts say the browsers are being used by the end-users that are using the site. A lot of times that will be a self-fulfilling prophecy because your users are going to use the browsers that are working with the code that you've written, not necessarily the other way around, if that makes sense.

Dave: Yeah. If it doesn't work on Firefox, 100% of your users, I guess, are having a great time.

Zach: Right. People just bail on your site if it doesn't work in that….

Chris: I wonder if there's a middle ground there where you could look at analytics that are only first-time visit, regardless of bounce or anything. Look at that first because they'll come. If it sucks, they'll leave. That's good to know.

Zach: Yeah. Yeah.

Chris: At least it would be a less skewed picture.

Dave: Even that, though, with the analytics, is that you have Firefox blocks stuff, so it's going to probably block Google Analytics--

Chris: Right. Right.

Dave: --which you're using to make a fricken' business decision. You know what I mean?

Chris: Yeah. You have to look at those UA headers on the server-side. It would be a more complicated endeavor.

Zach: I think the larger point to be made here is sort of tied into this manifesto, generally speaking, and that's that you need to have principles guide your development and not the development guide the principles.

[Banjo music starts]

Chris: Hey, this episode of ShopTalk Show was brought to you in part by WooCommerce. WooCommerce is e-commerce for your WordPress site and so it's a plugin. If you have a self-hosted WordPress site like ShopTalk Show is, CSS-Tricks is, the blog at CodePen is, or whatever, you can install WooCommerce there. Then you have a full-featured store ready to go.

It's kind of built for people who build websites, I think, is a way to think of it. It's pretty easy to get started with. I find it tremendously easy, but it's not meant to be, like, the absolute easiest hand-holdiest way ever to do e-commerce. It's meant to be flexible, designable, extendable, and stuff. I found that to be highly true. You can take really strong design control over the site or be pretty hands-off if you want.

But it integrates with lots of stuff and that's helped me over the years tremendously, like, oh, okay, I've got to get these orders, but they've got to go into ShipStation because X, Y, and Z company needs to deal with ShipStation on their end. Fine. It's a plugin. It works great. Or we need to take money through Stripe or some other thing, there's a plugin for that. Everything is a plugin. There are a zillion plugins for it and it's great in that way.

Now, that's for your self-hosted WordPress sites, but WooCommerce is an Automattic company and Automattic is WordPress.com, right? WordPress.com is like the hosted version of WordPress. You don't have to deal with hosting, security, or any of that stuff. It's great. I have a site on it as well.

You can start a store on WordPress.com and it's really woven in there. If you start a store, you don't even really see the WooCommerce bits, but it is WooCommerce under the hood. That's cool. You can do all your e-commerce on WordPress.com and kind of know that it's WooCommerce powered, if you care, so that's cool, and extended still through WooCommerce add-ons.

This is interesting too, and you might not have known this, but on WordPress.com, if you have a business plan, you can just install third-party plugins too on your WordPress.com site. It feels weird almost to some people, but you can totally do that, including WooCommerce. If you just want to use WooCommerce that you already know from some other experience, you can totally just do that as well right on WordPress.com. That's cool.

WooCommerce, a totally good e-commerce software for WordPress. Check it out. Bye-bye.

[Banjo music ends]

Chris: Speaking of principles, there's more to be had here. Here's the next one. "Progressive enhancement and unobtrusive JavaScript are my tools." It goes on here. "Without JavaScript or CSS or without mobile WebKit, my site might not look pretty but it will still be functional." That's kind of the core tenant of progressive enhancement anyway, which is, start with a totally workable version of a website and, when possible, go up from there, which is, I guess, the opposite of just use whatever; build the fancy version first and then perhaps deal with fallbacks when they break.

Zach: Yeah. The original argument of client-side rendering, which was brought up earlier, I think is another opposite of what this means.

Dave: Do you still -- like it's old and out of date -- but is progressive enhancement still sort of a core tenant of yours? I did notice on your search, on the 11ty docs, it'll actually fall back to DuckDuckGo. [Laughter]

Zach: Yeah.

Dave: It appears you're still committed to the cause, but do you see your opinion changing? I know a lot of people are just kind of like, "Yeah. I'm just going to use whatever, Next." I guess Next is actually a server-side generator.

Chris: Yeah … tool progressive enhance … instead of thinking about it from scratch.

Dave: Yeah, it seems like a lot of people went full client-side since you wrote this in 2012.

Zach: Oh, for sure. A lot of people were going full client-side back in 2012, too. It's not like things have necessarily changed since them. The same arguments are happening and the same arguments are being driven by the tooling default cases that are presented by the tooling.

Yeah, I am definitely still on board with the progressive enhancement. I think it's the best tool to provide you the broadest audience, especially when it comes to making things work with search engines. I think it's very important to have a nice baseline of content available to those.

I know Google will run JavaScript, but it's often on a delay, so it will run on a second pass two weeks after the HTML spider goes through and gets a version of your content. A lot of competing search engines won't run JavaScript, so that's a big one.

I think performance is another big one. There's really nothing that beats HTML when it comes to performance, so serving HTML is one of the best ways to get a high performing site and that's, I think, part of what I would like to see the JAMstack represent as well.

Chris: Mm-hmm.

Dave: Mm-hmm. There is that hint in the JAMstack culture. Performance is pretty top of mind for a lot of folks, I feel like.

Zach: Yeah, absolutely. We were all at the JAMstack conference in San Francisco a few weeks ago, and I feel like that was sort of mentioned in the keynote as being a big thing, trying to develop these sites for the next million or billion users or whatever. Yeah, getting those broader audiences, I think, is very important.

Dave: I guess, if you were going to build a to-do app today, would you try to start; would you type a form element posted to some PHP script? Is that where you would start? I guess I'm trying to find your limits here. [Laughter]

Zach: I think if I were to build a to-do app on the JAMstack, which I think is a nice progressive enhancement, friendly stack if you're using those tools, I think a nice middle ground would be to have just an HTML representation of your server-side to-do list. Maybe just a text list of the things you need to do, and then you progressively enhance to things that allow you to modify those to-do lists like add additional entries, check things off. You can really do progressive enhancement on a feature-by-feature basis.

Chris: It brings up the larger question of that application hollow types discussion, which is, it's interesting to talk about this stuff super broadly. There's some value there. Then there's value in scoping it down, too, and talking to, well, this is the kind of site I'm talking about. What does that mean, too?

I think that to-do thing is actually pretty fascinating. It got me just thinking just now. An important distinction here is that when we talk JAMstack, the one ingredient that we kind of don't have, we have two ingredients that we do have, which is prerendered stuff and client grabbed stuff. We can use those pretty well, but we don't really have a Web server to return HTML that did server-side stuff that well.

I could be a little wrong about that. There probably is some componentry to do that. But, at that point, you're like, what even is JAMstack if there are servers serving your HTML anyway? I would think that maybe an approach to a to-do list is that the to-do list itself, maybe you don't prerender because, say, you have 10,000 users of your to-do app prerendering all 10,000 users' to-do lists every time any of them makes a change to their to-do list. It's just a little too volatile, right? That's what stuff like PHP is for. There's no reason a server can't spit out the active to-do list of it such that it's still HTML when it comes down; it's still that fast, progressive enhancement, totally friendly thing.

Zach: Yeah, absolutely.

Chris: JAMstack is very great, but a to-do list on JAMstack, if you're not using client-side rendering, meh, it's a little weird. Then just use server-side rendering.

Something like Next.js totally does that. It can do all the fancy client-side stuff and do prerendering too, but Next will run on a Node server. If you want a JavaScript-powered thing that can send down HTML of your to-do list that's ready to go, Next is an okay choice.

Zach: Yeah, absolutely. Another interesting point there is, when I was working on the 11ty docs, I was thinking about maybe having premium tutorials or premium stuff to ID the authentication. It's hard to sort of do that, provide tailored content, or lockdown content in a static world.

Chris: Mm-hmm.

Zach: Yeah, that's a very good point.

Chris: I would think that JAMstack answer to the logged-in kind of system as, like, well, okay. There is login. There's client-side login auth stuff: JSON, Web tokens, et cetera.

Zach: Yeah.

Chris: Then there are cloud functions and cloud functions can accept your JWT to deliver certain stuff. You'd be like, "Well, don't prerender it then, but ask a cloud function for the authenticated stuff so that you're only serving it up to people with kind of a valid token." But you're talking client-side rendering there.

Zach: Right. Yeah. Yep, that's the big drawback is that there's no mechanism to do a server-side render with a serverless function without. At least not that I know of, but that would be a good offering, I think, for them to develop.

Chris: Yeah.

Zach: Yeah.

Chris: JAMstack now with server-side rendering. Hilarious. That would be weird. [Laughter] Okay, well, this is fun. Okay, we did the progressive enhancement one. Let's perhaps move to another one here.

Big, bold letters right upfront. "Simplicity is respect. I will not tax my users' brains with complicated designs and user interfaces. I will strive to make interactions succinct and minimize mental overhead." Kind of a UX one here.

Zach: Yeah, I've always sort of been a developer that wishes I was a better designer. I think, again, working with designers, I think, is very important because they're really focused on the user experience over developer experience. I don't know. This one is a little bit hand-wavy for me now but, yeah, I don't know.

Chris: I've always liked the clarity over simplicity kind of thing. Sometimes simplify-simplify-simplify begs you to delete words and delete lines. I don't know. It's kind of like less-less-less and it's not necessarily less is what you're shooting for. It's clarity. If you've got to say something, if you need more words to make it more clear, then so be it.

Zach: Maybe I just will keep it simple here and not say any additional words at this point.

Dave: That's very respectful of you.

[Laughter]

Dave: All right. Let's go to the next one. I will educate my friends and family that Web browser choice matters.

Chris: Wow.

Zach: Very topical.

Dave: Well, everything is Chrome now, so how do you--?

[Laughter]

Dave: How do you do this? I assume, back in the day, this was an IE versus Firefox discussion, almost.

Chris: Have you ever done the family member one, like literally, like, "Hey, family member. Did you know that there are other browsers out there and maybe you should consider using them"? I don't know that I ever have.

Dave: I possibly, when family members were having popup problems.

Chris: Oh, sure.

Dave: Like, "I get too many popup Web banners." It used to be a website could install its own search bar into Internet Explorer, so you'd get a little browser ribbon, almost like a bookmark bar. Then they would complain that nothing works and they get all these popups. I would just be like, "User Firefox," but I don't know. How do you feel on this, Zach?

Zach: [Laughter] I don't know. I feel like this one is more relevant now than it was back then but in a different way. Yeah, I think, originally, this was probably intended as an IE versus Chrome versus Firefox thing.

I think Web browser choice is very important. The thing that really stuck out to me on this one was the subtext underneath. I'll just read it real quick. It says, "Web browsers should, at minimum, properly implement Web standards and should be responsible for advancing the Web. Web browser choice should be separate from picking an operating system. This is especially important for mobile devices."

I feel like those last two sentences are extremely topical now because, on iOS, the server rendering engine is all tied to--

Chris: It's still locked down after all these years? It was back then.

Zach: Yeah.

Chris: It still is now. It's just becoming more in the -- I feel like mostly because Alex Russell is renewedly made about it that it's become more of a topic.

Zach: Yeah.

Dave: Really, it's been this long and we still only have one rendering engine. It's kind of funny. It's not even one. We get 90% of one because you get the publicly available one on iOS. Even Firefox has a browser on iOS.

Zach: Yeah.

Chris: I think Microsoft has Edge on iOS. It looks like you're getting those browsers, in a way, but you're not. You're getting Safari.

Zach: Right. I don't even know that I necessarily agree with Alex's critiques here.

Chris: Yeah.

Zach: It's almost as if -- consider if Apple decided to adopt Chromium or Blink.

Chris: Right.

Zach: If they allowed other browsers to implement their own rendering engines, then WebKit would be almost non-existent. If you look at Safari usage on desktop compared to Chrome, it's--

Chris: Nothing, yes.

Zach: Yeah, not quite as high. The same thing would happen on iOS. Apple, sort of maintaining this level of control, almost protects browser diversity, in a way.

Chris: I haven't heard this perspective before but I like it. I think you're right.

Zach: In that if they didn't, then WebKit would sort of be much more minimized in terms of how much power they have on the Web.

Chris: Pretty interesting way to hold onto diversity is to just hold onto the platform on that diversity. Interesting. I wonder, when you wrote this, were you almost pushing people towards Chrome and Firefox? Was it a very, very subtle dig at IE?

Zach: It's tough to kind of remember because, in 2011, Chrome was around, right? That was still a thing.

Chris: It was probably huge. It was probably the dominant browser even then.

Zach: I don't necessarily think it was about getting people to switch. It was more about, historically, educating people that choice is important and just knowing what a Web browser is, I think, is an extremely important thing for the everyday user because, if you don't know what a Web browser is, then developers have so much -- our power is minimized because people don't understand that they have a choice and they can choose what they want.

Chris: It's funny how sometimes people -- something in their life gives them a choice and then it just locks in forever. My mom just uses Firefox and I have no idea why or when that became a thing, but that's just the Web browser that she uses on her computers. She'll even go download it on new computers and stuff so that she has the thing.

Zach: Oh, nice.

Chris: But she doesn't know why, I don't think.

Zach: Yeah, because it represents the Internet to her.

Chris: Right.

Zach: That was kind of the classic problem with Windows and Internet Explorer is that the blue E represented the Internet for millions of people. Yeah, it became hard to get people to switch. I know that you always hear the story about family members installing a different Web browser and then changing the icon to look like Internet Explorer.

Chris: Yeah. [Laughter]

Zach: People didn't know that it was changed because the Web browser, for a lot of people, is just a window; no other changes to that window.

Chris: Yeah. It does the thing. It does my job to be done. I wonder. Do you have any predictions on the next kind of major movement in the browser landscape? Do you have a gut instinct on what's going to happen?

Zach: I would love it if we had more diversity than we have now. I feel like, inevitably, if a big change is going to happen, it's going to be Firefox is going to adopt Chromium, which would be sad.

Chris: That's a heck of a prediction, but I feel like it's the most clear right now. It doesn't feel like that's in the water, to me.

Zach: Yeah, I don't think it will happen but, if something big does happen, that will probably be it.

Chris: Yeah. Yeah, weird-weird-weird. Okay.

Zach: Yeah, I don't like it.

Chris: What's the next one, Dave?

Dave: "I believe in the power of the open Web. My content was accessible when Flash Flex apps were popular and I will continue to provide accessible device-independent content in the face of app store ubiquity."

Zach: Yeah, I don't know. This one is kind of interesting because it pre-dates progressive Web apps, I think, before that was even coined.

Dave: Yeah. I guess you're still anti-app store in this dichotomy. [Laughter] How does progressive Web apps change…?

Zach: I mean that's a strong way to put it, but yeah. I wouldn't say I'm anti-app store. I would say that I'm probably more just pro-Web than I am anti-app store, but you know.

Dave: Do you feel like the open Web has been preserved or do you think we're starting to lose it? I'm thinking of things like Electron. I think every app I use--Visual Studio Code, Slack, Microsoft Teams, even my mail client--are all electron apps under the hood - Notion. Are we losing the open Web for these native-ish clients?

Chris: Isn't it kind of good that they're still Web, though, or are you saying that's kind of like a--?

Dave: I think so.

Chris: Yeah.

Dave: But you can't tinker around. You can't inspect style sheets.

Chris: Yeah.

Dave: You can't override with your own style sheet.

Zach: Yeah, I don't think the Web is any more threatened by those than anything else. Historically, there's always been full native apps and there will always be full native apps and things that are controlled by app stores. Those don't necessarily threaten the Web. If anything, it's better for the Web if those are built with Web technologies because it improves the tooling around Web tech as a whole.

Chris: Right.

Zach: It's sort of investing in the developer tools around those, so I don't think those are threats to the open Web. I think that Flash was definitely a threat to the open Web, historically.

Chris: Flash, Flex; I barely even remember was Flex was.

Zach: [Laughter] Yeah, Flex was -- at the time when I wrote this, I worked at a big, giant IT company. It wasn't an IT company, but I worked for a major railroad that had a big IT department. This predated me working for Filament Group. Yeah, one of the big things that they wanted to do back then was that they were entertaining the thought of moving everything from open Web tech to proprietary Adobe, Flash, Flex apps. They had all the vendors come in and do the sales pitches. It was a whole thing. I'm really glad they didn't because Flex was retired a couple of years after that. It was kind of ridiculous.

Chris: Oh, gosh.

Zach: Yeah, I think that big companies, it's good for big companies to invest in Web tech, even if they want to do it on native apps, because it gives them a little bit more safety net when the proprietary tech comes and goes.

Chris: Yeah, that's the strength of the open Web, isn't it? Y'all come and go, and we're still here. [Laughter]

Zach: Yeah.

Dave: [Laughter] My website has been broken for seven years.

[Laughter]

Dave: But at least I don't have to rewrite it every three years when the platform updates.

Chris: Yeah.

Zach: You just need to update it to https.

Dave: Yeah, well, it's easier now, holy cow, compared to 2012 there.

Chris: I wonder if this JavaScript stuff is saving us, in a way, that there are so many developers that are so into it, they invent solutions based on it. They're like, "I don't want to write a native app. Can't I just write it in JavaScript somehow or whatever," and just be like, "Okay, well, we'll figure out some way to port it to native then, I guess."

Any of the latest players write it with Web technology but get a native app out of it are, in a sense, JavaScript-powered. Flutter is that way and all this Ionic stuff is that way. I don't know if that's technically open Web after that point, but it's nice that people still need to Google Flexbox and they still need me.

[Laughter]

Zach: The number one search result.

Chris: Yeah. [Laughter] But, yeah, a lot start on the Web and then get -- I feel like the tech of the Web is stronger than almost the Web itself.

Zach: Yeah, absolutely. I don't think that -- yeah, a wider base. It's not a fixed size of pie, right? We can grow the pie in the native space and grow the pie in the Web space as well. We can help each other in both ways.

Chris: Is this the closest one that leads to some IndieWeb thinking? I think of you as somewhat associated with IndieWeb because you've kind of gone a little further with the--I don't know--own your content, own your tweets, self-publish everything.

Dave: He has Web mentions, Chris. This is the Zach--

Chris: I know. You're one of … people with Web mentions, so--

Zach: [Laughter].

Chris: If anybody is IndieWeb, you are.

Zach: [Laughter] Oh, my God. All right, yeah.

[Laughter]

Zach: Yeah, I think that if I wrote this today, I would probably put something into here about owning your content, having control over your space, owning your URLs, and owning your domains. Yeah, I don't think there's necessarily a specific bullet in this one about that. This was really sort of before; I don't want to say it's before social media got really popular, but before social media started ruining everything.

Chris: [Laughter] Owning your URLs is nice. I'm glad you mentioned that because that is interesting. You use Web tech to build some other thing that doesn't have a URL. You're like, that's interesting and it's, "Go, Web!" but that's a different kind of threat. We're not talking about a threat to the Web. We're talking about a threat to URLs, which is a scoped threat, in a way, which is under fire from all sorts of different angles all the time. There's just nothing more worth protecting than that, to me. I don't even care if the underlying technology changes, but the URL, that's got to stick around.

Zach: Yeah, URLs are definitely sacred and they're certainly under attack. I think I had a section on that in my JAMstack talk as well, JAMstack conference talk, how they're just sort of being minimized by mobile browser UX, how they're sort of trying to design them away to improve--I don't know--user education around what URLs are and reduce phishing. Another one is proprietary tech like Amp where the technology enforces what sort of URL that your content can live on or maybe injects their own additions into the URL to advertise the framework, I think, is strange.

Chris: Yeah.

Zach: Yeah, when you have a tighter coupling to the URL, I think it's pretty dangerous.

Chris: This next one says, "I acknowledge that performance is critical. My own developer hardware is not representative of the real world and we must be mindful of limited hardware, poor latency, and low bandwidth situations." Gosh, I don't think you could go to a performance talk today that doesn't cover these. It's been a lot of years now to the point where I think if you were a more skeptical person, you'd be like, "I am a little bored of the performance talks that tell me about the existence of bad phones in the world," not that I think anybody should stop because I feel like it's an important message, but have you ever seen a performance talk that isn't like, "The next million people have $42 Android phones." It's the same message today as it was when you wrote this, probably.

Zach: Yeah, it's very similar. It hasn't changed. The gap between the top and the bottom is probably growing at this point.

Chris: Yeah. I think you're right.

Zach: Yeah, the underlying point, I think, has held up, for sure.

Chris: That's tough. I'm sure you are aware of these, like, "Let's do cap my bandwidth Wednesdays and black and white Thursdays," and stuff like that. Do you think that's kind of an effective tool?

Zach: I mean it's more about advertising to your team and getting your team excited about working on performance and getting them experiencing the site with a terrible connection or terrible hardware or whatever. It seems like our developer hardware is getting better and better and better and the real world hardware is sort of staying the same if not getting worse.

Dave: I don't know, man. I have a $500 GPU in this computer here, so I'm pretty sure phones can do it.

[Laughter]

Zach: You're running those 3D transforms on your GPU right now?

Dave: Oh, yeah. Yeah, every website is in 3D, actually, if you could pick enough GPU.

Zach: [Laughter]

Chris: This is a little aside, but I almost notice how poorly computers perform on a slow network. Even my desktop machine, which I have one of these, like my own developer hardware is not representative of the real world. Mine is not. This is this top of the line of MacBook that you can get, other than apparently this new 16-inch model that dropped that, of course, entices me greatly. It's a premium machine, you know. At my office, I have fiber Internet as well, so literally can't possibly be a better situation for looking at websites or really doing any sort of computing. If something weird happens with the network, like there's some wi-fi outage or it gets weirdly super slow or something weird is happening, the computer itself is problematic. It's like Windows drags slower and there is more beach-balling. The whole computer behaves badly. It's not that it just takes longer to download a JPEG or whatever. Isn't that weird? I don't know what's happening there.

Dave: Too many farts in the engine.

Chris: Yeah.

Zach: [Laughter]

Dave: It ran out of memory.

Zach: Technically speaking.

Chris: Why is beach-balling related to the network? I just wish that it wasn't. It makes me think of--

Zach: It all comes back to, the better our hardware gets, the more stuff we do to fill it up and the more stuff we do to use it, which further widens the gap between the top and the bottom.

Dave: What I find interesting about your performance thing is, there's low bandwidth. In 2012, I would be like, "No way. This guy is wrong. 4G is coming out. Boom."

Zach: [Laughter]

Dave: "It's going to solve the world's problems."

Chris: Yeah. Yeah.

Dave: "Data gets faster. I have an unlimited data plan. So, whatever." 4G is great when you're on it. But if you go into the bathroom, suddenly, 4G doesn't work for whatever reason.

It's just this -- I don't know. It's interesting to me or telling to me. You wrote this seven years ago, now, or almost eight years ago because I think you gave the talk in 2011. Eight years ago, and we're still having network reliability and even dips in quality and stuff like that, and I live in Austin, Texas. It just goes to show.

Zach: Yeah, so I work with Scott Jehl and he has this great point in, I think, his recent talk or maybe a recent blog post that 5G is coming but it'll probably make your site slower. I recommend looking that up. It's just like the same discussions keep repeating itself over and over and over again. We still have the same problems, but just in different ways.

Dave: Well, should we keep going? I fear we're not going to get through the rest of the tenants here. We have--

Chris: This next one is really funny. Can we just end on that one and then maybe we'll have Zach--

Dave: Yeah, we'll end on this one.

Chris: He's the perfect guy for this show. Thank you, Zach, for being a perfect guest for this show. This next one says, "I will learn at the root, not the abstraction: JavaScript before jQuery or why UI prototype new tools at all," which is great. The ones that you name are all sort of dead frameworks. JQuery will never die. It's in more than half the pages of the Internet, so there's a whole discussion to be talked about there. You know, not exactly in the limelight anymore, but the manifesto is, you know, learn the root technologies. How do you feel about that?

Zach: I think it's still super important, for sure. You want to invest in something that's going to give you a long-term benefit. I think learning one layer up from the framework abstraction is very valuable.

I think I was really dragged hard on Twitter for this because some people have seen it as a form of gatekeeping, which I guess I can understand because, when you're just starting out, you want to use--

Chris: I think that would be the -- yeah, like, who cares how you learn? You get there. You learn whatever you want. Chances are, you're not going to follow some perfect learning path anyway.

Zach: Yeah, and I definitely understand that. I think, if you're looking for a longer-term investment in your career, I think it's also important to learn just one layer up so you can kind of understand how things work and you can have knowledge that will carry forth to the next iteration of framework. Yeah, because jobs go through framework lifecycles, right?

Dave: I understand the criticism and I kind of do prefer doing the abstraction a bit first. But this is the front-end developer manifesto, or front-end engineer, I guess, but not the designer who is trying to make a website manifesto. In that sense, I'd probably say, "Hey, just get what you need to get done and be successful," but if you're going to call yourself a front-end developer or engineer, you probably do need to start backing off the abstraction a bit, jettisoning that and starting to learn the root, the source.

Zach: That's not even necessarily learning JavaScript generically. It's more like looking at the source code of the framework that you're using. For example, if you're using jQuery, look at how jQuery does what it does and then you can get some valuable knowledge from the source code of jQuery, React, Vue, or what have you.

Dave: It's been on my list of things to do but, apparently, Preact is only something like 15 functions or something like that and it's only 3 kilobytes. I've always been like, "One day, I'm just going to read it and just see what it does; try to figure it out." It's probably a bunch of … shift, operate….

Zach: [Laughter] It's very risky because that's been code golfed to death.

Dave: Yeah, exactly, but I just was kind of like, "Maybe that would be cool." I think of React or any of that as just this big thing I'll never eventually understand. When you tell me it's 13, 15 functions, it's like, "Oh, and it's only 3 kilobytes? I can maybe figure it out." Yeah, it has been code golfed to hell.

Zach: Yeah, just having the courage to open it up and take a look, even if you don't understand it, I think, is a big step.

Dave: Paul Irish had a talk from this era about reading the jQuery source code, right? Do you remember that talk?

Zach: That's a good question. I think that might have been Doug Niner.

Dave: Oh, Niner, yeah.

Chris: Doug is great. Yeah. No, I think maybe multiple people did it. I think Paul did it, too: 10 Things I Learned from the jQuery Source.

Dave: Yeah. Yeah.

Zach: Oh, nice.

Dave: A talk: Adobe Flash Player Has Been Blocked - LOL. [Laughter] Here you go. This is great. Cool.

Anyway, yeah, he just kind of goes through. It's classic. He looks like a baby in the video, but just classic. I'm going to turn on the screen recorder and just drive my browser window kind of talk, so pre-streaming sort of talk, but it was good.

He just picked up a lot of weird things like, oh, this is how this works or, oh, that's how that works.

Zach: Yeah, he is very good at that style of talk, for sure.

Chris: Thanks for coming on, Zach. This was really cool. There are more to look at here. I bet we only got through half of them, really. Maybe a little bit more than that, but I think the point of the show is, they all actually do hold up pretty darn well. Kudos, Zach, for being a good thinker for so long here.

Dave: I saved a copy of this on my desktop in case you try to change it on us….

[Laughter]

Dave: I have right-clicked, saved as.

Chris: Something to dif.

Zach:: I've already deployed changes.

Dave: Oh, no! Really?

Zach:: No, I'm kidding.

Dave: Wait. I gotcha here. We're going to getcha. It's got half of the styles.

[Laughter]

Dave: Cool. Zach, thank you so much for coming on. It is curious to see how this manifesto holds up or even--I guess we're getting into 2020 here--what a 2020 manifesto might look like. Thank you for that. For those who aren't following you and giving you money, how can they do that?

Zach:: I think the best way to give me money is to be an 11ty contributor on Open Collective. You can go to our website 11ty.io and donate from there.

Dave: All right. Long live the possum. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. Chris, do you got anything else you'd like to say?

Chris: ShopTalkShow.com.