Ep. #67, JAMstack Handbook with Colby Fayock of Element 84

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Colby Fayock. Hey, Colby.

Colby Fayock: Hey, how's it going? Thanks for having me.

Brian: Thanks for what you've done for the community, which is why you're here.

Do you want to intro yourself and tell us who you are and what you do?

Colby: Sure. I'm a UX designer and front end engineer by day, on the side I do content creation for educational materials.

That includes articles, videos, egghead lessons.

But it's really just helping others learn by doing, which has become a passion.

Brian: Excellent. Content creation, honestly it feels it's picking up steam.

We were just chatting about the Party Corgi Network, so if anybody knows about Chris and Jason who have both been on this podcast, you know that they have a network or Discord of folks who stream and write blog posts and create books, like yourself.

But it's exciting to see, especially at this time where we're all hanging out inside and not working in the office and stuff like that.

But you recently just created something, which is why you reached out and I had you on to talk about the JAMstack handbook.

So, do you want to talk about that and what that entails?

Colby: Yeah, sure. I saw that there wasn't a lot of published resources about the JAMstack, so I thought it would be a good opportunity.

I put together this JAMstack handbook, which gives an unbiased look at the ecosystem of the JAMstack, what it's good for and some of the challenges it has.

Then I have three walkthroughs to get you started, and I add increasingly complex examples.

We go through just building a simple Next.js app with Vercel, then we spin up a Gatsby app onto Netlify sourcing content from Graph CMS, and then doing an e-commerce shop with Next.js again. But then we put that on S3, and we use Snipcart for the e-commerce part.

Brian: OK, very cool. That's a lot of familiar names and projects and stuff like that for the jam, and I guess that's true around the published content.

The thing is, you don't work for a large company or anything like that.

You created this as part of your own accord and I guess your love for the GM, or the web.

Colby: Exactly.

I work for a small software shop called Element 84, which really has nothing to do with the JAMstack aside from my interests and our philosophy going into apps, because we've really bought into Serverless.

Which isn't necessarily the same as JAMstack, but they're very similar. JAMstack fits right into that concept, and we've been doing sites dumped into S3 for a while now, so it really fits well with that.

Just trying to share what I've learned through that and help that concept grow.

Brian: Also mentioning your background too, do you have a lot of experience in the web?

Did you come from a place where the JAMstack has been pretty prominent in your career?

Like, you mentioned your introduction to Serverless, but I'm curious of your introduction to the web and how you got to this place too, as well?

Colby: I wouldn't say that it's been something that has been foundational to my entire presence.

Of course I was doing simple things when I first started out on the web, like creating static HTML pages just to create a band site or something.

But I think really my first foray into this concept was working at a e-commerce company called ThinkGeek where we weren't necessarily going all in on the JAMstack approach, but it was similar, where the site was very cached on the checkout.

But then we would load and serve people through APIs, which wasn't traditional for the company when we were going through that, but it served really well and gave us that client side approach where we were able to serve that page really fast but still provide a good shopping experience.

Brian: OK, very cool. I'm curious as well, in your experience and I guess running up into this book too as well, walking through building a JAMstack project it all makes sense.

But I'm curious of also hearing about things in the ecosystem that are missing, like did you discover things that were not apparent in building this?

Colby: I think there's a lot of awesome stuff that's been going on with the tooling, but there's still a struggle to try to get some of the concepts that people traditionally get with some of the more traditional stacks.

I know at my work there's a lot of people who are Ruby on Rails fans, for instance, where you can do a ton of things like Write with Rails.

I know there are some cool frameworks coming out, like Blitz.js that builds on top of Next.

I haven't played with it yet, but part of what they're promising is that it's the Ruby on Rails for the JAMstack.

It's interesting to see, but I think we're still very young in the tooling world, and it's the same thing we've been seeing with Serverless, where I don't know if you're familiar with the Serverless framework but a while ago that was very difficult to get up and running.

But now it's so smooth to get services quickly moving up onto AWS and other providers, but I think the same thing is going to keep happening with the JAMstack.

We have some awesome things now, but I think it's going to keep growing and make it even easier to build awesome performance sites.

Brian: I remember Serverless, actually Serverless is on one of the first five episodes on this podcast.

The stuff they were doing was pretty groundbreaking.

The idea of "I know we have to amplify now which helps us get up and running with really trivial things," and connecting all the pieces together. But four years ago when this podcast started, none of that existed.

So echoing what you just said, and I definitely feel the pain of trying to do things and then punting on them and walking away.

If it's challenging or if it's going to take me a day and a half to figure out how to connect the dots, I start trying to figure out "Is it worth the value or worth the time of figuring this out? Or can I figure out how to copy and paste this thing from Stack Overflow or whatever it is?"

