Episode #17 - Netlify's Phil Hawksworth talks about modern front end development in the Jamstack, and his route into dev

Phil shares his career journey from classic ASP into modern front end with the Jamstack and Netlify

In this Episode

Phil is a developer experience engineer at Netlify and spends his days helping developers to build a better, modern web within the Jamstack.

We discuss how Phil went from engineering to computer science, to delivering computers in a van, to (eventually) Netlify. He shares his thoughts on the Jamstack and how Netlify is leading the charge in hosting a modern web.

Listen now

Sponsors

Want to sponsor the show? Head on over to the sponsorship page to take advantage of early sponsorship!

Resources

We mention a few different resources in the show and you can find them here:

• Find Phil on Twitter.
• Listen to Phil’s own podcast Fish and Scripts.
• Visit the Netlify website.

You can find out more about me, Rob Kendal, on my personal website, or follow me on Twitter.

Transcript

[00:00:00] Rob Kendal: [00:00:00] so joining us today on episode, check’s notes, seven episode seven, honestly, I do well to remember any episode numbers or seasons or anything, especially given that. Since March it’s felt like one long Monday, but anyway, coming up in episode seven, we’ve got the, the one and only jamstack master Phil Hawksworth who is a part of the developer experience team at Netlify as a principal developer experience engineer. I believe that the title is that, is that right? Something along those

[00:00:28] Phil Hawksworth: [00:00:28] It’s the right title, but I’m going to go with JAMstack master from now on that’s Way better. Yeah. Thank you. I’ll have that.

[00:00:35] Rob Kendal: [00:00:35] Jamstack master flash. And when he’s not being the champion of the jamstack, he’s a part time, comedian, a podcast host himself at fish and scripts, which is a much better name than the front end. I must admit. and is coauthored a book, modern web stack development on the JAMstack. So, Hey Phil, how’s it going?

[00:00:51] Phil Hawksworth: [00:00:51] Yeah. Very good. Thanks. Thanks for, thanks for having me on. Lovely introduction.

[00:00:56] Rob Kendal: [00:00:56] Thanks. We try and do our best it’s that portion where it feels slightly creepy. Cause you’ve got to go and stalk someone on the internet for a few hours before, like while you write up questions and then on other things and hope that it’s correct. Rather than just going, here’s a list of things I’ve discovered.

[00:01:10] Phil Hawksworth: [00:01:10] Yeah. And it’s difficult to say, how do they know. That’s creepy. How do they know that? On my Twitter bio. So I can’t. I can’t hide from it.

[00:01:19] Whenever someone says, Oh, part time comedian. Well, there’s just reign that in or touch. I’ve done some open mic bits and pieces and run a night and stuff like that. But, I think someone called me recently, they said, Oh yeah, cause he’s a professional comedian. No, that’s, that’s very much not the case.

[00:01:36] Rob Kendal: [00:01:36] I just, the Netlify thing’s to the side gig. Comedy’s my real passion.

[00:01:41] I’m I think from what I’ve from, what I’ve creepily discovered. I think we’ve been in the, In the dev industry for about the same kind of amount of time that, that kind of 15 to 20 years ish. So like almost code veterans, but you know, with slightly fewer medals, how did you get started in development?

[00:01:57] Phil Hawksworth: [00:01:58] yeah, so similar kind of range of time, like you say, so . I stumbled into doing a computer science degree. and that was.

[00:02:06] Rob Kendal: [00:02:06] Accidentally.

[00:02:07] Phil Hawksworth: [00:02:07] Yeah, well, I originally started, I was studying civil engineering originally and I was terrible. I was terrible at it. Just wasn’t really enjoying it. So I made a bit of a change in, did go into studying computer science. So I was very fortunate to be able to make a change kind of halfway through my, my degree then, by I had no idea what I was going to do with it. and at the time I wasn’t, I wasn’t really loving that either. Actually, this is a terrible start to, An inspiring career story. Isn’t it. It was rubbish at this was rubbish. but the point that I was studying computer science, there was no aspect of that at all. That covered web development. It just wasn’t, it wasn’t part of the syllabus. At all. this was in the mid nineties. so I graduated in 99. having not really. An idea of what I wanted to do with that. But one of the things I did discover while I was studying was, I could make HTML . And that was just as little sides site discovery and started tinkering around making very basic web pages with beautifully animated, tiled backgrounds. and all of the geo cities, goodness. And I just really fell in love with the fairly immediate response than the immediate kind of rewards you got for writing stuff in a file, saving the file, hitting refresh, and seeing results in is very different to the, to the journey of have with other languages that I was working on. So anyway, I started getting a bit interested in that and, and then left university thinking I better find a job in my first job that I was offered was actually driving a van that had computers in it. that’s the first thing that the computer science degree led me to. but thankfully I didn’t take that. I ended up working at a small software house who were putting numbers on screens for traders to trade off. So it would be working on like market data platforms and doing realtime data delivery. Which I found fascinating, but terribly daunting. And this was before the age of web sockets or long poling or Ajax, or really any sensible way of getting data to stream in real time across the web. So it was now I was putting little layers in front of Java applets that would take data out of a job. Right. But listen, displayed on the screen. He was pretty, pretty dry, but I started to get interested in doing more things with web technologies and became, you know, really, very keen on, on writing things with JavaScript. And so I kind of stumbled into more and more of the pure web development path as a results. and then did a bunch of jobs after that, but I would’ve, I would’ve killed for, for. web sockets back in the day, I’ll tell you that.

