Opt in Design – The New Era of React Frameworks

Rate this content
Bookmark

Picking up a new technology, developers stick with defaults. It's a fact that every tool from JQuery to NextJS has needed to face. At their worst, defaults ship hundreds of wasted JS kilobytes for routing, state, and other baggage developers may never use. But at their best, defaults give us a simple baseline to start from, with a clear path to add the exact set of features our project demands. This is the magic of opt-in design.


Let's see how smart defaults guide modern frontend tools from Astro to React Server Components, and why this new era reshapes your workflow, and performance metrics, for the better.

23 min
23 Oct, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

This Talk discusses opt-in design in web development, focusing on API design and understanding good defaults. Opt-in design allows developers to start with minimal tools and gradually add complexity as needed. The principles of opt-in design include finding the lowest common denominator, making complexity easy to add, and prioritizing the user experience. The Talk also explores the concept of opt-in design in React and Astro, as well as the comparison between React and Solid frameworks. Server rendering and streaming in React are highlighted, along with the importance of suspense boundaries for a better user experience.

Available in Español

1. Introduction to Opt-in Design in Web Development

Short description:

Hello everyone! I'm Ben Holmes, a core maintainer at Astro.build, and today I'll be talking about opt-in design in web development. Opt-in design is not about UI or systems design, but rather API design and understanding good defaults when building tools and frameworks. Let's dive into a classic example of building an app with create React app and how it evolves with added features.

All right, hello, everyone. Hope you all are enjoying the conference. Sad I'm joining you all virtually for this one, but I have a great talk lined up, so I'm hoping that we can make up for it.

My name is Ben Holmes, and I'm going to be talking about opt-in design, which I am boldly dubbing a new era in web development, new trends that I've noticed. So to clarify what is opt-in design, it's not a UI design talk, although graphic design is clearly my passion. It's also not a systems design talk. We're not going to be talking about Kubernetes clusters or anything like that. It's an API design talk, so learning what good defaults mean when you're building a tool or you're using a framework of choice and both finding and building those tools so that we can build the best apps for our users.

So a little extended intro, I'm a core maintainer at Astro.build, so I've been working in open source for a bit and getting paid to do it, which is very rare to do. I'm also the chief whiteboard officer at Astro as well. Unofficial title, of course, but if you've ever seen some videos of a vertical whiteboard online, I do a lot of educational content, might've been me and you can find an archive right over there. And I'm a champion of content formats. So Markdown, MDX, Markdoc, if you've ever used any of those, I love them and I work on maintaining all of those in the Astro framework. So you might see me around the support forums.

So in order to walk you through the journey of building an app for the first time and introducing what opt-in design is, I'm going to talk about, you know, a classic example of how you might've built an app in 2015, 2016 era with create React app. That's where I got started with component systems might've been your learning journey as well. So when you start, you read that blog post from whomever and you're building your hello world for the first time. And you're reaching for tools like React and React dom. You're using a router like React router and you're reaching for some CSS and JS option like style components. So you can co-locate everything. It was pretty nice to use as a developer, but you can see our little, a kilobyte meter at the bottom is going to start ticking up. There's definitely a base cost to using these tools. Then you want to add in more features as your application develops a signup form. For example, in reaction, there's a lot of form libraries that you could use here. Maybe it was for mech back in the earlier days and you're going to be preventing the default behavior of the browser. So you can drive the whole thing with Java script, which of course means larger bundle But you stick with that dev experience that you were kind of told, or you're trying, is a good idea. And then it progresses a little bit further. Now we have a full e-commerce flow, and we want to add a cart bubble to say how many items are in your cart, like the number 2 or something like that. And you need to persist that in storage, maybe you're using Redux to duplicate server state inside of your client, so you don't have to deal with flashes as it's fetching things for the first time, and you're using client-side storage, maybe local storage or something like that. Again, we're going to take up our JavaScript meter a little bit further, because as we add new features, they all have to be replicated in the React bundle, in the React flow.

2. Opt-out and Opt-in Design in Web Development

Short description:

And then you get your performance audit when you've reached a certain state, and you wonder why you have a 39 on your Lighthouse score. That is the pain of an opt-out system. Opt-out means opting out of the default configurations provided by libraries or frameworks. Opt-out requires extra work and knowledge of the concerns. Opt-out can be seen in various areas, such as managing web config, using CSS variables instead of JavaScript, and opting out of React context. The opt-out ethos assumes a goal of a highly interactive app and reduces developer friction, but requires dealing with complexity later during performance audits. Opt-in design, like ASTRO, offers a different approach, allowing developers to start with minimal tools and gradually add complexity as needed.

And then you get your performance audit when you've reached a certain state, and you wonder why you have a 39 on your Lighthouse score. And you were following the blog post. You were doing what the community said was a good idea. But that is the consequence of using a SPA. You're assuming all this reactivity, and you might have to walk things backwards and dig through the React dev tools in order to figure out how you can scrape up those Lighthouse metrics again. And that is the pain of an opt-out system.

So talking about opt-out, what does that really mean? Well, first off, looking at the Create React app library, framework, whatever you want to call it, it has a happy path where they manage a big old web config for you. And if you ever need to modify that or bundle your app in a different way, you need to opt-out, which is using the eject seat, literally just hitting a button and managing it all yourself. Which of course, is a very scary thing to do, which is why many people just stick with Create React app and whatever it gives you, and they avoid opting out of any of the opinions.

We also have style components, where the happy path is using JavaScript first to drive the experience. function in order to drive variables into your CSS, and you can opt-out of any of the client side JavaScript that shifts with your styles by using CSS variables or alternatives instead. And it kind of feels like you're going against the grain, you got to do extra work to get more performance, so it kind of hurts that you have to be knowledgeable about the concerns before you can address them. And opt-out panes of React context. This is the easiest one to understand, honestly, where you're storing state higher up, which is very convenient if you're storing the cart at the top of your application so everyone knows how many items are in the cart. But it's going to be very expensive if that cart ever changes, because as you know, anywhere down the React tree that relies on that state is going to re-render, so you need to opt-out with usememo across anywhere in the app that has intense calculations, which isn't a very fun experience. That, again, is performance auditing. It's not the happy path. We can sum that up into an opt-out ethos. You assume a goal, which is a highly interactive app, and you lower the developer friction to get there, but you need to bundle the best toolbox up front in order to get them there, hiding complexity, and then asking developers to deal with the complexity monster later once they do that performance audit and have to figure out what they could do differently. I want to flip that mindset with the more modern frameworks that we have today. ASTRO is, of course, my favorite example, unbiased opinion as an employee. It's a great way to do opt-in design. We'll start with our Hello World again. In this case, you don't have to cobble together a bunch of tools. You can use ASTRO and static templating in order to just write the Hello World and display it to the user. Zero kilobytes of JavaScript. You're just using HTML and CSS to get there. Then we add that complexity, the signup form, but we can be a little bit smarter about how we do it. Now that it's a static app or maybe a server-driven app, you could use a plain old POST request to an endpoint. Maybe prevent default.

3. Opt-in Design Principles for Web Development

Short description:

Maybe don't. It's up to you. You could use a lightweight library like Zod to validate on the client and get that nice experience where you're typing out an invalid email. Then you want to add your cart bubble again. How many items are in the cart? Maybe you want to do this in a client-driven way with client state. You can opt-in to using a client-side framework with Astro. It's a CLI option, Astro add React, that will install the dependencies and bundle React into whatever pages need it. We have an alternative to that. If you wanted to make it a server-driven experience, you could opt in to server rendering instead. Astro add node would configure your app to be a node server, endpoint by endpoint. Now, when you get to the performance audit, you remember why HTML runs on 3 billion devices. Starting with HTML and progressing from there is a better idea than starting from JavaScript and working your way back to server rendering. Let's sum this up into some opt-in design principles: find the lowest common denominator of your tool, make complexity easy to add, and stay user-first with the API design.

Maybe don't. It's up to you. You could use a lightweight library like Zod in order to validate on the client and get that nice experience where you're typing out an invalid email. Then you make it valid again and it instantly gives you that feedback that you're good. You still want that in your JavaScript bundle. Nobody don't need React to get there. We only take up our JavaScript a little bit, but we still get the same experience.

