Episode 012: Jamstack and Content Creation with Jason Lengstorf and Phil Hawksworth

Claire and Steph are joined by Jason and Phil, the most passionately pro-Jamstack duo you're likely to meet!

Released: May 31, 2021 • Length: 43:19

Listen Now Apple Podcasts Spotify RSS

Also available on Google Podcasts and Amazon Music

This episode has a large focus on the Jamstack, including both Jason and Phil's path into it. Spoiler: Phil says "tiddly" a lot.

Support Word Wrap

Interested in sponsoring the show? Get in touch on our sponsorship form.

You can also become a patron with a small monthly contribution which will help us pay for necessary services to keep a podcast running. Thanks for your support!

Support Word Wrap on Patreon

Timestamp Index#

Transcript#

Claire:

Hi.

Steph:

Hey,

Claire:

I'm Claire

Steph:

and I'm Steph.

Claire:

And this is Word Wrap.

Steph

On this episode of Word Wrap, we're jazzed to be joined by Jason Lengstorf and Phil Hawksworth. And I'm sure you are both pretty well known to most of our audience, but Jason works as a principal developer experience engineer at Netlify and works to improve the experience of building and deploying to the modern web.

He also hosts Learn With Jason, a live stream video show where he pair programs to learn something new in 90 minutes. He also spends a lot of time writing, which you can find at the very cool URL - jason.af.

Jason

It might be worth clarifying, uh, much to Phil's chagrin. I recently became the VP of Developer Experience at Netlify. And so...

Phil

Worst day of my life

Steph

Well your very cool bio slider updated. Yeah. Good call out. Yeah. That's that's important. I suppose that's important to you. Yeah, that's super awesome. And so Phil is also at Netlify and the developer experience team and has over 20 years experience crossing both agency and products. And he's currently focused on developing strategies for using Jamstack technologies to make building for the web simpler, faster and more secure.

And they're both currently involved with the Netlify a podcast called Remotely Interesting, which I have listened to and do in fact find interesting.

Phil

We've got to get that review somewhere. We've got to get that. I do in fact against all odds find it interesting, I mean that is what we're going for...

Steph

Cool. Well, anything else you, either of you'd like to add? Of course we had our important update from Jason there on the title.

Phil

No, I think, I mean, I think you, you just about nailed it there. I mean, that's, uh, I don't like to hear that number echo back at me though, the 20 years that's that's alarming. But yeah, it's definitely true that, um, I've been building stuff at agencies for, for a while, but, but now I get to enjoy kind of figuring out the lines and boxes of how we might use the various tools that we've got at our disposal to try and make stuff for the web. So, um, cos. But, so that's a fun thing that I get to enjoy now at Netlify, is good.

Steph

Yeah. Claire and I are both fans of Netlify and Jamstack. Course myself I'm the self-titled unofficial ambassador for Eleventy in particular. Um, but, uh, so we definitely have to talk about what's exciting with those. Um, and if we have time to get some insights on creating educational content and we will Word Wrap it up with what keeps you both excited about web development.

Exciting happenings at Netlify#

So. You know, we know you've had an exciting day to day at Netlify. Um, so whether it's that or something different, what, what are you kind of both excited to be working on at Netlify?

Phil

So I'm kind of excited to see with, uh, Where the ceiling is for Jamstack sites at the moment. I mean, I think, you know, I've been interested in this way of building sites for, for quite a long time because, um, I'm S I'm scared of lots of moving parts and lots of complexity, um, and lots of difficult infrastructure. I've been stung so many times by, uh, lots of complex systems. So I liked the idea of regenerating sites and then, uh, deploying them as simply as possible. But. They, that has a bit of a ceiling that I think we've encountered as the, uh, the popularity has grown. Then also like the. W, you know, the type of sites we've been trying to build with this approach has, has become more ambitious.

So seeing the ceiling gradually being pushed back for things like, you know, sites that are very, very large or sites to have user generated content, that's, that's an area that I've been kind of interested in for, for a little while. And whether that's because site generators are getting faster or the, the tooling to help you do it is getting more efficient or architectural models are evolving a little bit to try and push that ceiling up higher. Um, that's an area that I've been interested in, um, or, you know, I'm excited by at the moment. So. Yeah.

So, yeah, we've, we've been looking at, uh, a slight evolution of the jumpstart model at Netlify recently. Were talking about, um, uh, DPR, which is distributed, uh, persistent rendering, a bit of a mouthful, but ultimately it's like the long tail of, of deploys. Um, so like builds that run and build infrastructure as they have done for forever. Um, but then also being augmented by some build processes that run on request for some URLs that then persists a view in or views or assets into, into the same kind of notional deploy out on the hosting infrastructure in the same way that, you know, it gets populated at build time.