[00:04:41] Rob Kendal: [00:04:41] Java applets them were the days and they would bring back the marquee tag. That’s what we’re, that’s what we’re missing from. I would say it’s what HTML’s missing. Every time I hear someone talk about computer science degrees they all have such a rich and varied answers to kind of what they go out with them or why they did them. And, you know, some people just did it cause it was like, well it’s a, it’s a degree I’m remotely interested in computers, but I don’t get, I’ll get asked a lot of questions by kind of aspiring developers or who do you need one? And I feel like it’s a very Americanized thing that you absolutely definitely need a computer science degree, or you’ll never be able to work at Facebook and things like this, but, it’s interesting what people get out of get out of them. I think they can be quite heavy on a lot of topics that may be aren’t quite as relevant especially, you want me to do kind of front end development, you know, this, there are some useful things. It’s interesting to hear your experience about it. Did you have a particular leaning towards front or back end, have you done much back end stuff? Was it kind of primarily being, you know, I found HTML and JavaScript and off I went?

[00:05:38] Phil Hawksworth: [00:05:38] I think I’ve always been more interested in browser technologies and front end development. . I think I’ve traditionally been a front end developer. but when I was first getting into web development, it was, You really kind of went reached as far back into the stack, as you needed to make the things that you were working on work. So. I think I was useful enough to be dangerous. With various backend technologies, and woe betide any project that I would be working on that might need to scale because, it’s, it’s one thing entirely to be able to get something to to work. Well, I can, you know, I can build something with ASP classic as it was when I was doing lots of various things. And have that hooked up to an Access database with ODBC, try and scale that and be comprehensive about it. That’s a very different beast. So, yeah, my leanings were always to the front end development and then just, just enough understanding, for other levels of the stack to be able to make proof of concepts, make side projects, which. probably as a blessing that they never became successful because I would have shown the cracks very, very soon.

[00:06:43] I ended up working , in different teams where, classically I’d be working in the front ends and working out to a, kind of an API layer. with, with backend developers, on various platforms building to that layer. Over time I became much more keen on this kind of clean separation, which you don’t get everywhere. but certainly, you know, even going back 10, 15 years or so. you’re starting to see that in, in different, different stacks and different architectures. And, and that kind of clicked for me a little bit better because it felt like I could understand where the edges of my problems were. on what I had to build two, and then, then all you’ve got to deal with is the fact that browsers are all different in change under your feet. And you never know what devices that are also just that, that little wrinkle.

[00:07:26] Rob Kendal: [00:07:26] It’s like having someone hold a mirror up. Maybe it’s just that, that era, when we started. Someone hold a mirror up to your own career. I remember those days where it was like, I got into the meat and potatoes of my development in that kind of ASP 2.0. I got away from I managed to skip classic ASP, which was a bit of a, interesting beast and got straight into .Net and ASP 2. And that was all kind of post backs with this giant kind of web form thing where I was just this blunder bus of data that Microsoft we’re like, we’re just stuffing or this, into a post back.

[00:07:55] Phil Hawksworth: [00:07:55] I remember. So one of the, one of the very first talks I gave at a conference, I think I was bemoaning the stuff that comes out of big CMS’s is a particularly big enterprise CMS’s. And I forget which one I was probably grumbling about at the time. but it was definitely built on .Net. And I remember kind of pointing at that giant kind of mash of data that was, kind of, I think it was the view state

[00:08:22] Rob Kendal: [00:08:22] That was it, Viewstate.

[00:08:24] Phil Hawksworth: [00:08:24] view state attribute. And it just kind of scrolling and scrolling and scrolling pages of data at the top of an HTML pages like, well, this is something that encapsulates all of the state of the page and this incomprehensible blog and, Oh, yeah. Happy days.

[00:08:38] What a time to be alive.

[00:08:39] Rob Kendal: [00:08:39] Golden age, the kids will never know.

[00:08:42] Golden time. Oh. And how did you find your way into Netlify from, that then?

[00:08:48] Phil Hawksworth: [00:08:48] well, I mean, I bounced around a little bit. I mean, I’ve, I’ve worked in a few different places along the way. but for about nine years or so I was in, agencies. So I worked at a couple of different agencies. For six years, I was an agency called RGA who kind of a big kind of global branding agency. And there I was involved in kind of leading front-end teams. and I was, and I could say a tech director role, which largely meant I was working with prospective clients to say, okay, well you want us to build this thing? This is how I propose we’ll architect it and then, and then build this out with our team. and very often in that scenario, you find yourself working within the constraints that they bring. So they might have as tech stack already, they might have invested heavily in their own infrastructure. So you’re trying to work within those constraints . Often that’s, that’s challenging and often is over engineered . Given the projects have limited lead time’s limited budgets, and you didn’t want to reinvent the wheel every time I’ve often found that, you know, we don’t really need this giant, Kind of monolithic stack behind it. We’re serving an experience for a marketing site, which is not really going to change very often if at all. So I got very interested then in kind of static websites. I pre-generated static HTML that I could serve from GitHub pages at the time, you know? And really started to see some of the benefits when I was working as an agency of that and say, we can get something staged very quickly. We can deploy things quickly. We don’t have to worry about scaling all of the infrastructure to host it. if we do get that kind of visits that we’re hoping for.