Then you want to add your cart bubble again. How many items are in the cart? Maybe you want to do this in a client-driven way with client state. You can opt-in to using a client-side framework with Astro. It's a CLI option, Astro add React, that will install the dependencies and bundle React into whatever pages need it. It'll avoid React on pages that don't. Then you can use a lighter weight option, like nanostores, to store that global state. You don't have to deal with as many re-rendering concerns. That will bump up the client-side JS just to the level of React and React-DOM, but it's not adding anything unnecessary on top of it. You chose that path, and you're able to reach for a tool like the Astro CLI to get you there.

We have an alternative to that. If you wanted to make it a server-driven experience, you could opt in to server rendering instead. Astro has a number of adapters for this. Astro add node would configure your app to be a node server, endpoint by endpoint. You can choose which pages are pre-rendered, and then maybe use session storage and middleware to keep track of the user. That takes the client JS back down, and gives you roughly the same experience with some more server state to manage. Now, when you get to the performance audit, you remember why HTML runs on 3 billion devices. I'm joking here, it's poking fun at Java. But yeah, starting with HTML and progressing from there is a better idea than starting from JavaScript and working your way back to server rendering. It's just nice to start with the server, because that's what's going to compute things a little bit faster and avoid client-side stuff. So now let's sum this up into some opt-in design principles. First, you want to find the lowest common denominator of your tool. You also want to make complexity easy to add, only when intended. And you want to stay user-first with the API design, not developer-first.

4. Principles of Opt-in Design in Web Development

Short description:

These are three principles that guided how Astro was built: find the lowest common denominator, make complexity easy to add, and stay user-first. By understanding the simplest use case, adding complexity only when intended, and prioritizing the user experience, tools like Astro enable opt-in design. An example is Deno, which brings opt-in permissions, allowing users to control access to their system resources. This approach aligns with the principles of finding the lowest common denominator, adding complexity with simple flags, and prioritizing the user's needs.

These are three principles that guided how Astro was built, and I'm gonna dig into each of these in depth. So the first one, find the lowest common denominator. What's the simplest use case for the tool that you're using? For a Create React app, the simplest one is ship some HTML without any state, that's a hello world. You want to be smart and not have a car with opt-in wheels, for example. You don't want a framework that doesn't help you do anything at all, and you have to add a plugin to render HTML. But as long as you understand what the smallest use case is for your target audience, you can get there.

Also, you want to make complexity easy to add, only when intended. Don't start with a kitchen sink like a Create React app that you have to eject out of. Instead, you want to add really simple switches to opt into things that are more complex, like Astro's CLI, to add React when you want to add interactivity. Lastly, you want to stay user-first as you're building a tool, or you want to choose tools that are user-first. Developer experience does matter, but it needs to be guided by what the user experience is once it ships. So you want the low-complexity baseline for the base of the experience, the LCD, and an is opting into re-renders, which means fewer CPU cycles, better performance. And performance isn't the only user metric you can talk about. You can also measure the security of an application, for example. And I have a little Deno flag to show you there. So whole world of examples that I can reach for here to explain it. Deno, as I mentioned, it brings opt-in to permissions. Whenever you're running a CLI task, it may need to reach out into the world and access things on your system. And it shouldn't be able to do that willy-nilly. You should be able to say, I want to allow network access. I want to let you read from my file system. I want to let you access my environment variables. But without these flags, you're not allowed to do that. It's crazy when you log process dot env and node, and you realize just how much it has access to. It would be nice if we can make that opt-in instead. So how does this address our three principles? Well, first off, this is the lowest common denominator. The simplest thing you can build with DNO is just a CLI tool, maybe a text adventure game, without any IO. And then you can add complexity with simple flags that describe what's added. So no foot guns here. And it is user-first.

5. Opt-in Design in React and Astro

Short description:

We care about security vulnerabilities and opt-in design. Server components and client-side JavaScript opt-in are hot topics in React and Astro. Opt-in allows you to import components in any framework and load JavaScript when it's visible on the page. It also brings opt-in to streaming, allowing you to stream information from a server without much client-side JavaScript. React server components enhance server rendering by using React Suspense to show a placeholder and stream in information when it's available.

You know, we're caring about security vulnerabilities, opt-in, whenever security needs to be addressed. And the user understands what is being allowed. And also we can talk about server components.

You know, it's a hotness in React. Also in Astro. It brings opt-in to client-side JS, which of course is not a root evil or anything. It's just something that you want to be mindful about and only reach for when you need it.

