I've bean building things with Jam Stack for quite a long time, I think.

Actually, before the term jam stack was around on Bean come really excited about the possibilities of using Jam Stack.

What it could do for us is developers and also for user's as well.

So this is, Ah, quite a long video.

I go into a little bit of depth.

We start with an introduction to what the jam stack is, what the term is, what it means on then also some of the advantages of the jam stack.

We compare it a little bit to other stacks, like the lamp stack, which is something that might be a bit more familiar.

Toe many Web developers, and then we'll start to look through a bunch of examples.

So there are six examples can practically showing taking one site from a single file, a statically generated or statically written with my own hands.

Html file.

Deploying that to a content delivery network but then evolving that page, turning it into something a little bit more dynamic, turning it into something that has things like localization on clients.

I'd rendering another the other bits and pieces, and so that's a set of examples that grows throughout the video.

You can jump into any of those points and jump straight into those examples, or you can watch the kind of evolution of the whole thing as we go on.

Then, at the end of the video a CZ, we do a little bit of a wrap up.

There's also another demonstration, which looks at how you can start to use the jam stack in your own infrastructure.

So if you are already building sites using a different architecture, how can you add jam stack next to that?

What's an easy route in to do that?

So there's an example of that at the end as well.

At the end of the video, there also are a bunch of resources and links for you to take a look at on.

I hope it's useful.

So, um, let's get started on start to look a TTE exactly what this jam Zach thing is right then.

So where where to begin?

Well, we're thinking about an introduction to the jam stack, then it's probably worth our while just considering that this is an approach to delivering websites, and it's not the only one.

There are many, many approaches to delivering websites.

We've been at this a long time now as as an industry, and we've evolved a long way.

It used to be when we first started out.

This is an incredibly nice, simple diagram to begin with.

It used to be that, you know, when when we started building for the Web would create assets, we put them on a Web server, and then it would come along in a browser and we'd ask for stuff.

And then we get the stuff, and that's that's a lovely situation to be in.

You know, it's very seems very simple, very straightforward.

Now we'd have this relationship where we'd create assets, put them somewhere that they become available.

And then when someone came along with the Web browser and asked for those resources, we'd simply deliver them to them.

And that was great.

And it's did it stood up well for folk for quite a while and on.

That was kind of nice and efficient, but we soon run into limitations in that you know, these things were were kind of all there was static.

They weren't.

They weren't able to be changed based on what people ask for.

So the experiences we were getting seemed to be quite static as well.

So we try to add something new to this.

We started to add some kind of level of dynamism at the server level.

So now, instead of just asking for stuff and getting stuff, their server would do stuff as well.

We'd have this, this script, this logic that would be executed at the server level for every request that would generator, view and then return it to the user.

And that was great because it meant that as we were requesting things we could we could build things up on the fly so we wouldn't need to know every permutation that was being requested or or we might need it ahead of time.

We could respond to the needs of the user and create something dynamically on return it.

But it didn't mean that the responsibilities of this server Now we're we're quite different now.

We needed to make sure that for every request that came in, we had enough enough capacity here enough horsepower to be ableto service every request and get something back to them quickly.

So that soon led Thio a slightly different scenario.

So we started to introduce different bits of infrastructure.

So rather than just having a single Web server that was creating those views, we started to add many Web service to handle the traffic.

And we'd perhaps put something in front of those Web servers like a load balancer that would say, Okay, well, this request will go to this Web server.

This request were to another Web server gonna share the load across those servers.

And we started to do more things like abstract where the data lived rather than the data being on these Web servers as well.

We start to say, Well, let's let's abdicate the responsibility and share some of the load with with servers that are specific to that Andi abstract those out as well.

So we got to a point.

This a request from a from a page for from a user for a page would travel through all of these different bits of infrastructure, gradually assembling a view that would get returned to the user into the browser rather than having something ready to go.

We also started to think about well, maybe we could find some assets that are kind of just static and don't need generating on the fly.

And maybe we could put those in a different location.

So we started to introduce things like a CD en, which is a content delivery network, a network of machines geographically arranged so that wherever the user arrives from, some of those assets could be served directly from their, whereas others would have to go and go through this journey and get built up over time.

So all of this kind of added to the infrastructure and the the pieces in play for serving the request off a user ensure it got complicated on dhe.

We got more sophisticated in the kind of things we're building on.

Our infrastructure got more complicated as a result.

Luckily, though, you know, we we've been learning and we've been building new tools so we don't have to stay in the same picture that we've had for such a long time.

Now we understand that the needs of users have changed and what we what we expect to build has changed.

But So is the tooling that allows us to get there.

So you know, a few things have changed.

Browsers have got more capable.

You know, the Web browser that you'll be viewing this site and now is very different to the one that we were using at the beginning, when everything was was a little bit simpler, browsers away, more powerful, way more capable than they ever used to be.

And we can.

We can use those to great effect also as a as a consequence of building so many sites for such a long time, we as an industry of matured our processes.

We've really got a lot better at the way that we build sites on the way that we we can deploy them so we can start to make start to take advantage of these.

These maturing process is, and also tooling has improved.

You know, the things that enable us tow Thio generate our code to manage our code to deploy our code and all of the things around that that's all improved as well, so we can evolve our approach as a zoo result of all of these things improving.

So let's get to this small question, then it.

Since we're looking at an introduction to jam steak, what is the jam stack?