Um, Sounds really complicated when you describe it like that, but it's a build and then some functions and those functions also populate the build. That has been really fun to experiment with. So I've been having a lot of fun exploring that recently and seeing, seeing how that could, um, change the way that I might approach building sites or let me build sites that I just would not try building previously without with that kind of model. That's where I've, that's where I've been digging recently.

Jason

Yeah. Um, I'm similarly excited about, um, that I think is great. And, and really just to, to kind of span out to, to the larger concept that I'm really excited about is, um, I've really been enjoying watching teams, uh, start to find these really productive, really, uh, just unlocked sets of, of patterns and workflows that are letting them get a lot of things done.

And I, I think that you know, one of the most frustrating things about being on a product team as an engineer is when you feel like if they would just let us do our jobs, this could have been done yesterday. Like I think we've all had that conversation, right? And so one of the reasons that that starts to happen, especially as companies grow is that there are more moving parts. There are more systems that have more diff you know, different teams working on them and you need more, there's more risk if something goes wrong. And as these systems kind of grow, you get these layers of complexity, you need different people to sign off on different layers to make sure that the thing can go out safely.

And what we've been looking at is, is how can we untangle that a little bit. And how can we make it so that you don't need to deploy all the layers at once so that you don't need to manage each layer every single time you want to make a change. So the teams can just control the pieces that they need to change without creating extra risk across other layers.

And, and that's one of the things that the Jamstack architecture is, is from the get go. It was designed to do it. And with the introduction of distributed persistent rendering and, you know, the, the, the just wider availability of serverless functions, we're really starting to see that capability come in. So you can now take a front end team. And you've got a decoupled front end. You've got all your backend services are only communicated to, through a clear API layer. You're pre compiling what you can upfront. So you don't have to run a server in production. And that means that now a front end development team is capable of writing, building and shipping a front end completely on their own. And because it's only the front end and you're not touching the backend systems, you're not touching all these other layers. Then you can do that with low risk. And, uh, because it's, it's, pre-compiled, the rollback is like one button and if something goes wrong, you're like, oh, well we need to roll that back and try again. So you click the button, you roll back and then you just make another deploy. And what we're seeing happen here is that teams are getting to the point where instead of one deploy every week or every three weeks, which, you know, I've worked on teams that had that deployment velocity. We're now seeing teams deploying multiple times per day.

Um, you know, at Netlify for example, we build our core app app.netlify.com is a Jamstack app built on Netlify and that manages all of your site deployments, you know, identity. It's got our forms, database, all these different moving pieces that are very complex and it's doing a lot. We deploy that front end, probably a dozen or so times a day on average.

And I've never seen that done before in a team that's not kind of adopting this intentionally simplified architecture.

Um, and, and so what I like about distributed persistent rendering is that it's allowing for teams to keep this autonomy and this productivity while also getting into more and more advanced use cases.

Benefits of Jamstack Architecture#

So, you know, you, you keep this simplified mental model of, I have some files I'm going to build them and I'm going to put them somewhere. And that's really what the Jamstack architecture is. You've got a build step. You've got your, your CDN and you - that's it, you, you make the changes, you push it to the build step. And then that goes to a CDN and you're done. If you put your build step into a serverless function and then persist the result of that serverless function to your CDN, that's distributed persistent rendering. So it's the same mental model. You're taking some data, you're doing a build step and you're putting it on the CDN.

Um, and so now these front end teams don't have to learn a new model. They're not managing multiple layers of caching. They're not introducing all this complexity that comes in when you try to go for like a more traditional server-side rendering model. And that unlocks a huge amount of productivity and potential without introducing this additional, you know, mental overhead or additional risk or complexity and rollbacks and things. And that, and I find that really, really exciting as a, a way to just let us do more.

Phil

Yeah, that's, I'm just diving quickly back in on that, the, um, that, that idea of multiple deploys a day and, and the friction and doing it kind of re re uh, approaching zero is, is such a liberating thing. We, I, I got, um, I got quite excited when I saw some feedback from a new client of Netlify's recently where they kind of gave us some feedback saying, oh yeah, we just did our big, big release. It was really boring. And it's like, oh, that's the best, the best compliment I can ever imagine about deploying, you know, a site. Yeah. The deployment was boring. There was nothing to hap have nothing happened. Um, that's what I've been hungry for for a long time when I was in the world of "well deploying means we'll have a code freeze for three weeks."

