Redefining Reactivity with Signals

Thank you, Ben, for great introduction.

Yeah, and it's, as it's been, already referenced, this talk not related to react, but it's related to reactivity.

Okay.

So just bear it in mind.

So I will be covering, a lot today.

Signals.

This is like the latest, innovation in frontend engineering.

And maybe it'll be exposed down to backend in recent, in the future, who knows?

And the frameworks and how signals related to the frameworks, to the modern framework frameworks, I should say, these days.

And how can you leverage signals.

In your work.

So to create better apps and performance apps.

And before we get into that, let me introduce myself.

I'm Lex Kincevic.

I'm playing games sometime as well as, building software and helping other companies and dev teams, with hands-on advisory, guidance and long-term support.

So I love building tech.

Right now I'm involved in with the robotics company and we build an awesome robots.

Yeah, I'm Google developer expert, which means I'm talking a lot, and spreading my experience so other can learn around the world, globe, different conferences and events.

Also I'm running workshops sometime.

I love in-person workshops, dislike online after recent years especially.

And yeah, so I'm super passionate about technology.

Nice.

[audience member] ]Please tell it's your car.

[Lex] This actually wooden, you can't believe this is a wooden, Tesla like cyber truck.

If you go on your YouTube and type wooden cyber truck, you will be amazed.

So I also have a spare time.

I'm in spare time.

I ride in my motorcycle.

I'm climbing in the mountains, jumping up in the air.

And also sometime I wearing a beard and riding bicycle.

But sadly enough, this bicycle was get stolen six months ago.

But the good thing, I got a new one.

So yeah.

And I have a question for you guys.

What's the hardest challenge programming web apps?

So raise your hands.

Who's programming Web apps?

Okay, so now if you know the answer to this question, keep your hand.

There is lots of things.

Okay.

Go ahead.

[audience member] Name variables.

[Lex] Alright.

This is a good one.

This is a good one.

I like this.

You know what I have.

Alright, here you go.

Yeah.

Okay.

Any more shots, anyone?

[audience member] State management.

[Lex] Wow that's a good one.

Okay.

Would mind passing that right?

And yeah, you guys right there is lots of problems.

Anyone want to shut [audience member] avoiding s[?] [Lex] Okay, great.

Would you mind passing right there up?

And my answer to this question today, synchronizing the data in the view.

I think this is major one.

Of course you named also good, but this is what we're talking today.

Synchronizing the data in the view.

Imagine you have a source of data, source of truth, then you have a view.

Maybe there is one way, direction flow.

Maybe you have another view.

And there is two ways.

I'm not talking two ways data bi I'm talking the flow.

Because, two ways might be not a good practice is consider is not a good practice today.

And so there is always change detection involved, in, in things like that.

Synchronizing data and the view.

And it can get really crazy and depends on the framework of your choice.

The model can be different.

Synchronization model can be different.

Sometimes it's model data to the view synchronization.

Through change detection cycles, which occur in your application, sometimes it's virtual DOM involved, right?

So it depends on the framework of your choice.

You have this, change detection magic there, and it can get really complex and sometime in order to become a front end developer, you must become a change detection PhD for that specific framework of your choice.

And that has been a challenge for quite many years.

And the reason why, because there is no application in the world, which doesn't involve a asynchronous events, right?

It's always something about asynchronous.

Like API calls, event listeners, user notifications, management, web sockets, et cetera.

And the challenges it brings, like you always have to look out, for racing conditions, right?

This is quite challenging.

Memory leaks, Basarat gave a great presentation on that today.

So data flow, performance, the bigger the app gets the harder, performance becomes a harder challenge.

You always have to look up for that, running a benchmark, et cetera, making sure everything works smoothly as well as you can get in situation when you are… it's not happen always and not as always these days, but sometime, blocking main thread, can become a nightmare, and so you don't want to.

Your user's like doing this, oh no, I hate loading.

Have you been to this situation yourself?

Waiting for loading.

So yeah, we'd want to avoid it.