Well, there's a couple of ways that we could we could answer that we could We could ask, You know what does jump stacks down for?

And we could ask, What does John Stack mean?

And they first grants.

You think?

Well, these are the same question, but but not quite.

Let's let's let's dig into both of them in terms of what does jam Stack stand for?

Well, the word has come about by considering JavaScript AP eyes and mark up to make up the jam of this jam stack.

And certainly as we go through that, this video will look at how we use markup, how we use JavaScript and how we use AP eyes to create experiences in the browser.

But there's more to it than just what it stands for.

Let's also consider the words stack as well, for just for just a moment now.

What do we mean by stack in the first place?

Well, I think we're talking about where Web technology stacks.

The stack is the layer of technology which deliver technologies which deliver the website or application is the thing is the set of tools that make up that delivery.

So when we think about what it stands for, well, that's one thing.

But I don't think we're any the wiser, necessarily toe to talk about what?

What does Jam Stack actually mean?

And what's the result on How do we use it?

This is about the best definition.

I think I've I've encountered above Jam Stack, and that is James.

Stack means fast, insecure sites and APS delivered by pre rendering files and serving them directly from CDN, removing the requirement to manage or run Web service.

There's a lot to unpack there, and we'll do that over the course of this video.

But I think this is.

This is a good descriptive meaning for Jam Stack pre rendering the files so that you don't need to manage a Web server later on.

It's kind of a return toe capabilities that we might have had in this world, but there's so much more that's come along, too.

To empower things around this that will get to shortly, you might think, Well, there are a lot of Stax already.

You know, I'm aware of different approaches of building things for the Web.

They're all of these different stacks that we might choose from with different technologies on dhe, and that's that's fair.

But let's let's let's use one of them as a bit of an example.

Just as for means of clarification and a bit of comparison till it's let's talk about lamp stack for a little while now, Lamb Stack that stands for Lennox, Apache, my SQL and PHP.

And this is a very popular, I think, the most popular combination of technologies for building out a Web experience that exists on the Web at the moment.

And each of these, these technologies plays a certain role on these other stacks.

That's, you know, we've listed up here effectively.

They play into that place into the same kind of environment.

But some of these technologies air switched out, but ultimately they do the same kind of thing.

We end up with a system where on a Web server where we've got something that is delivering our operating system for us tow build on in the first place.

We want a layer for data access being my SQL here for a database and the service is attributed to that, Then we got a layer for doing pre processing or the actual scripting and processing and handling of the logic and assembling the views in this case is PHP for that pre processing layer and then some kind of Web server that will do things like the 82 p routing and the actual serving of of assets and passing things along down the stack, too.

To get the resources we need now in the lamp stack often find these things combined in a single Web server.

But over time, as load increases, a typical thing to do is well, we won't have.

One Web server will have many Web servers all running these bits and pieces and other described a few minutes ago.

And sometimes we'll start toe abstract things like the data layer out of these, but ultimately was still looking at a stack, which include reaches all the way back down to the operating system right the way through up to the actual routing and the handling of the http requests.

Meanwhile, if we to look at the jam stack is, ah, a comparison to that, the stack looks quite different.

The diagrams a little bit different here, but we're catering for the same kind of things.

We're still talking about a seedy P routing and serving.

We're still talking about data access.

We're still talking about processing in a run time.

A key difference here is that this run time, the processing layer in effect, the operating system, if you like, that lives within the browser here.

So we're not having to reach away down into an operating system that's provided to us by the client.

That sir, the runtime exists right there in the browser, the AP eyes, the data access.

We've kind of abstracted that away.

That's kind of not part of our domain.

Now there are AP eyes that exist out in the ecosystem.

Now that we could make use off, which we don't have toe manage ourselves, we can request access to those via their AP eyes, and we typically do that using JavaScript.

So that's why we get this thing kind of trinity of mark up, delivering content and then, if needed, we can start to use JavaScript in the browser to talkto AP eyes and get, get content and embellish and enhanced the experience here in the browser.

They're still rooting and serving, going on but typically in a jam stack world.

What we're doing is we're pre generating all of those assets they can so they can be served from a very simple, static server or even better, still, a CD en.

This is the kind of thing that could be managed for us.

It's almost like a service that's been completely abstracted away since there's no internal kind of clever logic logic here, which is coupled to the way that our system, our application, works so mark up.

Jobs rips in AP, eyes kind of moved the stack kind of away from the server and over here, So Jam Stack really is about having things that are pre rendered.

It's about leveraging the browser and the power and the browser and the technologies available to us in the browser.

And it's about operating without a Web server.

And all of these things bring is a bunch of different advantages.

We'll get on to that in a second, but I just want to kind of put these two things, but side by side for a second.

And consider you know what the stack looks like here in the depth of the stack that reaches all the way down to the operating system, right the way up through the data, the scripting and even the handling of the requests.

And compare that over here toe What happens with the jam stack, where Stack is kind of moved up a level it's closer to the browser is closer to the user.

We're not dealing with operating system infrastructure.

We're dealing with a run time which is provided to us in the browser so that we can use JavaScript right there to do the dynamic things we need right there in the browser and sitting on top of mark up and being out to call AP eyes.

So this means that if we're if we're thinking about a pre generating pre rendering things, working without a Web server, it feels like we're getting a bit closer back to this.

This kind of environment, this kind of flow, where we're pre generating things, putting them somewhere that they could be found, and then a request comes from a user to get this stuff.