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
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!
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.
@@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.
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?
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.
@@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
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.
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.
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.
@@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.
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.
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.
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
I love the content you put out Steve. So concise and well presented. Keep up the awesome work 🙌🏻
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
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!
Love this content format. Simple, concise, and more importantly, it provides bite-sized information for viewers.
Clear & simple explanation!
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.
Man u are the G.O.A.T. u made this topic so easy to digest. Keep up the firee content man!!!!!
Very clear explanation, thank you
Keep up the great content!
I hope you continue on liking what you do and provide us more good contents like this. Thank you so much. :)
Svelte does it out of the box
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
Hey Steve, nice video!
What tool and method did you use to generate your subtitles? They look great!
What do you mean by more code to download? Whole React gets shipped in case of SSR anyway
Straight talk: Its RxJs with training wheels. Of course its simpler, its solving a much easier problem.
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!
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.
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
How does it perform when dealing with arrays that are rendered?
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.
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
Like RH says, "As enginers, we should be offended". Checkout Svelte instead.
It is something that we can now use with ReactJS + Vite properly?
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
🔥🔥🔥
angular dev here, waiting for signals :)
I miss RXJS
Ah yes, we going full circle aren't we I remember "laser beam the value directly into dom" at 2001!
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
Can RemixJs use signals?
Soon Angular? What are they doing?
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()}
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.
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
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"
Dude, U should try Deepsignals, the upgraded version of Signals.
There is a typo - Coutn
Angular is implementing this in it's next release v16
Who works on React that they have not had "signals" till now?
svelte is the best
So it's like a useRef but it triggers a re-render of where it's used? Interesting
This will be also part of Angular
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.
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 👍👍
It is so similar to what Vue does :D
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
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.
The more mature qwik get, the more interested I become.
If you every create a course on React, i will be the first one to jump inm
For the interval example you can do the same in React by passing a function to setstate.
hmmm similir with svelte
hello jQuery
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?
When you fix a leaky abstraction you remove the bugs and nuance that it introduced ... and React hooks are very leaky.
This is why I use mobx instead
Coutn
React is really outdated at this point.
useSignal? lol
Jargon Thrashing is Lame
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