Everything you always wanted to know about Jamstack (but were afraid to ask)

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?

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.

It's yeah, it's and the thing is that and get into all kinds of things. JAMstack has changed a bunch, but the as as like a paradigm and things but it's not necessarily using new concepts. It's just kind of using older concepts that we've known and loved before but using them kind of in a better way with more modern technologies. And so what anyway, when the term was first coined, it was capital J A M stack. And that was because the J A M was stood for JavaScript API's and markup. And it was just solidly like use JavaScript and API's and markup to create a website. And it kind of focused more on static websites. And it evolved over time, because it kind of got overlapped with serverless. And then that method of developing sites where, if you don't know serverless, it means you don't have to care about servers, it doesn't mean the servers don't exist, it just means that they are not within your control, you create functions that live on a server elsewhere. Anyway, all this to say JAMstack is not server side rendering. So you don't have to maintain a server of some kind to host a website. If it is a jam stack website, it's typically CDN first, and then pulling in, again, API's and and perhaps serverless functions and that sort of thing. And it's evolved over time, while still being attached to the core principle that you are compiling as much as you can upfront, and then pulling in data as needed. And it's this concept that, for example, if you were to build a mobile app of some kind, whether you're building Android app, iOS app, Windows Phone, a hub, something, something to that effect, I don't know what people are building, you are building a lot of the UI into the app itself. And then if you need to query data, you kind of do that separately from the UI, realise, very rarely rendered on the fly with a mobile application, the with jam stack, concepts, methodologies, architectures, whatever you might want to call it philosophies. It's kind of treating the browser in a similar way where it's like an operating system, because the browser is very powerful like an operating system, you're building as much as you can up front, so that when someone reaches your application, they don't have to make so many different queries to API's, various servers and things. And so it's trying to run as little JavaScript as possible when the user gets to your page. And granted, JavaScript exists for a reason. That's, that's the J and jam. And JavaScript isn't necessarily a bad thing. But it would be good to do less JavaScript, because there's a lot of frameworks out there that ship so much JavaScript to the browser that if you have a slow internet connection, if you're in a remote area of the world, you might have to wait like a solid few minutes just to have an application load from the get go. And so again, compiling as much as you can upfront and pulling in data as needed. And that's the the high level version of what gem stack is. And when you think about how it's evolved over time, it kind of went from purely static to, again, pulling in data and content, but then also the kind of latest iteration of it pulling in data at the edge. And you might hear the term edge a lot. Also, I'm talking a lot, so cut me off if I'm talking too much.

No, no, it's very interesting.

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.

Yeah. But also the thing that I saw about the way how JAMstack evolve a bit because as you mentioned at first it it was very keen on this JavaScript part. And now I see that even even all those either generators or frameworks not build it in JavaScript, for example, Hugo, which is built in Go is seen as a, as a normal part of, of jam stack ecosystem. And even that, it has almost nothing to do with. With JavaScript. I mean, you can build websites that have has JavaScript inside of it.

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

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.

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.

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 interesting. I think, probably the biggest con is that it's confusing, because things have been changing so much. And I actually recommend recently, last week, I emceed a conference front end test fest, and the closing keynote was by Jason Lengstorf, who's the VP of developer experience at Netlify. And he gave a really interesting talk on the future of just JavaScript frameworks in general not not jam stack. And some of his thoughts I thought were really interesting because he was talking about these trends. As in his predictions for the future, and we'll see if the predictions are true. But some of the things he mentioned were, for example, more things moving to the edge, less frameworks that ship tonnes of JavaScript to the browser, which right now, like next is a very popular framework. Gatsby is a very popular framework. They both ship a lot of JavaScript to a browser. But all of these kind of new and upcoming frameworks like like eleventy, like Astro even Svelte and, and those sorts of things, they are shipping less JavaScript by default or no JavaScript by default. And like with remix, it's it's edge first. And so all of these different frameworks, they're, they're going into this newer era. And granted, I don't see Gatsby are next going away anytime soon. But it's interesting to see that trend and shift towards more edge driven things more jamstack style things and less server oriented things.

Looking at the last Stack Overflow survey, we can see that Gatsby lost a lot of ground when it comes to the most beloved framework. Last year. It was it was in the top and right now it's it's a lot. Yeah, it dropped a lot. And I remember the discussion about it. And most people will just respond that Yeah, NextJS has happened. And that's it. But in case of shipping, JavaScript, to the front, and to everyone, NextJS doesn't solve the problem. But you mentioned Eleventy, which is kind of interesting, because it's, let's not say legacy, but it's kind of old.

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.

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, well, first of all, the O'Reilly book on JAMstack is free. And so if you ever actually want to read in depth about it, read the free book, because you should take advantage of that. But and there's all kinds of great courses like Free Code Camp has a free course on it. And plenty of things like if the things are free, that's it's already pros. Yeah. Well, and I also think I think proofs of concept go really far. And just to compliment Zack again, he's so good at making proofs of concept where he'll recreate a website in multiple frameworks and be like, look at the performance benefits. And when you, when you use that jam stack style of building, granted, you can create a performance website with anything, you could create a performing website with jQuery, if you really wanted to, it's that that's something that hasn't gone away. But I think kind of just showing, if we were to improve this, look at look at our bundle sizes, look at how our accessibility might have improved look at how our first Contentful paint or whatever those metrics are called, have improved. And I think that's that's, the numbers don't lie. And that's, that's probably the best convincing way to do it. And also, if you, if that doesn't work, just kind of look at the trends of where web development has been going. Because it's, it's a very real trend. And when you're deep in the weeds of all of the Twitter, spheres and dramas and JavaScript frameworks and stuff, you'll see this drama, drama, I'm exhausted. But it's, it's it's a direction that the world is going in. And it's something to consider, because as you are building this business and moving forward, you want to stay on top of the trends, because you don't want to become a legacy system that nobody wants to work on.

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.

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.