I think, I think luckily as, as developers, these days, we're all getting just used to this, this slightly different world where we don't, we don't have to live like that. Deployments can be automated and you know, blissfully mundane. That's, that's what I'm always, I'm excited about the boring as, uh, it's an old thing.

Claire

Yeah, I think that's a really cool point too, is like, and decoupling the different parts of the deployment. Like to be what they're supposed to be like, you know, like you said, Jason, the front end, just being something that you deploy multiple times a day, that doesn't have to be like a high-risk thing. That, you know, you shipping all these new features that are back in, maybe have like, you know, PCI compliance or whatever the case may be, where I'm just trying to change a button. You know, like something like that, where, uh, cause I've been in teams before where it's like, oh, well I guess this just won't go out for three weeks because we're just, you know. So it's really cool to hear that you're decoupling that part, that process, um, as part of this. So yeah.

Jason

We just want to get away from this idea of like, it shouldn't take more coordination than development work to take a feature live.

And I think that when you start looking at these, these big highly layered application stacks that, you know, the cost to an organization, and to a team, and to an individual developer, you'll spend five minutes coding up the fix and then days or weeks communicating about that fix to get it to the right place. And I think that's the part that starts to get really de-moralizing.

So, you know, we're, we want to shorten that loop. Like you said, it shouldn't be. If, if I change a button, I have to worry about whether or not that affects our, our SOC two compliance. Right? And if we're not going to read redeploy it, whatever, you know, we don't need to redeploy a backend if all we're doing is changing a button. But with a lot of systems that requires everything has to roll out again, we've got to do the whole new standup a new full production environment and deploy the whole application, all backends included, and then do a full release management like blue-green rollout.

And that all happened because we changed one button. And as you can imagine, teams don't do that. So teams start to stack up lots and lots and lots of changes for each deploy because they don't want to go through the release management process every single time. And that means that each deploy gets bigger, which means that if something goes wrong, it's harder to trace what happened.

Like I never needed to know what git bisect did until I joined a big team with a complicated release management process. And now that I've moved back to this decoupled process, I have, I have not needed to use that. The blame view, the, or the history view of trying to determine the root cause of a problem.

Most of our pull requests are like five, six lines of code, or, you know, they touch one or two files. They've got one or two authors, like it's so much faster to figure out what went wrong and, and, and recover from that when you do have bugs than when you are doing the more traditional, like, okay, this is 15 teams with 40 combined authors doing about 6,000 lines of code in this, this week's release. Who knows what went wrong? I don't know.

Personal Histories with Jamstack#

Claire

Yeah, no joke. Um, let's talk about a little bit more of like your individual histories with the Jamstack. Um, so like I, I've only really worked with Eleventy. Actually at work um, we have a Hugo site. Uh, and, and there's just different complexities with different static site generators. So like, for both of you, like, what is your history with like the different generators throughout time? Or like maybe if you have a favorite one or whatever.

Jason

Um, so I've probably used it at least lately I've used, I think all of them at this point, just through, through my show, Um,

Phil

Whew! That's big, it? That's a big claim!

Jason

Personally though, I think I've used six. I think I've deployed my own personal websites on like I, so I've, let's see. I've done. Uh, I started out with Jekyll back in the day, GitHub pages and Jekyll. It was like the best deployment process that I could find. And then I, um, I realized that I didn't know how to write Ruby code. And so I got less and less interested in Jekyll. And I switched over to Hugo, which I'm not sure what my logic was there, cause I also don't know how to write Go code. So, um, I, I built out a nice, complicated Go process for myself that broke. And it was because I wrote bad Go code, but I didn't know how to fix it. So then I migrated over to Hexo because Hexo was an early Node static site generator. And then I ran into complexity issues with that. So I switched over to, I think gatsby. Um, and then I deployed another site on Next. Um, I've used create react app as a static site generator.

And then, uh, I've, I've recently taken to building a lot of examples using Eleventy because I really liked the idea of like, why ship JavaScript if you don't need JavaScript. And now, uh, all my sites are run on a static site generator called Toast, which is powered by Rust, uh, which I also don't know how to write code in, but the Toast part only exposes a JavaScript runtime. So you use it as a Node app, um, which is really, really nice. And it means that, you know what I like about Rust and why I'm excited about the Rust tooling space is that it's removing the... it is unbelievably fast. Like I build a 200 B the Learn With Jason site. We just had our 200th episode like this week.