So what steps can we take to avoid it?

First of all, we can get this nice idea of async programming.

I think everyone familiar with promises or async/await with just syntax sugar on top of the promises.

It's a great technology.

It's been around for a while.

Raise your hands if you ever use promises.

Oh, okay.

Most of the room.

Nice.

Me too.

Yeah, and it comes with downsides.

Like every technology has pros and cons, and so the downsides are error handling and debugging in complexity.

It can get really crazy to debugging.

If you create this crazy chain of promises that get crazy to debug it.

It has lack of cancellation, promises, doesn't have cancellation mechanism built in.

It's easy to get into race conditions and nested promises.

In other words you can get into callback hell quite soon if you trying to build this complex, promises chain.

Yeah, it's like exactly riding in these boats.

I'm not saying promises is bad, but I want to read you this poem.

Callback Hell had me tearing my hair out.

I thought promises would save the day.

Now I tangle in a promise hell.

But there is great use cases for promises.

I using it myself.

And the one I like the most is, just say you're querying a database like CMS type, right?

You just querying the data one off, get the data, forget about it, right?

So that's the best use case with the premises.

But once you get in something more complex, I would consider using something else.

So what are the options?

Any guesses?

Observables.

Raise the hand please.

Alright, nice.

Okay, here you go.

Two, would you mind passing it right there?

Okay.

So yeah, reactive programming, it's a great solution for that problem.

Reactive programming is all about observer and observable.

So observable is someone like myself at the stage, right?

So I'm an observable at this point.

And you are observers.

So you observing.

That's basically the observer pattern in the show.

That's how it works.

Of course, you have to remember, subscribe, and I subscribe.

That's another topic.

But yeah.

So observable is a core, object is a core concept in reactive programming.

And there is a great library which brings observable into JavaScript.

Raise your hands.

Who know what is that?

What's the library?

Okay, here you go.

Yes.

The library called RxJS.

By the way, it doesn't matter if you are, what language you're using, not necessarily JavaScript.

There is every language in the world has reactive library there.

Might be third party library or might be built into the language.

So if you interested, you can look up language name: RX, or language name: observables or, and you'll figure it out.

So yeah, RxJS is a library which brings observables into JavaScript world and the story of reactive programming and observable starts long ago.

I think the guys at Microsoft decades case ago were trying to solve the problem in building Excel.

Excel sheet, there is lots of different like tables and rows and you want, and they wanted to synchronize those cells together, right?

And they come up with this pattern.

It's like all this pattern, it's not new.

So yeah.

I guess you are familiar with some.

Okay.

Raise your hands.

Who is familiar with observables?

Okay, a couple of hands.

Oh wow.

That's great.

Awesome.

So I hope you love it.

And yeah, there is a couple, there is 45 million almost NPM down loss of RxJS from NPM.

Imagine that this double what React gets.

React library probably 20 million per week.

This is like about 45 million.

This is a big deal.

Lots of big tech companies using observables in their products, including Google, Canva, yes, YouTube and others.

So yeah, it's a big deal and I would encourage you to learn it and dig your brain into it.

But as, as any technology, it comes with downsides, which we cover in a minute.

But what are the features?

The major feature of observables?

They're cancelable.

Cancelable, right?

So you can cancel any request.

Which is good, like any, if you talking to data source using observables, you can cancel it easily.

Observables provide a predictable error handling so it is easier to error handle.

It's guaranteed tear down of resources and extensive list of operators, which means you have to write less code.

As well as it keeps you away from callback hell, which is great.

So what are the downsides?

There is a couple.

So first of all, steep learning curve, right?

So especially for experienced people, if you are in software engineering like five, 10 years or more, guess what?

You it'll take more time for you to understand how observables works versus a beginner.

I wonder why, and I guess get an answer because I think the answer is because observables, it's it's all about mental model.

It's a different mental model compared to traditional programming, right?

Because if you're a beginner, you haven't developed this traditional programming muscle, right?

So for you, it doesn't matter.

