Angular Renaissance

For the past 18 months Angular has been experiencing a lot of momentum that the community has been referring to as the "Angular Renaissance."

In this talk we'll see how this manifests in improvements in developer experience, performance, documentation, and a better look!

Rate this content
Bookmark
Video Summary and Transcription
In the video, the discussion revolves around the similarities and differences between Angular and React, particularly focusing on their reactivity models. Both frameworks keep the state inside components in sync with the UI by traversing the component tree to detect and reflect state changes. Angular's exploration of optimizing change detection through static dependency tracking and signals is highlighted. Signals, which wrap component state and notify the framework of its usage, allow for fine-grain reactivity and are being explored to become part of the web platform. Angular signals have been adopted by YouTube, resulting in significant performance improvements, such as better input latency and smoother swiping on mobile web. The video also covers deferrable views, a feature that allows parts of the template to be lazily loaded, improving initial load times. Partial hydration is introduced as a method to hydrate only certain parts of the UI initially, speeding up the time to interactivity. The build pipeline update to use Vite and ESbuild is discussed, which has led to threefold faster build speeds. The talk also touches on the integration of Wiz and Angular, aiming to add performance features without a rewrite. Minko's role as the product lead for Angular is mentioned, with a focus on supporting developers to deliver web apps confidently. The concept of a "minko alternatives" is not directly addressed, but the emphasis is on Angular's evolution and collaboration with other frameworks. The term "angular renaissance" encapsulates the ongoing advancements and improvements within Angular.
Available in Español: Renacimiento de Angular

FAQ

Despite differences in syntax, Angular and React have similar reactivity models. Both frameworks keep the state inside components in sync with the UI by traversing the component tree to detect and reflect state changes.

Zone.js in Angular is a library that helps to detect when something might have changed in the application so that Angular can schedule change detection accordingly.

Signals in Angular are used to wrap local component state, notifying the framework when and where the state is used, thus optimizing performance by limiting change detection to only the affected parts of the component tree.

Angular and WIS collaborate closely within Google, sharing code and features to meet the blended requirements of enterprise and consumer client applications. For instance, YouTube has adopted Angular signals through WIS for better performance.

Minko is the product lead for Angular at Google, responsible for determining what features to build for Angular, why to build them, and how to share them with developers.

Deferrable views in Angular allow developers to specify parts of the template that can be lazily loaded, improving initial load times by extracting these parts as separate bundles that are loaded only when required.

YouTube observed significant performance improvements with Angular signals, including 35% better input latency on low-end smart TVs and 60 frames per second swiping on YouTube mobile web compared to 25 frames per second with the legacy virtual DOM implementation.

Angular has updated its build pipeline to use Vite and ESbuild out of the box, resulting in faster build speeds. For example, Vanguard reported a threefold improvement in build speeds after switching to the new build pipeline.

Partial hydration in Angular is a feature that allows only certain parts of the UI to be hydrated initially, reducing the amount of JavaScript that needs to be loaded and executed, thus speeding up the time to interactivity.

Angular aims to make RxJS optional, providing better integration with signals. Developers can convert signals to observables and vice versa, allowing flexibility in using either approach based on their needs.

1. Introduction to Angular and React#

Short description:

I'm the product lead for Angular at Google. Angular and React were effectively the same framework. Over 50% of the responsibility of a front-end framework is to keep state inside components in sync with the UI.

My name is Minko, as you heard, I'm the product lead for Angular at Google, which means I'm accountable for what we build for Angular, why, and how we share it with developers.

So the community has been talking lately about this Angular renaissance. And you might be wondering what actually changed in Angular. What happened? Well, really, a lot happened, and I really can't wait to share with you. So last year, Angular and React were effectively the same framework.

Now, this may sound weird, because React has JSX and functions, Angular uses templates and classes for components, how possibly they could be even remotely connected? Well, when you're building your application, this is different, but at runtime, things are very much the same. I would say over 50 per cent of the responsibility of a front-end framework is to keep your state inside of your components in sync with the UI.

2. Reactivity in Angular and React#

Short description:

When building an application, the framework turns components into a tree and reflects state changes in the UI. Angular and React have a similar model of reactivity, traversing the component tree to find changes and update the UI. A practical example demonstrates how this works, with the framework optimizing change detection. Performance benchmarks show Angular and React with similar patterns. Traversing larger component trees in real-world applications can be more complex.

So when you build your application, you use whatever format, altering format you have in your framework. From there, at runtime, the framework turns these components into a component tree. And when something happens, when the state changes, the framework is going to reflect the state's change in the UI, and in the front-end world, we refer to this as reactivity.

Surprisingly, Angular and React have been having a similar model over the past couple of years. Let's look at how reactivity works. First, we specify that something has changed. In React, we do that explicitly. In Angular, there is something called zone.js that tries to figure out when something might have changed so that it can schedule from here a change detection or reconciliation where we are traversing this entire component tree in order to figure out all the places where it might have changed, where it may have stayed updated, go to the UI, and updated on. That's pretty much it.

Let's look at a more practical example to see how this works in practice. We have an app component here that uses two components, the user profile and the shopping card components. The user profile is pretty simple, just displays the user name, and the shopping cart goes through the list of items in the shopping cart, and for which one of them it displays the quantity. In turn, the framework is going to turn this into a tree. We have the app component at the top. On the left, we have the user profile component, and on the right, we have the shopping cart.

Now, if something changes, let's say we update the quantity for the first item in the shopping cart, both Angular and React are going to start traversing this tree, trying to find what changed. First, they're going to go to the app component even though it didn't change. After that, they're going to perform that first traversal, so they're going to go to the user profile component even though nothing changed there as well, and finally, they're then going to go to the shopping cart component and reflect the update. Now, both in Angular and React, we have a way to manually optimise this. In Angular, we have own push change detection strategy. In React, we can use memorisation. This allows us to prune parts of this component tree, so we're going to perform change detection or reconciliation only in the app component, and in the shopping cart component. If you don't trust me yet that Angular and React are very much the same in how they perform reactivity, let us look at some performance benchmarks. You can see that Angular and React have a very similar performance pattern right here. Both of them are not doing great on swapping rows, and they're doing all right for partial updates. Now, these are benchmarks with the legacy Angular control flow, so we optimise things since then, but that's how things worked last year. With this example, traversing this component tree with three elements, it doesn't seem like a big deal, right? We just traverse three elements and we check for state updates. But real-world applications are not really that simple. We have way larger component trees. Here we have over 100 components, and I know this because I put this tree by hand while flying to the conference.

3. Optimizing Change Detection with Signals#

Short description:

Real-world applications with thousands of components can take a long time to traverse for state changes. Angular explored optimizing change detection through static dependency tracking and signals. Signals allow fine-grain reactivity by wrapping component state and notifying the framework of its usage. Collaboration between Angular and WIS led to shared code and the adoption of Angular signals by YouTube, resulting in improved performance.

You can imagine that, if we have to traverse this tree to figure out all the state changes, this could take some time. Real-world applications are way bigger than this 107 components or so. They have thousands of components at runtime.

Angular was thinking what can we do to optimise the change detection on the reactivity system? We looked at expanding our compiler so that we can have static dependency tracking, and we decided that this is not the right way to go because it introduces some magic that might introduce challenges when debugging. We also explored signals. We joined the signals club, together with Vue, Solid, Svelte, and others. Inside signals, you just wrap your local component state inside of a signal. From there, you can read it inside of your templates, and this is enough to notify the framework, to let the framework know where exactly this state is being used, so that when you update the state, the framework can go there and perform change detection, let's say, in only this particular part of your component.

When you look at the larger component tree, and, let's say, we update the item.quantity and set it to one with a signal, we're going to go only to the components that have read the signal. In this case, let's say these two components, and the rest, we don't have to traverse, so this significantly improves the performance at runtime.

Signals became popular not only in the external community but also inside of Google. In Google, we have two frameworks for development of web applications that are in general availability. We have Angular and WIS. Angular has been more focused on enterprise-like experiences, and WIS on consumer clients. Let's say Google search is built with WIS, Google Photos, Google Drive, and more. In the external terminology of external frameworks, you can think about WIS being more similar to Eleventy or quick. In fact, WIS invented the concept of reasonability ten years ago. Originally, these two frameworks were occupying very different segments, but over time, we noticed how these requirements for the applications that we were building with Angular and WIS, they started to blend. People building applications with Angular wanted more of the Angular features. People using WIS wanted some of the developer experience features of Angular. We started collaborating together closely.