And that site with its 200 episodes and all the API calls and build steps required to make that happen still on Toast builds in 20 seconds. And that is not the case if you're using Next or Gatsby or, or a JavaScript based, uh, static site generator. So it's, it's really, really nice to be able to write React code, which is how Toast runs. It's a React runtime, but get Rust speeds. It's very, very pleasant.

Steph

Cool.

Claire

Wow. That's it's bonkers just to think that like, like I could take like an index site of all the different static site generators and you've probably hit them all already. I think the Jamstack.org site actually shows all those different ones. And I'm just thinking you probably get that one, that one, that one. It's just really, it's just so funny.

Jason

I I'm a chronic tinkerer like that. That has been my downfall.

Claire

I mean, that, that's how, that's how I got my start into web development. It was just tinkering. So like I get it. I totally get it. Yeah. What about you Phil?

Phil

Power of view source. Yeah. View source is the way into web development. Or at least it used to maybe, maybe it's less. So now maybe it's a bit harder to view source because everything's being compiled and obfuscated and the rest of it and packaged up. But, but yeah, there are some definite sort of similarities. Goodness, me, it's the end of a long day for me isn't it? I'm in a different time zone. That's why I can't talk.

Some definite similarities, uh, to Jason there. Um, I, I was thinking. Yeah. My first static site generator probably was Jekyll as well. And I didn't really know Ruby either, but actually now that I think about it, I may might be able to go back a tiny bit further.

And because I used to be a contributor to a, an open source project called TiddlyWiki, which is, um, beautifully named. First of

Jason

That is the most British thing I've ever heard.

Phil

And that's my gift to you. Enjoy. We still it's still a thing today, but, um, but back in the day when it was a uh, when it was, uh, created, um, uh, it was, it's a self-contained Wiki, so it's a JavaScript and HTML and CSS Wiki that lived in a browser.

You edit it in a browser and because of a bit of a browser quirk, it would save back to its own file in the file system. It's really bizarre, but it was, it was built on top of this quirk. Uh, and as a result, you would write the code for it in TiddlyWiki in a textarea and, uh, sections or pages were called tiddlers. Of course they were, uh, and you could write content or CSS or JavaScript in tiddlers. And those tiddlers - the more I say it, the more I'm hearing myself say it, and there's no way back. Um, but those would then extend the application. So you'd be writing JavaScript in there that would extend it. It was really very cool.

Um, but that led me to, um, to, to a build process that was kind of make files and a few other bits and pieces as that evolved. So maybe at a push that was my first kind of, uh, jaunt into like templating and static site generation. But really it, it kicked off with, um, With Jekyll and writing things with, with liquid templates and, uh, of course using GitHub pages.

That was my first introduction. And that's what got me really excited, uh, about this kind of approach. And, you know, at the time I was working at a large agency that would be working with big brands, big kind of global brands who'd invested. Um, I think the official figure is gazillions of dollars in their infrastructure. Um, so come hell or high water. They wanted you to use that infrastructure. So yes, if the deadline was six weeks from now, and it took them four weeks to provision a development environment in their infrastructure then so be it. Um, so that's what I was kind of fighting against.

And it was only at the point that the provisioning time was longer. The lead time was longer than that than the actual delivery date of the project. I managed to convince it's actually Nike on this particular project that, you know, we could build this differently and we could build it with this static and static build. Because it's a marketing site. That's going to live for a small amount of time and it'll be gone for a campaign.

And the first time that they bet on that was really empowering because it meant that the, the front end team exactly like Jason was describing earlier on, they meant the front end team was completely unshackled. They could, you know, they could ex you know, exploit all of their skills. They could deploy their craft. They didn't have to have the, front-end be the output of a backend system. They could craft it the way they wanted. And so that started to get great results. Anyway, that kind of led me on to oh. Also went down the route of Hugo. Not knowing Go either, um, and battling with the Go templates, which I know lots of people love, but it took me a little bit longer to get into it.

Um, dabbled with a middleman for a while as well. And yeah, but I've more recently landed on Eleventy and like, like you all, I've become a really big fan of Eleventy because it. It, it speaks my language. Uh, you know, I write in JavaScript. I can write in the templating language I like, and it doesn't ship JavaScript unless I explicitly want it to. So all of that, I'm just, I'm just echoing exactly what's already been said. But I use that for so many things. And Claire, you were kind of asking earlier on about education as well. I find it a really useful tool for that, because if you were trying to teach a concept. You don't have to also teach all of this other kind of alright, to get to a hello world you need to have that all of these things. You can just cut right to the thing you're trying to express. And I think maybe that's why I comprehended it in the first place, but also find it a really good tool for teaching and just a very effective tool for, for making sites that, um, that you need to make. So, yeah, that's, that's been my path.