[00:10:22] And so I started really championing that approach. and started talking a little bit about that approach, which was really out of Vogue. I mean, it was called static websites. So people were like, wow, that sounds boring. He’s not going to be what my big, big global brand is going to need, you know. Coca Cola don’t want to have a static website that sounds wrong.

[00:10:42] but I was very convinced that that was the right way to go for lots of projects. So I started talking about it a little bit of conferences and what have you, One of the things that made it compelling for me was the kind of tools that we’re starting to emerge that make the workflow a little bit nicer. So GitHub pages was my kind of entry point to that, you know, using Jekyll as the as a static site generator to turn content and data and templates into the sites and then hosting it without any hassle. but then I discovered a service called bit balloon, which was the, which is what became Netlify later on. and so I would be talking about it and saying, Oh, this is useful. and it kind of captured a few people’s imagination, I think. And so people would talk about it on Twitter. and then as a result that the founders of the company, saw that, and they were like, Oh, Hey, thanks very much. And kind of a relationship gradually blossomed over time. So, I think before I joined Netlify, I was advocating for Netlify a lot because I was really heavily convinced that this is the way that we can save a lot of headaches for the way we build sites. and then ultimately that turned into a role. Being paid, now by Netlify to advocate for that approach. Where of course immediately your credibility falls through the floor.

[00:11:53] Because, well, now you’re being paid to talk about it, right? so, so yeah, so then I joined the team and I’m now part of the developer experience really trying to. Let people understand how to get the best out of the platform. how this kind of JAMstack approach to building sites can, can benefit people, but also learning from the community of people who are out there building things and discovering where the, where the pain points are, what the limitations of the approach are, that their founding and trying to feed that back into the product team to see how we can maybe influence the, the roadmap of the project as well. So it’s, it’s kind of a two way bridge, I think someone I was talking to earlier kind of referred to it as.

[00:12:32] Rob Kendal: [00:12:32] It’s it’s interesting you touch upon that because there’s a few roles kind of popped up, I think in relatively recent terms like developer advocate and developer experience engineers and things. And I think certainly when probably we both stayed they were kind of unheard of positions, you know, but, and, and not that that long ago, I think really, you explain a little bit about your role as like a developer experience engineer, that, and kind of what it involves?

[00:12:55] Phil Hawksworth: [00:12:55] Yeah. So, so when I joined, the title I had there was developer advocate and it was exactly that it was advocating for developers and advocating for how to use the product. but that the organization was much smaller when I joined, we were about 20 people or so. And so that little team, we’re kind of part of the marketing organization within the, the company. but as we grew. We realized that it was important to, for us to move. And we moved into the engineering parts of the, the, the organization. And one of the reasons for that is that the team is made up of engineers. First of all, you know, everyone in the team has, has some experience over the years of, you know, software engineering, But also, you know, is because of that two way bridge. Like I mentioned, the fact that yes, we’re working with the community to let people know how to use the products and all those kinds of things. but also super important that we can be very, very close to the engineering of the product and understands the ins and outs of it and really what the limitations are and what the opportunities are and help the engineering team kind of grow the product as well. So being part of that for the communication is really, really important. In fact, the, what we do on our team as well is that people cycle, like they do like a rotation on the product team as well. So for like three months at a time, people will be off. not, not doing the kind of day job, but we have the rest of the time, but actually being part of the engineering team, helping to build certain parts of the product. To kind of keep you grounded and really kind of in the loop for how, how the product works. So yes, it’s. certainly, Kind of a role that’s evolved over the more recent years, I think with the different kinds of web offerings that there are and services and products that exist. certainly not the role that I ever imagined I would go into when I, when I started my started my career, but it’s just kind of where I, I ended up over time just through. The way I behaved really, I think.

[00:14:50] Rob Kendal: [00:14:50] And that’s nice. Yeah. You answered my next question, which was, you know, about kind of how much is it actually engineering focused, like hands on development, compared to our balanced out with. It’s either, I suppose, developer relations and kind of helping to still build our community. And it sounds like there’s quite a nice, you know, trade off well balanced between the two.

[00:15:09] Phil Hawksworth: [00:15:09] Yeah. I mean, the, the, the focus is in the developer relations part of it, for sure. that’s, that’s where the majority of the time is, but. It’s so hard to decouple the two entirely. and so that’s, that’s why we have this kind of rotation through the engineering team as well. and even when you’re not on rotation doing that, and when you’re, you’re doing the primary parts of the role, in doing kind of the advocacy and those kinds of things. We find it’s really important for us to still be very close to the engineering team. And to really understand, you know, what’s coming down the roadmap. what are the limitations? What are the things that we can, we can help to steer and really have a really good dialogue with the rest of the engineering team. That was a good move for us to make sure that we’re aligned very closely in parts of the engineering team. and that’s, that’s another reason why the kind of the job title kind of gradually changed from advocate to engineer developer, experience engineer. as a result of that and just to kind of reflect that and keep that, keep that, as a way that sets the expectations for others around us in the organization as well.

