Keeping It Simple

Hi, everybody. I'm Matt Bihlmann, CEO and co-founder of Netlify. Today, I'm going to talk about simplicity and state and the dangers of steering our communities towards complexity.

So, back in 2013, React launched as a view layer that brought simplicity to the process of building browser-based applications. Anyone that's tried to build a browser-based application before React had to deal with this mix of state all over the DOM. You would have bindings listening to DOM elements. You would have DOM elements that contained states. You would have AJAX listeners that would fetch, request, and update DOM elements, and as you build out more complex applications, reasoning about what state your DOM was in and what state your application went in and what a user would experience became increasingly hard. React launched this idea of turning the whole UI into a function of your state, and it really made it so much easier to reason about what experiences our users were having based on any given state. You could take a state, feed it to a tree of DOM of React components, and you would know for any given state what the user would see. React fundamentally made it easy to reason a bit about the state of your application, and that was one of the superpowers that made React powerful and adopted.

Of course, as we want React to solve harder and harder problems for us and solve more of the problems of building applications, we're introducing a lot of new concepts like context or hooks or the new proposed server components or streaming. And as we go along this way, of course it's important to be curious and excited and explore where we can go, but it's also important that we try to keep, keeping ourselves honest, do we still know what is the current state of our application? And do we know at any given time what will a user experience for a given state? This was like the initial superpower that gave React a feeling of simplicity and that made applications easy to reason about. So as we evolve React as a more complete framework, how do we keep that quality?

And the idea back then was very similar. I had seen how over time, web development had made it harder and harder to reason about the state of your web property. We had started out from a world where a browser would fetch files from a server to a world where we would run a program to a world where that program would always talk to a database for every request and to a world where to scale that architecture, we started introducing different layers of caching between servers and databases as the web grew global and we needed to reach users all over the world.

We introduced CDNs for assets or images or JavaScript files and to understand our system as developers, we had to be able to reason about all of these different layers of the stack. The GAM stack was really an architectural approach to say, how can we make it easy to reason about the state of your web property? How can we go towards an architectural approach to building for the web? When instead of this complex request response cycle flowing through all these different layers of caching, we take code and we take your content, your APIs or your data, we run a build and we deploy immutable assets to an edge network.

And as we do that, we start introducing this idea of atomic deploys where you always know you have a state, you've deployed, it's live. You know exactly what documents and HTML pages has been built as part of that. And when you change to a new deploy, it's an atomic operation where everything goes live at the same time and where you always know if a user visits a URL, what are they going to see? Now, in a similar way as with React, as we want the GAMSTAG architecture to solve more and more complex problems for us and build more and more applications in the gray zone of all that kinds of different use cases, we also starting to see more and more complex concepts introduced into the stack, rehydration, dynamic SSR for some pages, tiered CDN caching, approaches like incremental static regeneration and stale while revalidates HTTP headers. And in the same way as with React, as we built this future, we have to really ask ourselves, do you know what is currently deployed at any stage? And do you know what a user will experience if they visit a given URL? Do you know exactly what happens if you roll back to an earlier deploy? And do you know what happens if you push a deploy preview number 110 to the main branch right now? Now, of course, one of the reasons that we are exploring a lot of these new concepts like incremental static regeneration and stale while virality is because we're trying to build increasingly large projects with a JAMstack approach, especially large e-commerce projects with hundreds of thousands or even million of catalog pages have proven challenging.