But I think it is true, with the decoupling of the JAMstack and you have to make the decisions and pick the different stuff off the shelf, that can be a little daunting.

I'd mentioned, I actually had an entire episode with Ohad from Stack Bit and their pitch is actually taking away that decision fatigue.

You're able to get up and running and select your tools and get into the Stack Bit studio rather quickly, to then now you're at the point where you're just editing copy at that point.

You don't have to make the decisions of e-commerce, like if everybody is using Stripe or everybody is using SnipCart, just go ahead and give me a template that already has that connected.

Colby: For sure.

Brian: So that way I can get this thing off the ground really quickly.

In your work, and I know y'all are doing it in the JAMstack, but it's not like-- Are you working at an agency, where you're doing multiple projects?

Colby: It's kind of an agency, we don't necessarily consider ourselves an agency, but it's pretty much.

Because we do contract work, but typically we'll be on one project at a time depending on the person.

Right now, for example, I'm working on a satellite tasking dashboard which gives the ability for searching geospatial data and being able to task a satellite. That kind of stuff right now.

Brian: Cool. I'm curious about your side projects then, because I imagine the handbook comes out of your experience.

I see Next/js as one of the tools that you leveraged. Are you a big Next.js fan?

Do you always use Next.js for all your things? Do You have your JAMstack, I guess, "Recipes"per se?

Colby: For a while I was pure Gatsby, and it was just because it was so easy to get sites up and running with Gatsby.

There's nothing wrong with Gatsby now, but I've really grown fond of Next.js because I feel like the decisions they're making, both behind the framework that they're building and the APIs they provide for people to build things, is very--

It just feels right and it becomes really powerful to do a bunch of things that you want to do.

So, I'm really happy with the growth that they've been having and it seems like they're really pushing hard at getting things even better, which is very impressive.

Brian: As an outsider, because I don't contribute to Next.js or work for Vercel, but it has seemed that they have doubled down on adding some of the features folks have been wanting.

So the static generation that happens with Next.js that was shipped earlier this year, I remember that issue was opened two years ago and it was almost going to be shipped soon.

Maybe it was longer or shorter than two years, but anyway, I remembered that issue because I actually watched that issue until it finally got into a proper RFC.

But that just unleashed a lot of different things that people were waiting for, because not every time you want to actually deploy an entire server to host your JavaScript app, if you are doing some simple things that just need to talk to a bunch of client side rendered things, then there's a lot of value in being able to have that static-generated stuff.

I would say that I'm a big fan of Next.js and I now have my second project I've shipped using Next.js, and I'm looking forward to continuing to take existing templates and frameworks and then quickly getting my ideas out the door.

Because I think there is a misnomer of when you're a junior engineer or you're an engineer that just wants to learn cutting edge stuff, you have one or two things you can do. You try to convince your boss or your manager to let you use the next cool thing, or you could just get really good at something and ship stuff really fast that way.

I think there's a constant need to always learn something new and change it up, but at the end of the day if something is working for you--

I look at the Laravel community that are writing PHP and stuff like that, and in my mind PHP was always like "That was the old way we did things."

But Laravel has got a very vibrant community, it's actually a very popular framework that does a lot of stuff for you and gets out of the way really quickly.

Which I highly recommend, folks, check that out if you're interested.

I don't know anything about it, but what I'm getting at is if you have the tools and you've figured it out, do it until it breaks.

Or when it breaks, then fix that one piece. I think that whole decoupling of the JAMstack, like "Yes . FaunaDB might get purchased by Google."

I don't think that's going to happen, but if it does things will change.

You'll have to migrate stuff off, but the beauty is that you could export your stuff and then host it somewhere else.

That's only one piece that has to get changed, the rest of your app is still working and functional.

It just happens to be the URL where the database is pointed to just changed.

Colby: For sure. The PHP is an interesting one, because I also think about Ruby and Rails, and it seems for a while that it was fading out.

But there seems to be a recent resurgence in people advocating for it, which is interesting, because it's still an awesome tool but I know Will Johnson, for example, is trying to put together a bunch of resources to help people learn Rails.

It's cool to see because it's still helping the community help each other's framework build the good things and the bad things about each other.

So, I think it's just going to help the overall community be better.

Brian: Yeah, it is. It's easy to say we're a very polarizing-- You're in the States, so the States is very polarizing.

It's either left or right, or it's either this or that, it's either Next or Gatsby.

And sometimes it doesn't have to be either or, it could just be "Let's just get the job done and move forward."

I didn't mean to make that a political soapbox moment or anything like that.