[00:16:06] I think it’s very easy as a developer advocate to be seen as someone who makes videos and writes blog posts. And we do do those things, but of course, it’s to be able to do that credibly, I think you need to be able to go a lot further. And that’s, that’s how we’ve tried to structure our, our, our team, within, within Netlify.

[00:16:24] Rob Kendal: [00:16:24] Feels like it makes more sense as well. Like I think when I first saw this developer advocate style role, everyone just started sticking avocado emojis everywhere. And it was like, what, what, what is it, what is this thing? Do you get.

[00:16:36] Do you do something with avocados and development? It’s like, how can I get free fruit? so it feels that it describes it more. speaking of like keeping grounded and in touch with the rest of the dev team, I can see that. is kind of about 60% ish remote, probably fully remote I’d imagine at the minute, given the, the cheeky virus it’s out there, how do you manage day to day with, with a team sort of scattered across different time zones and continents and on fully remote, how, how do you kind of manage that day to day?

[00:17:05] Phil Hawksworth: [00:17:05] Yeah. So, we were very fortunate in that , the, the company was, structured from the outset as being distributed. I mean, the, the core team is in San Francisco and you know, it was founded in San Francisco. And that’s where that’s our biggest hub, but even from the very early days as the team was starting to kind of get structured there. The company as was then realized that we’re going to need to be able to scale beyond this location. So we want to make sure that we instill the processes and the culture that will allow us to work remotely. without there being kind of a it’s the people in the office and then the other people who are on the calls. So, so the thing, one of the decisions that I think was, was wonderful early on is that, the office is closed two days a week. So even the people who work in San Francisco have to work from home. Two days a week, which just means that it, instills this kind of, The working practices of you know, being able to work remotely and communicate asynchronously and with people wherever they are. And it just kind of breaks down that well, it’s the people in the office and then the others on the remote, remote calls. And that, that really was a really useful seed that was there, you know that just kind of has grown as the organization’s grown.

[00:18:19] It is about 60% who are, who are based remotely. and we’re in, we’re in various different, different parts of the world. Now I’m the only member of my team currently who’s not in the U S a so I went from being a tech director at an agency where I was involved in lots and lots of projects, which really meant I was in meetings from dawn till dusk, to now being, my team aren’t awake , until after my lunchtime. So I get this kind of very fortunate to kind of run at getting things done before — God, this sounds terrible — before my terrible team wake up and get under my feet.

[00:18:59] no, just, just the fact that I’ve got some kind of clear head space in the mornings is, is really valuable . but then again, the flip side of that is that’s the rest of your team come online when your, your day is starting to wane a little bit. So it does take a little bit of a shift to be able to deal with time zones. And what have you

[00:19:17] I’m blessed by not having to have a commute anymore. Of course. So I, I got two hours back every day when I made this change. So I’m happy to work a little bit later into the day to make that crossover work. But. The tools now for, you know, having so much of the community around in, Slack. Conversation happening in Slack and using zoom or whatever for, calls it’s, It really made it a lot easier. And the fact that the tools that we’re building are intended to be used in a distributed remote manner as well. it kind of fits quite nicely. So I’ve really actually enjoyed working remotely, it’s been, it’s been quite, it’s been. Quite fun.

[00:19:50] Rob Kendal: [00:19:50] Yeah. I’m a remotey and I’ve been for about two and a half years, ish. And it’s,

[00:19:55] Yeah, it is a, it is a mindset shift, but I think I see a lot of companies kind of really sort of denouncing it as is the devil, but I just think. In, in the nicest possible way I think some people just do it wrong. Like they’re still trying to, they’re trying to fit the old way of being in an office and trying to jam this kind of remoteness into it, rather than kind of going, it’s a different way of, you know, the difference between like driving a car and a bike. They’re both on the road, but they do the very different skillsets to make them work

[00:20:23] Phil Hawksworth: [00:20:23] Yeah, I think, I think some organizations, some businesses are fortunate in that they. They’re compatible with this way of working. And I don’t think every industry in every kind of job, of course. Can can so easily map across. but I think you’re absolutely right in terms of the way that you approach it is really important as well. And, Trying to bolt on a new culture of now you can work from anywhere to an organization that hasn’t done that it’s very hard to change that overnight, I think, which is why I’m so, so thankful that this has kind of grown from the outsets At Netlify and I think that’s just the, one of the benefits of a, of a company that’s been founded within the last five or so years, with all of the kind of benefits of, You know, the technology that we’ve got at our disposal. but one of the things I tend to find difficult is stopping working. I don’t know how you do, how do you do with that? Do you have a good way of having a routine where you can say I’m at work and I’m done at work? Have you got a trick?