It was my responsibility to figure out what code we can share. I was hanging out in Google chat in the WIS channel, and I saw something like this. I definitely didn't manufacture the screenshot yesterday. WIS was working with YouTube to rewrite their whole user interface and move it from a legacy virtual DOM-based implementation to WIS, and they were exploring signals for fine-grain reactivity. Angular, on the other side, we were designing the Angular signals implementation at that point, so we decided to team up and build a solution together. YouTube adopted Angular signals through WIS, and it is currently handling 100 per cent of their YouTube mobile web traffic. They noticed some improvements. For instance, on living room, this is smart TVs, they saw about 35 per cent better input latency on low-end TVs, and when swiping shorts on YouTube mobile web, they noticed 60 frames per second swiping compared to the legacy virtual DOM implementation that was providing 25 frames per second. Seeing that these signals actually work, and they work across Angular and WIS, and we're able to share the exact same signals implementation, we reached out to standardisation bodies and they both representative of other frameworks who have been using signals as well.

4. Improving Performance with Deferrable Views#

Short description:

Signals are being explored to be part of the web platform and added to the JavaScript language. Angular signals prove scalability and compatibility with different frameworks. Performance improvements include deferrable views for lazy loading and significant speed improvements in initial load times. Vue.com saw a 50% reduction in bundle size. Deferrable views allow for lazy loading of specific parts of the template, improving user experience and reducing unnecessary delays in initial load times.

As I mentioned, Solid, Vue, Svelte, Preact, Amber, and we started exploring together how we can make signals part of the web platform, how we can add them to the JavaScript language. Currently, signals are in stage 1 for T39, and the reference implementation is using Angular signals because it proves that it scales for YouTube, the second biggest website in the world, and also it can work across different frameworks. Angular and WIS.

All right. That was the developer experience part of it, even though you see that we have some performance improvements as well. Significant actually with the reactivity model. Let me talk a little bit about performance. We've been having a couple of major improvements here, and the first one was with something called deferrable views that allows us to declaratively specify part of the template that we can lazily load. We can extract it as a separate bundle and preload, prefetch, and lazily load when it is required.

This way, you can significantly speed up your initial build time, your initial load time, excuse me. Vue.com started using deferrable views, and they saw 50 per cent improvements of their bundle size, and I wanted to quickly show you how they work. How many of you like live demos? Cool. I like watching them as well. Let's see if I can figure out the mirroring now. All right, we see the same thing. So, I have a lot of things here. I have a simple e-commerce platform right here, built with Angular, and it has this chat box at the bottom.

We know that very few people are going to engage with this chat box, right? Why would you engage with the support? You're going there for shopping, so maybe one per cent of users would engage with it. However, by default, we can see that it is part of the main bundle of the application. And it just unnecessarily delays the initial load time. We can just load it lazily when it is required. So, ideally, we would like to load it when it enters the viewport. Then we expand the chat box, and we start typing something which will be already interactive. With deferrable views, we can use the first syntax, specify that we would like to prefetch when it enters the viewport. And we specify a placeholder. And we save. That's pretty much it. If we go to the main bundle now, we can see that we're no longer eagerly loading it. We have a dynamic import that the Angular compiler created for us.

5. Enhancing Hydration and Build Pipeline#

Short description:

When using deferrable views, Angular can handle the complexity of loading states and intersection observers automatically. The hybrid rendering solution is deeply embedded, and the build pipeline has been updated to use Vite and ESbuild, resulting in three times faster build speeds. The functionality of event replay is introduced to improve the hydration process and reduce the time between screen visibility and application interactivity. Inspired by a partnership with Wists, Angular aims to gradually introduce partial hydration using deferrable views.

When we expand the chat box and we start typing, and we go to the network tab, we're going to see that we load it lazily, just as you would expect. The cool thing about this is that it handles all the complexity around loading states, and intersection observers automatically for us.

