 Okay. Good evening everyone. I can't really see everybody in one, like, view, so I'll like switch sides. Can you hear me if I speak like this? Yeah. Okay, great. So as you heard, we are doing like a special talk, a special series of talks this week on something called the Jamstack. And to kick off this evening, I thought I would give a lightning talk on what exactly the Jamstack is. Okay, so the next slide was a lot funnier when I put it in. Now I don't think it's that funny anymore. But Jamstack is not this kind of jam. I don't know. And if you were here this past weekend, especially around the Marina Bay area on Saturday evening when the standard chart of marathon was going on, it's also not this kind of jam. It is something else. Okay, so let's get into it. So the way I'm going to do this is Jam is an acronym. So I'll just go through each of the letters and give like a really brief overview on what the letters mean and what that makes Jamstack as a whole. So Joe is for JavaScript. And I've taken the definition here from the Jamstack website. I bridge it a little bit. This means that dynamic programming during the request response cycle is handled by JavaScript running entirely on the client. Now what this means is this isn't something revolutionary in and of itself. Given that this is a React Meetup, this is something that we're used to already. But basically it means that you program from the client. For example, when you do a form submission, you don't make a traditional, I guess, post request to a separate endpoint on the server. You can submit that form entirely from the client. Another example, this one's a bit more, I guess, ubiquitous. Data is fetched from the client. So when traditionally you might have a server that builds HTML pages with the data already rendered into the mockup. With Jamstack, you don't do that kind of thing. Rather, you request data from the client directly. Okay, A is for APIs. What this means is that it's related to what I just said. Server-side processes are abstracted into reusable APIs. So as we have this dynamic programming handled on the client, this means that we have kind of a separation between the front end and the back end. So what this means is that you have to, the back end itself has to be exposed some way. And this is in the form of reusable APIs. And these APIs are reusable, meaning they're not necessarily bound to your particular client. There's nothing about them that means that your web application has to be the only one that can use them. Again, this is not unfamiliar to us as React developers. This is kind of modus operandi for us. So finally we have M, which is for mockup. So this was something that was a little bit less obvious to me when I first found out about Jamstack. Essentially what this says is that templated mockup should be pre-built at deploy time. So what that really means is typically these days you can achieve this by using something like a static site generator. What this does is it gives you basically just HTML, JS, and CSS files, which you can put, and these are static, this is static content. No matter what functionality your application has, it's the same HTML, JS, and CSS being served. And this is because the dynamic part is handled on the client. So going back to the J part and the APIs, the site code is the same for everyone, even if the functionality might be different and different people do different things. What this also means is that we don't build content at runtime. So traditionally you might have, if you have a server-rendered app, you'll make a request to a server endpoint and that will fetch data, put that into some markup, and then send the whole markup down back to you. This is not what we do with Jamstack. What we do is the content will reside somewhere else and through the reusable APIs, you fetch and render it from the client. All right. So I had a question when I got to this part, which was what about the routing aspect of it? So if you use something like create React app in its vanilla form, you can set up different pages of your site, but ultimately it's still a pure single-page application, which means there's only one HTML page and in your output from your build command, you still get one HTML page. So is that valid for the Jamstack? And I couldn't really find a definitive answer, but I'm going to go with, I don't know, for this. One of the things that you get if you use modern static site generators is specifically this idea of declaring your pages in code, but have it, have them generated out as discrete HTML pages. This is one of the, I guess, features of something like GetSpeak, and it's also, it works really well with putting out a everything behind a CDN because it helps with things like SEO and page response times and things like that. So I'm going to go with, if you have only client-side routing, that it's kind of not true Jamstack. Okay. Bonus letter. It's not the S in Jamstack, but I'm going to touch on serverless as well because although this is not a strictly defined part of Jamstack, it's kind of complementary. And the way it's complementary is because with this focus on having a lot of stuff done client-side, you might be wondering how do we do stuff which traditionally needs to be not on the client, right? So for example, if you have secret things happening, like secret keys for particular things which you can't do from the client because then you'd be exposing them, then how do you build a kind of Jamstack application with those requirements? So I guess you can get pretty close if you use a serverless architecture which basically means that you still have something that's not on the client. You have a serverless function, but you don't need to set up a full server instance just to do it. So if you're not familiar with serverless, one of the most popular products is AWS Lambda, which basically allows you to specify a function which you can put behind a HTTP endpoint, not necessarily a HTTP endpoint. And you don't set up the server instance, it runs on a separate instance that's not managed by you. So this is great because you don't necessarily need a full-blown server instance to do this and you might not necessarily want to pay for when nothing's happening. And also serverless is trendy, so that's kind of cool. If you use a service like Netlify, which Sean's going to talk about later, this is a kind of first-class functionality where you can write these functions in your project and Netlify will like bundle them and deploy them for you. All right, I think that's it. Yeah, that's it. So there you go. That's a really quick introduction to Jamstack. I hope that if you didn't know what it was, then it kind of gives you a little bit of an idea for the rest of the talks. And we're not doing Q&A, so if you have questions you can find me later. Thank you.