[00:21:23] Rob Kendal: [00:21:23] I think that’s one of the biggest complaints I’ve seen is that a lot of people and I, I. You know, completely appreciate that I’m quite fortunate at the end of this, this room around me for all, it does have a coat in the corner and like some shoes. it is like an office space. I can sort of come into the office, quote, unquote, and then stop and then leave. I mean, I’m guilty of like, I’ve got like mentees and I’ve got blog posts and I’m writing a course on react and blogging and other stuffs. I kind of never really stopped working at one when we’re finished with this I’ll take the laptop in the lounge watching TV with the wife whilst writing a blog post on the JAMstack and Next. So, to it, kind of, you know, that aspect of it my, my work and my hobbies kind of bleed together, but I think I’ve always been pretty good at going, right well, I’ve shut off. sort of Microsoft teams and I’ve shut off Slack and the work email. So all of that’s kind of done and I have that. And it’s done in the office in where I am now and I kind of just go away and leave. And I think some people aren’t fortunate to have those spaces. So they’ll be like sat, you know, cramped up on the kitchen table and then they never really stopped and they can’t stop. And maybe there’s some external spoken or unspoken pressure to, you know, your, you don’t have a commute maybe work later, or, you know, I don’t know. I think it depends very much on that . The sooner you can get a routine in place. I think where you go, right. It’s half, four, five, o’clock whatever you work until. And then you end the day and maybe you change your clothes or you go for a walk or you do something that, sort of delineates that. You know, working portion of the day.

[00:22:52] Phil Hawksworth: [00:22:52] Yeah. A tip that a friend of mine gave me before I started, which I did for low. I don’t do so much now actually, but I did it for a long time and I think helped me establish a bit of a routine. is a friend of mine. He said to me, Get yourself some work shoes. Wow. What do you mean? He said just a pair of shoes that you put on for while you’re at work, even though you’re going to be sitting at a desk at home and then at the end of the day, take them off. And then it’s like getting home from work and then it’s just triggers a little thing in your head that says, okay, I’m done. and so, yeah, so I went and bought myself some, some very comfortable trainers that I wear my work shoes and I only wore them for work. and I would. I was also, I mean, I mean, a spare bedroom effectively as my, as my office, but I would arrive in here and I’d put on my shoes. I sit at my desk. I was like, okay, I’m in work mode now. And. No matter what time I finished, it would be a kind of a moment of it’s like a little ceremony of slipping off the shoes. And walking downstairs and your commute is done. And that I found that really helpful, but, I don’t know. I’ve kind of slipped with the discipline of that yet, but I think it’s still instilled a habit and that kind of moment to say, okay, I’m finished now. Cause it’s so easy to let the time Time to bleed into the evenings. If you’re not careful.

[00:24:01] Rob Kendal: [00:24:01] Yeah. Oh boy, crafty little trick. That’s amazing. I just have really comfy slippers.

[00:24:08] Phil Hawksworth: [00:24:08] That’s what I, that’s what I do now as well. I’ve, I’ve succumbed to, just to. I’m I’m of a certain age and I like some slippers. Thank you very much.

[00:24:16] Rob Kendal: [00:24:16] That’s what I did. I put a tweet out the other day. And I just got some new slippers and it’s late. It’s like peak adult. And again, you’re in your twenties and you’re like, you look at people like this and you’re like, that’ll never be me. I’ll be, I’ll be too cool for that. And you’re like, well you wait kids you wait till you sort of hit their mid thirties. It’s all about comfort. You think, you know, I want some slippers while I’m sat in here all day.

[00:24:34] Now, we can’t possibly have the one and only, Phil Hawksworth, on the show without talking about the JAMstack, our, you know, more than we already have. So, am I right in thinking that Netlify pretty much coined the term JAMstack? Was it you that coined the term JAMstack?

[00:24:46] Phil Hawksworth: [00:24:46] No, it wasn’t myself. So I was kind of a, I was, I was kind of flirting with, with the organization at the time that they did, but no, that was, that was down to the founders actually. So Matt Billman and Chris Back. they, they coined the term. and. They, they did so really to help the conversation, move past things like static sites, which was, a ceiling I was bumping my head up against all the time. just people weren’t interested in hearing about static sites. and that term doesn’t really describe what we can do with these technologies. Now. I mean, a lot of things that we engage with, which you feel very dynamic, can still be hosted with static assets. cause the moving parts can be in different places now. so yeah, so they, they coined the term, and naming things is really, really hard. so in fact, even down to the spelling of JAMstack. You know, and how it, how it’s written. What’s capitalized. There’s never really been consensus about it. So, so it’s kind of ebbed and flowed a little bit.

[00:25:44] Rob Kendal: [00:25:44] You need to nail it down now, before we’re 20 years down the line with the Gif/Jiff situation.