All right, now let's see how I can get back to my presentation. We decided to build on top of this abstraction. I'm going to show you how in just a little bit. And we embedded it deeply in our hybrid rendering solution. I'll talk about partial iteration in just a moment, but before that, I wanted to tell you about how we updated our build pipeline. It uses Vite and ESbuild now out of the box. We're migrating existing projects. And Vanguard reported that their build speeds improved three times after they switched to this new build pipeline. So thanks to the Vite team and to ESbuild for making such a wonderful infrastructure product.

So one thing that happens when you use server-side rendering is the so-called process of hydration. We first get HTML. It could be from static side generation, or pre-rendering, or it could be from server-side rendering. Right after that, we download all the associated JavaScript with it. Next, we need to execute this JavaScript, and, finally, we add event listeners, and we make our application interactive. This process is known as hydration, as we know. It could take some time. Between the time that we have something visible on the screen, and the application is interactive, we will be dropping user events. The user can start interacting with the application and nothing will be happening. So we wanted to improve that, and we introduced a functionality called event replay.

So here, the application is not hydrated yet. The user interacts with it. We capture the event and replay them. This is inspired by our partnership or merger with Wists, and it uses the same event replay functionality that Google search has been using for the past ten or 15 years that is available here in the Angular repo on GitHub. There is one more thing that we can improve here. How we can reduce this path of hydration, how we can make sure we load the minimum amount of JavaScript, so the execution time is significantly shorter as well, and we have fewer event listeners to add. As I mentioned, with the mobility, we have been brainstorming together how we can gradually introduce partial hydration to Angular using deferrable views. I wanted to show you another quick demo. I may not have to switch to mirroring here.

6. Island Architecture and Component Hydration#

Short description:

We build our apps by loading and hydrating a few components instantly, while the rest of the application remains unhydrated. The event replay layer captures user events, downloads the associated code, and replays them. The island architecture creates independent islands on the page, allowing components to live independently without needing hydration. This approach is similar to the island architecture of Astro and includes additional features like detecting data dependencies.

Let's see. Yes, here we go. This application here looks like a mock but it is a running shopping cart. That is how we build our apps. By default, we are loading a couple of components, the footer, the navigation, and the header and the shopping cart. We just kind of load them almost instantly, and we hydrate them, but the rest of the application is not hydrated. Additionally, I have added a couple of artificial delays so you can see what is actually happening.

Here we have the application, only these couple of components are going to get downloaded and hydrated. At first, the whole application will be gray. We will just have this event replay layer that is responsible for capturing user events, figuring out what is responsible for handling them, downloading the associated code, and replaying them. Here, for instance, if I click on add to cart, this is going to trigger downloading this component. When the component is downloaded and hydrated, we are going to replay the event and add the item to the cart. I don't have internet connection, or I have killed my development server.

Let's see. If I click on the cart component, we're expecting to get the same. We have this island that is going to automatically detect what JavaScript is responsible for handling this event, going to go to the server and add the corresponding item to the cart. Let's see what is happening right here. Let me run the application. All right. Yeah, that's why I said I like watching demos. I don't like doing them. And if I open the tab, I don't have internet connection here, so I can't download JS Action. Excuse me for that! All right. The way that this works is it creates different islands on our page.

In this case, the navigation could be one of these islands. On the right side, we have another island that is responsible for something else. They can live independently, and none of the rest of the UI needs to be hydrated in any way. This is very similar to the island architecture of Astro. It is Angular-specific, and it has a couple of additions. For instance, it can detect data dependencies.

7. Designing Partial Iteration#

Short description:

We're designing partial iteration, a feature that automatically propagates changes in signals to the corresponding components. We have a working prototype and will release a developer preview soon. We're expanding the data story and are open to partnerships to define the requirements for partial iteration.

Say we have a signal that we have declared in the sidebar that is used in the navigation at the top, at the header. If we change the signal, this is automatically going to propagate in the navigation. We're going to handle this and figure out what has changed, download the code, bootstrap it, and reflect the updates. So that's what is expected to happen.

