Reza Bar clearly explains how signals evolve Vue’s reactivity from broad updates to surgical precision. It’s a must-watch for understanding why fine-grained state management is replacing the heavy lifting of the virtual DOM.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
Reza Bar - Reactivity in Vue Thinking in SignalsAdded:
[music] >> First be prepared.
Let's see. Let's see. Let's see.
Okay.
Okay.
No, it's okay.
Okay, it's okay.
Yeah. Okay. Yeah.
Well, Thomas and Harriet, ladies and gentlemen, I hope you had a fantastic beginning of UGS 2026.
I am super excited to be here. Welcome to my talk. I had a lot of coffee, so I'm pretty hyped. Yes, we'll have another coffee soon in about 20 25 minutes.
Well, welcome to this talk.
Thanks.
In the next 20 Thank you. In the next 20 25 minutes, maybe 30 minutes, I want to talk about reactivity in front-end development.
Uh yes, I want to tell you why it's become such a hot topic among developers these days and how it has evolved, not just in View, but also in other JavaScript frameworks.
And of course, the word on everyone's lips these days, well, not AI, cuz that's the word on everyone's lips these days, but the past years, signals. I want to tell you what they are and how they relate to modern reactivity.
I might strongly regret this, but I made a little thing to make this more fun.
So, if you go to the link mentioned here, reber.com/livecomments, you can send a message and write comments during the talk to ask questions, leave feedback, or make bad jokes, if that's what you do, which is fun as well.
Please keep it family-friendly and remember the sessions will forever be on YouTube or somewhere else. They are also I think there's a live stream somewhere, so uh yes, I see comments coming in.
Amazing, amazing, amazing, amazing.
Before talking about reactivity, let me introduce myself. My name is Reza. I am a software engineer based here in Amsterdam. Welcome to our city, by the way, if you come from outside Amsterdam.
These days I do a lot of contracting and freelancing, which is good. You can find me at certificates.dev events as a View and Knox person for the official certification program. We also have a booth outside. Come by, say hi. We have some discounts and amazing stuff going on.
I have also very recently joined the good people of Directus to work on cool projects that turn your databases and backends into shared platforms.
I am stoked to be here, back on the stage one more year, and can't wait to tell you about reactivity, which is a fun topic for me.
Uh it's my favorite non-AI talk.
Okay, so let's talk about reactivity.
Let's start with a bunch of fundamentals to lay a ground to lay a foundation and then to that.
Reactivity is a fundamental aspect of modern web development. It allows developers to create responsive dynamic interfaces. We know that.
It is a system where changes to your data automatically propagate to the UI or other dependent code without manual updates. That's fun.
It really matters these days, well, in general, because it keeps the UI in sync with your data.
It reduces boilerplate and bugs that could happen, and it also enables dynamic and interactive interfaces, experiences.
Many front-end frameworks like Angular, like React, like View have their own systems for reactivity and their mechanisms, but they vary in how they implement it.
Let's look at this timeline and see what major when major frameworks adopted key reactivity systems. The end result for them might be different, but um the end result might be the same, cuz they all achieve reactivity, right? But they do it a bit differently. So, let's go all the way back to around 2010 when AngularJS introduced its dirty dirty checking two-way binding, which was an early automatic propagation with watchers.
Few years later, around 2013, React started with virtual DOM and diffing updates, which was its early foundation, and it had renders per state. It was not very fine-grained. Uh it was very reliant on set state and on hooks.
Soon Oh, wait. Yes.
Where was I? Here. Soon after in 2014, VueJS introduced reactive data binding and declarative templates with built-in dependency tracking.
It was around the same time that Svelte 1 introduced reactive data binding and declarative templates No, sorry, talked about compile-time reactivity or its initial versions, anyway.
Uh but in the years after Svelte the Svelte team didn't sit idle, and they improved it a lot in Svelte 3, and they started with modern reactive assignments with compiler-powered reactivity.
Skipping to the good part, around 2020, it's when things finally get a bit more interesting. Uh let's talk about Solid.
Solid used true fine-grained signals.
What signals are, I talk about them in a second, but Solid did something very interesting there. It tracked dependencies at the smallest granular granularity.
Uh it meant no virtual DOM, and it meant that it directly updated DOM, meaning minimal overhead, meaning runtime cost being very low, debugging being very good, because it was very fine-grained.
About the same time, Vue 3 happened, and it was getting very popular with composition API around, I think, 2020, and a refined reactivity. It exposed reactive primitives like ref, like computed, and it tracked dependencies at runtime via proxies.
It resulted in runtime cost being low as well, and debugging becoming kind of easy. At least for me, it was around this time that I got very interested in View, and I especially coming from React back then, I was like, "Whoa, what is this? Composition API? Let's go." That was very cool.
2021, Astro was introduced. Well, Astro itself it Astro has an island architecture, it doesn't have JavaScript by default, but it uses whatever you use with it. Like, if you use Astro, then it has a reactivity system that View has.
2022, Qwik also had something to say.
They introduced fine-grained signals and fine-grained signals, and it promised signals and partial hydration.
And finally, Angular caught up in their V16.
About time.
They integrated signals into the core of Angular, and they had signals-first options.
So, from 2023 to 2024 2025 6, you see a kind of a pattern that a trend grows with signals. Like Preact, like Solid, like View, and signals-based reactivity is widely adopted.
So, you see how the concept of reactivity has evolved over the years from the early days with AngularJS watchers to React's virtual DOM to the fine-grained reactivity that we have now with View, for example.
But the reason that frameworks are putting so much effort Um console.log, please work. I'm doing no mistakes.
The reason frameworks are putting so much effort in making reactivity mechanisms is that JavaScript um is not reactive by default.
It evaluates eagerly and once. It has no subscription mechanism mechanism built in.
So, like in this example that you see, if you update your price after total is computed, total value won't change anymore. And this is kind of a no-brainer, that's what we expect from JavaScript, that's what the JavaScript as we know it.
Hi to everyone who's saying hi in the comments. Ty, someone's looking for you.
>> [snorts] >> Um but you can make your own dependency pattern, a pattern with subscribers that are a list of effects that um that depend on a value.
You can have a depends method called in the getter of your system that says, "Hey, I am running now. Remember me.
Depend on me." And also a notify method that you can call in the setter and say, "Hey, I changed. Everyone, rerun."
A dependency class like this is the heart of View's reactivity system.
Um by this, I mean exactly like this. I think something pretty much Let me actually scroll down a bit, so um Yeah, a dependency class like this is how View is doing it these days for the reactivity mechanism. This track and trigger is the conceptual core of every reactive system. Like, for example, in Solid, in MobX, in single in signals, uh in Angular signals, frameworks just make it automatic, so you don't have to wire up a depend method yourself. So, thank you, frameworks, because it makes my job easier as a developer.
Um but so, talking about View, because we are in a View conference, View has ref containers. We know that, right? We use it a lot. They wrap uh any value, like primitives, objects, uh arrays, anything in a reactive layer and make them observable.
With the first render, View records which refs were accessed and says, "Hey, I depend on you."
And later, when the value changes, View rerenders the component that depends on it. This is exactly like the pattern we saw in the previous slide, right? That it says it's just built into the core of View. It's just built in what a view user's. So, you don't have to invent it yourself, just use view. Just use ref and computed.
The example that you see here is not pseudo code. Yeah, the part of code that you see here. View is actual ref is essentially this pattern.
The dependency class with the same subscribers, depends and notifies.
>> [snorts] >> Uh from the previous slide is wired directly into the the getters and setters of the ref object, which means accessing value during a render in the system, uh it recurs the effect, and assigning the value notifies the system and it runs reruns all the affected uh the records that are affected.
Well, of course view offers more than just ref, right? It has reactive. It uses proxy, which I mentioned a bunch of times and also we saw it in Guillaume's talk, which if you don't know proxies, it's a topic by itself, but just think about um objects that wrap other objects, something like that. So, uh reactive in view uses proxy instead of getters and setters. It's the same track and trigger mechanism, just a different interception layer.
Um it works for objects, uh arrays and more, and uh it does not work for primitives. We use ref for those, like if you just have a number or something.
You don't need to unwrap that with dot value like ref, and you just access the properties directly, but well, you might lose the ability to reassign the whole object then.
Let's try to scroll down a bit so we see more of the computed. Well, yeah, we know that view also has computed, not just reactive and and and and ref. It is a derived reactive value and it tracks its own dependencies automatically. Use the same It uses the same trick and trigger mechanism as ref, but it adds caching.
Internally, view marks the computed off ref as dirty uh when any dependency is triggered, and when you read the the value and it's dirty, it re-evaluates and it caches the result. When you read the value and it's not dirty, >> [snorts] >> uh it returns the cached value immediately.
Under the hood, it's just an effect with a notify method that says, "Hey, I changed, so everyone rerun, please."
Uh it's just pretty simple.
Where am I? Here. Okay.
View recursively wraps uh nested objects in proxy when you use uh reactive or ref uh on an object. This is convenient, but has a cost.
Every nested object becomes a reactive proxy and it will be tracked.
You have If you If, for example, you have a large data set to work with, this can become costly.
Instead, you can use shallow ref to uh to track only the the dot value itself. In this case, mutations inside the object are invisible to view.
Some of the use case And if you want to update uh if you want to manually force a re-render for a shallow ref without replacing dot value, you can use the trigger ref function.
It's useful when you mutate the internals of a shallow ref and you want to notify view.
But, it is time we talked about the elephant in the room.
If you join If you have joined this conference before the past years, or if you have been doing any kind of uh web development lately, you have heard the word signals a lot. I know I have.
They relate closely to how modern reactivity systems work, and there's a good reason for that.
A signal is a container.
I agree, it is a bit cold here. Yeah, I Thank you for mentioning that. Yeah.
Thanks for the comments, by the way.
>> [snorts] >> A signal is a container. It's a reactive container. It's uh it holds a value.
It tracks who reads it, but also notifies them when it changes.
There is There There are three pillars to to signals if you think about the concept. A signal is the source of truth.
It is a writable value.
The computed or the derived value, which is a read-only value, and is it's derived from the signal, the source of truth.
And the effect function, which is a function that reruns automatically when the signal dependencies change.
This is a complete reactive system.
Everything frameworks do with reactivity is a composition of these three pillars.
Like the the source of truth, uh derived value from that, and an effect function.
This is what all frameworks are doing Well, most of them are doing these days.
>> [snorts] >> Uh this looks kind of familiar, right?
Like when we're talking about view and how it does it, it's uh it's kind of very similar, right?
This is a complete mental model when when thinking about signals. Everything else is just implementation details.
Just doing it could be a bit differently.
Look at this example with with a signal, you write a value that triggers all that reads it, like count in this example. And it computed only re-evaluates when accessed. And a dependency changed.
Otherwise, it's just cached.
Effect, which is an auto subscribe uh to any signal it reads, and uh there is no manual dependency arrays here with an effect function.
One difference here is that unlike use effect that maybe maybe some of us are more familiar with that one.
Um you never declare dependencies manually here when you use an effect.
Uh the runtime just figures it out automatically by watching which signals are accessed during the execution. So, you read signals, signals remember you, and when they change, they find you.
Only the parts of the UI that depend on a changed signal update, nothing else.
This is the core performance win and argument for signals. If you think about an older approach like the VDOM updates, when state changed, it triggered full component re-renders. So, you were kind of working against the grains the grains against a small bit only that one needed a re-render.
The signals approach says that if my value changes, directly notify only the DOM nodes that explicitly subscribe to that signal, meaning update exactly those parts. In SolidJS, for example, you can create a direct signal with real DOM subscribers, just like the visuals that you see on the right.
Um in view, for example, the compiler can optimize templates to create targeted subscriptions. Uh this is why view three's compiled uh templates are so efficient.
This model scales better as apps grow.
And um because more signals don't mean more re-renders, because each effect only reruns when the specific dependencies change.
But why is everyone talking about signals now? Because they are not new.
They uh they went mainstream around, I don't know, three, four years ago.
Uh for a few reasons, I think. Well, SolidJS proved that the model could build production apps with exceptional performance. So, thank you, SolidJS.
React had developers frustrated for years, as we've seen in the comments, the name React keeps popping up.
And with uh with time, bundle size matured and they grew. Well, signals said, "We are tiny and we don't contribute to a growing bundle size, so it is a win."
The key shift with signals was that they are not framework-specific, right? They become uh they compose very cleanly. You can build a signal system in just 20 lines of JavaScript.
They reduce friction. The The industry cat caught up with them.
Um but they have been around for about 15 years.
So, saying signals are a new invention won't be correct. It won't be fair.
Signals have been around since around 2010 with KnockoutJS and then with MobX, if anyone remembers.
Maybe the word signal is new, but the idea certainly is not.
They are not a library or a dependency you can install in your packages. There is no npm install signals or pnpm pnpm add signals, right?
They are a concept.
They are a model.
A pattern or a data layer.
It's about implementing a piece of code that tracks changes and updates whoever uses those values.
Well, what if I tell you view has signals?
Maybe the API is a bit different, but the mechanism is identical.
The ref is a signal. Computed is derived from that ref, and uh it has um lazy evaluation and caching.
Watch effect hook in view is an effect that we saw in signals implementation a few slides ago.
So, basically, view has had signals since view three.
Yay!
>> [snorts] >> Since around 2020, view has had signals, but maybe the naming's are just slightly different.
Maybe it's just not directly called signals.
>> [sighs] >> Generic signals say, "I have signal computed and effect.
Uh View 3 says, I have ref, computed, watch effect. It's kind of the same for Solid with create signal, create memo, and create effect.
And Angular now these days, I think since V16, it has signals, uh computed, and effect.
Do you see the similarities between the different frameworks? Do you see that they're all kind of using the same wording, the same concept, the same idea behind these the mechanisms?
Uh it's pretty similar between different uh frameworks.
On top of signals, View adds some more cool things.
View has template compiler optimization, like for example, when you use V1s or V if, it's it becomes way more optimized.
It has component scoped effect tracking and it auto cleans up on unmount.
It has suspense and async integration and it also has it can handle pretty nicely the SSR reactivity.
Before wrapping up, let's take a look at uh the patterns that separate someone who knows View versus someone who thinks in View. This was made by AI, by the way. This this is pretty AI line.
Someone who who knows View, someone who thinks in View.
>> [snorts] >> Ref versus reactive. The reactive hassle is real, I'm telling you guys. Engineers coming from View 2 often reach for reactive out of habit, but I'd say use it only if you need it. If if if you need it, otherwise, let's just stick to ref.
Computed versus just using a normal function to re-update something, right?
This is about performance.
Normal functions rerun every time any reactive state changes because components re-render, of course.
>> [snorts] >> Computed values rerun only when their specific dependencies change. So, always use computed for derived state.
We also have watch effect and watch that we can use in View.
Uh well, watch effect runs immediately and there is no old versus new um access the value access.
Well, with watch, it runs explicit uh when explicit dependencies change and you can access the previous values of that uh the value that you're watching.
>> [snorts] >> So, use watch effect for hey, sync this to that. And use watch for react to a specific change.
View also has effect scope. Well, View use uses this internally. Every composable that creates effect should wrap them in a effect scope so the color can dispose all effects as one unit.
Without these, effects outlive their context and it leads to memory leaks in especially in SPAs.
I cannot repeat this enough. Keep computed pure.
A computed property that mutates state is a bug waiting to happen.
Uh the reactive graph assumes that compute uh computed is a pure function.
Side effects inside it break the mental model and they create update loops and we don't like that.
Well, lastly, having said that signals are a pattern and not a library you install, there are standalone packages outside or out there that you can use uh to test or actually implement a feature with them. For example, View reactivity or View/reactivity uh can be used completely standalone, not even with View. Like you can use it with anything. View is not required for that. We also have Preact/signals that work with vanilla JavaScript, with React, with Preact. There is an alien signals by the View core team that uh is extremely minimal um but it's very good for experiments, very powerful for experiments.
Uh yeah.
Okay, and now uh I promise it's the last two slides before wrapping up and I would only take 1 minute. Time me if you want.
Reactivity alongside many other topics are fundamental uh parts of web development these days.
Uh if you want that extra boost of confidence about topics like reactivity, um check out certificates.dev. There is now a promotion on certificates.dev that if you purchase a Nuxt or a View exam and preparation bundle, you get a free upgrade to a full bundle with bootcamps.
So, I did some calculation myself, but take it with a grain of salt.
It becomes like a 50% discount kind of thing. I don't know, I'm just guessing, but if you purchase a View and or a Nuxt uh exam with preparation bundle, you get a free bootcamp.
The exams are created and reviewed by Evan You himself, uh first off his name, Sébastien Chopin himself uh for the Nuxt certificates.
They're endorsed by so many good people in View and Nuxt community that you see here today or they're talking today.
Um And these are the official certifications that you can get for these programs, for View and Nuxt.
There's also there's also React, JavaScript, Laravel, a lot more, but these are the official certifications that you can get and become a certified uh developer.
Uh they also have different levels so that you can choose if you want a junior, a mid-level, a senior, up to you to to find one that suits you.
There are quizzes, training materials, specific bootcamps, and so much more.
And just so you know, all the exams are proctored so they're all um fair for everyone.
Come to our booth. We have a lot of stickers. You can collect them all like the Pokémon from Guillaume.
Uh ask for ask questions. We have cheat sheets. We have discount codes and everything or find the website.
And to match with the theme of the conference this year, we have a new AI platform cuz why not?
Unlearn.dev is about learning the new ways of development. You can scan this QR code. It gets you there and it tells you a lot about it. It teaches the the foundations of programming and how to create software when AI is part of the stack these days.
So, we unlearn some of the older methods and we try to learn how we can use AI more properly more than just And with that comes my talk to an end.
Thanks for listening. Thank you for writing your comments. If you have any questions, please please go to Evan You.
If you have if you want to get a coffee, find me outside. Jokes aside, if you want to connect or chat, you can find me on socials listed here, mostly found via Rebar.
And enjoy the rest of the amazing conference. Thank you very much.
>> [applause]
Related Videos
Agentforce NOW AMA: Build with React and Salesforce Multi-Framework
SalesforceDevs
490 views•2026-05-28
How agent o11y differs from traditional o11y — Phil Hetzel, Braintrust
aiDotEngineer
450 views•2026-05-28
WEB TECHNOLOGIES UNIT-2 | Degree 4th sem BCOM Computers web technologies unit-2 full explanation💯✅
LearnwithSahera
1K views•2026-05-29
More tests are always better? How to use AI to identify tests that bring little value
Alliance4Qualification
335 views•2026-05-29
Search Algorithms Explained in 60 Seconds! 🤖💨
samarthtuliofficial
218 views•2026-06-01
People of Game of Thrones using JavaScript DOM
AltCampus
296 views•2026-05-30
Introduction to Problem Solving Part - 1 | Lecture 1 | Intermediate DSA
ascensionix
107 views•2026-05-29
🚀 BCS613C Compiler Design | Module 1 to 5 Schema Evaluation 🔥 | VTU 6th Sem 💯 #VTU #bcs613c #exam
Pranavaa-y4y
104 views•2026-06-02