Steph

Awesome. Yeah, as I said, self appointed the Eleventy ambassador over here. And it's funny you say that I'm doing a workshop later this year, and that's exactly why I decided to go ahead and go forward with Eleventy. Cause I won't have to explain too much, but they'll get the benefits of the server and all that good stuff.

Serverless Functions#

Well, cool. You know, we've already talked about quite a few things. Uh, you've shared a lot of awesome information about Jamstack and unrelated things, but is there anything left that, like you don't think enough people know about Jamstack that you wish they would, that would either help them get the most out of it or anything like that?

Jason

I think the biggest thing is I wish more front-end devs knew how approachable serverless functions were. Um, I think that when I first looked at them it seemed like a lot. And I think my, my first experience with serverless functions was trying to use it without any help. So it was like, okay, well you write this function and then you need a bunch of YAML config. And then I need to find a cloud to put it on. And then I have to configure D - it was like, it was too much. I didn't want to deal with it.

Um, but now that more and more providers are making serverless functions, a, a drop-in. So like, for example, on Netlify, if you create a .netlify folder. And in that folder, create a functions folder. You can just put anything in there. And if it has the right format, which the format is that you literally export a named function called handler and you return a status code and a body and if you do that, you've written a serverless function. And inside of that, you can do anything that you would do with JavaScript.

And you can do these these very powerful workflows. Like you can make privileged calls with secret keys. You can't do that on the client side because you would expose that key. You can process files, you can hit other APIs. You can, you can do all of these really powerful workflows that enable you as a front end developer to start moving into the middle of the stack, to the back of the stack, without having to learn a whole new set of skills.

So it starts to really unblock you as a developer to feel like when you hear somebody described as a full stack developer, serverless functions are a shortcut to that. Because it lets you do that full stack thinking in that full stack application development, without having to become an expert in the boiler plate and deployment and scaling of servers, which is where I really think it starts to get tricky as a developer.

You know, you're when you're doing front end writing some, some business logic in JavaScript, I can do that. I get that part. Figuring out how to deploy and scale a Node server? I'm starting to feel way out of my league here. Um, and so I think that if, uh, I really want. I would love to see more front end developers start experimenting with serverless and really starting to understand just how much you can do and how far you can go completely on your own.

Um, using, you know, a front end, a front end stack of your choice and serverless functions you can build just about anything.

Claire

I think that's cool. I admittedly I haven't gotten into serverless a lot and I think the name is really funny. But I think it's really, really powerful. And especially the way Netlify does it, it removes a lot of that tooling aspect, which, you know, it's that it's, I think it's the same thing as what Eleventy kind of provides is that you, you get from making it to seeing it quickly.

Phil

Yes. Yeah. And that's, that's the thing that sucked me into web development in the first place, you know, ba - back at the times where you would view source and then you'd copy and paste things into an index to HTML file, save it and hit reload in the browser and see things like that kind of instant gratification. That's exactly the hook that got me there in the first place.

So the more you can shorten the distance between writing something and then seeing results and even even better if that's also shortening the distance between writing it and shipping it. Um, the, the more you can shorten that feedback loop, the more productive you're going to be. And I think the more inspired people get.

So, um, I think that's great that that's the way that things are things are evolving. It's amazing to me, as well as we're talking about, um, build times long, build times for large sites and, um, you know, getting up into many minutes. Um, and you know, and obviously longer than that for very, very large sites, but it's interesting to me what we will tolerate now on what we, what we think is acceptable.

You know, going back to the start of this conversation, we were talking about many weeks of deploy cycles. Uh, and so reducing many weeks to many minutes or to a few seconds is a really good direction of travel. But it's, um, but yeah, the shorter, the better because of that, that feedback loop.

Claire

Yeah. Totally agree.

Re-scoping the Jamstack Definition#

Steph

Yeah. Did you have anything Phil that you felt hasn't been shared about Jamstack related topics?

Phil

I mean, I think Jason hit pretty much the bullseye for me as well about, um, uh, on that topic. But I think one misconception that I think it's, I I'm hoping will go away soon is the idea of. And this is one of the reasons that the, the word "Jamstack" is a little bit problematic because it's got "jam" in there. So, you know, it comes from the JavaScript API add some markup attributes. If you like. I'm I'm keen for people to move past this perception that I think some people have that a Jamstack site means reinventing everything client side and building an entire application client side.