[00:25:49] Phil Hawksworth: [00:25:49] Exactly. Exactly. Exactly. And in fact, So for the longest time, I was in the habit of writing it with capital J, capital A, capital M, and then lowercase stack. And the reason for that was because, you know, the, the word came from. A JavaScript API’s and markup being kind of these. These three key, pieces that would enable sites that are hosted statically to do so much more. Now you can do so much with JavaScript in the browser, in the runtime of the browser, and you can access APIs. either third party or first party APIs or browser APIs. so those are all kind of things that have given rise to the name. However, I very quickly, when I start to describe to someone what the JAMstack is, have to then walk that back and say, but you don’t have to use JavaScript and you don’t have to use APIs because, really the biggest kind of game changer here is the fact that you pre generate the sites. And then that means it can be served very simply from a static server or directly from a CDN, even better without having to perform logical operations on some, some server infrastructure, per request.

[00:26:56] So it’s the kind of pre baking and then serving things as assets, which is really the fundamental game-changer of the idea. So that immediately means that JAM in capital letters, just adds a little bit of confusion to people, when you start to talk about it, So now you see, you see the word now written with just a capital J. I mean, I’m undoing all of that work now by immediately unpacking this. but a while ago I made a small change on jamstack.org, which is a site which tries to describe, you know, what the JAMstack is and the benefits and those kinds of things. I thought I’m just going to make it a little sweep and change the naming on there to be as if it’s a proper noun. And, people noticed to people certainly noticed and like, why, why are we doing this? And it turned into a big discussion, which actually was really healthy. You had a long discussion on like a good GitHub issue about it and figured out what works for people and what doesn’t. And we decided that this is the way that we will refer to the term. but you know, it’s the, the meaning is the most important thing and the idea of pre-generated things so that you can serve them much more, much more simply.

[00:28:03] Rob Kendal: [00:28:03] It’s much nicer as well. There’s so many different tools, like that embrace, it like Gatsby and Next and even like 11ty basically anything that just sort of, like you said, pre-baked this dynamics stuff into just the static you know, front end and it’s so it’s so much nicer that you can do an awful lot of sites, even something you wouldn’t think. So like, e-commerce, you can do a lot of that with, you know, this, this statically generated stuff and it’s more secure. It’s it’s harder for it to be tampered with. And it’s a lot more robust because you know that what you’re doing locally. Is going to be, what’s generated really on the, you know, stuff up somewhere. You don’t have to worry about several other environments with sort of semi duplicated server running code. You can sort of go with this is the static assets. We can stuff them anywhere. And they’ll be served.

[00:28:48] How does Netlify fit into that?

[00:28:50] I mean, I must, ashamedly said I was slightly later to the JAMstack and Netlify party, I only learned about it maybe sort of two and a bit years ago, which has plenty of enough time,

[00:29:00] Phil Hawksworth: [00:29:00] That’s no, that’s not late to the party. I don’t think that was late to

[00:29:02] Rob Kendal: [00:29:02] I felt I was late enough cause I was in the university of York at the time. And I had, which is where I found out about you because I had a, junior front end developer, Dave Hill, under me, and he was kind of talking to you about various things and he was, he was, he was, he was all over it and I was kind of, why is this thing you’re talking about, and he was, ‘oh it’s static sites’ and then what the hell is Netlify? Cause you keep using it. Are you, do you work for them now? And I kind of discovered it and now everything I do is kind of hosted on bloody Netlify. So I cause it is really good. So I mean, you know, you can describe it as like it’s a static, well-cached kind of host for these static sites, but I feel like it’s doing a real injustice with everything else that it does. So where does Netlify fit into the JAMstack?

[00:29:41] Phil Hawksworth: [00:29:41] Yeah. So, so really. Netlify as kind of a glue layer. the two main pieces that you could perhaps think about what we do is we operate a kind of a global CDN, which is a content delivery network. So in other words, a network of servers around the globe that are optimized for serving. Static assets. Pre-generated data assets in the same way that like somebody like Akamai was a CDN is a big enterprises. And what have you. so we operate our own, our own CDN, but then behind that we also operate. all of the continuous integration, continuous deployment infrastructure as well, that can run your build for you. And then take the output of that and then distribute it to our CDN for you. So the idea being there that allows you to create this nice workflow, around. making your changes to your code, wherever that may be an either pushing it to us through an API or pushing into your code repository and then we can watch your GitHub repository for you. So whenever a change is made there, we can say, okay, we’ll run another build for you. Pull the code from your repo pull any other data sources that you might be requesting at build time as well. So whether that’s from a decoupled CMS or. putting in tweets or assets or what have you. Running those in a build in like a sandbox build environment that we create for you per, per build output, goes to the CDN and then you’re done. and really the idea is that since we’re pre generating all of these sites, our build time, each of these deployments then becomes what we call an immutable atomic deploys. So every change becomes an instance of the site. It has its own URL that you can address. and that is all deployed to the same. hosting infrastructure, the CDN. So you get all of these nice advantages from this JAMstack architecture this way, because. Since it’s not a set of moving parts and it’s, you’re not mutating or changing the state of the server. You’re just creating a new instance of the site. Every time you change your site, you get a new URL, which means you can roll back to previous versions instantly as well. And anything that helps me eradicate mistakes that I can and will and have made. I’m a fan of that. it really is intended to create this really productive workflow kind of sitting on top of your git workflows that developers are familiar with to be able to quickly make changes. Push them to the hosting environment and get them out into the world. So that you don’t have to manage caching and all of those other bits and pieces, because it’s, it can be, it can be commoditized across our infrastructure for you.