Now, we're currently in the process of designing partial iteration. We have a working prototype when you have internet, actually, it works, and we're going to release a developer preview, or an experimental version of it in the next couple of weeks. We're expanding the data story, so we would love to partner. If you're building a large application at scale that has performance-critical requirements, please reach out to us, we would love to partner so we can figure out what the requirements for partial iteration are, something that doesn't really exist in all the popular frameworks, and we would like to implement it together.

QnA

Innovation in Angular Community#

Short description:

There has been a lot happening in Angular, including the release of Analog and the port for Angular in TANstack. We refreshed the logo and updated the Angular documentation website. We're working on features like partial hydration and zoneless. Our mission is to support developers to deliver web apps with confidence.

There has been a lot happening in Angular, and we have been seeing a lot of innovation in the community as well. Brandon Roberts released version 1.0 of Analog, which is a community-driven meta framework for Angular. TANstack introduced the port for Angular in TANstack query, TANstack table, store, and also forms. But there was one thing that has been bugging me for a while, and it has been this logo. We have all these cool features, but this logo hasn't changed for the past almost 15 years now. So last year, we decided to refresh the logo as well and make sure it reflects the future-looking nature that Angular has. Together with this, we updated the Angular documentation website, and we introduced a getting-started journey that allows you to experiment with Angular directly in your browser at Angular.dev.

So we have a lot of stuff that we covered today, and there is a lot more coming. First of all, we would like to make sure that, if you would like to adopt signals, you can adopt them only for the components that make sense in your application, and, if you prefer to use the very coarse granular reactivity in Angular, you can continue doing so, so you can adopt them without any breaking changes. We're working on partial hydration, zoneless, and much more. All of these features are in support of our mission to support developers to deliver web apps with confidence.

That's all I had for you today. Thank you, and I would love to answer your questions.

Q&A on Signals and Angular#

Short description:

We're going to answer some questions now. React is doing well and recently shared an experimental version of their compiler. Signals can work with NgRx through an RxJS intro package. RxJS, while successful, may not be part of the core learning journey of Angular. Progressive enhancement can be an alternative for when the JS bundle doesn't load.

Yes, so, we're going to get through some questions now. Again, the code is 1317. If you want to jump on to Slido, we are going to ask some difficult questions.

All right. Well, the first one has to be asked, doesn't it? Oh, no, I missed it. There was one that said, is React dead? You might as well. A lot of people are going to a React conference tomorrow. Might be careful. I think React is doing pretty well. They recently shared an experimental version of their compiler.

Yes. Excellent. So, will signals replace or work in conjunction with something like NgRx? Yes, there is an RxJS intro package that allows you to convert your signals to observables, and vice versa. We want to make RxJS optional from Angular so that people who don't want to use it don't have to, but also at the same time provide better integrations with it.

Nice. This is probably a similar question, same vein as well is what is the future of RxJS, and Angular seeing as the major investment in the signals? Is it going away? RxJS is very successful. You can see that it has way more downloads than any framework out there. We may not want to add it as part of the core learning journey of Angular. We're still going to have integrations with RxJS where it makes sense.

Excellent. One mosquito is trying to get me here. One mosquito is trying to get me here. Maybe they're hiding here. There's a nest there. We don't tell anybody about. Resumability and event replay is nice, but what are the possibilities for progressive enhancement as a fallback for when the JS bundle doesn't load with Angular? Yes, that's definitely an alternative when you have server-side rendering. You can change some of the links in your page, for example, to be leading to a hard refresh. Not all the functionality would work. A lot of it is dependent on JavaScript. As we saw, view transitions, they kind of support covering some of these use cases, but not entirely.

Integration of Wiz and Angular#

Short description:

You have a lot of JavaScript-dependent use cases. Can I have your VS Code config? We recommend moving off the in-memory web API of Angular unless you have heavily invested in it. Reactive forms will evaluate using signals. The integration of Wiz and Angular will add some of Wiz's performance features without a rewrite.

You have a lot of JavaScript-dependent use cases. Fantastic. There are so many. You're getting a lot of questions here, by the way, so you're not going to be moving for a while.