Which it certainly can be. And in some cases that's exactly the right thing to do. You know, things like, I mean, netlify.com for example, or app.netlify.com, which is the admin, you know, the admin application for all of, all of every Netlify sites. Is a client side application. It's a React application, you know, client that shipped, which is static.

And then it's, you know, is enhanced with API calls, which are obscured and personalized and all the rest of it. And that's great for a certain type of site, but you don't have to build everything client-side in that way. You know, there's, you can have Jamstack site to the house, no API calls and no JavaScript, and it's just HTML.

But it's the attribute that Jason talked about earlier on of yes it's decoupled from, from other systems and it's you get it to the CDN as fast as possible. Um, and then it can be served already. That that's, that's the key attribute. So. Yeah. I mean, I'm keen for people to, to not be muddied or kind of weighed down by this idea of, oh, I've got to rebuild all of my application stack in cli - in client-side JavaScript for it to qualify as Jamstack.

I mean, it doesn't really matter if it qualifies or not. It's a question of, can you get it to the CDN and take the hosting of a hosting of a web server and maintaining an application server out of your life so that you don't have to have a pager anymore? Do pagers still exist? Are pagers still a thing?

Jason

PagerDuty still exists, but I think, I don't think it actually has a - well. No, there are still pagers. I think, uh, I think like ops teams still carried actual pagers sometimes

Phil

See how privileged we are not having to worry about it? I don't even know if pagers are a technology that exists anymore. That's how that's how far I've decoupled myself from that.

Steph

Another great reason to push for decoupling the front end.

Awesome. I started extremely light. I, I kind of headless CMS'd into an Eleventy to sort of see what that was about. I thought that's what I wanted. And then I love that you can just kind of essentially also add on as you grow in complexity, not just Eleventy, but Jamstack in general. And of course know that Netlify supports a lot of that.

For example, I know one of my beginner web developer struggles over a decade ago was like, how do I even get a form on my website? And you guys solve that immediately. And that was, I think, just genius, you know? And so then you continue to add on like, oh, okay, well, it'd be nice to start taking payments or whatever else.

And I get - to your point, like, as a front end developer two years ago, I would not feel confident figuring that out. And now it's pop it in a serverless function and it's not a big deal at all. So yeah. All very cool, cool stuff.

Jason

Yeah. I, I, uh, I did an episode of Learn With Jason, with Thor, from the Stripe team where we were able to in like 90 minutes, And like this isn't like a sped up we, we copy pasted the things. We like started with an empty folder. We were able to build a full subscription management service where you could have three tiers of subscriptions and it took two or three serverless functions and 90 minutes. Um, it's really incredible just how far this technology has come. And, and what's really possible when you, you take advantage of, you know, the platform stuff that's out there.

Like you can, you can use serverless functions, you can use the the CI/CD features of Netlify so that you push code and it immediately goes live. And then take advantage of the, the services out there, like Stripe, where everything's just, they've done all of the PCI compliance. They've done all of the security and they just hand you these really clean APIs that we can take advantage of to say, all right, somebody wants to pay for something. Okay. I want to validate that somebody has a valid subscription before I show them something. Great. I can do all of that. And all I need to know as a developer is how to send and receive data through APIs.

It's, it's really fantastic how much has unlocked in the last, you know, just the last few years, but really over the last decade or so of watching companies like this come to the forefront.

Becoming a WebDev Content Creator#

Steph

Well, cool. I definitely want to get to our last topic because I think both of you have a really valuable, unique perspective.

Um, and so we are switching out of the Jamstack topic.

Yeah. Like I mentioned earlier, I know that, um, at least as a outsider perspective, Netlify really seems to have a focus on producing resources for the web community at large. And I know you both do conference talks and of course, Jason you'll have your own show where it literally promotes learning in public. But what would you kind of share with folks looking to start producing educational content or, you know, learning resources, um, about web development?

Phil

Ooh, that's a good one. Jason's going to have way more things to offer here, but I'll, I'll, I'll throw my hat into the ring very, very quickly in that I think one of the best ways to approach this is to get your hands dirty and experiment, making things. You know, I, I love, um, uh, building a proof of concept, learning a lot along the way, and then using that as a resource to either talk about, to demonstrate to concepts. You can, it can be the seat for so many, many things, um, and sharing what you learn along the way is, is, is really valuable.