So in this example, I have an Astro template. Static HTML is the default. And if you want to reach for client-side interactivity, you can import a component built in any framework, including React, maybe solid, maybe view, maybe Svelte. And you can opt-in to client-side JavaScript using a client directive. This is saying load JavaScript when the component's visible on the page. And again, lowest common denominator, static home page, nice default to have. Added complexity. Yes, the client directive is how you opt-in to client-side JavaScript, with granular control for when the JavaScript is loaded, like when it's visible. And this of course is user first. We care about those core web vitals. We know HTML is a good starting point. That's where we're going to start you when you're building your app as well. And it also brings opt-in to streaming.

So React server components are a little spicier, they have more going on for server rendering your application. You notice in this example, we'll have a live code demo to dig into this a little bit more. But you know, it starts with static HTML, like our Astro example, and it also allows you to stream information from a server without much client-side JavaScript to render it on the page. So in this example, maybe we have an Albums component. This Albums component fetches from a database, grabs some albums, and displays them to the user. But maybe it relies on a third-party API that takes time. You know, we can't speed up this third-party client, it takes a second to load, but we still want to show the user something. So it's not just a spinner in their browser for one to two seconds that they can't control. So we load up our Albums component, call that third-party API, and we use React Suspense to show a placeholder and stream in the information when it's available. And we're not doing this with client-side loading spinners and if else's, we're letting React handle it and Next.js is the framework on top that's able to manage it for us.

6. Opt-in Design and Server Rendering with Spinners

Short description:

This part discusses the concept of opt-in design in web development, specifically focusing on server rendering and the use of spinners. It highlights the default behavior of not streaming and waiting for server processes to complete, but also provides the option to opt in to spinners for a more interactive experience. The importance of considering layout shift and using suspense boundaries is emphasized to prioritize the user experience.

So yeah, this assumes the lowest denominator, which is, again, server rendering everything without spinners, so our heading is not gonna be inside of the spinner, we can just ship that straightaway. And it's additive complexity. Of course, streaming is more complex than not streaming. So the default is don't stream it, just block and wait for all the server stuff to be done. And if you want to opt in to spinners, which can have layout shift, understand the risk, you can add a suspense boundary to say what fallback you want to show while that server's resolving. And of course, that is user first, we care about the layout shift, we want to avoid that as much as we can. But when it's necessary, when we can't control it, let's reach for suspense. Let's try to give you some feedback straight away, it just feels a bit snappier.

7. Comparison of React and Solid Frameworks

Short description:

So let's compare react and solid here. Solid is a declarative JavaScript framework with fast UIs and maximum control over reactivity. It brings opt-in to the component level, allowing for more precise updates. In a shopping cart example, Solid ensures that only the necessary parts, such as the price, are recomputed when the quantity changes. React, on the other hand, assumes that everything should re-render by default. This can lead to unnecessary recalculations and potential performance issues.

So I obviously can't do this in person. So I can't see your hands. But I'm assuming this has happened to you at some point in your react journey, where you call on use effects, you forget your dependency array. And things happen. You don't need a performance audit to know that there's probably something wrong going on here. And that's because of reacts reactivity model.

So I'm gonna breeze through this pretty quickly. Let's compare react and solid here. So solid is a declarative JavaScript framework fast UIs, maximum control over reactivity. It's a new hotness. It's from fireship, the second best YouTuber that quoted this second best because I'm on the platform. Okay?

So let me show you an example of how we can bring opt in to the component level, which you may not have seen before I have two components here, one built in, react, and one built in solid, you'll notice that at first glance. They look almost the same, but there is one subtle difference that I've highlighted right here. So we're building a shopping cart, right? We have our quantity, which is how many things are in the cart. We have our price, which is based on how many things are there. And then we have some unrelated server side fetches to resolve. Like getting the product images and getting the shipping text. So a few things going on that all display info about the product. And we can write this with JSX as you would expect. But the one interesting part is this dependency that we're drawing here. Price depends on quantity, so it needs to recompute anytime quantity changes. And if we pull up how these are written, React and Solid, I have working demos right here. You can see when you click on the React example it's going to update the price every time quantity updates. But it's also going to rerun product images and shipping text because you need to care about useEffect and useMemo and all these other things to prevent other stuff from recalculating behind the scenes which you might need to reach for developer tools to even figure out is going on. I made it really obvious here, but it might not be so obvious in your app. So React assumed you want everything to re-render. That's the simplest mental model, so they went with this approach here. Which it can be a little scary. It's a little foot gunny. Now Solid takes the opposite approach.