I think this one was for you as well. Can I have your VS Code config? Sure. It should be on my GitHub. What is your GitHub handle? Mghetchv. I'm sure it is linked to your Twitter or whatever. Just Google you.

I am using the in-memory web API of Angular but I can't find any docs. Is it still being maintained? We were using it specifically for the documentation. We haven't really promoted it much outside of that. It is not something that we're wanting to maintain openly for everyone at this point, so I would recommend you to move off of it, unless you have heavily-dependent invest in it already. If you have, come and talk to me after that and we can figure something out.

Nice. Will reactive forms get first-class support for signals, like an on-change signal instead of observable? Yes, we are going to evaluate exactly where we are using observables in reactive forms and figure out where it makes sense to use signals. It's on my site, one of the features that is on the road map.

Excellent. It is coming very soon, then, if it is already being shown. Yes, we have a massive road map to you. It's coming.

How easy it was to do the fallbacks and the lazy loading was incredible as well. It's very cool. This is one I'm just curious about as well. Will the integration of Wiz require any migrations? Yes, that's a good question. The way we are planning to converge Angular and Wiz together, it is going to manifest as just adding some of the Wiz's performance features to Angular. That's how things are going to work. It's not going to be a rewrite of Angular or a rewrite of Wiz. Overall, we will be moving the implementations closer together.

Exploring Angular's Future#

Short description:

We have a long timeline and are delivering features immediately. We want to deliver value quickly. Are view refs the same as signals or even more performant? We will never get rid of dependency injection. We observe other frameworks' roadmaps and learn from them. We worked with Solids and T39 on Angular Reactivity and signals.

We have a really long timeline for this. So, we are delivering features immediately that you can see right now with partial iteration and signals in Wiz and event replay but we're not necessarily aligned 100 per cent on the implementation for all of them. So it's still a work in progress to figure out how you do that migration.

Yes, we want to. Very new. Yes, also we want to deliver value as quickly as possible because nobody really cares about the implementation details from developers using Angular or Wiz.

I'm curious about this one so I'm going to put this into the live one as well if I can find it. It will pop back up. Are view refs the same like your new signals or are they even more performance? I'm guessing this is a view based question so it might be the wrong person to ask on this. Yes, that's probably Evan. Yes, we'll annoy Evan again afterwards. We have to have an arm wrestle upstairs to decide who is a better... I guess we have signal based queries, view queries that are similar. I don't know if that's the question but there are other questions we can let this one... We can probably argue over afterwards, I'm sure, at the Q&A booth.

And then, when will you get rid of dependency injection? Yes, never. That's the most loved feature. Everyone loves dependency injection.

You mentioned React a lot for your comparisons, so how much does the Angular team observe the other frameworks' roadmaps, and how much does that influence how you're developing or what you're developing as well? Yes, we're definitely looking around. When we're designing deferrable views, you can see that to React developers, it will be reminded suspense. We want to make sure that we're learning from other frameworks when we're building new features, and we are at the same time collecting a lot of requirements from developers and seeing where the web is moving so that we can head this direction as well, and grow the framework kind of based on more grounded foundation, not necessarily getting inspiration from other alternatives. Not stealing. Inspired. Inspired by other frameworks. Learning, yes.

I guess that's the fun of open source. You can learn as we do these things as well. You can see how, for example, we worked with Ryan from Solids on making sure that the Angular Reactivity with signals works great, and now T39 is using the Angular implementation of signals as a foundation for signals in JavaScript. Nice. I think that's all we're going to have time for on the Q&A right now. You're going out to the Q&A booth after this? Yes, perfect.

Minko Gechev
Minko Gechev
29 min
13 Jun, 2024

Comments