Um, particularly if you can kind of let people understand that you're sharing your learnings, not your, like the you're the experts here. This is the de facto way of doing it because I've got decades of experience. Those two things, aren't the same, but sharing what you've learned and sharing the observations is really valuable.

And yeah, so I, I love banging my head against the wall, trying to figure out how do I solve this particular thing and having a real thing that you're trying to make, that you can then. That, that kind of grounds your ex exploration. I find that works really well. Um, but Jason has got so much more experience in, in creating, learning content. I should, I should let him, him tout his amazing, um, show.

Jason

Well, okay. So I have a few things that have, that have showed up as like themes for me. And one of them is: just show up. I think that so much of creating educational content is getting the reps in. Be there every day, doing something. And it can be five minutes, just do something that works toward this idea of learning and sharing.

Um, consistency is going to make all the difference. I've seen people who do really, really amazing work, but they only release one thing a year. They don't get as far as somebody who puts out something mediocre once a week. And I think that, you know, you can see that in the community as well. There are people who are incredible creators and you're like, whatever happened to them?

Um, and then there are people that you might kind of like, huh, I didn't didn't expect them to go as far as they did. But it's because they show up every single day and they keep creating. And so it really is a vote for a vote of confidence for, if you put in the work, you will reap the benefits of, of doing that work.

And to make that possible because consistency is hard I am a big fan of not losing your sense of wonder. I think that you should be looking for things that when you do it, you're like, wow, I can't believe I just did that. Or like, wow, I can't believe this is possible. And then when you chase your sense of wonder, don't use that as a barometer for what's worth talking about. Because I am really excited about something and I think it's really hard right up until I figure it out. And then my brain starts to say, Hm, that's not useful. Nobody needs to know that. Since I figured that out, it's clearly not useful information anymore. So keep in mind that the act of learning something is not, uh, does not devalue it.

Like once you've learned it, your ability to understand something doesn't devalue that knowledge.

And sharing it is useful because everybody is one day behind you or more on any journey that you're on, right? Like you, everybody has something to teach everybody else. And it's really important to remember that like, even if you think it's easy, somebody else is trying it for the first time and they will benefit from that thing you have to share.

Phil

I had to tell me that, to tell myself that so much when it comes to conference talks. Um, because for the longest time I'd be thinking, well, I think people know this already and yeah, to Jason's point, if you, if you're creating something for, uh, for a talk or a presentation, it doesn't, it doesn't need to be something that no one in the world or in the room has ever heard of. It doesn't matter if some people have heard of it before. I actually, I like the balance. So conferences of hearing things that are completely new to me and maybe blow my mind is completely fresh and things that I kind of knew and it reinforces like some of my opinions. I love having a balance of that, that kind of thing.

Um, but yeah, I. Th that would genuinely prevent me from writing a talk sometimes thinking, I think some people know this already, and it's a, it's a really important hurdle to get over that, that opinion I think.

Claire

That is literally something I suffer from anytime I look at something and be like, oh, I should write about that. And generally the only time that gets me, gets me through that is when I'm just angry about something. And so I'll just write it out and then I'll just hit publish, and people are like, oh, that's a really great idea. That's a really great point. And I'm like, I wish I could do this more often

Phil

It's hitting the publish button is the key, isn't it hitting the publish button. Yeah. Yeah.

Jason

I used to do an exercise where, uh, to build the consistency muscle. Um, I would set a timer for 30 minutes and pick a topic, write for 30 minutes, and I had to publish, even if it wasn't done. So for, for like a month and a half on my blog, you know, years ago I published like 200 word posts that were these snippets of thoughts. And it got me over my fear of publishing things that weren't perfect, and also got me used to the idea of, of just getting it out there.

Um, and I'm still really bad at this. I overthink things. I write way too much. I will sit on an idea for a month and a half because I'm trying to get it perfect. And so, you know, it's, but, but I think that it's. It's good to remember that half of an idea can start a conversation that will lead to finishing that idea. Whereas, you know, spinning on an idea that you're stuck on can you can do, it'll just sit in your brain until you die, and then it's better to get it out there. Right? Like have that discussion, ask those questions and, and, you know, be okay to say like, I'm not sure I have answers. I'm just thinking about this. And I'd love to hear what the community has to think. Um, it, it really does drive great conversations and great insights.

Phil

Yeah, absolutely.

Steph

For sure.

Claire

Yeah. That's a great point. I mean, this podcast started because of a Snapchat message. So like, you know, just, just something getting it out there. So I it's yeah. Great point.

