JAMstack: Silly Name. Serious Stuff.

Phil Hawksworth at Pixel Pioneers 2019
Sign up for Conffab Free to watch this and hundreds of other videos for free
[Music] you thank thank you all okay so I want to start this by just kind of reflecting something looking back in time a little bit so there's this wonderful quote from from Aaron Swartz who did so much for by the Creative Commons and the open web he wrote on his blog back in 2002 he wrote this he wrote I care about not having to maintain cranky AOL server Postgres and Oracle installs whoo yeah that sounds like things I would like to avoid as well and he said this in a blog post that he wrote on his own blog that was entitled bake don't fry and what he was talking about there is this notion of instead of frying content on demand when people came to your site and requested it you should bake it ahead of time kind of batches all up and do it ahead of time really what he was talking about there he's talking about pre rendering and doing that rather than than rendering on demand and when we're talking about rendering what we're really saying is we're talking about generating markup I'm ever so self-conscious about talking about server render or pre-rendering I think I used the expression server render once and someone tapped me on the shoulder and said you mean a web server emitting HTML right yeah that's that's what I meant but all of this you know was was what he was kind of talking about this and he was really talking about simplifying the stack I love the notion of simplifying the stack because development projects are complicated enough let me let me see if there are any people in the room who kind of recognized this notion of the perfect project and a perfect project timeline you might have worked on will draw a line from start to finish in the project starts at our very beginning when we have a brief we receive a brief and it ends obviously when we receive the awards that went it went great sadly this is a nonsense because there is no perfect project timeline let's unpack it a tiny bit well first of all we don't deserve the awards because we haven't done any work yet so at some point we'll start doing the work before we can receive any awards we need to launch something so towards the end of the project there'll be an actual launch before we even get started we should probably kind of define a scope for the project yes we have the brief book what is done going to look like we'll define that and then before we can launch it we'll probably need some kind of final sign-off from the client to say yes you build what was written about in the scope that's great and to be able to give us that that nods they'll probably have some kind of big client review which is our kind of big day so the time is already getting compacted we have to do a lot in a lot less time than we're expected but we kind of get started with our work and we're building things and we're getting them out into the world and we're reviewing them and after we've been working a while and starting getting closer to our client review date that's when we Reese cope because now the client seen how things are going and we've gone are we're gonna built a different thing instead after all that's fine it happens so then we kind of keep on working working a little bit more frantically now doing faster and faster work our processes are hopefully holding up we get to our client review date and we're happy except we're not happy we've got other things to do it turns out after the review this is starting to get to be a real scramble now our processes are starting to hold up hopefully our deployment is all working ok and then this happens I don't know what that is I don't know why it's over there it happens to us all and the best of times usually around crunch time that's fine because we know what the problem is we'll fix it the next deploy will be perfect it's not perfect it's now also in the wrong place and for some reason it's a piece of fruit we don't know why that is deployments are sometimes unexpected but then we you know we get back on track we do a bit more work we get to our final sign-off date we're delighted we get final sign-off except it's not final sign-off it's final sign-off in quotes because there's just a few more comments so we'll do a little bit more work then we'll get to launch and then we'll do a few more bits of work which are the fixes and then we it's a show is what I'm saying it's complex enough launch day can look a bit like this I think this is stolen wholesale from MailChimp you know this is the button you press when you mail out to millions of people and this is what deploying a site and what a launch could look like you know there's unpredictable piece pieces we never know what they're gonna look like it's a bit of a nightmare when you're working in this kind of environment so I love this notion of simplifying the stack and this is kind of what we're talking about with jam stack I'm gonna get into this in more detail after I've just enjoyed this therapy for a second jam stack stands for JavaScript API Xin Markov that's what the jam in that is but what does that even mean well I'm going to get to that in just a second my name's Phil hooks that we've heard from me already before I do indeed work in the developer experience team net if I if you've got questions and you can't grab me please grab me later on but if you'd like to ask questions you can also do so on Twitter I'm very happy to answer questions there but I'll try and get into some information in this session that will hopefully help because I want to get into like a bit more of a definition and more of a description really of what Jam stack is I want to talk about the impact and the implications of adopting this kind of stack along the way I'll try and describe a couple of tools and services that can potentially help and then also I'll try and reveal you know some sources and some good first steps to try this if you should like but just kind of returning to this notion of simplifying the stack well already we're kind of dealing with slightly loaded terms with there are stacks already there are lots of stacks around does the world really need another one we've got the mean stamp the lamp stack the maps that the Weiser stack though Ruby on Rails that doesn't work in the same way it's not as gratifying there's probably many more besides so does the world need another one why do we need this jam stack well let me try and be a touch more descriptive about gem stack so this might be a bit difficult to read at the back I'll read it out so apologies if it's a bit small so gem stack is a modern architecture to create fast and secure sites and dynamic apps with JavaScript API sand pre-rendered markup but served without web servers and it's this kind of thing at the end that sounds a little bit unusual I love getting web servers after the equation because fewer bits of infrastructure make me happy so let's try and explain that a little bit more by looking at a traditional stack versus the jam stack and let's look at this kind of example of a traditional serving of a request so in this scenario we've got our web browser or we want to want to make a request for overview some kind of a page so we'll we'll send off our HTTP request and perhaps it's hitting a CDN but more likely it's hitting some infrastructure that we manage somewhere that might be a load balancer and that load balancer will determine okay which of our websites is going to service this request we might have many that were kind of spreading the load across and those are web servers might need to compile a view they might need to apply templates and content and data maybe that's data that data is held in a database so we'll make a request off to a database we'll get that data back compile it into a view pass it back through the load balancer perhaps on the way through a CDN will cache some items for future and then ultimately we'll return something back into the browser and into the eyeballs of our of our user so there's a there's a lot of steps here and of course this isn't every web architecture but it's a fairly typical web architecture for something that's that's working at some kind of a scale and there's a bunch of moving parts there so we compared that traditional kind of stack to the jam stack this is how the jump stack would work in in comparison so similar scenario making a request from a web browser that requests hits a CDN or a static server which has the view compiled and pre-rendered and it returns it to the browser so yes it's shorter I like that very much you know I used to occasionally refer to this as the short stack because there are fewer pieces to consider but this is the kind of comparison we're going to come back to this this diagram a bunch of times because the jam stack I think really means it's a site that's capable of being served from either a static server or a CDN directly it doesn't need machinery behind the scenes to to crank on request time to to service these requests it offers an opportunity to reduce complexity and fewer boxes there on that diagram at request time and I think that's key and it kind of enjoys the benefits of serving static assets and I'm going to talk a little bit more about some of those benefits as we as we go along now you might be looking at the last diagram and hearing me say a few these words and think ok Phil but isn't this just a fancy new name for static sites that's a fair question and in many ways yeah it is it's a fancy new Wayne name for static sites but static sites are so different to what we might have expected before because the ecosystem has changed the tooling and the the technologies of chain so much that actually it's gone way beyond that now but I used this word static and I do so with kind of caution because when I say the word static you don't think of something cool necessarily you might think of something that's a little bit undesirable and in fact if we look up the dictionary definition of static it says static lacking in movement action or change especially in an undesirable or uninteresting way sweet sweet I've definitely got you for the rest of the talk now so it's you know it's a it's a very loaded term but my challenge to you is that when we say the word static are we talking about a static experience for the user who's experiencing the site are we talking about a static hosting architecture because really one doesn't necessarily mean the other and I'm talking about a static architecture of a way of deploying and serving sites that doesn't actually have to result in a feeling for the user which is a static experience at all I want to kind of demonstrate that static is a real virtue it really unlocks a lot of capabilities and that's what we want to get to before we get into that let's let's talk about stacks I've used the word stack a little bit but what do we really mean by that well when I'm talking about a stack I'm talking about the layers of technology that deliver your web site to your web application you know that's that's what we're talking about is this delivery now that doesn't mean that it's the tools that we use to build it in the first place our kind of development process the technologies we're bringing to bear to actually create the site that we then deliver from whatever are hosting stack is but certainly the way we host things that we deploy them has a huge impact on the way that we might be able to develop that so I want to talk about that a little bit along the way but let's do a little comparison let's just refresh our memory about what the lamp stack consists of we've got you know Apache is the web server that's doing things like the HTTP routing and essentially I'm serving some of the static assets we've got PHP in the stack which is there you know the pre eight hypertext processor which is doing the pre-processing and the logical request time we've got access to data through MySQL and that sits on top of an operating system being Linux now that's all kind of wrapped conveniently up together in this notional webserver of the lamp stack and that's what's serving our site at scale will typically have many of them and they're kind of replicated to kind of share the load so just as they're kind of a refresher for us now to compare that to the lamp story to the jam stack thinking about this JavaScript API sand markup what does that mean we'll the key thing to remember here is that before when we were talking about operating systems and things running running on a server a Java stack we've actually moved up a level we're making the assumption that we're sitting on a static server or some kind of static infrastructure potentially a CDN in our area that we really care about is moved up it's kind of closer to the browser now because that's where our markup is being delivered that's where our JavaScript is being delivered and that is where we're kind of starting to make use of the runtime of the web the browser and JavaScript gotta become the runtime of the web and that's where we're doing a lot of our work so yes we're delivering markup and JavaScript pre-rendered pre-generated so can work in the browser and then we might be calling on you know our access to data might be through external api's we might even think of api's in you know the a in jump stack as calling browser api's with javascript right there in the browser so that's what kind of this kind of comparison means so dam stack is pre-rendered it's served statically and it's progressively enhanced it means that we can progressively enhance in the browser with JavaScript should we need to again doing this little side-by-side comparison of the lamp stack and the jam stack once again we've moved the stack up a level closer to the browser closer to the user now when we were building things with a lamp stack of course that's not where it stopped we were of course rendering HTML we were outputting markup and we're outputting JavaScript potentially and maybe even calling api's in the in the front end so in some ways this the lamp stack was all of this with the jam stack we're kind of focusing down and narrowing things and it's again this kind of simplify all kinds of things including deployments and what have you because whoops because you know we're trying to get away from this scary environment any opportunity we've got to simplify of course is something we should have so if we do a little comparison thinking about you know where we're deploying code here we might be every deploy we might need to get changes to our database service our web service logic on the load balancers logic of the CDN all of these things with the jam stack we're deploying to one place we're deploying to our static host or to our CDN and this deployment process is the kind of thing that you know our build runs either in a continuous integration service or it runs in our local develop development environment and we push it to where we're serving the site from and this decoupling is critical this ability to change what's happening at request time versus what happening in build time and separate the moving parts and then the logic that's really key to kind of simplifying we've become very good at serving static assets on the web over the time that's where we began that's where we started before we we started going crazy with Perl and CGI bins good old days I'm kind of glancing across a handy Davies wherever he is there he is I know that your URI or Perl guy won't you yeah you lost the CGI bin but we're getting really good at hosting kind of static static assets now and that's the key now when we can optimize getting our things to the CDN that deployment process can become much much simpler there are loads of tools and services that can help with this I work for one of them I work for Neto Phi but there are others others to consider as well the top one at the top of the slide there is surge which has been around for for a while as well which lets you know install via NPM this kind of command-line tool that when you run it it will take your folder that you're in your working directory and and pump the contents of that up to up to their static hosting infrastructure the one at the bottom there's I now have a similar kind of set of tooling again trying to make it easier to get things to a CDN get things hosted statically and of course like some of the big players the big cloud hosting providers like as your AWS Google Cloud and they also are working on ways to make it easier and easier to get things up on to the crowd get things hosted in an automated way so there are lots of players here all of them kind of behind the scenes are working on this notion of yeah you'll be running a build somewhere that might be a static site generator or something similar to that that takes content templates data the kind of things that were happening at the the PHP level in the lamp stack and generating this kind of static set of resources that we can review locally but also can get pushed to some hosting environments ideally off to a CDN for an optimal experience there is a there are lots of different ways that we can run this deployment and I'm not going to go into too many details of those today I might touch on them a little bit but before I do anything else I actually want to address like whoa that's bright for I want to address a common misconception and I set myself up for this really because you know this name Jam stack and I said Jam stack is JavaScript API sand markup the issue is that it doesn't need to be JavaScript and api's and markup every single one of these is kind of optional you can use as much or as little of these as you like no the key really is in the fact that this is statically served it's served without an origin server so you could very easily have something that I would consider to be a jam stack site that didn't include all of these things let's let's kind of explore that a tiny bit more and you know if the site was again it's small for people in the back so apologies but I read these out so if this is a site that was perhaps generated with Jekyll you know a static site generator that runs in the Ruby runtime interpreting yeah more files where the content is to deliver a site that maybe doesn't have any JavaScript at all isn't making any request to any api's and it's served on github pages that's is that a jam stack say yes absolutely years what about using Gatsby which is a static site generator that many of you might have encounters which is a JavaScript based running in the react kind of ecosystem maybe this is taking content from markdown files maybe it's query and content from graph QL api's it's doing hydration using javascript in the front-end in the browser as well it's served from Amazon s3 perhaps that's a jam stack site as well we move along you know Hugo a static site generator built on go again maybe using markdown it's content adding some JavaScript interactions but not calling any other api's serving it on Google clouds that's jam stack next if you're more of a view person static site generator taking things like JSON files adding JavaScript interactions may be calling commerce API is to do e-commerce served on something like net if I perhaps absolutely a jam stack site and then this last example maybe you're an artisan and you're kind of got a hand roll your own JavaScript with no frameworks and build a progressive web app compile it all together using webpack maybe using something like JSON web tokens for authentication to some API service somewhere using browser API is for goodness knows what servicing on expose your yeah that's jump stack as well the whole point is this is that it's a really broad ecosystem lots of things could be considered gem stack but all of these things share one anything in common which you definitely can't see and that is that none of them have an Origin server that's the thing that they share in common and that's the thing that I think makes these things Jam stack because remember Jam stack means they're capable they're being served directly from a CDN okay so what are the kind of impacts and implications of this now that we've defined a little bit well let's start with security security is something that's you know top of mind when we're delivering things out to the web and with a jam stack we've got a greatly reduced surface area for attack you know we'll go back to this kind of friendly diagram once again and think about places where we might experience some kind of a of an attack you know we have to think about how we secure the load balancer we have to think about how we secure the the web server and the database and make sure that those things aren't susceptible to any kind of attack indeed the CDN you know we have to think about that as well now the more static that CDN is the more static the assets are and the less logic that's executed there the fewer things that can actually be be done to that I mean maybe we might experience some kind of denial of service attack by trying to flood it with with requests but that's that's more of a scaling issue than a security issue so by reducing you know the number of pieces of infrastructure that are serving in a request we end up with far fewer moving parts that could be attacked but Netta PHY we run our own CDN and as a result we get the you know the luxury of being out to see what kind of traffic is passing across it what requests are coming in and overwhelmingly we have this huge amount of traffic a huge proportion of traffic which is making a request so all of the domains that live on notify and looking for wp-admin you know the admin console for for WordPress there is no such thing anywhere on Metro 5 because we won't run WordPress biggest is a static hosting infrastructure so it's not on the lamp stack I love the fact that we're one or two people who redirect wp-admin of their sites to to youtube and to rickrolling people but I I'm not sure that all of these these attacks are actually coming from someone like typing in domain and visiting and looking in their browser I get I think it's a little bit more automated than that but I like I like the notion nonetheless but it's this decoupling that's key here you know the what's happening at runtime versus at request time versus build time is quite different there are no moving parts in this environment to be to be attacked all the moving and paths are decoupled and they happen way before time at deployment time in a build time rather than a request time this as you might imagine has an implication for performance as well let's go back to our faithful diagram here just by simple virtue of the distance that the request has to travel and the systems that hist has to interact with it is faster by default will often find that traditional whoops the traditional stacks will start to introduce effectively static layers into the stack to try and speed things up I'm talking about you know caching we think about where we might try and optimize things for performance here we are likely to put some caching into our web servers and potentially cache common queries to our database servers throughout the stack even to the load level and the CDN itself is a giant cache the bottom of the diagram everything is in a cache everything is served from this content delivery network and everything is effectively cached there at deploy time the level at the top we're adding these layers they actually start to move as closer to things behaving as a static site but we still have to maintain the logic of what gets served statically what's dynamic how do we control the logic that so where it's set up for for performance in a much better way on this simplified stack this kind of touches on scale as well and when I'm talking about scale I'm talking about trying to handle large levels of loads traditional stacks will will typically add infrastructure to the equation in order to scale out yes our caching layers that we put in will help us for sure but ultimately when we're trying to figure out how do we service millions of requests what typically happens is we'll start adding more more machines to our stack of web servers to our database servers potentially to our load balancers will have more load balancers as well so there's lots of complexity that kind of creeps in and as someone who's worked in technical architecture and planning and scoping and costing these kind of things and being asked how how many servers do you need for your four websites well how many how much traffic really yeah mm-hm it's challenging it's really difficult so if we can simplify this I'm all for that this touches as well on developer experience and I'm cautious about using the phrase developer experience because sometimes we kind of get tempted into this feeling the developer experience is the be-all and end-all and it Trump's user experience and that's not what I think I think that a good developer experience unlocks the capability of creating a great user experience it gets cruft and friction out of the way so that we can focus on the nuance and the subtlety of building something that's great in this environment again you know where the work we're doing is kind of down in this this section at the bottom where the build is happening we're taking as read that's serving it is a Souls problem make a static hosting is something we've become very good out on the internet so really we're focusing down here you know where our build is and this is a really well defined problem space for us and critically we've got like freedom to make some decisions here here we're not coupled to the hosting architecture and the cogs and pieces of machinery that have to turn there I love the fact that this introduces freedom and introduces choices gives us the freedom you know from the technical strip constraints of sometimes potentially pretty exotic platforms content management systems hosting infrastructure they can often you know teat night take you down a particular route for building and serving sites and it gives you the choice of the kind of tools and approaches that you want in the best fit your team and best fit the kind of project you're building it's not forcing your hand you can choose what you like but the other thing it gives you is this confidence the fact that you don't have to deploy to all of these different moving parts at the same time means that you can deploy with real confidence and I'm going to show you a little example of that in just a second and what that's talking about but I think that a Jam stack our site confer more easily be have immutable and atomic deploys and that sounds a bit buzzword he so what what are we talking about well when I was when I'm talking about an atomic deploy I mean that the site the the deployment itself is only valid when all of it is they're self-contained together you know you're not in a situation where you've got like a partial deployment if you think about those lines and boxes we had within like databases and load balancers and web servers we've got to make changes on all of those things and they those changes arrive at different times potentially so you can get yourself into a position where not everything changes at exactly the same time an immutable deployment is again it's kind of related and this is unlocked by virtue of the fact that we're serving static assets and immutable deploy by it's very different definition it's not mutating the state of the server we're not making incremental changes on a server what we're doing is we're taking this whole atomic change and we're saying here it is this is a new state of the site and that can live on in perpetuity and it means that we can do things like roll back from one version to another and all of these things get unlocks purely because we're we're hosting something effectively statically so I'm going to do something which is either brave or silly I'm going to go and look at my own websites no can i let's see here we are no you can't see that hang on I decided to unnerve and the notification is need more displays never has that never has that been bought true all right well let's let's let's try this this this will be easy okay all right all right let's see if I can just see if I can do this this is this is excruciating but it will be fine okay so what I'm doing is I am looking at so forgive me I'm going to show you something in net the fie to make the point discuss all I know best this is where I work but the principle is something that is now unlocked by virtue of this beam statically hosted from a CDN I'm gonna look at deploys so I'm looking here at the list of all of the deployments that have happened on my sites now each of these each of these sections is a deploy and I mentioned this this kind of notion of immutability the fact that these these taboos can live on forever and each one of these in fact has its own URL I should let me so I'll show you what it looks like now so this is this is my my site it just no it's just a it's just a just a blog that's not it's not getting the traffic I think it deserves its one but critically you know here so here is my I got a mouse there is so each of these deployments is something that's happened in the past I did one today at quarter to one that and automatically because I tweeted and every time I tweet it does a deploy it pulls in my tweets it puts them on the page but I can do things like I could go back as far in time as I dare to the very beginning I can look at their look at their sites this is what it looked like back in 2016 and surprise surprise I was banging on about the jam stack then as well so this is you know this is what the site whoops this is what the site kind of looks like then and you know and it has this URL that you might just have to say my word for it went sir so it has this some unique URL which is unique for that for that deployment I've really messed with the monitor when I when I did the zoom I'm sorry I'm sorry I promise not to do that again but if I if I wanted to what I could do is I could find my mouse any anyone see a mouse on there I know it's there Thanks honestly I don't know what I expected you to do so if I go to this deployment itself I could see the deploy logs that happened when it built and if I wanted I could say publish that deploy so now you know since this is a static site which is already hosted on the CDN if I go back to my actual site and if I can have refreshed that now I published that to the world so if you were to go to my site I'm sure you're on there already bless you that he would now have step back in time to 2016 and that's because you know we're we're hosting things statically um I'm gonna put it back I think this might take me a moment because I can't see what I'm doing deploys today okay so I'll go back here so publish that deploy publish oops hopefully now okay so we're back to normal this is kind of the advantage of having immutable deploys that live on in perpetuity there's not lots of moving parts the work was done ahead of time so now if we're simply kind of flicking versions around from one one to the next but you might say well that's a that's a simple come on at the top is this fun for you is everyone doing okay my discover is fun thank you oh there it is I'm almost there I won't be dabbling here for too much longer biggest that would be insanity yeah it doesn't it's not picking it up for somebody the same same deal yeah I'm doing the jiggle I'm doing the mouse jiggle as well but so what I just showed you was kind of simple right it was just a blogger is pre-rendered but what if you were building an application it was crawling lots of api's and it was there's more like a web app than a website well this that I'm looking at this is a this is a website a web app you know it's a react web so if I was to go into the the site for the admin for this itself god this is this is dangerous especially since I can't actually see what the hell I'm doing so Netta fire is built and ferb donnetta Phi so this UI is a jam stack sites that served froth as a reacts app from our own hosting infrastructure so I could in the same way if I go to the deploys or this is the potential for a screw-up is massive here yeah so what I'm I'm not gonna keep just paging through them all because I don't want to give away secrets eight there's more than 800 pages of deploys on here as you imagine we've been deploying for a while but we could do something like let's go and look at the production version of this from February 2017 and open that up and this is what the come on there we are this is what the web app looks back in like in 2017 was going to login hopefully ha oh this this might just be a bridge too far for me to demonstrate over my shoulder it's probably just as well because I don't want you to see me accidentally deploy a two year old version of the site a couple of things would happen it would be impressive and I'd be fired okay I'm I'm trying I'm going to try and come back to safety here that was a voyage of discovery wasn't it okay okay so what I'm asking myself that how never has that been more opportune you know net the fire is a net the phi site hosted on net the phi but ultimately it's a jam stack site it's a bunch of static assets from a CDN that's talking to a bunch of AP is let's mention AP ice and services for a moment or two there's a bunch of different things that this unlocks if you have an api kind of base model for your for your sites and applications you can access port services so those might be things that you're accessing either through the browser runtime or potentially at build time in your build so we might be doing things like pulling content from content management systems there's a number of them that exists you know where you might be pulling the the data from those into our build generating the site and outputting it or we might be doing it in the browser we might be hot we might be serving assets from something like cloud inori or some api that lifts on the web that can serve our assets for us and do transformations we might be doing things like commerce and there's a bunch of different vendors that continue ecommerce for us now again as a progressive enhancement in the browser through javascript and even things like identity you know using things like all-zero or auth all of these things expose api is that we can then consume and so we don't have to build all of these things internally and become experts in all of these things the kind of team you need to be an expert in everything here is kind of large but in addition to port services there's also the fact that this model unlocks a much simpler way to build your own services you know you might be thinking I'm advocating for just only building static sites and just just that static HTML but actually this model is great if you also have api's that you build yourself I kind of almost got to show you that with Netta fire cells where we've got a static site and a bunch of API is to drive it so in this way you know we can start to add to these other services our own core capabilities we might be building those things out as api's ourselves that live in a different stack that have just a very focused set of jobs and roles um occasionally you know you absolutely need some kind of logic that runs on a server and that's where things like service functions can come come to the rescue I'm cautious about saying the word service because people will say think you'll find as a server running there somewhere fill and to which I answer well your wireless router at home so I thought I don't know far with my phone like to instill them I thought I'd been cut off I've always liked which would be fair so when I'm talking about service I'm talking about functions as a service and I'm not going to go into that now because I just don't have the time but there are fantastic companion to the jam stack you know they're this great way of creating very focused services that can embellish things that you can call via api's so I just got a couple of minutes left so let's just to show a couple of quick examples and results sites like this like react Jas says it's a jam stack site hosted statically as this yarn and view those will kind of feel kind of similar in terms of yes they're very large load and large audiences but they're they're kind of simple kind of static kind of sites this is a great one it's a documentation site from Citrix which is a multilingual site that they've gradually moved away from this huge technology stack finding one area of their site that would fit this model perfectly and sending that traffic to being on static servers and they did a great talk at the JumpStart conference in New York that happened a few weeks ago where Beth Pollak who's part of the team at Citrix talked about the turnaround time for updates went from weeks to minutes and she's talking about not just code but also content because some of these big systems can have really slow turnaround times for updates so that was a great result for them in fact they said it kind of reduce the cost by about 65% building this way so the results are really impressive um a slightly different kind of sights to those that we just seen before one that might be a bit surprising is the Smashing Magazine no is a jam spec site it's hosted statically and this isn't just articles and things that were posted once upon a time on WordPress but now static there's other things here you know there's a membership area that has log in there's ecommerce there's there's a job board all kinds of things at one point it was on five different platforms running and now it's on one because it's statically generated and then hosted on a CDN um literally Friedman who was involved in there in the project here talked about having lots of caching issues at the site and took me probably had every word press press caching plug-in there is out there and then you know by going Jam stack they changed their time to first load from 800 milliseconds down to 80 so it's a 10x improvement in performance I'm gonna skip I'm going to skip to the end because I'm I'm kind of I'm kind of out of time but I wanted to kind of just describe that we can serve a variety of sites in this way you know I asked about what is the jam stack at the beginning and I'd say that Jam stack sites are rendered in advance they're not - they're not dependent on an Origin server that's the kind of thing that's key they can be progressively enhancing the browser with JavaScript but you don't have to use javascript remember there was kind of the core attributes of gemsto sites it's this modern architecture for fast and secure sites without web servers this talk has got this these slides I've got a bunch of different links and resources should you wish to have them I will tweet oh sorry I was very quick people taking pictures what I'll do is I will tweet at the during the rest of the day using the pixel pioneers hashtag the link to these slides so you can get these and kind of peruse them at your leisure thank you for bearing with me with the over-the-shoulder demo and thanks for attention thanks a lot you you