Building Web Applications with Signals at Grammarly

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Signals have recently become a popular concept. Their ideas are based on the functional reactive programming (FRP) approach, which has been leveraged in the industry for a while. I would like to share how someone can build an architecture based on signals and React and how we have used FRP at Grammarly for quite some time. The talk aims to showcase the foundational principles of observables and how to structure applications based on FRP ideas.

This talk has been presented at React Day Berlin 2024, check out the latest edition of this React Conference.

FAQ

Lesh Levzhinsky is a web developer at Grammarly, working with several Grammarly clients, primarily focusing on web applications. He is also a maintainer of Grammarly's open-source library for reactive state management, GrammarlyFocal.

In Grammarly's web applications, signals are used as a concept of reactivity to manage changes in the application's state, updating the UI or executing business logic in response to changes in text input by the user.

Grammarly uses signals in its editor to handle text changes dynamically. Signals help manage features such as providing real-time suggestions, calculating text statistics, and supporting multi-device editing by tracking text changes and updating related features accordingly.

The benefits of using signals in web applications include decoupling the state from the view layer, facilitating declarative programming, and enabling the use of functional reactive programming techniques to handle dynamic data changes efficiently.

Grammarly uses signals to efficiently manage the text suggestions feature by calculating text diffs instead of sending the full text, using techniques like throttling to optimize performance and reduce payload size for long documents.

The main challenge with using signals is testing, particularly integration testing, to ensure proper application of functions like diffing and debouncing. Debugging streams can also be complex due to dynamic changes in state over time.

Marble tests help in testing signals by providing a way to define and control the execution time of events in a stream, allowing developers to simulate and verify the behavior of signals over time with readable syntax.

GrammarlyFocal is an open-source library developed by Grammarly that provides tools for reactive state management using signals. It wraps RxJS to offer a simplified interface for working with signals and streams.

Yes, Grammarly's signal-based system is framework agnostic and can be integrated with other frameworks like React, using hooks to work with changing values and providing flexibility in application development.

There are various resources available, including community proposals for standardizing signals across frameworks, which provide insights into the potential integration of signals into JavaScript's core. These resources help developers explore the concept and application of signals in web development.

Oleksii Levzhynskyi
Oleksii Levzhynskyi
29 min
13 Dec, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Hello, welcome, everyone. Today, I'm going to talk about building web applications with signals in Grammarly. Signals are like values that can change over time and are used in Grammarly's editor for real-time updates. Signals can be implemented with React and are leveraged for state management and business logic. They enable functional reactive and declarative programming, allowing specific actions to be defined. Testing signals can be done using classical unit tests or marble tests. Signals are a perfect fit for Grammarly's domain and can be easily integrated with various libraries and frameworks. Handling cleanup and unsubscribing to signals can be done through the dispose method and React lifecycle. The main challenges in signal-driven systems are testing and debugging streams. Marble tests provide control over signal emission and combined states can be calculated using the view function. Grammarly is considering migrating to the signals proposal in the future. Thank you, Alexey!

1. Introduction to Signals in Grammarly

Short description:

Hello, welcome, everyone. Today, I'm going to talk about building web applications with signals in Grammarly. I joined Grammarly many years ago and now work with Grammarly clients, primarily web. I also maintain our Grammarly open source library for reactive state management. At Grammarly, we use signals to build our applications, and I encourage everyone to consider using similar approaches. Grammarly is a writing assistant that provides refinements and suggestions. We have a Grammarly editor with various features, including statistics, multi-device editing, and Grammarly checks. These features update and recalculate in real-time as the text changes.

Hello, welcome, everyone. My name is Lesh Levzhinsky, and today I'm going to talk about building web applications with signals in Grammarly. I was already introduced, but anyway, I joined Grammarly many years ago. I joined like a web developer, and now I'm working with a couple of Grammarly clients, primarily web. Also, I'm a maintainer for our Grammarly open source library that's about reactive state management. It's Grammarly for Kal, and also I'm a member of FW Days conference. It's the biggest conference about JavaScript in Ukraine.