Sign in or register to post your comment.

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

Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Full Stack Documentation
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
The Talk discusses the shift to full-stack frameworks and the challenges of full-stack documentation. It highlights the power of interactive tutorials and the importance of user testing in software development. The Talk also introduces learn.svelte.dev, a platform for learning full-stack tools, and discusses the roadmap for SvelteKit and its documentation.
SolidJS: Why All the Suspense?
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Top Content
Suspense is a mechanism for orchestrating asynchronous state changes in JavaScript frameworks. It ensures async consistency in UIs and helps avoid trust erosion and inconsistencies. Suspense boundaries are used to hoist data fetching and create consistency zones based on the user interface. They can handle loading states of multiple resources and control state loading in applications. Suspense can be used for transitions, providing a smoother user experience and allowing prioritization of important content.
From GraphQL Zero to GraphQL Hero with RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
RedwoodJS: The Full-Stack React App Framework of Your Dreams
React Summit Remote Edition 2021React Summit Remote Edition 2021
43 min
RedwoodJS: The Full-Stack React App Framework of Your Dreams
Top Content
Redwood JS is a full stack React app framework that simplifies development and testing. It uses a directory structure to organize code and provides easy data fetching with cells. Redwood eliminates boilerplate and integrates Jest and Storybook. It supports pre-rendering and provides solutions for authentication and deployment. Redwood is a cross-client framework that allows for building web and mobile applications without duplicating work.

Workshops on related topic

Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Miško Hevery
Miško Hevery
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.
Back to the Roots With Remix
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
Alex Korzhikov
Pavlik Kiselev
2 authors
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)
Monitoring 101 for React Developers
React Summit US 2023React Summit US 2023
107 min
Monitoring 101 for React Developers
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
If finding errors in your frontend project is like searching for a needle in a code haystack, then Sentry error monitoring can be your metal detector. Learn the basics of error monitoring with Sentry. Whether you are running a React, Angular, Vue, or just “vanilla” JavaScript, see how Sentry can help you find the who, what, when and where behind errors in your frontend project. 
Workshop level: Intermediate
Get started with AG Grid Angular Data Grid
JSNation 2022JSNation 2022
116 min
Get started with AG Grid Angular Data Grid
WorkshopFree
Stephen Cooper
Stephen Cooper
Get started with AG Grid Angular Data Grid with a hands-on tutorial from the core team that will take you through the steps of creating your first grid, including how to configure the grid with simple properties and custom components. AG Grid community edition is completely free to use in commercial applications, so you’ll learn a powerful tool that you can immediately add to your projects. You’ll also discover how to load data into the grid and different ways to add custom rendering to the grid. By the end of the workshop, you will have created and customized an AG Grid Angular Data Grid.
Contents:- getting started and installing AG Grid- configuring sorting, filtering, pagination- loading data into the grid- the grid API- add your own components to the Grid for rendering and editing- capabilities of the free community edition of AG Grid
Micro-Frontends with Module Federation and Angular
JSNation Live 2021JSNation Live 2021
113 min
Micro-Frontends with Module Federation and Angular
Workshop
Manfred Steyer
Manfred Steyer
Ever more companies are choosing Micro-Frontends. However, they are anything but easy to implement. Fortunately, Module Federation introduced with webpack 5 has initiated a crucial change of direction.
In this interactive workshop, you will learn from Manfred Steyer -- Angular GDE and Trusted Collaborator in the Angular team -- how to plan and implement Micro-Frontend architectures with Angular and the brand new webpack Module Federation. We talk about sharing libraries and advanced concepts like dealing with version mismatches, dynamic Module Federation, and integration into monorepos.
After the individual exercises, you will have a case study you can use as a template for your projects. This workshop helps you evaluate the individual options for your projects.
Prerequisites:You should have some experience with Angular.
Let AI Be Your Docs
JSNation 2024JSNation 2024
69 min
Let AI Be Your Docs
Workshop
Jesse Hall
Jesse Hall
Join our dynamic workshop to craft an AI-powered documentation portal. Learn to integrate OpenAI's ChatGPT with Next.js 14, Tailwind CSS, and cutting-edge tech to deliver instant code solutions and summaries. This hands-on session will equip you with the knowledge to revolutionize how users interact with documentation, turning tedious searches into efficient, intelligent discovery.
Key Takeaways:
- Practical experience in creating an AI-driven documentation site.- Understanding the integration of AI into user experiences.- Hands-on skills with the latest web development technologies.- Strategies for deploying and maintaining intelligent documentation resources.
Table of contents:- Introduction to AI in Documentation- Setting Up the Environment- Building the Documentation Structure- Integrating ChatGPT for Interactive Docs