8. Opt-in Design and React Server Components

Short description:

Instead of re-running the whole component any time state changes, it's just going to re-run the part of the page that cares about that state. So in Solid, for example, if you want to declare dependencies, like price depends on quantity, you can just create an execution function. And Svelte does the same thing. They all kind of work like this, and we're converging on a model of signals in order to manage this. Lastly, I'll leave you with a little demo on a repo called simple-rsc, which shows you how React Server Components work outside of Next.js.

Instead of re-running the whole component any time state changes, it's just going to re-run the part of the page that cares about that state. It's just going to re-render the quantity every time quantity updates. And it won't update product images and shipping text, yay, but it won't even update price. You have to be very specific about what parts of the page re-render.

So in Solid, for example, if you want to declare dependencies, like price depends on quantity, you can just create an execution function. And, the Solid Compiler is smart enough to say, alright, this is a function now, I'm going to trace the dependencies inside of this function, quantity, and I'm going to re-run that function any time one of those dependencies changes. So not even a dependency array, so it's just smart. Now that we've made this function, we can see that Solid will update price. But unlike the React problem, we're not going to reload anything else that doesn't depend on quantity, because again, you opt into reactivity with functions. So that's how the whole framework works, and it's a really nice primitive. And, we'll see this in modern examples like Svelte, and Vue, and Angular, they all are based on this model of where the initial state is going to be run once, and then we only rerun wherever state is used. So we rerun the JSX element right here instead of rerunning your function top to bottom as you would in React. Cool little trick, cool little mental model.

And Svelte does the same thing. Using the dollar sign operator, and this is changing in future versions, apparently to a state operator, that will rerun price whenever quantity changes. Same sort of flag to say, hey compiler, look at the dependencies, re-render this stuff whenever those dependencies change. They all kind of work like this, and we're converging on a model of signals in order to manage this.

So, lastly I'll leave you with a little demo, looks like I have about two minutes, but I'll you know, speed run this, see what we can get to. It's on a repo called simple-rsc. So if after the talk, you want to try out this tool, even contribute improvements to it, I definitely welcome it. But it's a basic benchmark that shows you how React Server Components work outside of Next.js. So you can understand the mental model of Server Components, what they really do. So, I have that code pulled up right here, we're going to zoom in for you all just a little bit. And we can see we have our server root, this is just a page that's rendering, don't worry too much about that. And we're just rendering the static text, abramix. I built this with Dan Abramov on Stream. It's a Spotify clone, so Abramov, Abramix. I thought it was funny, okay? I thought it was funny. But yeah. It's just rendering this static text right here.

9. Server Rendering and Streaming in React

Short description:

In React, we can stream HTML as soon as it's available, without shipping a component to the client. Server rendering and server-side fetching can be used to display complex data. By streaming only necessary information, we can avoid sending unnecessary data. Adding suspense boundaries can improve the user experience by showing content while waiting for the rest to load. React's future looks promising with its server-driven approach. Check out the demo and join the Astro Discord for more support.

And if we pop over to our browser, which I'll go ahead and do right here, we can see our static text rendering to the page. And also a dev panel that shows you what information is being sent over to Wire to show this. So in React, these are very truncated server messages that tell React, construct an H1 with the child abramix. And we're not shipping a component to the client to do this, we're literally just streaming in HTML as soon as it's available.

And you can even server render that up front, so you don't have to wait for the server stream to come down. And we can get a little bit more complex if we want to by doing some server side fetching and seeing what that gives us. So I have an album component here that fetches from a dummy database and it renders a little search box with client-side JavaScript to search for albums in that list to re-fetch everything from the server. So I'm just gonna pass down this query here, don't worry too much about that. But we're just rendering an albums component to the page that's gonna do all of our server fetching and if we head back, oh that's the actual Spotify, if we head back to our browser we can see all of that coming into view.