[00:32:12] Rob Kendal: [00:32:12] And you give so much away for free with it, which is, you know, brilliant. I mean, I think I’m in the free plan. Once you get like 300 build minutes a month, which is. It’s just incredible, you know, and SSL and all the other extras, extra stuff that Phil’s mentioned that is absolutely epic The best killer feature though, if you’ve never used Netlify before, the best thing it does, I think is, the forms. Which sounds like such a small part but forms are, if you can have the best, most staticky static site in the world, but when you have a form, you’ve got to do something with it because he’s got a post it somewhere. And ultimately that’s going to be some kind of server or an API to process that form. You know, if you want like a contact form and that leaves you with a quandary of what do I do? You know, you’re into like something fancy, like a send grid API. which I’m using it for a random e-commerce client, but something like that, or, a PHP script or some thing, like I said, that’s a bit more servery or some kind of integration, but what Netlify does is it just, you just stick a random HTML form on a page and Netlify goes, ah I see you’ve got a form there I’ll handle that and without anything else of your own devising, you just stick a HTML form in, and give it a post to the same page. Netlify catches the post, the actual submission to the form. And then goes, Oh, someone’s submitted this form. What would you like to do with it? And tells you about it. And I just think that’s such a killer feature.

[00:33:31] Phil Hawksworth: [00:33:31] I think it was really smart by the team at Netlify to say, well, there are so many sites that could just very well be pre-generated and you don’t need a server for, but the first place that you. Bump your head against the ceiling is ah I just need a registration form. And the notion of having to create an entire hosting stack to be able to serve that, that you then have to maintain and secure and scale and all of those kinds of things. So you can have a registration form. Is is just overkill. So. So, yeah, exactly as you described our build box as we call them. So the, the, the kind of instance that runs your build since it’s generating your HTML for you and sending it to the CDN, we can spots form elements. You do actually have to add one attribute to it. You have to say, put a Netlify attribute on it, just so that we can go. Okay. But that’s a, it feels like a fairly, fairly small lift to do that. that does get stripped out as well. So by the time it reaches the CDN, that attribute is gone. So it’s completely unobtrusive, but yeah, it does mean that we can create an API end point for you and then do things with the data when it comes in for you. So. Hey, that saved me a lot of times, you know, I’ll get Slack notifications of. posts coming to my, to my form on my website for kind of inquiries and things. And I had, haven’t had to maintain a server for it for forever.

[00:34:49] Rob Kendal: [00:34:49]

[00:34:49] What advice would you give or would you recommend to people if they want to venture into this kind of Jamstack and the static sites?

[00:34:56] Phil Hawksworth: [00:34:56] although there are so, so many tools that you could use the nice thing is that you can find a tool that suits the way that you currently work. So it’s not, you know, we don’t need to say, ah, if you want to be able to build a Jamstack site, you have to use Jeckll or you have to use Next to you can, you can use whatever I would tend to think more about what is the, what is the user experience we’re trying to create? So what kind of application are we building. Some types of sites lend themselves without even too much thought about that, too. To being hosted on the JAMstack kind of architecture. things that are more viewing sites than doing sites, as I sometimes like to think, you know, sites that you, you read information rather than you’re manipulating a lot of information. You certainly can do both of these things with JAMstack, but in terms of newcomers, wanting to try it for the first time, any kind of blog or documentation site is, or marketing site is a very, very good for for JAMstack sites. And then you can extrapolate out to all kinds of things afterwards, but to get your feet wet for the first time, finding a, a good candidate site to work on is, is the, is the, probably the key. But then when it comes to choosing the tooling you want, well, that’s that’s really, when it comes down to what’s going to create the kind you like. because I know that lots of people like building things with react and using the kind of component model that you can get from a development. environment. Great that can output statically pre-generated HTML CSS and JavaScript that you can host I have my own favorites, but that’s a, you know, that’s, that’s the, that’s the way that goes. Everyone does. And my favorites changed from time to time. I’m really enjoying eleventy at the moment.

[00:36:42] Rob Kendal: [00:36:42] it gets, gets a lot of good press and rightly so, it’s so flexible and simple.

[00:36:46] Phil Hawksworth: [00:36:46] It’s it’s nice. Cause it’s it. Doesn’t try to do too much. And that’s the, one of the things I like. I like tools that don’t do lots eleventy is. It’s made with JavaScript and also in terms of installing the various dependencies. That’s nice and simple. but ultimately it turns content and data and templates into HTML doesn’t bundle any JavaScript or anything else it. if you want that, you can roll it yourself and you build that in as well. But I like the fact that it just gives me the thing that I asked for. You know, if you, if you prefer working in, in Vue, they’re a static generators, built on top of Vue that you can absolutely use, like Nuxt. if you’re a Ruby person, you’ve got Jekyll, you’ve got other bits and pieces. So it’s, it’s, it’s almost overwhelming. There are hundreds of static site generators, and I have a feeling that, that almost became like the, the, the new kind of, to do app kind of examples. Oh I might use a static site generator. Oh, this isn’t exactly what I like. I’ll build my own. And so I lost it. I’ve but I think that’s one of those dangerous threads to pull because you know, building a good static site generator can be, could be, it needs a lot of thoughts, but there are so many to choose from that you’re bound to find something that suits the way you like to work. I think.