Feel free to have your own ideas and thoughts and push for your candidates and stuff like that for sure, but what I'm getting at is, if Ruby on Rails works for you, Ruby on Rails worked for me seven years ago.

That's my introduction into web development as a whole, and I have a soft spot for Ruby on Rails.

I don't write Ruby or Rails today, I only fix bugs when I have to. So GitHub today, it's popular, they're on Rails.

So if there's something that I have to touch or massage, I understand how it works and it's invaluable to my career because I don't work as a full time engineer at GitHub and work on the app.

But if I did make a change, I'm able to actually jump in there and be like, "OK. Just move this around."

And then get a review from the bazillion engineers that can review code in Rails code, and then learn from there.

But I guess what I'm getting at is there's so much opportunity, and we had mentioned the Blitz too, as well.

Their pitch as being the Rails for React apps, or modern JavaScript apps. I actually had a chance to play with that, and the fact that they--

I use the term "Recipes," Blitz has recipes as well.

Where you can literally just do a recipe for Blitz that includes Auth0, it includes Prisma by default, but it includes Prisma and you have up and running an application.

So what you get from the JAMstack handbook, you get that as nice little snippets and recipes within the Blitz framework.

It'd be really cool to see what you have shipped here, even shipped to a Blitz recipe, and then that way people can just be like, "This works. These are all the bells and whistles I need."

Colby: For sure, and it's great to be able to very rapidly get up and running with awesome solutions like that.

Brian: So if you don't mind, I want to talk more about the-- You have an entire section in your book which is called "The Not So Good Parts of the JAMstack."

I want to talk more about that because there are more areas, and I guess you've discovered in the process of your learning, where the JAMstack falls down as well.

Colby: Absolutely, and one thing that you were alluding to just a minute ago was the decoupled services.

You might have one front end that reaches out to a bunch of different services, and I think that was one point that Matt from WordPress argued in his blog post that has surfed around the web lately.

I think there is validity to that, because trying to manage a bunch of different sources and services can be challenging, especially with things like billing.

But at the same time, I think there's something to be said about the focus that you get from each service.

For instance, if you're using something Fauna, you're going to be sure that they're going to do their job and provide an exceptional service for a database where you can focus on the things that are important for your application.

The things that are actually special for your application, which it might not be a database if that doesn't need to be completely custom made.

Brian: How about the concept, or the build time. You come from Gatsby, and Gatsby previously had issues with build times.

I think some people have been public about Internal Gatsby build times and how they've been very long, I personally know from working with Gatsby and actually contributing that their build times can be extensive.

But just in general, when you have all this decoupling of these aspects, do you want to talk about that instead of "How do you circumvent that?"

Colby: Sure.

I think the build times are an interesting one, because traditionally some of the stacks that I have worked on, like one of the Rails projects that I worked on, deploy times were well over half an hour.

So coming from Gatsby, I know some of the comments were extremely long build times, which is rough.

But a lot of times you see those things compared against WordPress, which is pretty instantaneous, which doesn't speak towards a lot of the more enterprise solutions in my mind.

Where it's more people who might be just putting out a blog or something, and I know WordPress is more than just a blog for a lot of cases, but I think it doesn't speak to the entire ecosystem.

That said, I think it's still playing and attributing to the not yet mature tooling for the JAMstack.

Thinking about it, we're still really young into this concept, the modern concept of these static sites.

I think that's going to keep getting better, especially as we learn how to leverage other tools.

I know one solution, a lot of the build times I've seen part of the issue is the images. One solution is to move those off to something, like Cloudinary.

But I think we're going to keep seeing more and more tools that are to be able to take care of these issues, and as these issues keep becoming more of a problem people are going to spend more time focusing on how we can resolve them.

Like, incremental builds for example is a more recent one, where that's going to tremendously help.

Brian: Honestly, I can't believe I never thought of the thing like incremental builds.

I know it came out roughly sometime last year with Gatsby, It's been introduced-- I think it's introduced in Next at this point.

Colby: I think so, yeah.

Brian: But the concept with WebPack, we have the-- Just in building in general, you have the, I'm trying to think of the term where you actually have your different bubbles.

Colby: Like code splitting?

Brian: Code splitting, that's the term I'm looking for.

So you can actually code split your bundle, and the cool thing with the server side rendering is you can actually render--

You only call for the data that you need, so you can have anticipated loading.

But when you think of that and taking that to the concept of your build time, only building the pages that have changed or need updates or "Rehydration," that seems pretty novel.

But also it's nice to see that we're advancing into a new realm, because I think once you take-- Again, going back to Blitz and Ruby on Rails, if you set up the layer of people just to get involved really quickly.