But once you train this programming muscle, if else, all that loops though, understanding observables becomes a little bit more challenging.

And I was challenged as well.

So yeah, debugging difficulty can be tricky.

There is a couple of solutions right there, but yeah.

Debugging.

Yeah, not as perfect sometime.

And it can get really complex.

Like honestly, one time I remember, using observables for the first time and actually I was using an state management library built on top of observables and we, two weeks later.

I get back to this project, I didn't know what's going on, like what the hell?

I don't understand.

So it can get really crazy, but the more you do that, the better you understand it.

And here we go, promise hell had me tearing my hair out.

I thought observables would save the day, and now I tan in Observable Hell.

So it's all about pros and cons, best practices, et cetera, et cetera.

But yeah, I'm not trying to sell observables are bad.

There is a couple of good, great use cases dealing with multiple events over time, handling real time data, combining multiple assumed sources.

But primarily it's when your source continuously changing, that's a great use case for observables.

And promises, if it's not continuously changing one operation, fetching data, forget about it.

That's a great use case for promises.

That's a difference.

Okay.

We just covered a little bit of promises, observables, then you know, there is a check change detection theme.

Depends on the framework of your choice.

It might work differently.

Model to DOM dome or model through virtual DOM to DOM and there is lots of magic there.

Yeah.

Usually getting tricky, especially in the complex scenarios, and that's where signals comes in.

Okay.

Raise a hand if you ever heard of signals.

Alright, a couple of hands.

Okay, great.

Awesome.

Alright, signal is a way to represent still stateful reactive data doesn't mean anything to you.

Okay, let's try that.

Signal is reactive primitive.

Does that make sense?

Eh, so let's break it into two reactive, primitive into two separate words.

What's reactive?

Reactive is a propagation of change, data flow propagation, right?

So that's what really means reactive.

What's primitive?

Just a fundamental data type, first class citizen, right?

So that's a primitive.

So now I think it's making more sense.

So think of signals like in a way, you need direction, data flow, and it's all about values and computations, right?

And the benefits are well signals, they are optimized for front-end frameworks.

Not every front end framework involved in the in signals game at this point, but I'll cover that in a minute.

So signals reduce the rendering time, which means your application become more performant and it in the future, it might become actually useful on a server.

And I know for a fact there is a team, I cannot disclose a much details.

They working on three way data by then using signals.

Server, signal, talk to frontend signal and frontend signal talks to DOM.

Imagine that.

Yeah, it's fun.

Signals are fun.

So when to use signals?

When literally, when you want to render something on UI, you just use Signal.

That's the rule, right?

So the rise of signal started quite a while ago, a little bit more than a decade ago, right?

It's not new.

Signals, totally not new.

Do you know what was the first front-end framework implementing a signals concept?

Eh?

Uhuh.

Knock out.

Uhhuh.

Okay.

Knock out.

Yes.

Knockout.

Oops.

Knock out and meteor these two guys.

Okay.

Would you mind passing right there.

Yeah.

Anyone experienced Knockout?

Have you tried Knockout??

Yeah, I did as well, but at this point it was like 2012.

And I didn't really understand like what, like why I need it.

Like honestly, but only maybe five years later I start getting it.

But at this point, like back in 2012, like why I need Kockout?

like I dunno Anyways, also, I used to experience, Meteor, but unfortunately, Knockout and Meteor they're not as, they not become a predominant frameworks, and right now we wouldn't see much applications written with  Knockout and Meteor.

They're kind of, Redundant, I dunno.

But, going forward, Vue JS took these same ideas, implementing some of internal change detection and.

Et cetera.

It's called, ref in Vue.

SolidJS popularized, signals idea quite big, back in 2020.

That the core idea, SolidJS built on top of the, on the idea of signals.

Then Quick JS borrowed this, this idea of signals and well implemented within their framework.

Have you heard of Quick js?

It's new.

It's created by a original author of Angular, but it, I don't know.

Yeah.

Okay, so Preact.

