Netlify CEO and co-founder Matt Biilmann reflects on the history of React, the promises of the Jamstack, and the complexity that can creep into developer workflows if we don't continue to defend simplicity over time. In this lightning talk, Matt describes the trade-offs developers face to deliver large sites and introduces a new idea for a more scalable future solution.
Keeping It Simple
AI Generated Video Summary
React brought simplicity to building browser-based applications, but as new concepts like context, hooks, server components, and streaming are introduced, it's important to know the current state of the application. The JAMstack simplifies reasoning about the state of web properties through immutable assets and atomic deploys. However, as the JAMstack evolves, challenges arise in areas such as build times and API caching for large projects, especially e-commerce.
1. Introduction to React and Simplicity
Today, I'm going to talk about simplicity and state and the dangers of steering our communities towards complexity. React launched as a view layer that brought simplicity to the process of building browser-based applications. It made it so much easier to reason about what experiences our users were having based on any given state. As we want React to solve harder problems, we're introducing new concepts like context, hooks, server components, and streaming. But it's important to keep ourselves honest and know the current state of our application and what a user will experience.
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?
2. Reasoning about State and Challenges in JAMstack
Web development has made it harder to reason about the state of your web property. The GAM stack simplifies reasoning about the state of your web property by deploying immutable assets to an edge network. Atomic deploys ensure that you always know the state of your deployment. As the JAMstack architecture evolves, more complex concepts are introduced, such as rehydration, dynamic SSR, and incremental static regeneration. It is important to know what is currently deployed, what a user will experience, and the impact of rollbacks or deploy previews. Large JAMstack projects, especially e-commerce, face challenges in build times and API caching.
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.
Comments