Ep. #143, Jamstack’s Next Chapter with Mike Neumegen of CloudCannon

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got Mike from CloudCannon. Mike, actually, I failed to even ask how to pronounce your last name, so do you want to pronounce your last name and then tell us what you do?

Mike Neumegen: My name is Mike Neumegen and I'm a static website enthusiast, I co-founded a company called CloudCannon and usually spend all day thinking and talking about static websites.

Brian: Yeah. And CloudCannon's earliest partner, the stuff that... So I joined Netlify pretty early, a lot of folks know this already. But yeah, CloudCannon has been around since pre-Jamstack so you've seen it all at this point. Actually, I want to ask you the question what is Jamstack?

Mike: Flipped on me. Great question. It is something I'm spending a lot of time trying to figure out the answer to. I think it means a lot of things to a lot of different people. My feeling about it is rooted and comfy in the initial definition of Jamstack, where it's about pre-rendering websites and using decoupled services, and just that simplicity and mindset of static, autonomic deploy, all the files just live on the server. It's just files, there's nothing dynamic running. I just really like that paradigm and the simplicity.

Brian: Yeah. I think we're going through a... We had the Jamstack Renaissance, and so Jamstack, the term, has been a little bit more fluid the last couple of years. The original intro to this podcast was like, "JavaScript APIs and markup," and now it's a JAM. But then we lowercased everything and Jamstack became more of a fluid term because at the time static websites, that was the focus.

How can I get static sites deployed in a very quick way, and also promise uptime and security and a bunch of other stuff? But then we saw JavaScript evolve, so you've seen this evolution and I'm curious how this has affected CloudCannon and how we all are focused on what you do?

Mike: Yeah. It's been fascinating to be a part of that story. When I first came to the Bay Area there was a guy running a static web tech meetup, and it was Matt Billman, co founder of Netlify. Then the room was me, Matt, Chris, another co founder of Netlify, and I think one other person. We were just talking about static sites and Jekyll was somewhat popular during the day, but it was still this very niche community and way of thinking about building for the web.

WordPress was dominating at the time, so seeing that evolution of static websites becoming more popular, Netlify played a huge role in that. Then hitting limitations and solving those limitations and to the point where we have pretty complex applications and it's the way most new projects, the mainstream way web projects are built today is with this approach at Jamstack.

Brian: Yeah. And it's wild to see that. I mean, I witnessed an evolution as well and even back in the day, to tell people, like, "Okay. Well, what's your build tool? How are you getting this to HTML?" At the time, I guess a lot of people that weren't around at that time or it was blip in their history. But I remember distinctively when you published a Heroku unknown application, Heroku ran npm-start and you had a running server running whatever was delivered to you by ExpressJS.

There was a huge, a shift that Netlify helped champion which is instead of doing npm-start npm-run build. Before that, it was basically like it was Gulp, Grunt, Browserify, there was a bunch of other build tools that established this playing field to compete against WordPress so you don't have to get a full on LAMP stack server that you have to pay for compute per second, or bandwidth.

Now the bar was lowered for a bunch of engineers. But as you mentioned, we hit some limitations. Do you want to share some limitations when it came to doing static only sites?

Mike: Yeah. I feel like Jamstack was really a big move against WordPress in the early 2010s to 2015, maybe, because you have all this complexity with WordPress and this complicated ecosystem and all these plugins and moving parts that all have to fit together which is powerful for a non-technical user but it's also fragile. All those plugins need to work together, any single one might have a security vulnerability, you need to keep them up to date.

So Jamstack said, "Listen, let's just get rid of all of that and go back to just hand crafting HTML and CSS and prerendering it, and going back to static files and just avoiding all that complexity." So CloudCannon actually just started off with purely static websites and the way it worked was you would put static files in Dropbox, we didn't have GitSupport at the time.

It would sync it to a web server and then it would just be a live website, then you could add a class editable to any element and then a non-technical person could update that content directly on the page. There was a lot of freelance developers who were really into that, but the first limitation you hit is, "Okay, I want a website more than five pages and doing purely static sucks because if I want to update the nav, I have to do that on five pages." So that's where static site generators come in and make that repetition a lot easier.

Now I can have my nav in one file, manage that in one place, so now I can build 10 and 100 page websites with a static paradigm, and I can build blogs and it opens up a lot of opportunities like that.

But then you hit a few limits with that as well, where one is build time, particularly with Jekyll which was the most popular SSG at the time, where now if I want to build a 1,000 page website that might take a minute to build. Which every time, as a developer, you make an update and you have to wait a minute for the build, that's not good workflow.