Well, about my talk. Today, I would like to share our experience at Grammarly, how we are using signals to build our applications, as well as I would like to maybe encourage everyone to think about using similar approaches, if you are not yet.

Well, and before we dig into details, I have a couple of questions. First of all, have you ever used it as signals? Could you raise a hand? Oh, nice. What about FRP, functional reactive programming? Maybe something? Oh, it's going to be easy talk. Nice. But anyway, I'm not going to start with the technical definition. I would like to start with the use case.

Grammarly is a writing assistant. At Grammarly, user may type a text and we will provide a refinement for this text. We'll provide suggestions so you can go ahead, update it, rephrase, and so on. On this slide, there are a couple of typos, and red underlines it's something from Grammarly. Well, also, we have a Grammarly editor. It's like a typical editor where users can go ahead and create documents, as well as to get the full power of Grammarly to refine, do a revision of your text. Well, in this editor, we have a couple of features. First of all, yeah, maybe not first of all, but also move to the primary function like writing text. We would like to show some statistics. Also, we definitely need to send it somewhere to the backend for permanent storage. We would like our users to be able to edit it from different devices, maybe. And for sure, we need to provide a Grammarly check, so we need to send this text to maybe another service. As well as there could be multiple of different features that needs to be updated, recalculated as soon as text changes. Well, it sounds quite a lot for just one key press.

2. Understanding Signals and Their Usage

Short description:

Signals are like values that can change over time. They are a concept of reactivity and can be used to update UI or execute business logic. Many libraries and frameworks, including Angular and ArigGS, incorporate signals. Grammarly has its own library called GrammarlyFocal. Signals are leveraged in the Grammarly editor, and we can implement them with React.

Well, it sounds quite a lot for just one key press. And here signals may be useful. So, in this case, what might be a signal? The signal might be actually text. It's like a value, static values, that we can work with at any time, as well as the fact that it changes over time. And maybe a bit of what it is about.

It's a classical diagram. Nothing special here. On the left side, we have just a value. Okay, we can, what is the value, we can access it at any time synchronously. On the opposite side, we have a sort of observable, just a stream of events, like without the sort of static value, but rather you need to listen for it. And the signal is something in between, first of all. Usually, here it's like a bucket. There's a value that you can access at any time, as well as you can subscribe to it, so it behaves in both ways.

Well, this is another presentation. So, signals in general, it's a concept of reactivity. I'm not going to dig into reactivity, but, yeah, in general, we need to react on some change in state and update in a reactive way our UI, or maybe execute some business logic. Well, here is just an observable part of our signal, like we're applying to the stream of events, we're applying the bonds function in this case, and getting another stream. Well, what about the usage? There are quite a lot of libraries, frameworks that contain this concept of signals. For sure, there are signals in Angular, as well as Angular uses ArigGS.

Probably, the term signal become popular after solid.js introduced it. And for sure, there is a standalone library, ArigGS. It's not only about the signals, but there is a concept called behavior subjects that may contain the value that can be accessed synchronously. There is a standard proposal, for sure. At Grammarly, we have our very own library that was developed quite a long time ago. It provides a code called GrammarlyFocal, and it also basically provides or shares the same concept of signals, and there are a lot more examples.

Well, enough with sort of introduction. Let's look at how we are leveraging the idea of signals in our Grammarly editor. It's like the same screen, nothing fancy. I'm not going to dig into details, but let's look at how it might be, in theory, implemented with React. This is very simple, just for the sake of the demo.

3. Integrating Signals in React

Short description:

The text component needs to track state changes and send values to a check-in service for suggestions and improvements. Questions arise regarding the frequency of sending text, buffering, and handling large payloads. The dynamic UI requires immediate updates, so a view model layer is introduced to handle state and business logic. Signals, implemented as atoms, are used to communicate between components. Custom hooks subscribe to these signals, allowing React to work with changing values. Suggestions also require a similar approach for dynamic rendering.