So so so it's not the approach that first learn JavaScript deeply and then try those frameworks, but only when you like, almost fully understand most of the JavaScript concepts, just experiment, right?

Experimenting is great. And I and I will say I do think that it's good to understand the deeper JavaScript concepts because if you know JavaScript really well, and then something is broken in Vue JS, you can be like, okay, is this the frameworks problem or JavaScript problem, and you can solve that problem faster. But you don't need to get started. I know some I was actually talking to a developer recently, who has four years of experience pretty experienced and a mid level developer, because they have only been using React and no, didn't really use JavaScript before didn't really go vanilla at all, just only use React. They didn't actually know how for loops worked. Which is such a base concept for me as a developer with a computer science degree and stuff, but they just never had to learn them. Because they always just use map and react and never had to think about it. And it was something that blew my mind. But at the same time, I was just like, you know, you've got done well, and you've been moving up the ladder at your workplace not having to know this particular thing. Good for you. Maybe you should learn it. Cool. Cool. Yeah.

I also had this this problem because while I'm in worker space, I started with PHP. So I first learned PHP let's say I learned PHP deeply right. And for me, it was impossible how many people are first learning how to use WordPress. And at some point, they are just starting to learn PHP. And it was right to understand you should know the basics. But right now I see that with the number of new frameworks of new tools just showing up every day, especially in the JavaScript world, I mean, I remember that moment, there wasn't a day without two new frameworks that will change the world. Like this, right now. It's better it's only one framework per month or something like this. But yeah, it's really difficult to to get a grasp of everything. It's it's really moving so quickly. And but on the other hand, maybe it's it's another argument for learning, learning the basics. First, it will be easier to jump from, from one framework to another. But it depends, and I really understand why people like frameworks, they are so much easier to start, they solve a lot of problems for you, and why reinvent the wheel? Yeah, exactly. The problem is, when you stop using them,

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.

Okay, so this game, it's, it's very fun. Basically, you are given a picture or a screenshot of a webpage. And you and everybody around you opens their editors and just tries to build it from scratch, you have like one notepad file or whatever. And you just try to build it from scratch as much as you can. The HTML, the CSS, maybe JavaScript and stuff you do, as well as you can. And then after 15 minutes of not previewing your code, you just save the file, and then everybody submits it to a particular thing. And they open up all of the files and see who got the closest to the final screenshot. I used to play this a bunch. And it is very humbling when you're just like, oh, I need to work on my basics, as you see people's broken CSS and stuff. And I highly recommend people playing it if you get the chance, because it is so interesting to see how people solve problems or programme things in a particular way. And also you can see the reliance on frameworks where I remember, I played it back when I was earlier in my career. I played it with like my manager, and then a bunch of people on my team and I was the youngest on the team. And the most senior person on the team had been using React for so long that they were using class name instead of class, and all of their HTML. And so their their code and the darks mission was broken. And I was so satisfied. I was like, I know more than you. In this particular instance, for this one game, this moment in time, it was very satisfying. But anyway, I do think it's good to know the basics. Even though that's just a game. It's kind of an illustration of if you're ever in a situation where you have to build something from scratch, could you and I think it's helpful to be able to do even though it might not necessarily be a common situation.

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.

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?

Great question. Because I've been debating this back and forth a lot lately for like some of my side projects that I haven't started because I've been stuck on the framework idea, because for a long time, my answer would just be either create react app, or nextJS. But create react app is very single page application style where it's all JavaScript on the front end to the point where if you have a slow connection, it just won't show up. And next, similar but different ships so much JavaScript to the browser, where if you want to use our image component, it's just so heavy that it's it's kind of a pain. And so I think for myself, currently, I want to experience experiment more with Astro and with remix. I did try playing with solid and I like it but it some aspects of it aren't intuitive to me. So I I haven't I haven't played with that one as much. But I think right now, Astro and remix are probably the ones that I want to play with the most. Oh, yeah. Astro is also one of my favourites right now. It's, it's so nice. Yeah. And so simple and intuitive.

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,

it's really cool. So powerful. You can connect like everything with it. It's amazing. Yeah, even read some time ago how to connect it with, with notion, for example, using notion as a database and everything. Yeah. And then yeah, it works. Again, it works and everything works. Yeah. I think that when it comes to this, the way how to connect all Eleventy with all those other third party services, it's so amazing. It's so amazing. I think it's a bit a bit more clear than then in Astro. At least for me, I mean, you like store all the data at some point. And but still, both of them, especially for this low JavaScript on front end approach. It's really, really big kudos from for the creators, they are really doing an amazing job. And I already got this one question here. And it's so it's very important, I think, and how Jamstack affects accessibility? Because this is a very important question.

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

I can say my I have a headless WordPress. Gem stack, almost. Almost Generally yes. Generally. Yeah. I think with with with this current definition, we can say that I'm a jamstack developer, alright. Yeah. Yeah, you could have parts of it is jam stack again, because it's not a particular stack you have to stick to it's just like, the philosophy that you are aiming for in how you build and use few lines of JavaScript. So there you go. It's perfect. Yeah, it's perfect.

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