The barrier of entry, solve that for people, and then that people can actually innovate in other areas.

We don't need another-- We have a whole new JavaScript runtime with Deno, but, yes, we do get another runtime. It is faster. We got that.

So now we can move forward to building on top of things like Deno and building on top of Rust, then we could build up on the stack."

I guess what I'm getting at is now we're looking at innovation on the CDN space, where you don't have to worry about "Is this going to work in Japan? Do I have to pay more money?" You're just opting into that when you choose things like CloudFlare and Cloud Foundry, or Cloud Formation.

I don't know which one is which, but one of them do that thing.

But what I'm getting at is, you don't have to over index or over optimize.

Honestly, this might be fighting words, but you don't need to learn Kubernetes.

Now that's a layer that's been abstracted away, it's cool that the kids have learned this but I don't want to spend all my day SSHing the containers and teammates and stuff like that.

Let me just benefit from Kubernetes by paying very low money to get my stuff up and running.

Colby: I think that's one of the thing that's really compelling for me, for services.

I haven't built any huge projects, but being able to leverage these services where I can get my foot in the door and start hacking around with something, but not have to worry about all the servers that maintain that for things like scalability, is very compelling.

Because if you think about it, if you're trying to run those things custom on a service, you're going to be having to deal with load balancing out of scaling, and a lot of that stuff might be a toggle of a button but it's still things that you have to worry about.

There's billing behind it, and that's what DevOps people are for.

Brian: It's funny because even four years ago, the amount of people I'd see on Hacker News that would just rebuild GitHub pages as a thing, it's a cool problem to solve but if you're looking to host your own blog and rebuild GitHub pages from the ground up, you might move up the stack and solve another problem and make other things more reliable.

Which, I'm not trying to talk down on anybody who wants to solve that problem, but I guess what I'm getting at is this.

Let's make the problems easy to solve by having the drag and drops, the one clicks, or the CLIs.

Then that way we can solve the things that have not been solved, that now we're having this problem with APIs with Chrome.

I don't know if you've run into this before, but in the JAMstack if your API is not on the same server, Chrome, the same site none thing-- You would have to allow all data, and--

Colby: I must not have hit that.

Brian: I'm not sure if I'm explaining this.

Colby: Is it the same site cookie thing?

Brian: Yeah, the same site cookie. It's something that's come up that Chrome is starting to adopt, I think in Chrome Canary.

It got shipped a month ago and now it's already the current version of Chrome that's out to everybody, but essentially what happens is if your API is not hosted on YourSite.com, but your front end is hosted on YourSite .com, then you either need to set up the cookie headers to say "It's OK."

But then that lets everything else in at the same time, so it's like the same site strict is the header that you can set up--

Anyway, it's a real problem I have today with a project I'm working on where I'm migrating an entire backend to be hosted in a way that the subdomain can match.

Anyway, long story short, there are things that we could solve like that, that would make my life easier.

But sometimes we can get stuck in the weeds, and trying to solve how to get CSS in JavaScript again, which I think it's novel.

If you have a weekend to kill on that, definitely do that. But also, help me out with this other problem. That'd be great.

Colby: For what it's worth, I still write my CSS outside of my JavaScript.

Brian: Excellent. Fighting words. Is there anything else you want to mention about the book for potential readers and listeners that want to pick it up and check it out?

Colby: I think the biggest thing is I really fundamentally believe that learning by doing is one of the best ways that you can learn any of these things.

So that's why I include three step by step tutorials to walk you through.

But I think everybody should, whether it's my book or check out some of the resources out there, definitely check out the JAMstack if you haven't.

There's a lot of great things about it.

Brian: Cool. So with that being said, I'm going to transition us to picks.

These are things that we're jamming on, things that keep us going. Could be music, food, tech related, all of the above.

Since you have some picks already, do you want to go ahead first, Colby?

Colby: Yeah, sure. My first pick is Toucan, which is a browser extension.

I think it's only available for Chrome right now, but they said that they're coming out with more.

What it is, it's a learning tool for other languages.

With this extension they randomly replace words within the web page documents, so I'm trying to learn Portuguese, for example, because my wife is from Brazil.

Little bits and pieces of Portuguese words that I can learn as I'm just browsing the web is super awesome and helpful.

I think the other one is The Social Dilemma, which is a documentary on Netflix.

I think a lot of us understand that it is a problem, but this really shows how much more of a problem it is than most of us realize with all the social media things.

It's definitely something people should check out and learn about.

Brian: Yeah, I just watched it last weekend, the documentary per se.

The extension sounds awesome, I'm actually going to check that out too, as well.