It's quite a simple React component. There is a text area. In real life, definitely not a text area. And here we need to track the state, the change of the text. Here is a simple use state. And for sure, as soon as user types something, we need to send this value to somewhere, to the check-in service, to get some suggestion, to get some improvements. And let's dig into, let's dig a bit into this client sort of server communication and text processing.

So in this case, we have an editor. As soon as user types something, as soon as text is being updated, we need to send it somewhere. So it feels like sort of a stream of events. We need, for sure, to get the suggestions, but almost immediately we need to answer a couple of questions. Well, how frequently do we need to send this text? Do we need to use buffer? What about if it will fail? Do we need to send a full text? There are cases when user works with very long documents, like 10 pages, 100 pages document, it might be quite a huge payload. Well, and we need to remember that we would like to get to show on this underlines live, not to wait for a couple of, even for a couple of seconds or for a minute for a check-in.

And that's only one part. Another part is we have a quite a dynamic UI. And as soon as something is changed with the text, we need to update all of these pieces almost immediately. Still, it sounds like too much for just one React component and maybe for a couple of use cases. That's why let's, for the sake of the demo, let's introduce additional layer. We will call it sort of view model. It might be called in different ways, but all the logic will be, all the like a state for our visual component, as well as the business logic that will pass data to, let's say, API to the backend will be here. And what is view model in our case? It's just a class, a simple class in this way.

But here we have a couple of signals. So here, here we go. Now, the line number two and line number three introduces two kind of signals. In our case, we are using atom term because our library was invented before the signal term become popular. And for sure, all of them contain some default values, like the initial, and will be updated later. But then the next question is how to plug them into the React and how to make React works with these changing values, given that React already provides the hooks. And there is quite a simple way to implement very own hook. I'm not going to show the implementation, but in general, under the hook, it's just a use state and use effect that listen and subscribes to the signal. Well, and the same we need for the suggestions as well, because they're going to be dynamic and we need to React and render them as soon as they will arrive from the server.

4. Benefits of Using Signals in React

Short description:

Signals in React allow us to leverage functional reactive programming and declarative programming. We can define the specific actions we need to take. For example, we can calculate the text diff instead of sending the full text to the server. Throttling can be used to optimize the calculation process, considering factors like word breaks and completed sentences.

Moving on. So what's the point? Okay, we have introduced a couple of signals, so we have plugged them into the React. But what bonuses does this bring us? What possibilities do we have right now? And there are two primary things. The first one is basically the signal. In our case, it may behave like an observable. It kind of allows us to use all the beauty of functional reactive programming and declarative programming, so we can define what we actually need to do. And on the line number eight and nine, for example, we decided that we don't want to send the full text to the server, but rather we need to calculate the diff. But also it doesn't make sense to calculate it for every single key phrase. But rather we maybe need to introduce some logic, maybe to throttle. In this case, it's throttle, but in real life it's much more complex. We are waiting for, let's say, word break and for maybe when the user will finish the sentence, because it doesn't make sense to show suggestion for not completed word, for example.

5. Testing and Value Over Time in Signals

Short description:

Our signals can be used to recalculate statistics based on user input. They can also behave like classical values, allowing immediate access. This decouples the state from the view layer and enables isolated development. Testing signals can be done using classical unit tests.

And another, maybe simple example as well is, okay, the same text value. It's our signal that emits as soon as the user changes the text. We need to recalculate the stats. And we are quite flexible here. It's like the same stream, but we can use a different technique. In this case, we decide for some reason, I don't know, we decided to use the bonds and wait until the user will stop to recalculate the statistics. Maybe there are not a lot of users that will type and check the statistic at the same time. Anyway, it's just an example.