Yeah, Preact is good and they implemented, they followed and implemented signals within Preact.

If you guys using React, you can take Preact signals in, so no problems.

And also Angular follows the suit.

So now actually is version 19 of Angular being released last week.

Anyway, so if you want to learn more on signals, I would encourage you guys to read this, doc on vuejs dot org.

And guess what?

Yesterday I become official contributor in the Vue JS documentation.

I updated this web page with some small useful link and it's been merged.

While dealing with the signals, you come across this term called fine-grained reactivity.

Anyone heard of that term?

A couple of hands.

So what it means, it's literally, like what is differentiate from traditional change detection to signal kind of base change detection that in that case.

In case of  fine-grained reactivity, the only UI portion of the view will get changed.

The rest of the view might stay the same.

So there is no like crazy change detection cycle going on.

If you change the one, like I know, number stream, et cetera, so the DOM corresponding to this value will get re-rendered.

Everything else will stay the same, right?

So it's super performant technique, change detection technique.

And thanks to, signals now it's yeah, become reality and, it's a great, it's a great technology.

I'd say.

It's so great that TC 39 involved into discussing and potentially making signals as a part of JavaScript language.

Imagine that.

And that what it means is first class citizen, right?

Signals they're first class citizen in, in a couple of modern frameworks, not yet in a JavaScript language, but maybe sooner or later it, they will become a big deal in JavaScript language.

So currently this proposal, reached stage one, Rob Eisenberg and Daniel Ehrenberg, the original authors, by the way, I want to shout out to Rob Eisenberg.

He's the guy who reviewed my slides and but it's not limiting to just these two guys.

Also, people from other frameworks being involved and still involved into that discussion, making signals, part of ECMAscript, JavaScript language.

The major goal is to unify reactivity model across every single framework, which means, for developers it'll be less work.

Because it doesn't, it would be, if it become a part of, JavaScript language and which means we, we will get this unified reactivity model, it means it wouldn't be really matter what javaScript library you're using, or maybe you wouldn't want to use frame.

It doesn't really matter what framework you're using, or maybe you wouldn't be using framework at all, but you would be able using that builtin reactivity.

If you want to learn more, check out this proposal.

And if you want to get your head really deep, check out this, signal, polyfill.

It's, open sourced, currently just a preview so I wouldn't build serious stuff on it.

But if you want to just learn.

Yeah, that's the best way.

Okay.

I have a demo for you.

I want to really quick because look, talk is cheap, right?

You want to see the signals, how it works.

So here is my app.

I hope internet won't break.

So that's how it looks.

Simple search.

I can search here.

This page can be built with anything, to be honest, even with jQuery, no problems.

But this is just a demo.

So I can reload the data, clear the data, filter the data.

Easy.

So how can we implement it?

Oh.

Yeah.

And if there is no internet connection, let me emulate that.

No internet connection.

I got this nice error, right?

And if internet connection gets back, everything works, everything online.

So that how it looks.

This is my, oops, this is my forest.

Supposed to be like a full screen.

Anyways, I hope you can see it right?

Can you see it?

This is my, code.

I wish it full screen.

But anyways, so this my template.

Ah, it's freezed.

Oh no.

Is it dead?

Ah, shit.

What can we do?

Alright, let me, so all you see is a template.

So that's fine.

So this is my signal right here, which is a query, right?

It's a query signal.

So it's looking for input right when you type in it changing.

Then I have another part of, template is loading.

So this, okay, query and data is two different signals.

So query corresponding for input.

Data corresponding for output.

This is loading progress if loading, so if error and if success right here, right?

So if while, if data, if while you type in the data gets load in, so that gets executed.

The progress bar showing.

Once there is an error, you can see this nice error section here rendered on the view.

And yeah, if there is a data there, I'm checking if it's empty.

If it's not empty, it just loops through the, array of values.

And if it's empty, you just can see this, no data.

Unfortunately there is part of code here.

Yeah, I cannot show it, but it's simple code.