So static site generators like Hugo introduced that, build and go, a lot faster build time which, again, extends that limit. But now you're at when you get to 100s of thousands of pages, you're hitting that sort of limit. So that's one path of limitation is just the size of the sties. The other is a static website... Well, Jamstack brought in these ideas of using APIs and JavaScript to bring in dynamic elements, and that works great but you're doing that on the client side so let's say you have an authenticated state in your nav bar and you show a profile image, you can't just show that on page request.

You have to show a blank state to an AHX request to an API, get the auth state and then bring it in. It's just showing a lot of spinners in general. So that's where serverless functions come in, to solve that limit, which Netlify really pioneered and I think made popular in this paradigm where now the pages that are static can be static, the pages that need that dynamic functionality, you can just use a serverless function to render that page. Even the whole page or have an API that will return dynamic content, so that pushes it out further and now you can build whole applications with that paradigm.

Brian: Yeah. The introduction of serverless, serverless now it's, again this feels like the standard... use serverless if you're going to build something that needs some compute or maybe some background jobs because one of the examples when I was at Netlify was caching cookies. So hey, someone wants dark mode. Now it's trivial because now the MAC let's you know they want dark mode by default and stuff like that, but it let's your browser know that you're a dark mode person so next time you come back, dark mode is always going to be default when you come on.

You store that in a serverless function, it caches that, it's stored in the user table or whatever it is. But you don't need to have a running server to basically say, "Oh yeah. Mike's back, dark mode for him." Or light mode or whatever mode it is. But there are so many of these, I normally would pass the cookie back and forth to the server so that way the client would know exactly what was the expectations.

I remember I built this app, this was as serverless was getting okay, there was good use cases, AWS Lambda was kind of the standard when it came to serverless functions. It was literally the standard because it was the first one that had mass adoption, and I built this app that told me when there was a baseball game and I called it Hustlin'.

The reason for that is I had to get on a BART and then another train, the MUNI, to get out to Netlify's office. So if there was a Giants game it would slow down my entire commute. I'd spend basically an extra hour and now the Chase Stadium is right there in between as well, so you got baseball and basketball at the same time.

Mike: Yeah. You need multiple sports added to this app.

Brian: Yeah. So it would basically send me a text in the morning, I had an app that you log in, IsThereBaseballToday.com, which I don't have any more. It would just tell me if there's baseball, yes or no. Then I needed more of that, so then I'm like, "Send me a text message through a serverless function on Twilio," then I started doing all these extra things like add serverless to a site to then check, as soon as you go you hit the client, it's already pinging the serverless function.

I don't rebuild the site at all, it's just displaying whatever is coming back from the serverless function and it was beautiful. Now we see a lot of projects, and you've mentioned the multiple pages. I remember distinctly Gatsby, they solved that problem a bit for large agencies and enterprises that need multiple pages. Gatsby has came and went during this whole Jamstack.

It's still around, you can definitely still ship stuff with Gatsby but what I'm getting at is they were always this nice, little solution for the next problem, the next problem, the next problem, and Jamstack became this larger architecture. Do you think that Jamstack isn't benefiting that now we have multiple choice to do almost anything on the Jamstack or do you feel like there's a paved path that you just solve problems?

Mike: Yeah. I'm kind of split between those. I think that evolution of new technology is necessary and really cool. Serverless functions, as you say, have opened up so many opportunities. You probably wouldn't have built that service or it would be a much higher bar to build it if you had to spin up a Digital Ocean server and manage it, make sure it was always online, and have a nodescript running.

So the fact that you can just do that with a serverless function, yeah, it just lowers the bar to everything. But it's also a slippery slope, where if the paradigm started as very clear of prerendering and decoupling, and then you add a little bit of dynamic functionality to open up some of these use cases. Pretty soon we're in a world now where there's a lot of server side rendering, which is also a good approach for particular problems, but you just expand the term so wide that it doesn't really mean anything anymore.

It's everything from static to dynamic, which I don't really know what's not encompassed with that anymore. So I think for it to have meaning, it needs to be tighter and it's not to say that other technology isn't good, it's just the talk about the trade offs that you're making at each stage and to have the word actually mean something.

Brian: Yeah. So now it's 2024, the serverless function I think actually just recently came into, I guess, conversation because now we see a couple tweets like Vercel and both Netlify have had these 100K bills, people were putting that on HackerNews. So the promise is that if you get on HackerNews your site will not go down, and that is true. But at what cost?

I think the cost that we're seeing now is if you have a bunch of compute and serverless functions, your project's architected in a way that it's going to use some compute, we're now seeing a string of tweets of folks complaining about their bill being astronomical when the expectation was like, "Hey, I can just use Netlify and it works, or I can use Vercel and it works." So do you see there's now another evolution at play today that we're seeing unfold?