And the second cool thing about our signals is they behave like a classical value. They can be accessed and we can get it synchronously at any time. This is quite a simple example of implementation. Copying to clipboard. We need to basically, user may want to copy selected text, or maybe the full text. And on the line number six, there is a method, basically getters, that allows us to get it immediately. Well, what's the result? We achieved quite a couple of things here. First of all, we have decoupled our state from the view layer. All business logic can be easily plugged to our streams, because it's a stream. We can use a declarative programming to describe what's going on. Also, all of these pieces might be done in quite isolated state, because nothing depends on each other. That's basically it.

When we are talking about the streams, quite a frequent question is, well, but how to test that? And still, with the signals, there are a couple of techniques. The first one is just about, okay, this is a classical unit test. We are trying to test our logic that copies to clipboard. In line number seven, we are creating our view model. In the next line, we are copying it to clipboard, and then we are asserting that, okay, our service that probably should do it, depending on the platform, can, what's called, with the proper value. Nothing special here. It's just a classical unit test. This is because the signal may behave like a classical, like a static value that exists always. But here we go. Another piece of our signal is the fact that it's a value over time.

6. Testing with Marble Tests

Short description:

We need to test our functions to ensure they work properly. We can use marble tests to define the behavior of our signal as it changes over time. This involves using characters and values to define the expected results. The logic is defined in the code, which may include creating a view model and performing a sort. Testing is done using a framework or library that allows running the marble test.

So, we need to somehow test it as well. Let's look at the example. We have a text. User decided to type hello. Then user decided to change it to hello world. And we would like to ensure that our different functions, different function works properly. So, for the first case A, there is nothing before, so it's going to be hello. For the second case, it's going to be just a world, as a piece that was added. And later on, we will send this maybe to the back end for the sake of checking.

Well, how it may be implemented? There was a teaser on the screen. We are going to use a marble test. Marble test, marbles, we have a stream and marbles on it. This is quite a simple example. Still, we are using to define our behavior, to define the behavior of our signal as it changes over time. We are going to use just the characters, a couple of them, the dashes and the values. Also, we can define it on the line number two and line number three. We are defining the values. This should be, that corresponds to this A and B value. Also, on the line number five, we are defining what's expected.

And the second piece of our code is basically to define the logic. In this case, it's just a demo example. It's not a real one. In real world, it's probably going to be a creation of the view model. That kind of exposes the observable or exposes the signals in this case. And also, on the last piece, we are doing a sort. And the marble test, there is a framework, there's a library that allows you to run it. Definitely, there will be a wrapper that creates sort of the scheduler that needs to be used because it's not, its value changes, that changes over time. So, there will be a bit of boilerplate, but the core of this test is quite readable, for sure, if you know the syntax on how to define the events. Well, basically, testing is done. And let's wrap up what we have.

7. Working with Signals in Grammarly

Short description:

Signals allow for working with streams and single values, making them a perfect fit for Grammarly's domain. Grammarly's browser extension and editor, powered by React and signals, provide observation and analysis of text changes. Signals can be easily integrated with various libraries and frameworks, allowing flexibility without the need for extensive changes. While signals offer code isolation, integration testing should be carefully considered due to potential unexpected cases. Signals are framework-agnostic and can be used in scenarios such as reacting to data changes or events in multiple parts of an application, as well as processing long tasks with multiple states. Resources for signals standardization are available, although standardization is expected to take time. Thank you for your attention.

