June 29th, 2022
Length: 60 min
Everything you always wanted to know about Jamstack (but were afraid to ask)
Learn what exactly Jamstack is, how it evolved over the years, and how it fits in your day-to-day development process.
Who is this webinar for:
- Full stack developers that want to explore the concepts of Jamstack pre-rendering and decoupling
- Everyone who knows the term but is unsure if the benefits are worth it
- Automation freaks and DevOps enthusiasts
- Agency owners that do not want to fall behind industry leaders
What you're going to learn:
- What Jamstack is
- How it changed over the years
- Pros and cons of implementation
- Where and how to start the Jamstack adventure
04:07 What is Jamstack?
08:22 What are edge functions?
11:23 How Jamstack differs from other tech stacks
14:09 Biggest pros
19:23 Rebuilding legacy websites
20:53 Cons of Jamstack
28:03 How to convince your manager about Jamstack
36:27 How to start your adventure with Jamstack
43:44 Favorite SSG or framework
Hello, everyone, welcome after a short break we had. And that's why we are back. And we decided that we will start after this break with something really great. So today we are going to talk about jam stack. And we'll answer all your questions that you have. And while I know a thing or two about JAMstack, because, yeah, it's, it's cool. It's interesting, it's all over the place. But I decided to invite someone who is so much better than me, not only in JAMstack, but also when it comes to doing PowerPoint presentation. Because Cassidy is also mean such an amazing person when it comes to creating PowerPoint presentations, if you ever had the chance to see her skills, really. And so Cassidy, tell us a few things about yourself.
Sure, I cannot speak as well for my PowerPoint skills. But thank you. For context. I did a PowerPoint once that basically just made it logo spin the whole time. And then I went into live coding so very professional. But anyway, my name is Cassidy and I'm a head of developer experience and education at Remote and I also do developer experience. With OSS capital. I like open source web dev and memes. That's that's a good enough overview, right.
I think. I think Lego too. I see.
That's true. That some Legos got some keyboards.
Yeah, yeah. So yes. And my name is Maciek Palmowski. I'm your one and only so favourite, by the way, because there is no other host here at Buddy. And yeah. And so before, we will get started with talking about, about jamstack. Let's see what we'll learn today. So first of all, learn what is jamstack and how it changed over those years. It maybe wasn't a long history, but they've already changed a lot. What are the biggest pros and counts of this approach? Because, yeah, there are no silver bullet, sadly, sadly, and how to start your adventure with Jamstack. Because there are so many ways to do it. So it's, it's really not not easy to pick the the best approach. So also, if you like our webinars, don't forget to press the subscribe button on YouTube, you will be always informed about all new webinars that are incoming. And like I said, we are full of energy after this break. So there are some really cool, interesting coming in soon. So okay, let's, let's start with that basic thing. What is this JAMstack?
What is Jamstack?
Great question, because I think the what is it? And then the how has it changed kind of is intertwined? Because it has, it has changed so much. So when JAMstack was first coined as a term, I forget the year I want to say 2015 2016, but don't quote me on it or
something like this, because I was I also had this problem when I wrote about and how changed over over those years. And I so Oh, but these are only few years.
No, no, it's very interesting.
What are edge functions?
Great. So the edge is not the Edge browser, as as one might think. But the edge is a concept of CDN that that has, again is not new. But it's definitely evolved and is a lot more accessible now. Where, with CDN, when you host something that's a content delivery network, you are getting just a web page from somewhere, you don't really care where it is, it was built up front and you just kind of get it you don't care where it is, when you are calling an edge function or pulling something from the edge of a CDN, that means it is getting the node that is closest to you geographically speaking, and depending on the provider that you use, that could be that's kind of vague on the one that's closest to you. It could be the city that you're in, or it could be the zip code you're in, it could be the country that you're in, kind of depends again on the provider. But that means that things can be served to you even faster, because it is physically coming to you faster and closer and stuff. And that's kind of been the latest trend with JAMstack is rendering things with Edge functions.
Yeah, and and as you said, the most coolest part will be rendering edge functions in Edge browser, right.
There you go. That's the most the most meta thing.
But you could you could build something with rust, it could be built with any. Yeah, kind of like you say it. That's why it is no longer capital J A M stack. And now it's more just like jam stack with.
Yeah. By the way, the way how we spell this, I was even wondering just just a few minutes before, I was wondering, like, what, a bit differently. Yeah, what what happened, but I went to the official website, jamstack.org. And I saw, okay, right, J rest is small.
So I think that that transition is fully complete. But it was definitely very confusing for a while because we're like, wait a minute, I thought this was a specific stack are acronym and stuff. And the capitalization change is so minor, but it's trying to illustrate that it's not just like, this is specifically what you have to use. It's like the philosophy and architecture that people
How Jamstack differs from other tech stacks
Which is, which is totally different. When we think about different stacks, like for example, this LAMP stack, typical technological stack and technologies. Yeah, exactly. And, and I think that this is also one of the biggest things that how Jamstack differs from from many others, that it's mostly about the way how we are doing things rather than which technology we use. It's, I would say that, at least in my opinion, though, one of the most important things behind behind Jamstack is the fact of all those different technologies being decoupled from itself, you can interchange everything at any point. Rather than when we look at, for example, the website built in, let's say, Wordpress, we have this, this monolith that is built, and changing some parts like which database we would like to use, it's almost impossible when it comes to JAMstack. If our database has an API, it's simple. One day, we were using, let's say markdown files next day, we connected it to notion because it has an API or whatever we want, or we can connect it to workers that also has an API so so we can change all those small pieces of our of our of our application with ease.
Right? Well, and that's another illustration to kind of describe the decoupled nature is, if you have some kind of Castle, you could have like a knit castle that you made with it with where you where you intertwine all of these different pieces of yarn, let's say, or you could have a Lego Castle, where you swap out bricks by bricks in a typical structure, and I would argue that you could do like monoliths style things with JAMstack. But in a typical non decoupled architecture, if you want to change something in the middle of this castle that you have knit together, you would have to undo all kinds of different threads and stuff to be able to get to that part you want to change and then re stitch everything back together. Whereas with a Lego Castle, you can kind of swap out a brick much more easily. And that's kind of the power of of leaning on decoupled API's from your user interface is that if you want to change some kind of database, kind of like you just said, you can just switch it, it's just switching which API that you use, and hopefully it shouldn't cause too much of a rewrite for the rest of the codebase
Yeah, probably. I mean, if it does, as in Lego, sometimes we have to put put out a bit more of the bricks to get on we need but still it's much better rather than just getting rid of of the whole set just to pick 1 little brick. Yeah, so we are already talking about this headless thing. So this is one of the biggest biggest pros when it comes to jam stack we are not so tied up to a technology we can we can interchange it much more easily. And what are the other biggest pros of going going jam stack use it rather using jam stack? Yeah, you going jam stack? I said probably just so we could Yeah,
Right, do you follow obey? I think the biggest the biggest pro, for me in particular is well, there's a few different ones. But this one that that comes to mind is because you're not server side rendering anything, you're not querying a server for information, it's just already built. It's much harder for your site to be bogged down and, and just kind of tanked because of too much traffic. And that was actually something that a real world example A friend of mine, her startup was working with a bunch of different streamers. And they decided to convert their website from a server side rendered website to a jam stack style website, where it was basically just a glorified HTML page that was rendered with a form and they wanted people to fill out this form. And they were working with some very popular streamers, and eventually worked with one of the most popular streamers on Twitch. And he said, followers, everybody go here right now and fill out this form. So I could send you stuff. And normally, when you have a server side rendered application, you imagine that's going to slow down to a halt, and eventually the site will go down. For them, the site didn't break a sweat, like, yes, there's bandwidth costs and everything. But it did not slow down or anything because it was already pre built on a CDN. And they're just like, This has never happened to us before. Typically, we're just like, Okay, we'll brace for traffic, and then hope we can like redirect people and load balance and everything. You don't have to do that, in this particular case, because there's no server to worry about it just their site ran without any sort of issues. And actually at jamstack conf. I'm not sure if it was last year or the year before. Someone similar did that. And I am butchering the exact people. But it was it was folks who are gathering data about COVID, and about the pandemic and illness and everything. And they used this architecture. And even though they were having 1000s of hits a day, to the point where millions of people were visiting their website, their site didn't break any sort of performance rules that like it, it just worked for everyone. And so I think that's that's honestly the biggest pro because if you know that your site isn't going to go down. Because some server somewhere goes down because of traffic because someone is is DDoS in you or something to that effect. That's enormous. That's that's such a big pro.
Yeah, that's That's true. I mean, I think I remember the case you mentioned about this COVID website, or maybe there was another because it was kind of a similar case, especially during the start of the pandemic. And I remember that one case it was, yeah, it was jamstack and database was Google, Google Spreadsheet, hosted somewhere, and it was just rebuilt every 10 minutes or 15 minutes. And that's it. I mean, it's really difficult to take down a server that only has one thing to do serve HTML website. And also, if we cover it up with CDNs, or things like this, it's it's almost impossible to do so I'm, in worst case, the Cloudflare itself will have some problems, right?
Depends on how you do caching and all that, you know. And I also think, to what what's nice about this is because you are building your website, it's it's very, it's almost like a state machine where every time you build your website, it's like a new state of that website. And so let's just say you do have a bunch of people hitting your website and you realise Oh, no, I made a typo or something is wrong, because it's state, a state of the website, you can just revert to the previous state immediately. And that like that's the joy of atomic deploys, and that's what that's called where every single time you create a build it is this atomic node where if I want to rollback I just say this is the one that I want to roll back to and it immediately pulls that up and then doesn't have to rebuild the site to that previous version. It just existed at that point in time and for site maintenance and again for quick reverts and stuff. That's that's so huge and awesome.
Rebuilding legacy websites
Oh, yes, that's, that's true. Because let's be honest, building websites is one thing about maintaining them. This is this is the longer part and taking much more of our time, and it's less fun, let's be honest. And I would also add that when it comes to one of the biggest pros is the moment when you have to rebuild some very old legacy website that is just so old, and so legacy it's like covered with virtual webs. and everything gets, it's like horrible. But the only good thing that that it has, it has the possibility to share us an API and share an endpoint so we can get the content. So we can still use this website and use some framework that we prefer the language that we prefer. And that just fetch the data from this website and give it the literally new coat of paint, fresh coat of paint. And it's like, literally this this time, because we are just putting the new frontend, it's still using the old engine. But it will work. It will.
Rebuilding websites is easier when you do it this way. Because, again, it's good query and date of when you need to.
Cons of Jamstack
Exactly this separation of front end and back end. In such cases, it's, it's very useful. It's very useful. And but what about counts? Because? There? Let's be honest, there are no silver bullets. Yeah, I mean, yeah. From Poland, we are always trying to find things we don't like and yes, we I just like it.
I get it. And I think I think that is where it? It depends. It depends on all kinds of things. And I see that Andrew in the chat said, Could you use the jam stack with the LAMP stack. You don't want to use a server. But some people want to use servers. And so depending on the language that you use, you might rely on servers and stuff. And so this is just an architecture that doesn't really make sense for you. A lot of times if you want to do personalization of your websites, and granted, the edge rendering stuff is helping with that. And so this might be something where we laugh at Sunday saying like, remember when we thought personalization was hard. Right now, personalization is kind of hard with jam stack stuff, because so much is built upfront. And so you need to figure out your you need to think more about when do you want to personalise something, how do you want to hydrate a particular page, and you have to think about that, that extra layer. And also, if you are more of a back end person, this could or could not make your life more difficult. And once again, it depends on how comfortable you are with servers, how comfortable you are with front end, for a front end person, I think it's particularly great because I never want to think about servers. Again, I want to be able to just put the files built on the internet, and then query things and not have to think about it. But if you are dealing with monorepos, if you are dealing with a legacy system, kind of like you say, or if you're dealing with just things that you want to be server side rendered, for particular, things that you want to be server side rendered, like personalization, or, gosh, there's so many cases that are just escaping my brain right now, to that effect. That is that is where the cons come in. Because it's it's something where when you render something on the server, you do get the benefits of like having the database right there and having it all built at once on that front, if you are comfortable with that. And if you like having everything queried there, that's that's something that you just don't get as much with the jam stack. And I say as much because again, the whole edge rendering thing is new and and fancy. And I'm still learning it myself.
Yeah, but still I mean with. I see also how many frameworks are changing, because for example, Gatsby, it's really started as a static site generator. And now it's changing more and more, to be more like nextJS. So all those server side rendering options, more more things when it comes to using all those API's in a dynamic way. Yeah, I mean, as you said, it was it was mostly static site generators at the beginning. And right now, all the all those static things are getting more and more dynamic, which is it's really,
It's old, but they only recently did their v1. And they only recently started supporting all kinds of edge stuff. And also, Zack Leatherman, the creator of it only recently started working on it full time. And so you're right. It's old, because it's been around for a while. But it suddenly is making a lot of changes to be a modern thing. And again, has someone working full time on it now. So that's why I kind of keep an eye on it. Because I've seen a lot of people pick it up saying, actually, this is exactly what I need. And Zach also did a demo recently, where he basically talked about how he was using this edge function style things to render images and use that in different static regeneration, which is basically rendering things on demand, but then caching it to be a part of the build. And his build times went from like, something like an hour to to like less than 13 minutes. So some, something wild like that, where it. It was such a testament to this style of building, then I'll be curious to see how it evolves.
How to convince your manager about Jamstack
Also, it's worth noting that Zach was always a total freak when it comes to web optimization and everything. He's very good. I I first learned about about him when he wrote this amazing article about how we should serve those first party fonts. Yes, or which method should we use. And it was like a Bible on how to take care of this one small little piece of web serving fonts. And I remember that the updated constantly amazing work, and we can see that the approach didn't change, he is still optimization is one of the most important important things, things. And yeah, we talked a lot about those cool things or less cool things for for developers. But there is almost always one more problem. It's called the managers. Because quite often when we come and say, Hey, we have this new cool technology, it's called, let's say, Astro, and we would like to test it and the manager will, of course, first ask how much does it cost? It's free. So okay, but the next thing will be how much time we will have to spend or something like this, because managers doesn't like to introduce new stuff. So how to how to try to convince them to that the jam stack is, is a really good thing to learn. Maybe even not as the as the primary thing, but to have it in your belt of, of skills to use it together with others with other things.
Yeah, I think that and especially the said, there are so many materials for free, I think that some managers should be interested that it may be, it may be a really, really good argument. Why, why to start? And yeah, but still I the things that I quite often hear because I'm I'm mostly from the WordPress environment. Always remember that. One of the biggest arguments against was this fact, this was originally about the fact that everything is so decoupled, that in WordPress, we can have everything in one place, we can manage everything. And that is cool, because we have that we have total control. And when it comes to JAMstack, we, in many cases are have to build this application in one place, we have to have our database or databases, because it's kind of natural to have many sources that comes to our website. For example, yeah, if we would like to use forms, maybe we'll be using, like Netlify forms, which is also a third party tool, and there are so many so many third party tools. So we are losing this control. And what do you think about this?
I totally get the argument. And I think that's something where the and I've seen this argument and so many talks and fireside chats and blog posts and stuff there. There's pros and cons. And I think it really depends on your team, where do you want to be all or nothing. If you want to use WordPress, you can use headless WordPress very easily with this jam stack style of things. But let's just say you don't like how WordPress does forms. Just to use your example, with when you're using WordPress, you can kind of try to hack it to use something else. But if you use a more decoupled thing, you can just choose the form provider that you want. If you are using something headless, like I'll just use headless WordPress, and you want to use a database, you can choose whatever database you want. And if you don't like it, you can change it. And it kind of because it's separate, it gives you the flexibility. I think someone needs to create a startup to consolidate billing for all of these different things. Because you could either have one really massive WordPress bill or you could have just a bunch of smaller bills depending on what you're using with. And I think that that's one as featured as a one product. So it will look almost the same. I mean, this this was because for me to think that it was a bit strange, because there were many freelancers who are raising this topic, and I felt that this problem is a bit more I would say that more enterprises should have this kind of the problem because I know they are control freaks and I understand them because if you are a big corporation,
you want to be in control of all your data. And on the other hand, I don't see that corporations are having, or the big companies are having problems to start using catalyst because they are, it's even better for them that they can use one API for one website, one mobile application for like, everything. So the problem that seems to be so enterprise is mostly raised by freelancers that just shouldn't care about that so much with
the multiple services thing is more of a business problem than a developer problem. I think JAMstack is much more that the concept is much more developer first, because developers are picky, and like to change their minds and decide certain things. And so this gives them the flexibility to do so. But if I were a freelancer, I could see it being like, I have to specialise in so many things to build this one thing, and that can be frustrating. But you could also think of it as I have all of these tools in my tool belt that I can use to solve a problem. And it doesn't have to be just I'm a WordPress specialist or something to that effect. I specialise in all of these different things. And I can custom tailor make an application for you with these various tools and pros and cons. Once again, I will always say it depends for something like this.
How to start your adventure with Jamstack
Oh, yeah, that's, that's, I mean, you just mentioned one thing about the business side, I mean, having all those things are all parts of our website. The database is stored, let's say on notion here, we have something else. Yeah, it can cost a bit more, rather than having just a small server. That is true. Yeah. Once again, depends on what you're building depends. Exactly, exactly. Okay, and if you would start again, your adventure with Jamstack, like, how, how could you do it?
That's a good question. I am a big fan of react. And so I I've been using React since 2014. So very old. And I think I, if I were to start my adventures over again, a lot of times when I look at jamstack, I'm just like, this is just web development. It's not anything particularly fancy. Because once again, it's it's older technologies, or rather proven technologies, just that was more easily access edge functions. And that type of stuff has been available for years. But it's been very expensive and enterprise focused. And so it's more about easy access, I would probably say, I would be more flexible on tools, rather than going all in on the React side. If I were starting over now, because once again, I'm very comfortable with React. If you need me to build something with React, I can do it. I can kind of do that with the VUE, sort of do with solid js. And so I would probably be a bit more, a bit more not even open to new technologies. I was I would experiment more with new technologies are starting over.
and you win, then you're in the in the unknown, and you're like, Oh, no. Have you ever played the game code in the dark with with folks?
No, I didn't.
Yeah, but I never knew this game. But then it really sounds really good. Sounds amazing. At this point, if someone asked me to write something in CSS, I'm just like, oh, do I have to? Want to I don't want to I mean, I don't know hex colours at all. I mean, you you but I don't,
I don't know hex colours willingly.
Favorite SSG or framework
Yeah, and one of the last questions that I have. If you would have to pick a framework or a static site generator, what would be our top three? And why?
Yeah, yeah, exactly. I mean, because, like we talked about before, and I mentioned that JSX is not my thing. I just don't like it. But, and when I saw the syntax of Astro, when you're just, it's like, almost HTML, almost HTML with only few lines of something extra. It's, it's nice. And yeah, now on second place, I would put Eleventy Yeah, Eleventy does the same reason I really like the optimization part and everything. And the fact that they they're using those the syntax like Liquid with like something like this, which, for me, it's so similar to using twig or, or all those PHP style
There was a live stream that I saw recently, within the past couple of weeks from front end horse, where they interviewed the team of Netlify, because they just rewrote their entire homepage. And like the website, and it looks good, and it's got cool animations. It's got like Easter eggs in there. If you do Konami Code and stuff. It's cool. And it was all made with Eleventy and GSAP. And so it has all these beautiful animations and stuff. And it's so cool, because I think a lot of people think of eleventy is just like, oh, yeah, you can like throw markdown in it. And there you go. It's a very static site. But if it's, it's powerful,
Great question. And I like very briefly passed over that earlier. But I think they're separate but are related in very good ways. You can build an accessible web application, in any which way you want to whether you are building a single page application or a jam stack style one or a server rendered one or anything. What I like about, again, the jam stack style is if you compile as much UI as you can upfront, that means that it is just that much faster for a screen reader to work through it or other assistive technologies. And it's something where because you are thinking about the browser first rather than how the server will render it, you could actually work with the window object and stuff and say like, Okay, I want to add certain key commands or certain abilities for people to navigate this website using an any particular technology they want to so it relates, but it doesn't necessarily change it. I think it's it's just something that you should always be thinking of when you're building.
Yeah, it also depends on the framework we are using because let's let's go back to Astro or Eleventy, they are just, they're static site generators, you get the HTML, there is nothing more accessible than well written HTML. On the other hand, when it comes to those single page applications, it's a bit more difficult. It's more difficult it's much easier to break it to make it non accessible for everyone. So So yeah, like going back to the roots using HTML. It was always accessible. We just broke it at some point at fancy. Yeah, we get fancy and everything because yeah, it will look so cool. If we and here is the long list of well, things we we did and later we are thinking how to fix it. While we were we have everything working in the first place. Yeah, I also have a few more questions that that were asked when the people signed up. So for example, oh, we already discussed it a bit. But what are your thoughts about Hugo?
Hugos? If you know, Go Hugo's great, I've only played with it briefly, like not enough to have a good opinion on it. But everyone that I know who uses Hugo is just like it gets the job done. I have no complaints.
So yeah, because it's so fast. Go is fast. Yes, yes, I remember once, when I saw how there was a comparison between how much time takes building the same on the similar website in Gatsby in Hugo and then few other static site generators. And it was like, Hugo, with everything, just speeding up. Yeah, exactly. Just just like this. Another thing we got, it's a bit about static site rendering, can you run static site rendering without a dedicated node server.
You run it on a PHP server, somehow that part kind of confused me, server side rendering, you need a server of some kind. It can be it can be done with anything. But it could be a node server, it could be a PHP server, it could be anything. But server side rendering requires a server. You could fake it with serverless functions, which I have done. And it works nextJS actually allows you to do that pretty easily, especially if you use it on something like Netlify or Vercel where you can create a serverless function and then just have that query a page and create a page. It works. But typically, if you want to SSR something, you need some kind of server. So whether you use a serverless function to serve a page or a node server, PHP server, what happens some point as the name stands, you will need to serve a server to render.
And last thing that I got, would you recommend this to a small businesses compared to say WordPress with regards to long term maintainability and complexcity?
It depends, once again, I think it depends on what folks are comfortable with what you are comfortable with, as a developer, what the business is comfortable with all of that it? It depends on you. Because I think once again, if if you as a developer are very comfortable with WordPress, and you can whip up sites and maintain sites with WordPress, use it. There are a lot of glorious websites out there that are still built with WordPress, I would I think it's like a majority of the Internet uses WordPress in some way. Most it's, it's 40, something 40 something percent 40 Something significant percentage of the Internet uses it. Nothing is wrong with WordPress, it's just your comfort level. If you are like me, where I left WordPress a long, a long, long time ago, because I didn't like maintaining it. It's just as maintainable for me to maintain a React website that uses a headless CMS of some kind.
I started converting WordPress into static websites just like this. I mean, I am like merging the the both both cool parts of two world. I have an easy to use WordPress to write content and I convert it to a static website and I store it on Netlify or something like this. And
Yeah, so I think we were really covered, covered a lot of things. When it comes to gems like at the beginning of this webinar, we asked our users a question, do you use jam stack in your projects? And what's surprising most because 63% said, No, they aren't using jam stack.
Hopefully we swayed you.
Oh, sorry. I got one more question. I missed one. Because nextJS, Gatsby first one would be what cast someone? Oh, I think because I only listed the two frameworks
So this is where I become kind of a hipster. If I were again, building a website from scratch again, and in no particular order was Astro and remix, those are the ones that I want to play with. The third thing that I want to play with is doing react, and Vite together. Because Vite is is a build system. And that being my, my framework, and Vite has a way of compiling statically and stuff. And I kind of want to experiment with just using those because Vite so fast, and seeing if I could build a website with just those and still have all of the guarantees that Jamstack allows. That is probably not a good answer, and probably not for everyone. But that that is how I feel right now.
Yeah, because because I saw that video is really going strong. I saw that it's great that Laravel just decided to adopt it as as their main main asset builder. They're replacing Webpack, which is kind of what I really appreciate about sorry, go ahead.
No, no, go ahead. Go ahead. What I really appreciate about the Astro folks is they're they're very humble and great people were they're the same people who created snowpack, and Astro was originally built off of snowpack. And that's what they used. And even though they were maintaining both snowpack and Astro, they switched out snowpack for Vite. Because they were just like, we acknowledge that this is faster than what we build. And we'd rather go for the best solution rather than the one that we control. And I appreciated that a lot when they that it was a very like humble well written post about it and everything. And I think that is a good sign when developers are not just using what what they own and what they build. They're, they're going for the best solution they can find.
Yeah, that's the true and, and I remember the moment when when when they switch and eyes and I saw that the builds became really faster. At the beginning. I was wondering, what did I messed up? Because it's builded already, that something was wrong? Probably. something isn't working, because it's so fast. Yeah. Oh, and one because we missed one thing about about Jamstack, because when it comes to building all those websites with, let's say, PHP, it's cool. You just put the file on the server and it's working. And with Jamstack, we have, we have to, let's say compile everything we have to build all the assets. Don't you think it's this extra step can be overwhelming for some people.
Just having it's being compiled one way or another. It's just a matter of when, when you have something on a server, it's being compiled when the user queries it. When it's on a CDN is being compiled when you put it out there into the world. It's the exact same thing. It's just a timing thing.
Okay, yeah. Okay, so yeah, I think that we really covered everything I'm checking out. Did I miss something? No, I didn't. Yeah, so like I said, definitely the bit surprised me about this, our poll that most people said that they aren't yet using JAMstack in their projects. 63% said that they aren't. But the good news is, they are here they are listening. And, and I really wonder in about two months, what will be the answer? We will have to post this this. This poll on Twitter and ask. And how about now and also,
I want to throw it out there while we're here. The Jam stack community survey just came out. And if you fill it out, you get a free sticker. So I dropped it in the chat. There's a sticker. Oh, if that's true there says I get nothing from sharing this with you. I'm purely sharing it because I want you to get a sticker. Oh, that's That's amazing. I really love stickers. You can find it on jamstack.org Like in the eyebrow header but then I also just dropped it in the chat there. Okay, yeah.
So So thank you very much for saying all the things about gems like trying to bring up all the pros and some of the cons because they are they are here but they are not so they are not so horrible.
That's yeah, once again, build what you're comfortable with will kind of like what you said earlier. It's there's no silver bullet. So build, what you're comfortable with build what you can work with the fastest and what is the best for your users.The end?
Exactly. So thank you so much for joining us. And everyone. Remember in two weeks, Ryan Sullivan will be our guest. He will talk to us about how to manage multiple Wordpress scale because his company maintains like hundreds, hundreds of WordPress pages at once. And they are doing it without JAMstack. So really this is this is this is not an easy thing to do maintaining all of those websites advance. Also, don't forget to sign up to our Buddy CI/CD group on meetup you will be informed about all of our upcoming webinars. And like I said at the beginning, don't forget to subscribe to our YouTube channel because this is the really nice place to learn a lot about CI/CD About JAMstack about WordPress and about so many other cool things. So really, don't forget to press that subscribe button. Okay, so, Cassidy once again. Thank you so much. It was a real pleasure having you here. And thank you everyone for joining us. See you in two weeks. Have a nice day. Bye bye