 here today to talk to you about Jamstack. If you don't know me already, I'm a developer at Simplabs. You can always find me on Discord or on Twitter. And if you pretty much if you say anything Jamstack related on the Ember community Discord, I'll probably pop up and want to join in the conversation. As I said, I'm going to be talking a little bit about Jamstack. And I'll give you a bit of history about where Jamstack comes from, what it means. And then I'll go into a little bit of detail about Ember's position in the Jamstack revolution. And a little bit just a tiny bit on why Ember Optane is potentially a really unique selling point for us compared to some of the other Jamstack offerings out there at the moment. I'll go into a few projects in Ember that are using Jamstack and hopefully show you how you might get involved or get started if you're interested. So now it's time to get started. But before I do, a little bit of an issue when talking about Jamstack related things is that you say Jam a lot during the talks. So I'm going to, if anybody wants to give me an estimate of how many times I've actually said Jam today in this talk, if you tweet me with your guess, I will send the person who's closest a piece of swag or something Ember related. So tweet me at real late if you want to participate, if you want to guess. And now let's get started. So I'll start with where Jam comes from. So what actually is Jamstack? This quote here is actually taken from jamstack.org. So hopefully it's a good definition. It's actually been updated recently in the last kind of two or three months. So it's actually much easier to understand now. But I'll read it out just so we can experience it together. Jamstack is fast and secure sites and apps delivered by pre rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers. Okay. Interesting. Good definition. It's interesting though that doesn't say anything about Jam. The old definition did say Jam and what that actually stood for. So let's bring that up now. So J A M stands for JavaScript, APIs and markup. Okay. Pretty clear, self evident. No. Okay. I don't think so anyway. This doesn't give me a feeling that I know what Jamstack actually means from just looking at these two things. So let's dig into a bit more of the history of it and see if we can understand it a bit better. Jamstack is a marketing phrase 100% created by Netlify. Okay. Some of you might have already known this. Some of you probably see this for the first time today. I'm not. I don't mind. I don't think this is a bad thing. The only thing that makes me think off is respect Netlify. They have gotten so many people to talk about Jamstack, to give presentations about Jamstack, to even have entire conferences about it. And that is a very difficult thing to do. And actually thinking about it, why Netlify? Why would they be one of the ones to coin a phrase like this? So back to the definition, it said serving sites directly from a CDN. And that's the link. That's the key. Netlify is essentially a content management hosting company. Sorry, not a content management. A content delivery network hosting company. So they are focusing on serving static assets quickly all over the world. And part of what makes Jamstack's jammy is this idea of not having to manage servers as well. So I'm not having to maintain it yourself, which plays quite well for a company that does exactly that sort of CDN hosting. Site caveat here as well, just to kind of an aside, you might hear people talk about Jamstack as like the serverless off front end development. In the same way that the whole serverless movement doesn't actually remove servers, it just means that somebody else is running them. And in our case, there are servers still running the CDN, we're just not hosting them. We're not maintaining them. So hearing me talk about all this, bringing up the fact that it's a marketing term only, you might think that I'm a bit of a cynic. And I'm not. I'm really happy with what Netlify are doing. And I love the Jamstack. And the reason why I'm saying all of this that's mostly marketing is just to illustrate that Jamstack isn't something revolutionary. It's not new. It's just an evolution of some of the stuff that we were already doing as a community, building web applications and giving it a catchy name allows us to more easily talk about it for us to gather around the term and build things specifically for this idea. And also, you know, thinking of it in these terms also gives us a way to categorize what apps are or are not very Jamstack. So with this history in our backpockets, let's see if we can move on to our to my patent pending Jamstack classifications spectrum. This is supposed to be a strawberry jam spectrum. I apologize for my art skills. But this starts at the empty Jamjara side of the spectrum and runs all the way through to the jammiest jam donut you can imagine. So as ember developers, just building a single page application or an SPA. Did you know that actually we deserve a position on this spectrum with every one of the apps that we've already built? Depending on a few things, it kind of put us in a different position, but I'll go into some of those details now. So let's imagine you're building a single page application. We tend to have this idea of a separate repo for your front end and back end. Let's just ignore the whole mono repo thing. Pretend that doesn't exist for a second. So you have these two separate repos, you can host your front end using something like Netlify. And if your back end is in this other repo, then you actually end up in a not very jammy part of the spectrum. Because if you think back, think back to where the term comes from, Netlify doesn't allow you to do the server hosting. Now, you know, there's some caveats there, you could do it as a serverless functions or something like that. But even if you are using serverless functions and you're maintaining those, it's kind of like a half jam technology anyway. So if you want to move up this spectrum, if you want to become more of a mid jam application, then one of the best ways to do that, or one of the first things you should do is you should be hitting an external API instead of one that you maintain, one that you write. What do I mean by an external API? So some things that you could do is you could build an application that just hits the GitHub API directly. So it's like maybe a new dashboard app or something like that, something custom using GitHub data. Or if you want to build something entirely custom, something new, you could use something like Contentful. Or Contentful, I don't know how you're supposed to say it, but it's fine. So Contentful is like a CMS as a service. So CMS is Content Management System. And it's pretty cool. It means you can start an app really quickly and not have to worry about hosting the server aspect of things. And, you know, if you're building your application using some of these external APIs, then I would kind of put you just shy of the middle of this spectrum in the jammy dodger part here. So let's imagine we have our Ember app. It's using one of these cool external APIs. Now what? How do we become more jammy? How do we aim for that donut? Well, the first thing that we have to look at is server-side rendering. Server-side rendering will help us climb this ladder, this jam ladder. And one of the things that we need to think about in these terms is that we have to build fast applications. I can't remember if my definition from jamstack.org, the latest one, has building fast sites in it, but the old one definitely did. Jamstack applications tend to be really fast and with server-side rendering, you really improve the performance of your single-page application or your perceived performance of your single-page application. And we've been able to do this for years. We've had fast boot for ages and it's relatively easy to set up, but there is a slight problem. If you are running fast boot in production, then you might need to actually host a node server somewhere. And as I said, now if I doesn't allow you to host servers, like you could do it in potentially serverless functions, but I'm not sure fast boot is set up to be optimum in that. So if you did actually run fast boot in production, that would have you start slipping down the jam continuum, which you don't want. So how do we get this? How do we get server-side rendering the benefits of server-side rendering without having to host our own server? Well, this is where pre-rendering comes in. And with a massive thanks to Ed Faulkner, we have this amazing ember add-on called Prember. I would say a round of applause for Ed, but I don't want to do that here. So maybe, you know, Tadaz in chat or something like that if you are following along. So what is Prember? What does it do? With a tiny bit of effort, you can set up pre-rendering, which is a way of telling your ember application what the routes that you want to build at build time actually are. So you have this list of, you know, all the posts or whatever it is if you're building a blog app or something like that. And at build time, your app will use fast boot, render your application, and then save that juicy HTML to disk, which can actually be served statically. So you can start using a CBN. And this is where it goes back to using hosting like Netlify. It's also probably worth mentioning that I'm not getting paid by Netlify to say all of this and other static hosting providers are available. And so thanks to Ed, we are one step closer to earning our jam making scouts badge. And so far, if you've been following along, you might be thinking, this just kind of sounds like, you know, a static site generator, you know, we just, it's just the same as using Jekyll or middleman. And everything that I've said so far would definitely make you feel that way. But the interesting thing here about the J in jam, the JavaScript aspect of it, it's not that we're using JavaScript to build this static HTML that matters. That doesn't matter at all. The key thing about making about this modern architecture is that we have a jam lifecycle. When you render your application, when you get your HTML, you then once it's loaded, you load JavaScript, you load your JavaScript application. And in Ember, we have this thing where once fastboot has finished rendering and the same is true with primer, it loads the Ember application, the full Ember application. And that means that has a few interesting things. You could build something like a to do app in with jam technologies, so that you could have like your public to do items as static HTML, and etc. And all that sort of stuff. Not sure that's the best use case, but you could if you wanted to. And or another example is something like a blog. You could load your HTML really quickly. And then once it's loaded, your application boots up. And then if you want to move to a different route, you only need to load a type of JSON or something like that, the data that is related to your next page. And that will vastly increase performance. And if you're using something like Ember data, the performance is way faster because you'd likely already have that data loaded into the store and it is literally instantaneous. So that is a kind of a whirlwind introduction to jam what it is and how to do it in Ember. And it probably might seem a bit simple here. And you know, I'm joking here, you know, I've said a lot of things, it's a lot to think about. And to be honest, it's a lot to remember to know what to do. And in the Ember ecosystem, we don't tend to like this idea of, you know, here's the tools, just put it together yourself. We like to build shared solutions. We like to build things in a way that everybody can make use of the collective knowledge quickly without having to learn it all from scratch. So there we, I've been thinking very strongly about like a complete solution to jam in Ember. I'm going to take a slight diversion to kind of look at some of the other big players in the jam ecosystem and explain how they work and how Ember's solution is slightly different. So if you know anything about jam, you've probably heard of Gatsby or ViewPress. They are big players. Gatsby is for React fans and as the name might suggest, ViewPress is for ViewFans. Both of these are really great choices. If I'm saying anything, if I'm implying anything negative about them, in my comparisons, it's not true. They're great projects. They've got great communities. They've got great documentation. The thing that I think is different or the thing that I see as a problem is that both of them are quite low level tools. They are building blocks that you have to do most of the actual building. Now, you're probably going to have some really good time using the documentation, following along, building applications with it. As I said, they've got great communities and Gatsby even has 15 million dollars in funding, whatever it means for an open source project to have funding. Time will tell. So as I said, you'll probably have a really good time following the documentation and building something and getting started. And even if you don't want to start out from scratch and use the building block, you could find a number of starters. I think there's a Gatsby starters whole website where you can browse and find where people have done most of the work themselves and you can start where they left off. The only issue with this, the starters, is that they are essentially GitHub repos. And to use other people's work, you have to fork the work that they've done. Which is great. That's wonderful. But it means that if, say, the starter updates, you have to then do like a sync from upstream and it tends to lead to people not doing upgrades. You kind of locked in a period of time. And that's, you know, that's one way of doing it. And this is where I felt like we could do a slightly different approach here. And what I said earlier on about this complete solution, the shared solutions in the Ember ecosystem, that's where I felt like we could bring something new to the table. And this is where we introduce Empress. Empress is Ember's answer to the Jamstack. And it has a fundamentally different approach to building Jamstack applications. And I don't just mean because it's using Ember instead of React or Vue. Firstly, there is no single Empress installable add-on. It's not a building block. We have a different way of doing this. We have essentially a set of products focused on one particular use case. I'll go through really quickly some of these products, and then I'll do a bit of a deep dive on one of them, which will help us understand the architecture. So each of these products essentially try to do one thing and one thing well. I'm splitting them up here into stable beta and alpha just because they're slightly easier. The stable ones are a lot easier to get started with if you're interested. And some of the beta or alpha ones are either still a tiny bit in progress or slightly under documented. But I'll talk a bit more about that at the end. So let's go through the top ones real quick. Ember's blog. It does exactly what it says in the tin. It is a blog system. It is our very first product in the Ember Empress ecosystem, and it's the flagship. It's the thing that made us think of this in terms of products. The next one up is GuideMaker. It's probably something that a lot of people won't have heard about, but a lot more people will have used. GuideMaker happens to be powering the Ember guides. So if you've ever gone to guides.emberjs.com, you've used the output of a GuideMaker application. FieldGuide. FieldGuide is like a style guide or a design system documentation tool. It's different from GuideMaker. It has different focuses and it's specifically designed to make it easier for you to build a design system. We've used it recently for the Ember website redesign project and FieldGuide was really instrumental in helping us make sure that the Ember style guide is something that will document and bring the new design system of the Ember website to each of the different applications over time. And if you haven't already checked out the new Ember website, it is pretty awesome. And I spent a lot of time recently getting that up to date. So check it out and let me know what you think. So next up we have some beta ones, open slide. I'm using open slide right now to do this slide system. It's, you know, it's interesting. It's a little bit janky because it's using reveal in the front end aspect in the template aspect. And reveal is nice, but it has some rough edges. One of the reasons I like to use it is because all of the Emper's products focus on trying to use markdown as the basic building block. So you write all of your content and markdown. So each of my slides is actually just a markdown file. And TrainingBuddy is like a sidecar app for workshops. The last few are kind of experiments at the moment, RFC process and tech survey, but hopefully they'll be something that people can check out pretty soon. If you're interested in any of these or if you want to know more, you can go to github.com slash Emper's and all of this code is there. So as I said, let's jump into Emper's blog and have a look at what it is, what it does, and we can talk about the architecture of an Emper's product using Emper's blog as an example. So this is what you get when you run the Emper's blog quick start. And if you recognize it, that's probably because you know this has been the default ghost template, the Casper template, I think it's called. So this is essentially a shallow fork of the Casper template because Ghost uses handlebars. And as we all know, Emper templates are close to handlebars.js, which means that we can tweak them just a tiny bit and maintain a fork without too much effort. And what this looks like, what the Emper's blog quick start actually looks like is that we create ourselves an Ember application in this case called Superblog. We jump into the Superblog and then we install two add-ons. We install Emper's blog and Emper's blog Casper template. So first thing you notice here, you might not have seen MPM init Ember app. That's just a quick way to get started if you don't have Emper CLI installed globally. But if you're watching this, you might already be in the Ember community. So you might just be able to do Ember new Superblog. And then the other thing to note of interest is the fact that we're installing two add-ons into our host application. So we have the Emper's blog, which is like the brains, the system add-on, as I call it. And then we have a template add-on. What that actually looks like and what each of those, what that does, I'll kind of go into more detail here. So as we saw in the quick start, we have this host app. It's just a normal Ember app, nothing any different. Ember new, you've created an Ember app. We then install Emper's blog. Now, Emper's blog uses some maybe lesser known APIs for Emper CLI and Emper CLI add-ons, where when it is installed, it'll install a bunch of things into your host app, like Fastboot, like Prember, as we already mentioned, does that for you. And I also generate a bunch of example content, so that if you follow the quick start, if you run Ember serve or npm start, and you actually got a blog there with posts, authors, tides, all this sort of stuff. So it generates a bunch of example content for you. And that's it. Your Ember app doesn't change from this point on. The only thing that your Ember app actually contains is the content. It's essentially an empty shell. The brains, as I mentioned, the build time stuff, the broccoli stuff happens inside Emper's blog. And actually, the definitions for your roots as well happen inside Emper's blog as well. You'll notice that there's nothing, no mention of a templates here. This is where the template add-on comes in. So your Ember templates and your CSS happen in a separate add-on. So that means that even though your roots are defined in one place and your templates are somewhere else, that means that your template add-on is essentially just HTML and CSS, with one or two Ember template syntaxes thrown in for good measure. So each is ifs and things like that. So, and this is where it took me a while to get to it, but this is where Octane can really shine for Emper's. Emper's templates, because Ember Octane is so HTML-first nowadays, somebody who has HTML and CSS experience will have a fantastic time building an Emper's blog template. And because it's an Ember add-on, you will be able to create it and run the dummy app and it will show you what your content actually will look like when your template is done. So before we get into that and how we actually create ourselves our own template, I'll show another benefit of using this kind of a system. Because the template is entirely separate, you can get a new look and feel for your blog by just NPM uninstalling something and installing something else. So in this case we're uninstalling Casper and we're installing another popular open source template for Ghost Attila. So just by swapping this dependency, your look and feel of your blog entirely changes. But maybe we don't want to use some of the pre-existing templates. Maybe we want to use one that you want to build yourself. In that case, we can make that a little bit easier for developers. As I said, we really want to make the developer experience really awesome for this. So as I showed before, an NPM init kind of thing, this is just a helper to create to get started. You can create an mpress blog template. We're calling it mboconf, I wonder why. And then as I said, you can just cd into the folder that I created for you and then you can do NPM start. And what that actually gives you, as I mentioned, is this dummy app. Now it doesn't look very good. If you are familiar with the Ghost ecosystem, you might recognize this as the starter template that Ghost came out with, I think it was early last year, January last year. And that is essentially just a way for you to get started quickly. And it gives you some structure. And in our case, it has a application template, an index, HBS, you know, post component. And I think it also has like a author root and things like this. So as I mentioned, we're creating these example templates when you create this use that helper. And if you just know a little bit of html and css, now thanks to mbrock team, anybody who's just a html and css developer can come in here and build something build an entirely new template that can be leveraged that can leverage the Jamstack in all of its glory very quickly. And this is something that really excites me about what our community community can bring to the Jamstack revolution. So that's kind of an overview of what we have right now. I want to go a little bit into the future of Empress and how people might get involved if they're interested. The first thing I'll say is that this architecture that I described this idea of having a host Ember app, a system add on a template add on, that is the same for every single one of these Empress products. So a guide maker has a guide maker template, etc. So the future of Empress, from my perspective is twofold. First of all, I want to try and move some more off the beta and alpha products into stable so people can get some use out of them. Part of the thing holding the back is related to my second aspect of this. A lot of this stuff is underdeveloped, under documented. It's nicely well developed, but it's under documented. And hopefully by the time that people are seeing this, Empress.dev will have been stood up. It'll have some example content there, but it will have links if people want to contribute and want to help with actually documenting some of this stuff. And I over the next few months will be, you know, putting my brain out on paper on that. So one of the reasons why some things are in beta is because even though I'm using Open Slide right now, the documentation isn't there. So these are related. The two aspects are related. And that's pretty much it. If anybody's interested in talking about Empress things, or if anybody's interested in starting their own blog, please do try out Empress blog. Tweet me at Relate and let me know what you think, or chat to me on Discord. I am always happy to talk about JAMstack and Empress related things. Thanks a million everybody.