For Grammarly, in our case, the idea of signals and idea of working with the streams and at the same time with a single value is perfectly fits to our domain because the primary function is working with the text user's writing test in whatever place. We have a browser extension. We have an editor where we need to sort of observe the text and provide a lot of things on the, I don't know, text lengths, on what was changed. Our Grammarly extension, Grammarly editor that I just mentioned, powered by React and signals, in our case, we're just using Atoms, by our own open-sourced library. The bonus of idea of signals, they can be easily plugged into, there are a bunch of libraries that provide this concept. You don't need to have them built into the framework. They can be easily bundled together with React or even React Hooks. So, in this case, you are free to try and you don't need to change your framework or rewrite everything. And maybe like a side effect, but they allows you to kind of straighten your code isolation. So basically the nature of streams that you can plug and unplug at any point of time, but with this power comes that you need to think about the integration testing twice. Because the isolation may lead to some quite unexpected and hard cases when you need to think about testing. Well, and maybe to sum up in general, so yeah signals are framework agnostic. You can use it for quite a lot of cases. Maybe it makes sense to talk about a couple of them. So like in my examples, like you have a single data and the application that needs to react in multiple pieces to this data. It might be in other case, it might be okay, you are doing some, you need to listen for a scroll and show at some point of time some banners. It's also like in single data, but not in multiple places, but the one. And for sure, it's like processing the task, the long tasks that you need to react on and you need to show a couple of states, listen for some events. So it also makes sense to use signals as well as reactivity. And a bit about resources. They're quite a lot of useful. I would suggest to go ahead and read at least about the proposal, the latest in this list. There is a community trying to standardize how signals should look across different frameworks. There are a lot of interesting ideas. Maybe it will become, eventually will become to the core of the JavaScript, but at least they are mentioning that it will not happen this or next year. It's quite a long pass to standardize it. And that's it. Thank you so much. All right. So we're going to start with the one which is right at the top.

QnA

Handling Cleanup and Unsubscribing to Signals

Short description:

Handling cleanup and unsubscribing to signals within view models can be done through the dispose method and by plugging it into the React lifecycle. Depending on the architecture, garbage collection can handle unsubscribing when moving between routes. The main difference between MobX with observables and Grammarly's use of signals is that Grammarly uses Rigs-JS and BehaviorSubject to ensure there is always a value and provides additional helper methods for working with streams.

How do you handle cleanup or unsubscribing to signals within your view models? This is a great question. First of all, thank you for asking. And this is probably not really about the signals. Not only about the signals, but probably about the architecture itself. So in this case, it's definitely in view models that can be created at some point of time. And unfortunately, in JavaScript, you don't have a kind of clear way to define how to destruct it. But there are two options and there are two ways for doing that.

The first of all, in some cases when we realize that we need to reinstantiate it, maybe or like explicitly dispose, there is a dispose method. And we are kind of plugging this to the React lifecycle. As soon as React components are being rendered for the first time, we are starting a subscription. And on this sort of kind of unmount phase, we are doing that, like unsubscribing. Another option, it also depends on a lot of, like on the architecture. For example, if it's sort of single SPA, single page implication. In this case, if you're moving from one route to another one, you don't... In most of cases, you don't need to think about it unless you are keeping your subscriptions in the global namespace. In this case, garbage collection will handle it.

Awesome. Andreas, thank you for the great question. The next question is anonymous, but it's asking about what's the main difference between two MobX with observables. I think ModX is the signal-based framework, I believe. Yeah, as well. It's maybe, I would say the biggest difference from what we are using, we are using under the hood is a Rigs-JS to power our signals. Like I mentioned, we are using BehaviorSubject and GrammarlyFocal is just a wrapper that allows you to... That provides a couple of nice methods to work with a signal. Basically, it limits the interface of Rigs-JS because with Rigs-JS, you can do almost whatever you want. And the primary interface in Rigs-JS is observable. But observable is something that doesn't contain a value. But yeah, we've wrapped it. And basically ensures that there is always a value, like we're using BehaviorSubject and additional types. Regarding the primary difference, I would say because we're still using Rigs-JS, we have quite a huge library of helpers that allow us to easily work with the streams, to combine them.

Challenges in Signal-Driven Systems

Short description:

The main challenge in signal-driven systems is testing, especially when dealing with dynamic streams and integration. Marble testing is helpful but requires understanding and dealing with boilerplate. Another challenge is debugging streams, as it can result in complex stack traces. Marble tests provide flexibility in defining event execution time and control over the life cycle, making it more than just an array.

Somehow the bonds switch from one to another, pass it to another observables, and so on, so on. So probably this is a primary difference in our case.