So you can see it is blocking. We're now waiting a solid second for the database to load and for everything to be available because that's the default in React. Just block on everything so that there's no layout shift and we can show you that information. And it'll stream in just the info about the albums that we need on the page. This is kind of why it's like a modern GraphQL if you really think about it, where you don't have to be smart about what data you're codifying as JSON. It's just going to send down HTML. So as long as you're smart about fetching from a database, rendering what you need, you don't have to worry about sending stuff you don't. It's going to stream exactly what's necessary for the page. And if we decide, you know what, that one second wait is a bit long, I don't really want to wait for that, we can add a suspense boundary in here to unblock our heading. To show the heading straight away, and then show a little placeholder while the albums are loading into view. So we can see that, and I'll refresh a few times to show you what's going on. We can see Abramix streams from the server straight away. Then we show our loading spinner while the database loads, and then the server streams in the rest of the information a bit later. And React is smart enough to resolve that onto the page based on how you structure your component tree. Cool, little trick. Definitely excited about the future of React, and just making everything driven by the server, but keeping it in JSX. It's something Astro's been doing for a while, and I think React is codifying it in a really nice way. All right, so that's what I wanted to leave you with. Check out the demo if you want. And if you want to, you know, show your support to Astro and other opt-in frameworks, you can join the Astro Discord, astro.build slash chat, and you can find me everywhere at bhomestev if you enjoy my teaching style for some reason. All right.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.

Workshops on related topic

JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
React Day Berlin 2023React Day Berlin 2023
119 min
Crash course into Astro and Storyblok
WorkshopFree
Headless architecture has gained immense popularity in recent years for its ability to decouple the frontend and backend, empowering developers to create engaging, interactive, and scalable web applications. 
In this workshop, we will quickly take a dive into the Headless World and Architecture. 
Additionally, we will build a blog website super quickly using Storyblok, a headless CMS that offers a real-time preview feature with nestable component approach, and Astro (3.0) which is already creating a buzz with the new app directory. 
- Master headless CMS fundamentals- Master an Astro & headless CMS approach- Use Atomic design in your Astro & Storyblok application- Creating pages, adding content and understanding how the dynamic routing works with headless
Node Congress 2021Node Congress 2021
128 min
Learn Fastify One Plugin at a Time
Workshop
Fastify is an HTTP framework for Node.js that focuses on providing a good developer experience without compromising on performance metrics. What makes Fastify special are not its technical details, but its community which is wide open for contributions of any kind. Part of the secret sauce is Fastify plugin architecture that enabled developers to write more than a hundred plugins.This hands-on workshop is structured around a series of exercises that covers from basics "hello world", to how to structure a project, perform database access and authentication.

https://github.com/nearform/the-fastify-workshop
JSNation 2023JSNation 2023
66 min
Build a Universal Reactive Data Library with Starbeam
WorkshopFree
This session will focus on Starbeam's universal building blocks. We'll use Starbeam to build a data library that works in multiple frameworks.We'll write a library that caches and updates data, and supports relationships, sorting and filtering.Rather than fetching data directly, it will work with asynchronously fetched data, including data fetched after initial render. Data fetched and updated through web sockets will also work well.All of these features will be reactive, of course.Imagine you filter your data by its title, and then you update the title of a record to match the filter: any output relying on the filtered data will update to reflect the updated filter.In 90 minutes, you'll build an awesome reactive data library and learn a powerful new tool for building reactive systems. The best part: the library works in any framework, even though you don't think about (or depend on) any framework when you built it.
Table of contents- Storing a Fetched Record in a Cell- Storing multiple records in a reactive Map- Reactive iteration is normal iteration- Reactive filtering is normal filtering- Fetching more records and updating the Map- Reactive sorting is normal sorting (is this getting a bit repetitive?)- Modelling cache invalidation as data- Bonus: reactive relationships
React Summit 2023React Summit 2023
91 min
Crash Course Into Astro, Kontent.ai and Portable Text
WorkshopFree
During this crash course, we’ll create a new project in the headless CMS, create the content model and data using the Kontent.ai CLI. Then, we’ll use the content to build an Astro website including front-end components and rich text resolution using Portable Text.
This will be hands-on workshop, you’ll need VS Code, Git, NPM and basic knowledge of JavaScript. Don’t worry, I will explain all the steps as we advance through the workshop and you will be able to directly ask any questions.