Small but important correction - in these trivial examples you *can* use setCount(count => count + 1) to get around one issue I showed (assuming your code is that simple/trivial) In the real world this is not always an option though, the article shows better examples that demonstrate more properly: www.builder.io/blog/usesignal-is-the-future-of-web-frameworks
hmm the entire component doesnt need to rerender if you return it in a hook using dependencies, so wheres the difference to signals? i guess with signals you can have call the (lets say) signalhook directly without using an extra dependency, but does it work faster? i dont think so. and you cant use signals without statesand more than one component, so theres the same issue with async and statemutation
I like React because it exercises the browser with rerenders. It's like browser calisthenics so the browser stays fit. I don't want by browser getting fat.
It's been present in react long before this video, but it's popularity exploded when people realized you could do things useState can do but 40% faster
The way Solid JS should really be the norm in my opinion. React was build to deal with a UI that was constantly being updated, which is not the case with most web apps. It's odd that the React way as seen as normal and the Solid JS way is seen as revolutionary
I used (and loved) KnockoutJS before React came out. It used a vaguely similar approach to singals which led me to always believe the whole virtual DOM diffing thing was kinda dumb, yet it was quickly accepted as being normal. KnockoutJS came out years before react and was by no means perfect, but I wish its approach was improved upon over all these years rather than largely forgotten until now.
What bothers me the most is JSX. - It makes it real hard to do separation of concerns between UI layer and business logic. - Event handlers. I always wondered why they don't add a history parameter to the callback like they do with state setters. That's yet an other entry on the long list of React's inconsistencies. - JSX is supposed to be a HTML DSL yet you end up using more JS in your templates for some reason. - There is no built-in CSS DSL so you end up with bad implemented CSS-in-JS librairies and utilities CSS, the man who thought it was a good idea is a masochist. When a common return statement look like this how long does it takes before you start to question wether your fancy library is solving an issue or is causing a completely new problem ? return ( {TodoStore.todos.map(item => ( {item.text.replace("x", "y")} {item.isCompleted && ( TodoStore.removeOne(item.id)}> Remove )} ) That's why I would choose Vue over React any time, the directive-based templating. And I'd obviously prefer Angular at work but the lead forces us to work with React.
I tipically never comment, but damn, you present stuff that actually matters in a really easy and enjoyable manner. 5 minutes ago I didn't know or care about this, now I do and it's interesting af!
@@ajfalo-fi3721What are you talking about? @mjarkk is correct, and I didn’t see any other comments yet pointing this out. Nothing wrong with the truth being stated more than once, unless you want to hide it.
@@alex-craft yeah svelte is less boilerplaty than solid + i prefer the templating of svelte over jsx. I was already accustomed to it through smarty and twig etc
Question for you since you do deep dives, and have a general interest in learning. What are your thoughts on code assessments vs take homes for assessing a candidate's talent?
In my experience, having a candidate do a small home assessment and then mob/pair program with the candidate to is the best way of finding out what level they are
@@creamy_gavin Completely agree, and you get a sense of how they name, do they test, and how well they abstract and simplify the code. I wish more people like you were hiring.
Thanks again, Steve. I've fallen in love with this framework, but one thing concerns me, though. I'm quite aware of the $qwikfy function, but ideally it would be best if we had some UI qwik libraries, done in the qwik way, don't you agree?
@@cedi2929 With Vue you use Watchers, the API looks like this: watch(dependency, callback) The dependency can be any type, ref, reactive, getter function, array, etc... And the callback can be asynchronous or synchronous.
im a but confuse, so this signal thing is a solidJS only method ? and can we use it in react app ? 0:51 is that a solid js app or a react app ? is it possible to use signal in a react app ?
Ryan Carniato, creator of Solid JS, has been on an evangelical mission to introduce the concept of signals to the javascript community, which is being adopted by a lot of other frameworks.
Thanks for explaining that the hype isn't around something new--just that the rest of the JS community rediscovered the pub-sub model that has been around since the 90s lol
To be clear, I think signals are good--it's just odd that they haven't been around for longer. I wrote something of a wrapper around the DOM api at one point that utilized a construct very close in semantics to signals, but I never really maintained it since I shortly after learned about Solid.
Hydration basically means that instead of shipping your whole JS code in one bundle you have multiple chunks, so the browser only has to download the code for the content that's currently on the page.
In UI frameworks, hydration is a process where JavaScript code attaches itself to HTML that was sent from the server. It means JS doesn't need to rebuild whole UI again, but rather for example it can just attach event handlers to appropriate DOM nodes for that existing HTML (in case of React). It still has to run some code to actually do all that, but it doesn't need to rebuild the whole UI from scratch because it already exists, so hydration is less work compared to rendering full from scratch. What Charles M. said in his comment above is not hydration, but rather code splitting. This can be used for delayed hydration so that you only hydrate certain parts of UI when they become relevant. I think Astro does this a lot and you can tell it to only hydrate (load and run JS) for a certain part of the UI when you scroll to it for example. I guess in context of Redux it might be sending Redux store with existing data from server to browser and then just reuse that state on client. I'm not sure, haven't used Redux for a very long time.
@@rand0mtv660 That's partially true. Hydration's goal is to offer the possibility of modifying a view client side that was server rendered. In a meta-framework, the server generates the HTML, ships it to the client and the client side takes over, hydrating the page content upon state changes. Those event handlers you talked about aren't explaining what hydration is, they're explaining one implementation of it.
@@charlesm.2604 Yeah that's why I mentioned for example it can attach event handlers. I was mostly referring to React implementation since I'm most familiar with that one. The point I tried to make is that hydration doesn't have anything to do with many smaller JS bundles (code splitting) and you can have hydration with a single monolithic JS bundle that isn't code split at all. They are two different things that don't have to be used together at all.
Hello, can you help us with more Fine-Grained and deep discussion for signal. I can see quick and solid js, is more Fine-Grained Reactivity, less expensive and give fast performance. Why not angular so much
There’s no doubt that things are more performant but I don’t believe that the framework makes or breaks an app. With the sheer volume of react apps in production it’s clear to me that any performance gains from frameworks like solid likely won’t matter at the end of the day unless my use case is in the critical path of what solid is great for.
Technically it can be {count} (only in the DOM, when used directly in JS like `const double = count() * 2` you need the parens. But I think it's more idiomatic to use {count()}
Hope react will take this as a signal 😂 to support this natively. Valtio is the close but not quite to supporting this type of behaviour but it really would be nice to be built in.
I'm not aboard the 'signal' train. I can see the benefit if you're new to React or don't have much experience or a good understanding of the fundamentals. I feel like it's just syntactical sugar for useState with useContext or something along those lines. I'd rather just implement that myself so half my team doesn't have to study some 3rd party library. For this example, wouldn't simply returning a function to setCount solve this problem i.e. setCount( count => count + 1)? Either way, you shouldn't ever be setting a useState variable directly in it's setter. Always wrap it in a function and pass is the old state variable as a param as shown above.
Small but important correction - in these trivial examples you *can* use setCount(count => count + 1) to get around one issue I showed (assuming your code is that simple/trivial)
In the real world this is not always an option though, the article shows better examples that demonstrate more properly: www.builder.io/blog/usesignal-is-the-future-of-web-frameworks
extreme performance and javascript in the same sentence...
on what kind of drugs are you on ?
Thank you for correcting yourself in the comment here :)
Great job, Steve. Greater job still for the correction. Shows sincerity.
Except you might want to not shadow the variable.
hmm the entire component doesnt need to rerender if you return it in a hook using dependencies, so wheres the difference to signals? i guess with signals you can have call the (lets say) signalhook directly without using an extra dependency, but does it work faster? i dont think so. and you cant use signals without statesand more than one component, so theres the same issue with async and statemutation
I like React because it exercises the browser with rerenders. It's like browser calisthenics so the browser stays fit. I don't want by browser getting fat.
Rather the exercise of the memory i'd say
React also keeps us warm in the winter ^^
@@nawfelbengherbia8302 you mean more CPU cycles? hehehe
I love how you simply start the video with subtitles and finish the video without doing some unnecessary stuff. Loved the content
It's funny how something that has been present in Vue for a really long time now is depicted as something revolutionary :D
Popularity never always means better!
It's been present in react long before this video, but it's popularity exploded when people realized you could do things useState can do but 40% faster
The way Solid JS should really be the norm in my opinion. React was build to deal with a UI that was constantly being updated, which is not the case with most web apps. It's odd that the React way as seen as normal and the Solid JS way is seen as revolutionary
It’s still lipstick on a pig compared to Svelte imho
I used (and loved) KnockoutJS before React came out. It used a vaguely similar approach to singals which led me to always believe the whole virtual DOM diffing thing was kinda dumb, yet it was quickly accepted as being normal. KnockoutJS came out years before react and was by no means perfect, but I wish its approach was improved upon over all these years rather than largely forgotten until now.
Stencil does something very similar to signals with their state decorator
@@bradyfractal6653 your comment should be pinned!
What bothers me the most is JSX.
- It makes it real hard to do separation of concerns between UI layer and business logic.
- Event handlers. I always wondered why they don't add a history parameter to the callback like they do with state setters. That's yet an other entry on the long list of React's inconsistencies.
- JSX is supposed to be a HTML DSL yet you end up using more JS in your templates for some reason.
- There is no built-in CSS DSL so you end up with bad implemented CSS-in-JS librairies and utilities CSS, the man who thought it was a good idea is a masochist.
When a common return statement look like this how long does it takes before you start to question wether your fancy library is solving an issue or is causing a completely new problem ?
return (
{TodoStore.todos.map(item => (
{item.text.replace("x", "y")}
{item.isCompleted && (
TodoStore.removeOne(item.id)}>
Remove
)}
)
That's why I would choose Vue over React any time, the directive-based templating.
And I'd obviously prefer Angular at work but the lead forces us to work with React.
I love the content you put out Steve. So concise and well presented. Keep up the awesome work 🙌🏻
I tipically never comment, but damn, you present stuff that actually matters in a really easy and enjoyable manner. 5 minutes ago I didn't know or care about this, now I do and it's interesting af!
You don't have to add count to the useEffect dependencies if you make setCount a function with count as argument setCount(count => count + 1)
do you even read comments before posting?
@@ajfalo-fi3721What are you talking about? @mjarkk is correct, and I didn’t see any other comments yet pointing this out. Nothing wrong with the truth being stated more than once, unless you want to hide it.
@@peterbalogh5622 see the pined comment from Steve
Love this content format. Simple, concise, and more importantly, it provides bite-sized information for viewers.
Hey Steve, nice video!
What tool and method did you use to generate your subtitles? They look great!
Svelte does it out of the box
Clear & simple explanation!
Man u are the G.O.A.T. u made this topic so easy to digest. Keep up the firee content man!!!!!
Do you have a video about svelte? I'd like to hear your insights about it
@@alex-craft yeah svelte is less boilerplaty than solid + i prefer the templating of svelte over jsx. I was already accustomed to it through smarty and twig etc
I hope you continue on liking what you do and provide us more good contents like this. Thank you so much. :)
Very clear explanation, thank you
Straight talk: Its RxJs with training wheels. Of course its simpler, its solving a much easier problem.
So is it better to hydrate or to dry?
2:39 yeah vue was not forgotten =)
Is Vue way performant than React in 2023? Just asking
How does it perform when dealing with arrays that are rendered?
Like RH says, "As enginers, we should be offended". Checkout Svelte instead.
It is something that we can now use with ReactJS + Vite properly?
Question for you since you do deep dives, and have a general interest in learning. What are your thoughts on code assessments vs take homes for assessing a candidate's talent?
In my experience, having a candidate do a small home assessment and then mob/pair program with the candidate to is the best way of finding out what level they are
@@creamy_gavin Completely agree, and you get a sense of how they name, do they test, and how well they abstract and simplify the code. I wish more people like you were hiring.
What do you mean by more code to download? Whole React gets shipped in case of SSR anyway
is there a sharable state management for components in qwik.js?
Thanks again, Steve. I've fallen in love with this framework, but one thing concerns me, though. I'm quite aware of the $qwikfy function, but ideally it would be best if we had some UI qwik libraries, done in the qwik way, don't you agree?
There's a group of people working on exactly that!
Can RemixJs use signals?
I miss RXJS
Keep up the great content!
Soon Angular? What are they doing?
2:38 Vue was mentioned LETSGOOO, I feel it gets left out most of the time, thank you.
The "Vue way" is ref() correct?
@@cedi2929 With Vue you use Watchers, the API looks like this:
watch(dependency, callback)
The dependency can be any type, ref, reactive, getter function, array, etc... And the callback can be asynchronous or synchronous.
@@cedi2929 Yess, ref() and reactive() are Vue's fine-grained "signals"
im a but confuse, so this signal thing is a solidJS only method ? and can we use it in react app ? 0:51 is that a solid js app or a react app ?
is it possible to use signal in a react app ?
Ryan Carniato, creator of Solid JS, has been on an evangelical mission to introduce the concept of signals to the javascript community, which is being adopted by a lot of other frameworks.
Ah yes, we going full circle aren't we I remember "laser beam the value directly into dom" at 2001!
Thanks for explaining that the hype isn't around something new--just that the rest of the JS community rediscovered the pub-sub model that has been around since the 90s lol
To be clear, I think signals are good--it's just odd that they haven't been around for longer. I wrote something of a wrapper around the DOM api at one point that utilized a construct very close in semantics to signals, but I never really maintained it since I shortly after learned about Solid.
Observer pattern
@@charlesm.2604 Mixed them up, thanks
I'm a freelancer, switched to Svelte this year
@@aamorous Now I use both Svelte and Next, depends on the project
Next probably easier due to the React ecosystem but Svelte nicer to code in
Okay, but what does hydrate mean? You're saying that as if its a commonly used term and I've only heard it in redux.
Hydration basically means that instead of shipping your whole JS code in one bundle you have multiple chunks, so the browser only has to download the code for the content that's currently on the page.
In UI frameworks, hydration is a process where JavaScript code attaches itself to HTML that was sent from the server. It means JS doesn't need to rebuild whole UI again, but rather for example it can just attach event handlers to appropriate DOM nodes for that existing HTML (in case of React). It still has to run some code to actually do all that, but it doesn't need to rebuild the whole UI from scratch because it already exists, so hydration is less work compared to rendering full from scratch.
What Charles M. said in his comment above is not hydration, but rather code splitting. This can be used for delayed hydration so that you only hydrate certain parts of UI when they become relevant. I think Astro does this a lot and you can tell it to only hydrate (load and run JS) for a certain part of the UI when you scroll to it for example.
I guess in context of Redux it might be sending Redux store with existing data from server to browser and then just reuse that state on client. I'm not sure, haven't used Redux for a very long time.
@@rand0mtv660 thanks for the responses
@@rand0mtv660 That's partially true. Hydration's goal is to offer the possibility of modifying a view client side that was server rendered.
In a meta-framework, the server generates the HTML, ships it to the client and the client side takes over, hydrating the page content upon state changes.
Those event handlers you talked about aren't explaining what hydration is, they're explaining one implementation of it.
@@charlesm.2604 Yeah that's why I mentioned for example it can attach event handlers. I was mostly referring to React implementation since I'm most familiar with that one. The point I tried to make is that hydration doesn't have anything to do with many smaller JS bundles (code splitting) and you can have hydration with a single monolithic JS bundle that isn't code split at all. They are two different things that don't have to be used together at all.
Dude, U should try Deepsignals, the upgraded version of Signals.
Hello,
can you help us with more Fine-Grained and deep discussion for signal.
I can see quick and solid js, is more Fine-Grained Reactivity, less expensive and give fast performance.
Why not angular so much
There is a typo - Coutn
Who works on React that they have not had "signals" till now?
angular dev here, waiting for signals :)
So it's like a useRef but it triggers a re-render of where it's used? Interesting
There’s no doubt that things are more performant but I don’t believe that the framework makes or breaks an app. With the sheer volume of react apps in production it’s clear to me that any performance gains from frameworks like solid likely won’t matter at the end of the day unless my use case is in the critical path of what solid is great for.
I Agree, It's impressive to see these new frameworks. But for me react is good enough.
Angular is implementing this in it's next release v16
Shouldnt count be a function in solid.js? "Count is {count()}"
Yes
Technically it can be {count} (only in the DOM, when used directly in JS like `const double = count() * 2` you need the parens. But I think it's more idiomatic to use {count()}
Oh cool, I didn't know that. Your videos are absolute golden. Thank you for the effort, its most appreciated 👍👍
This will be also part of Angular
You forgot to call count as a getter . . typeof count is Accessor. To access the value you need to call it:
setCount(count() + 1)}>
Count is {count()}
🔥🔥🔥
Can we get a PAID frontend Reactjs course from you where you only teach about performance related stuffs? It will blow up the internet for sure.
He's working on Qwik, not React.
Hope react will take this as a signal 😂 to support this natively. Valtio is the close but not quite to supporting this type of behaviour but it really would be nice to be built in.
react would have to fundamentally change as a framework for that to happen which is very very unlikely
The more mature qwik get, the more interested I become.
It is so similar to what Vue does :D
For the interval example you can do the same in React by passing a function to setstate.
Who the hell updates state in react by accessing state variable directly😭😭😭😭😭😭
Solid is what React should have been. I am worried that our app will start to be doggy.
The signal is basically like refs? I guess?
If you every create a course on React, i will be the first one to jump inm
I'm not aboard the 'signal' train. I can see the benefit if you're new to React or don't have much experience or a good understanding of the fundamentals. I feel like it's just syntactical sugar for useState with useContext or something along those lines. I'd rather just implement that myself so half my team doesn't have to study some 3rd party library.
For this example, wouldn't simply returning a function to setCount solve this problem i.e. setCount( count => count + 1)? Either way, you shouldn't ever be setting a useState variable directly in it's setter. Always wrap it in a function and pass is the old state variable as a param as shown above.
hmmm similir with svelte
hello jQuery
When you fix a leaky abstraction you remove the bugs and nuance that it introduced ... and React hooks are very leaky.
React is really outdated at this point.
This is why I use mobx instead
Coutn
Jargon Thrashing is Lame
useSignal? lol
what is hydrate
these frameworks are each time worse than before, it's such a mess, fixing issues that are wrong by design
What's the right design? Wrong implies the existence of right
@@hunterwilhelm Let's gooo, please ratio the OP