Mike: I think so. That case is interesting, the Netlify one was, I think, a three megabyte MP3 file that either got DDoS'd or just downloaded a lot, which I mean it's a static file, right? So that's just the bandwidth cost, and I think the problem there is what a lot of people are afraid of. It's, "I go on this free plan and I'm expecting to pay between $0 and $10 a month, and then suddenly I ended up with a 100 grand bill and I'm bankrupt."

That's a scary thought to be on. But I think just bringing it back to your question of are we seeing a shift, I mean, any technology is a cycle and a pendulum, and if we go back one generation we start in the 90s with static websites. We go through the same sort of things, it's like, "Okay, I can only have a small website and managing the nav across them sucks.

So we're going to run a dynamic script that just has the nav live in one place and then insert it dynamically onto the page. Then you go a step further and it's like, "Well, it's only web developers building for the web. What if we could have non-technical people editing for the web?" Then you end up with WordPress and the whole ecosystem of WordPress, a complete city, and you kind of lost that initial simplicity.

So that's what Jamstack was, and now we've gone through the same thing of solving problems and edge cases, and now it's complex. There's a lot of moving pieces that all need to fit together and work together, and you don't know exactly... You're not guaranteed what's going to render if you have dynamic rendering, so I think, and I think what we're seeing, is a lot of conversations about simplicity and yearning for those earlier days of just static for a lot of use cases.

Brian: Yeah. I know I was on your podcast earlier, so you've been running this series, The Future of Jamstack. I proposed the idea, and I'm curious if you've put any more thought on this because we've mentioned WordPress a few times. Jamstack, we solve innovation, we solve the progression of how we're building on the web and now it's mainstream.

But does that mean that we need now, and Jamstack needs, a WordPress so that now we have the one, the paved path, the decision tree? Okay, I know I want this architecture, what's a thing I can install to get that fast? What's a thing I can purchase to get that the fastest?

Mike: Yeah. It's a good question, and the obvious candidate there is NextJS. It's dominating the space and it is a tool that can do everything. I think a lot of technology is bundling and unbundling, and I think NextJS is the bundle where you have a tool that can do anything from simple portfolio websites to powering an entire application, Software as a Service business.

And that's great, because now all your developers just need to know this one tool and they can work on any part of from the marketing site to an application. But a specialized tool for a particular use case is always going to be better at that use case. I really believe in going to browser standards, and I think HTML and CSS is just so elegant.

I find it hard to beat that, unless you need to go outside it for an application. I find that hard to beat for simplicity and just the elegance of building simple websites. So it really depends on what you're trying to do, but I think there is a space where we really focus and get back to just HTML and CSS. That's the fundamental of the web from day one. Well, maybe not CSS but pretty soon after day one.

Brian: Yeah. I know Brian LaRue is working on this thing at Begin, which is like taking a step back to building websites. We got Quick as well, which is focused on performance. Really we have all these different paradigms that are kind of changing how we're approaching even building React apps. For example, SolidJS completely breaks the paradigm on how folks are thinking about their performance and their component rendering and their first time to paint.

But we have a few other options when it comes to Next alternatives, and I'm curious of does the community jump from Next to something else? Or have we all solidified on Next and Next will just become the stronger base, and for anyone who wants to do more of an indie or up and coming thing, yeah, we could always just go spin up some JavaScript in HTML and then sprinkle in a little bit of framework juice in there?

It's not a definitive answer, it's more me waxing poetic, we're in interesting times and I think we can still build sites, we can still deploy them, we can still get stuff to our end users and customers. But the future of the Jamstack, which I guess I'll ask you this question, you've been talking to a lot of folks in the space, what's the TL;DR on the thought process of a lot of these innovators and the folks that built a lot of these tools for us?

Mike: I feel like this movement, we're like the paramedics and we've just got the defibrillator on Jamstack, they've just done the buzz and we're seeing if there's life there, and there is! There are people who are really interested in Jamstack and want it to exist. What the movement is about is trying to figure out exactly what that is and what that circle and core values are. We just had a panel discussing these ideas, and we sent it around, this idea of portability. So not tied to a particular hosting provider, and I can basically deploy my website on any hosting provider on the web.

Immutability, so I should just be able to deploy my site and 10, 20 years later it just exists. I don't need to make sure I'm at the latest version or fix any security vulnerabilities, and there's nothing dynamic there that can get hacked. It's just files on a web server.

So something around those two ideas. We don't have the semantics around it yet. It's still pretty early, but I feel like that's where it's heading at the moment.

Brian: Excellent. Well, Mike, I do want to transition us to picks. But how can folks find out the content that you've been doing? Particularly with this podcast?