We've got another question from an anonymous person. And I know that even just from some of the talks today, and I can even see some familiar faces in the crowd, which I will call signal evangelists, right? There's a lot of these signal-driven systems. And what are some of the main challenges that are affecting them?

Another great question. Thank you for asking. This might be quite a huge talk. It might be a discussion room at the next React Dig Berlin. Yes, I think so. Well, the main challenge, like I mentioned probably at least from my understanding, is like how to test it. Because in case you have a lot of streams and everything is dynamic, in this case, definitely the integration part will be quite huge. You will need to ensure that, I don't know, you are using the proper, you're applying the proper functions like, I don't know, diffing, debouncing, and it works properly. Marble testing is quite helpful here, but still there is a lot of boilerplate and you need to really understand how it works.

Also, the big idea of this proposal that I mentioned to make it to the core is to simplify the debugging of streams. Because it's still, if something is happening, you will have a huge stack trace with some inner functions about who called it, how it was called, how it arrived to this place. So, yeah, maybe these are two challenges. I feel like you could keep on going on that question. So, if you do want to chat to him afterwards, feel free to do so.

And you spoke about marble tests and this person has asked about the marble test syntax. What's the benefit of using it as opposed to using like an array with values over time?

That's a great question. The idea of marble tests and basically the libraries that we are using is that it's not just an array. It provides you a flexibility over the sort of execution time. So, with dashes on the screen, you can define at which point of time the event was fired. It's like it's one dash, it's one tick, three dashes, three ticks. And also, you have a control, still, with quite complex cases, it's become unreadable. But you need to be kind of meaningful here. Another great help from this library is it also controls the life cycle. You can subscribe, unsubscribe, and with all the syntax, you can do that. So, it's not just about array.

Marble Tests and Combined States

Short description:

Marble tests provide more control over signal emission, allowing events to be emitted at specific points in time and stopped when needed. Combined states in Grammarly Focal can be calculated from other signals using the view function and the combine helper. The use of property-based testing is recommended to check invariants in signal combinations, although it should be limited to avoid complexity. Property-based testing is powerful for ensuring the stability of divs and other components in Grammarly's system.

So, it's not just about array. With array, it makes sense, but for the simple case, like if you just need to emit at any point of time a couple of events. But with marble tests, and basically powered by library, you can control that, for example, this sort of the signal emitted a couple of values and then stopped, like unsubscribed, the feature was complete. Nice.

The next question is from Alexey. I was like, what? Alexey? But it's slightly different spelling. There are a lot of different variations of the same name, for sure. And this is about combined states. So, what does combined state look like when you need to calculate a signal from other signals? And can OVMs have a dependency from signals? It's hard to explain, probably in words. I would suggest someone who asked that to open Grammarly Focal repository on GitLab. It's called Grammarly slash Focal. And there are a couple of examples on how it may look like. In general, there is a function, we are using the view function in our libraries that allows you to somehow rely on the previous value and calculate it. If it's about combining, you can combine, there is a combine helper that combines a couple of states. And there is also a sort of callback, let's call it callback, that allows you to somehow create a computed value. Nice.

We have a question back to testing from Jacob. He says, have you considered something like property-based testing to expand beyond marble tests and check invariants when the combination space is large? Property-based testing. This is a great thing. Recently, at Grammarly, we had a talk about the property-based testing. I would suggest everyone to search for this talk, or just come here. We have a presenter, Nastya Zelenka is here as well, and talk about property-based testing. My suggestion would be maybe try to limit the overlap between the marble test and property-based testing, because it definitely will become a complex. But by itself, it's a very powerful thing in case you don't know the output. And we are heavily using properly-based testing for our divs. We need to be sure that divs that we are producing are stable enough. As well as not only divs, we are also doing some optimistic kind of dates for these divs on the clients, for the suggestions, and so on. Another topic. That makes sense. And again, remember, you can catch him at the speaker's Q&A over by the entrance after this talk.

Signals Proposal and Migration

Short description:

The signals proposal may lead to Grammarly migrating from the Grammarly-specific code in the future. One limitation is the lack of a solution for working with signals as streams. Angular has addressed this by introducing signals and providing helpers to convert signals to RxJS. The proposal acknowledges that it will take time to make it to JS core and adapt it. Grammarly will keep an eye on the progress. Thank you, Alexey!

And the last one. You only have one minute to answer, so it's got to be quick. How do you feel about the signals proposal? Are you thinking that Grammarly might migrate from the Grammarly-specific code eventually? It may happen. So far, maybe the biggest limitation about this proposal is that it's not providing the solution for working with signal like a stream. So basically, it's more about how to plug the signals idea into the existing frameworks, into UI updates. But the stream part is missing. In our case, it's definitely important, but still there is a way I believe Angular did something similar. So they introduced the signals, but also they added a couple of helpers that allows you to convert from signal to RxJS, for example. So we'll see. Even so, in this proposal, there is a mention that it's going to be quite a long way to make it to JS core and also to adapt it. So maybe in a couple of years, we will consider that. We'll keep an eye on it. We'll keep an eye on it. Thank you so much, Alexey. Can we give him a round of applause?

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

Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Understanding React’s Fiber Architecture
React Advanced 2022React Advanced 2022
29 min
Understanding React’s Fiber Architecture
Top Content
This Talk explores React's internal jargon, specifically fiber, which is an internal unit of work for rendering and committing. Fibers facilitate efficient updates to elements and play a crucial role in the reconciliation process. The work loop, complete work, and commit phase are essential steps in the rendering process. Understanding React's internals can help with optimizing code and pull request reviews. React 18 introduces the work loop sync and async functions for concurrent features and prioritization. Fiber brings benefits like async rendering and the ability to discard work-in-progress trees, improving user experience.
Thinking Like an Architect
Node Congress 2025Node Congress 2025
31 min
Thinking Like an Architect
Top Content
In modern software development, architecture is more than just selecting the right tech stack; it involves decision-making, trade-offs, and considering the context of the business and organization. Understanding the problem space and focusing on users' needs are essential. Architectural flexibility is key, adapting the level of granularity and choosing between different approaches. Holistic thinking, long-term vision, and domain understanding are crucial for making better decisions. Effective communication, inclusion, and documentation are core skills for architects. Democratizing communication, prioritizing value, and embracing adaptive architectures are key to success.
Full Stack Components
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
The Eternal Sunshine of the Zero Build Pipeline
React Finland 2021React Finland 2021
36 min
The Eternal Sunshine of the Zero Build Pipeline
For many years, we have migrated all our devtools to Node.js for the sake of simplicity: a common language (JS/TS), a large ecosystem (NPM), and a powerful engine. In the meantime, we moved a lot of computation tasks to the client-side thanks to PWA and JavaScript Hegemony.
So we made Webapps for years, developing with awesome reactive frameworks and bundling a lot of dependencies. We progressively moved from our simplicity to complex apps toolchains. We've become the new Java-like ecosystem. It sucks.
It's 2021, we've got a lot of new technologies to sustain our Users eXperience. It's time to have a break and rethink our tools rather than going faster and faster in the same direction. It's time to redesign the Developer eXperience. It's time for a bundle-free dev environment. It's time to embrace a new frontend building philosophy, still with our lovely JavaScript.
Introducing Snowpack, Vite, Astro, and other Bare Modules tools concepts!
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
Top Content
Today's Talk discusses building flexible, resilient, and future-proof React components using composition and configuration approaches. The composition approach allows for flexibility without excessive conditional logic by using multiple components and passing props. The context API can be used for variant styling, allowing for appropriate styling and class specification. Adding variants and icons is made easy by consuming the variant context. The composition and configuration approaches can be combined for the best of both worlds.

Workshops on related topic

AI on Demand: Serverless AI
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Top Content
Featured WorkshopFree
Nathan Disidore
Nathan Disidore
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
High-performance Next.js
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Michele Riva
Michele Riva
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.