[00:37:55] Rob Kendal: [00:37:55] And actually my, my last question here on the roster is, what what’s on the horizon for Netlify? I any, any spicy features on the roadmap or is it all kind of closely guarded secrets?

[00:38:05] Phil Hawksworth: [00:38:05] Well, there, there, there are a few things that I’d love to tell you about that. I can’t yet. Well, what a lovely tantalizing thing that is to say But there, yeah, there are a few interesting things coming down the pipe soon, but, we recently launched build plug-ins, which not everyone might have a. I’ve dabbled, with. Yeah. but ultimately that, that is reaching other parts of our build infrastructure that you wouldn’t normally be able to. So now, without a build plugin, what happens is. We’ll check out your code, go run your build for you in this kind of build container that I mentioned. And then the output goes to the CDN with build plugins. What you can also do is access bits of our infrastructure before, during and after the build. So. That gives you access to things like a build cash as an example. So we could, before your build runs, go off and get out, get the content from different data feeds. And cash those. So that, that stays between the builds as well. And we could cache the assets that come out to there. So kind of gives you a route to doing things like incremental builds and all kinds of exciting things and you get also get access to a load of other kinds of utilities as well. So that’s, that’s kind of interesting. People are building things with build plugins now.

[00:39:15] But the one that’s closest on the horizon, which isn’t out there yet. but we did do a small preview of it. Is, edge handlers. So. These are kind of like serverless functions, but they run at our CDN edge on request. So again, that means that we’ll be able to do all kinds of interesting things just extending the JAMstack model a little bit and starting to do some request handling at the CDN edge. So that might mean, for instance, you could perform any logic you want based on that HTTP headers that you find or manipulating the HTML that’s being returned based on, different attributes. So it really is extending beyond, you know, the core of JAMstack, but still happening within this kind of CDN hosted world. I’m really excited about edge handlers. It’s gonna, it’s going to open the doors to all kinds of exciting things. And that’s, that’s a quote, unquote, coming soon. We’ve done like a preview. You can see that , on our blog. . There was a preview at the last JAMstack conf by our CTO who, who showed a demo of that. So, I’m excited for that release, which will be, would you be coming

[00:40:19] Rob Kendal: [00:40:19] And a lot of that top secret features that we can’t talk about. But stay tuned. Oh, anything you want to, anything else you want to plug?

[00:40:29] Phil Hawksworth: [00:40:29] Oh, I think we’ve covered all sorts of things. One, so you’ve very generously mentioned Fish and Scripts, the podcast I do with my friends, that’s, that’s still knocking around. We’re gradually , trickling more of those out. into the world. The dev-ex team at Netlify also recently, started a podcast of our own called Remotely interesting. which you can, which you can find, uh, on the netlify.com site via our blog. You’ll that’s kind of fun. It’s a nice, there’s a team of about six of us chatting about the kind of things that we’ve talked about here and a few other bits and pieces as well. And that’s. check that one out, I feel like now that I’m doing anything on a podcast, I need to be telling people to like, and subscribe.

[00:41:04] Is that what I do? Rob you’ll know? Is that the right thing to say?

[00:41:07] Rob Kendal: [00:41:07] smash that like button.

[00:41:10] That’s much smash that like button it’s. I get the idea. It’s. I’m too old for that, mate. I’ve Look listen, don’t listen whatever you’re like, that’s not the attitude.

[00:41:20] Tell us what you don’t like. We will do less of that.

[00:41:22] big thanks to Phil for coming on the show. You can find him kicking him about twitter on Phil at Phil Hawksworth, you can find the Fish and Scripts is the best name. I’ve come across for podcasts at fish and scripts. on Twitter. you can even venture to Phil’s on website, which is hawksworks.com. that is Hawks. W O R x.com cool spelling like it, needs a few more ‘z’s in there, that. just to tip it over the edge. I’ll link all these things in the show notes and I’ll, I’ll put the, the Netlify’s, dev, what’d you got remotely interesting in, I’ll put that podcast in there as well. Yeah, cause it will be, is that, does that feature the, the superstars you have over that? Like a mrs. Drasner and Jason Langstorf?

[00:42:03] Phil Hawksworth: [00:42:03] Yes. So that’s that’s Sarah Drasner, Tara Menicsic, , Cassidy Williams, Jason Langstorf , those, those are the core on there at the moment with myself, but, uh,

[00:42:14] Rob Kendal: [00:42:14] Excellent. See all these Twitter celebrities go and listen to them. It’ll be great.

[00:42:18] Phil Hawksworth: [00:42:18] Well, I don’t know, but, uh, it certainly, uh, certainly a bit of a giggle.

[00:42:21] Rob Kendal: [00:42:21] Thank you very much and, uh, have, uh, fun with your top secret features.

[00:42:25] Phil Hawksworth: [00:42:25] Thanks, Rob. Thanks for having me on. I appreciate it.