Mike: Yeah. So you can go to TheFutureOfJamstack.org, and we've got highlight clips of all the conversations we've been having as part of the project. There's a survey there if you're interested in being involved that you can fill out. So if you're interested in Jamstack, yeah, excited to have you join.

Brian: Yeah. And are y'all going to publish the results of the survey or are you just collecting thoughts and trying to figure out what the next steps are?

Mike: Both. We're feeding it into a lot of the conversations and panels, and back and forth, but the whole idea is this is a community led movement and we're doing everything, all the conversations and decisions and everything, doing it in public and doing it as a community.

Brian: Excellent. Sounds good. So let's transition to picks, these are things that we're jamming on, things that keep us going. Could be music, food, technology related, all of the above is on the table. Speaking of table, I'll go first. I just spent a day in Portland, got back yesterday, last night, and we did a series called The Pizza Bites, so we'll have a couple of new Pizza Bite episodes where we sit inside of a pizza restaurant and talk to open source luminaries, developer influencers, YouTube stars, whatever.

Yeah, we talk to these folks just about questions and stuff that they have expertise in. Just recently I had a conversation with True, True from Twitch and TikTok, but we actually had the pizza at Ranch Pizza in Portland. I'm not very familiar with all the neighborhoods in Portland, but it's there and you can Google it. So ranch PBX does a Detroit style pizza, which anybody who's listening to this podcast knows Detroit style pizza is definitely my favorite by far.

Their whole gimmick is they provide ranch with pizza, and I've actually never been a ranch and pizza person. It's always disgusted me, there's already tomato sauce or you can have a white pizza so why put ranch on it? But this ranch was good, it was amazing, so I can definitely see dipping carrots in there or having a salad with it.

But we went there, we had the show, so I'm eating ranch with pizza and by the end of it I've eaten three slices and it's a 15 minute podcast, and I've had three slices and I've eaten all my ranch so I think I might've turned a corner. Maybe this is an age thing but, yeah, I'm down to do ranch on pizza. Definitely try it, don't knock it.

Mike: Yeah. That sounds amazing. I never even considered ranch on pizza so I'm going to try this place out.

Brian: Same. Yeah, I'm here to convert you to a new lifestyle choice. I think there's a quality of ranch situation, you can't just put Kraft Ranch on there or something like that. You got to get some homemade stuff, put it on there, and it kind of elevates the pizza. Cool. Mike, do you have any picks for us?

Mike: Yeah. I'm going to get on the pizza thing and I'm going to go Cheeseboard Pizza in Berkeley. I've only been there once and it was pre-pandemic as well, it's probably about 2018, but also I talk about it all the time. They serve one vegetarian pizza a day, that's all you can get, you can just get pizza and it'll be whatever it is that day.

So it's a pretty cool ordering experience, there'll be a big line but it's not like, "Ah, I want extra cheese and Hawaiian or whatever." It's just like, "I want one pizza," and they'll just hand it to you immediately. It's already made. The cool things on top of that are I think you get the pizza and then there's two extra slices in the box and then there's a dipping sauce as well. Just overdelivering on the expectations. Yeah. I went there once then I talk about it all the time. I need to go back.

Brian: Yeah. So I've had a history of the Cheeseboard and that style of pizza. For those who are in the Bay Area, you know that style of giving cheese on bread. Actually, Cheeseboard is a cheese shop and a bakery, and the reason for that and the reason why Arizmendi, there's a bunch of other bakeries that do this. It's because of tax reasons. Bakeries are taxed lower than pizza shops, so if you want to not be taxed like crazy to have a pizza shop, you make a bakery, you sell bread and cookies, and then you sell pizza.

Mike: Pizza on the side.

Brian: Yeah. So it's an easy way to make sure dough doesn't go bad and you can also throw cheese on it because of the Cheeseboard Cheese Shop and Bakery. But I knew a guy who owned a company called Sliver and he worked at Cheeseboard, he had a troubled youth program so he worked sweeping floors and eventually learned how to make pizzas.

Then he started this company called Sliver which is literally the Cheeseboard, but if it was a full on chain. He ended up selling it a couple of years ago, right before the pandemic. Great story, I don't know if it's out there in public, but I happen to know the guy and I'm a big fan of that style pizza in the dipping sauce. Yeah, it's unreal how good it is, it shouldn't be that good but it's amazing.

Mike: Yeah. Agreed.

Brian: Yeah. I got all the pizza knowledge so we'll talk offline about this. But, Mike, thanks so much for coming on the podcast and chatting with me. I've been successfully educated about the future of the Jamstack. Folks, check out your show, Mike, The Future of Jamstack, and keep spreading the jam.