Let's uh, for our last topic, um, just something real quick. I think we've kind of already covered this, but I just want to explicitly ask it. Um, what keeps you excited about building for the web? So like, what is it. What what's, what's the thing that brings you to the table every day?

Jason

I just, I just want to make people laugh. I want to make myself laugh. Like I, a lot of the stuff that I do is, is my own little terrible brand of humor where I'm, you know, doing something where somebody can blow the top of my head off with a menu or, or, you know, my, like my brain expands and there's little like corgis and toys in there. Um, or, you know, you can like bury me in boops on my, my stream or play goofy sound effects. And all of those things are, are utterly useless in the broad scheme of things. But each one of those things taught me something. I learned how to program, uh, like 2d physics for the boop drop. And I learned how to deal with sound effects. And I had to build a state machine to handle queuing.

And there's all these little things that you learn when you just try to make yourself laugh. When you, you go out to build a joke. And so building useless things doesn't mean that the thing you learn is useless. And I've really tried to like rep on that a lot is, is, you know, not everything you're going to build is going to be a big life-changing product. A lot of times you're just trying to make a fart joke, but you want to use some code to do it. So it's, it's okay to to steer into that. And that that's what keeps me moving is the idea that maybe, maybe I'll get Phil to, to move beyond the British, like "It's quite good", which is actually code for it's trash too. It's fine. Which is a, which is potentially, maybe it's good. There's about a 50 50 on whether or not it's fine.

Phil

I also want to call out just for a second that I used the words "TiddlyWiki" earlier on and the three of you were sniggering away. But Jason, Jason uses the, uses the phrase. Um, I want to, "I want to learn 2d physics for the boop drop" and nobody bats an eyelid. "Bury me in the boops". Nothing. So I don't, I don't know if this is a British thing or

Claire

You raise good points.

Phil

Thank you. I mean,

Steph

I think "Tiddly" is humorous no matter who is saying it.

Phil

I couldn't agree more with, uh, with what Jason's saying and, and, you know, and I kind of aspire to that as well. But Jason's playfulness is definitely very evident in his site I mean, he talks about the, his brain that opens up on his site. He here, he forgot to mention that when you do it, it makes a sound effect. Um, and I I'm, I'm a big advocate of, you know, an animation on the web is good if when you invoke it, it kind of makes you want to make a sound effect yourself. If you find yourself going whoop and something happens. That's great. Jason does that for you on his site? He's so he's so determined that you'll have a good time. Um, but there's, I think there's, there's a lot of value in that kind of playfulness and what have you.

But, um, but yeah, I love um, figuring something out and thinking, oh, that's, that's cool, but elegant. I I'm I'm I like to try and that sounds so worthy doesn't it? I like it to try and under engineer rather than over engineer, if I can find something that feels like there's not a lot to understand, but still solves a problem that really excites me, which is probably why I gravitate to it towards a certain kind of development than others.

But the fact that the web keeps on evolving, keeps on, um, pushing us to, um, create more interesting experiences. We're all a bit more demanding about what entertains us and what feels good on the web. That I find keeps me very interested because it keeps us all moving forward and trying to find new ways to solve, you know, uh, evolving problems and evolving challenges. So, um, that, that just means that it's a, it's a new challenge every day. And that that's exciting to me.

Steph

Awesome.

Claire

That's great. Yeah. I, I feel the same way, uh, new challenges every day, which is really cool. And if I can always sneak in a pun, then, you know, I am very happy about that. So.

Phil

You're going to have such a good time with Jason's website. Made for you.

Claire

I'll have to check it out. I've I've, I've looked at it. I think I played around with the animation, but.

Phil

It was his brain. I played with his brain for a few minutes.

Steph

Alright, well, that was, that's been an awesome discussion and, and super cool to hear directly from you. Um, both of you, we. Like I said, I'm sure you're no strangers to our audience, but it's awesome to dive a little deeper on some of those Jamstack topics. And we always on this show, particular, we enjoy hearing about the other kind of extra stuff around, you know, for your own personal developer life. So we appreciate you sharing that with us. I think we'll word wrap it up. Um, that's our pun. Um, and we'll definitely, uh, see you around on Twitter. Um, and we will be posting those links for anybody who's not familiar with you in the show notes.

Jason

Thank you so much.

Phil

Thanks so much for having us.

Steph

Thanks for joining us on another episode of Word Wrap. Be sure to subscribe on your favorite platform, or pick up the RSS feed on wordwrap.dev. You can also catch us as @wordwrapshow on Twitter. Until next time!

View All Episodes