It's just another five lines.

But I hope you get the idea.

This is WebStorm by the way.

It's supposed to work.

I thought, should I use VSCode or WebStorm?

I'll report it.

I'll report it to WebStorm.

I'll complain.

I complain.

Alright.

And yeah, we're getting to the end soon.

And last point here, I want to say signals at scale.

You just learned a little bit of signals.

I show you simple demo, hello world demo.

Who cares, right?

But, I guess you guys watching like YouTube, right?

Are you using YouTube platform?

Maybe a content creator?

Or maybe you're just watching YouTube, right?

There is signals already built into YouTube platform.

The journey starts probably maybe a year ago.

They set the goals.

I mean it clearly for YouTube team, Google team, which correspond to YouTube code basis solutions, they are, were cautious about performance.

They wanted to improve performance, especially on, low spec devices.

So they set some goals, okay, we want to improve interaction latency, high and consistent frame rate.

Yeah, that's what we want.

And simplify and unify code base because it's very important unification, and start of a code base, especially, for a big projects.

Because in the big teams, in the big projects, people come and go, right?

And some people can go learn that, and then they leave.

And they take in the knowledge and if you have a system, to onboard new people and you have your code base unified, so it's easy to onboard people and it's very easy to let people go.

So I think it's a good idea.

And so they like said, okay, how we can solve these problems.

They can see the signals.

They, come up with a, they prototype it, they benchmark it, and then they just put solution together and their result exceeded expectations.

It's like it's blow their minds the results.

So they get 35% performance improvement on low spec devices on a, on a old mobile phones, let's say.

If you're using like cutting edge mobile phone, it really doesn't matter.

But they were targeting, low spec mobile phones and they achieved 60 frames per second on video player on that same low spec devices.

I was testing YouTube VPS on my, pc, it showed like more than 100 VPs, but again, they were targeted, low spec device.

It's not like powerful machines.

And yeah, and at the same time, they improve the code structure, which a is great win.

And yeah, last thing here.

I think it's one of the last points.

The new reactive data flow though, in order to achieve that, like in order to build a solution using signals, first you think of your data flow.

I think it's really doesn't matter, like if I build a solution, I don't care if I using signals or not, but when I would always think of data flow first, but building solution with signals is forcing you to think data flow first.

It's, so we think of how your data flow, like what you decide what signal would be responsible for what action and et cetera, et cetera.

Maybe like showing the demo, some like a signal, taking care of user input, another signal, taking care of the output and so on and so forth.

And in the real world application, you would have maybe like dozens or hundreds signals like that on the page.

And yeah, the bigger win here in the end, there is no need to focus on performance tuning.

Raise your hand if you guys ever stuck with change detection magic.

Don't know what's going on.

Like performance, goes down like, why my application doesn't work, why everyone can play, why it's working on my machine doesn't work on the earth.

If you deal with signals, it's not silver bullet.

Definitely you'll get issues, you there, you'll get someone complain, but just simpler to build applications, interactive application using signals.

And also definitely you would get less, you won't get kicked by performance, like maybe like only 5% scenario.

So like really low here.

Oops, no signal.

But please stand by.

So how to start with signals.

So the best, I can give you a couple of links.

What you can do, you can take this photo or this slide, and while you do, if you want to continue learning the signals.

And while you're doing that, I'll take a picture of you, if it's okay.

Oh, alright.

Yeah, I hope you enjoyed the talk.

Sorry about the demo.

I never get this trouble with demo.

Usually it's like internet doesn't work or something, but it's freaking the whole thing freezed.

Imagine that.

Anyways, hope you enjoy it.

So yeah, imagine I just went, do you have a little, another minute?

I think we're running out of time.

So let me get to that slide.

If you want to get connected, guys.

Yeah, just send me a request on LinkedIn if you want to grab some swags, like a nice stickers, exactly that sticker.

So come and see me.

So thank you for your time and if you have any questions, if you have time for a question, I'm happy to answer any of your questions.

Thank you guys.