Because I would like to get better at Spanish and learn technical terms so I can give a talk eventually, but The Social Dilemma, what blew me away with that documentary is the Stanford course where they actually teach how to attract and manipulate users.

I don't know what the course is called, but there was a number of the people who are now high level execs in these companies who are focused on that problem and went through this discourse itself.

Which honestly, I wish I went to Stanford and got a CS degree and learned all the stuff.

Because I would be sitting-- Like, I wouldn't be sitting here as a simple developer advocate hosting a podcast.

I would be probably some c-level and one of these companies, but you live and you learn.

Colby: But no, that that was crazy. Being able to show the examples of real life c-levels that have went through it is just-- It just feels eerie.

Brian: No, you're not immune.

Even scrolling through Twitter and then finishing the last tweet you saw, and then going back to top to then see the same tweet you just saw again, that cycle, that endless refresh.

It's genius, yes, but also it's another reason why I don't have Twitter notifications on my phone.

I have Twitter on my phone, but notifications, I don't see them. It's usually out of sight, out of mind.

I have to train myself to check my email at certain times or check my Twitter at certain times.

Colby: It really does affect us all, because I know for me for instance, with Slack notifications, I specifically now snooze those after a certain time every day.

Otherwise I know that they realistically give me more anxiety, so I still can check my notifications from time to time but those push notifications really do impact people.

Brian: I actually turned all push notifications off completely.

Colby: That's smart.

Brian: The only thing that I do is I will have the Slack red dot, or whatever, the number.

That way, if I do see it, someone probably important mentioned me or whatever.

A lot of times it's not, but I also keep Slack on the last page of my phone too as well and hide it, so that way I have to go look for it if I need to see that.

Colby: You have to really go deep down for it?

Brian: Yeah. But cool, thanks for the picks. So, I've got two picks.

First pick is going to be Nadia Eghbal's Working in Public book. It's around her exposure in studying open source maintainers and how they manage community.

Fun fact, Nadia actually interviewed me for my job at GitHub, which is pretty cool.

We crossed paths a bit before she went off and did her own thing , but I highly recommend the book.

The book actually changed the way I even thought about open source.

My assumption has always been an outsider looking in.

Like, "Yes. I do have an open source project, but it's not huge by any means. I still do the large projects, I want to get involved I just don't know how to get it."

It's like Double Dutch. It's like, "Can I do this issue? I can't do this issue. Can I do this PR? I can't do this PR."

But it also gives you a perspective of the maintainer, which up until that book I thought I understood, because I had a lot of conversations with them, but I highly recommend checking out the book.

It's also put all on Stripe Press, which I didn't know.

I guess Stripe's new way to get authors to leverage Stripe, which is pretty cool. It's a beautiful cover.

I highly recommend you get the hardback, don't just get the PDF or the audio book.

Colby: I totally did not make that connection between Stripe and Stripe Press. I even bought the book before. Now my mind's blown.

Brian: Yeah, I know. It's a cool little service, and if I ever write a book about some thought process things that I'm going to put it there, and then my memoir. BDougie Memoir, that'll be great.

Colby: We'll be waiting for it.

Brian: Yeah. All right, everybody hold their breath. My second pick is actually headphones.

Which sounds weird, but we've been doing some social learning for my eight year old--

Sorry, my seven year old. He'll listen to this one day and be like, "I can't believe you don't know how old I am."

But anyway, what I'm getting at is they've been doing first grade from home and we didn't realize how much of a hassle it was doing the Zoom calls and having the chat happening in our living room, so we ended up getting headphones for his birthday, which are these Pikachu headphones.

One, he loves them. He keeps them in a special place so they don't get lost.

But two, we also don't have to listen to every single ki d say random stuff on the Zoom call when they're called on.

So it's actually given us sanity inside the house.

So I highly recommend if you are doing Zoom calls, have a quiet place for them, give them headphones so they can do their thing and feel like they're in school ass opposed to in school with everybody else walking around them.

We do it with our open office plans already, which probably are dying at this point.

We just do it for kids too as well.

I also want to mention too, shout out to our first grade teacher who does YouTube videos for her content instead off having kids be on Zoom all day.

If you're a teacher who puts you on Zoom all day, you need to talk to your PTA or superintendent because that's insane.

I'm super happy that we can pace the learning throughout thee day and have them watch the video and do a worksheet, hands down best path we've done.

We happened to be in a small school public school and we were about to figure that out with the teacher.

But yeah, that's all I got to say about social learning and headphones.

Colby: That's awesome.

Brian: Colby, thanks for coming on and talking about the JAMstack handbook.

Listeners, please check it out and keep spreading the jam.