A lot of of people don't understand the benefits of asynchronous reactivity, but it's literally the same selling point as synchronous reactivity. The only difference is the learning curve. It's not harder to do. There's just more to learn. IMO it's worth it.
Saw your video. combineLastest is annoying. It's impossible to group form properties by form name without doing a bunch of redundant calculations when some props rely on form.valueChanges and some do not. Rxjs simply does not allow people to write clean code in some cases
Ryan could you give a presentation in which you do not mention any other Web framework (React, Svelte, Prereact, Vue, ...) and just talk on your Design Philosophy, your assumptions why you have choosen the your basic syntax construct (createSignal, createResource). Every mayor Web Framework has a profound Design Philosophy and works with assumptions. All your thoughts should be your words with no reference to another framework! Still appreciate your effort on finding a new way!
I have never written a line of code with solidjs but recently started watching your content like mad man!)) I am really confused though, why all these frameworks like react, svelte, and solidjs included allow only using synchronous components, whereas all the useful things in javascript happen asynchronously due to its single main threaded implementation. The only exception as far as I understand is Qwik which allow you to write async components using very similar to solidjs (to the best of my knowledge) reactive primitives like signals.
It's not that they ignore async. There are mechanisms. Things like Suspense. The goal here is consistency. The challenge is JavaScripts mechanisms give us a bit of what you need but don't make those guarantees. And the APIs aren't all suitable. Like pretend you wanted an Async Component.. that used async/await .. the second you hit the await you don't process the rest of that code. It's blocking in a sense. What you probably want to do is show some sort of affordance related to its loading. UIs are a constant thing, not something that freezes in time, we need to indicate the passing of time. The solution generally is to turn the promise into something we can describe synchronously like a Signal(Resources we call them in Solid when the source is a Promise), or if you have a re-render model catch it above in a boundary of some sort. I would say most frameworks now have good patterns around async now. Especially things like Transitions in React or Solid which give us tools to ensure consistency. And I'd challenge anyone that would suggest otherwise. If you'd like to learn more about what I mean on consistency I suggest these 2 articles: dev.to/this-is-learning/why-all-the-suspense-understanding-async-consistency-in-javascript-frameworks-3kdp dev.to/this-is-learning/the-cost-of-consistency-in-ui-frameworks-4agi If you want to understand the difference between how Qwik and Solid use Signals this video you are watching is a good one. Most things I say about Preact apply to Qwik which differs from how Solid works.
@@ryansolid Thank you very much for your detailed reply, and even more for links provided! I indeed to seek to understand these things better, since many topics you are talking about makes my head hurt when thinking about 'em to long (which I enjoy ;) ).
Where has Angular's potential for creativity gone? Is there no RxJs Guy after Rob Wormald has left the team! Is Angular after Misko Hevery Quick left the team now Standalone?
I wish to have a list of what is used for what and when. Which trade-off is optimally used in which situation. And all basic constructions and mechanisms inside JavaScript, with one basic syntax without any framework bloatware for specific purposes full of additional constantly changing plugs for this and that. Make JS modules doing anything in one system. And let me know which to use for which functionality I may in that moment need. This Babilon tower is a confusing place for. newcomer. Bring me Abrahauron and give me one Ring to rule them all.
If anything is clear from this stream is that there are different philosophies and things are still constantly changing. Since there isn't agreement it will be some time before we get good standardization. Unfortunately we've been in this state for like 20+ years so I don't know if this is changing any time soon. Starting to think it is a characteristic of the platform.
It could support them and there are places for it. But most frameworks internally are focused on synchronization and most things in our world are multicast and hot preferably. Andre Staltz is an Rx guy so I will let him explain it better: staltz.com/why-we-actually-built-xstream.html
@@ryansolidI went down the rabbit hole of reactivity using observables. Based on my experiments I concluded that yes hot is better fit for view. You might know I wrote xania from benchmark by krausest which gets it's reactivity from observables. I extracted the internal `state` feature to a separate library and contributed to the benchmark of maverick-js to measure how efficient it solves the diamond problem and it is the fastest. you can check in github pull request #13. I still belief that the UI library should not care about hot or cold. xania proves it is not a matter of performance when u use state library like xania's. On the other hand using signals in solid it is not clear to me how that affects composability in the higher order components, my instict is telling is tricky to get it right with signals becuase signal are not time independent like observables but I admit I am not certain about my thoughts on that. I also want it to ask what makes solid not able to adapt a state library like xania's as first class citizen?
A lot of of people don't understand the benefits of asynchronous reactivity, but it's literally the same selling point as synchronous reactivity. The only difference is the learning curve. It's not harder to do. There's just more to learn. IMO it's worth it.
Saw your video. combineLastest is annoying. It's impossible to group form properties by form name without doing a bunch of redundant calculations when some props rely on form.valueChanges and some do not. Rxjs simply does not allow people to write clean code in some cases
The best explanation for what SolidJs does is Ryan's:"...you can have ten different expressions in your template and each can update independently.."
Ryan could you give a presentation in which you do not mention any other Web framework (React, Svelte, Prereact, Vue, ...) and
just talk on your Design Philosophy, your assumptions why you have choosen the your basic syntax construct (createSignal, createResource).
Every mayor Web Framework has a profound Design Philosophy and works with assumptions.
All your thoughts should be your words with no reference to another framework!
Still appreciate your effort on finding a new way!
Hi Ryan, thanks for the content you make, it's masterpiece 👌. Hope to see more similar streams
I have never written a line of code with solidjs but recently started watching your content like mad man!))
I am really confused though, why all these frameworks like react, svelte, and solidjs included allow only using synchronous components, whereas all the useful things in javascript happen asynchronously due to its single main threaded implementation.
The only exception as far as I understand is Qwik which allow you to write async components using very similar to solidjs (to the best of my knowledge) reactive primitives like signals.
It's not that they ignore async. There are mechanisms. Things like Suspense. The goal here is consistency. The challenge is JavaScripts mechanisms give us a bit of what you need but don't make those guarantees. And the APIs aren't all suitable. Like pretend you wanted an Async Component.. that used async/await .. the second you hit the await you don't process the rest of that code. It's blocking in a sense. What you probably want to do is show some sort of affordance related to its loading. UIs are a constant thing, not something that freezes in time, we need to indicate the passing of time.
The solution generally is to turn the promise into something we can describe synchronously like a Signal(Resources we call them in Solid when the source is a Promise), or if you have a re-render model catch it above in a boundary of some sort. I would say most frameworks now have good patterns around async now. Especially things like Transitions in React or Solid which give us tools to ensure consistency. And I'd challenge anyone that would suggest otherwise.
If you'd like to learn more about what I mean on consistency I suggest these 2 articles:
dev.to/this-is-learning/why-all-the-suspense-understanding-async-consistency-in-javascript-frameworks-3kdp
dev.to/this-is-learning/the-cost-of-consistency-in-ui-frameworks-4agi
If you want to understand the difference between how Qwik and Solid use Signals this video you are watching is a good one. Most things I say about Preact apply to Qwik which differs from how Solid works.
@@ryansolid Thank you very much for your detailed reply, and even more for links provided! I indeed to seek to understand these things better, since many topics you are talking about makes my head hurt when thinking about 'em to long (which I enjoy ;) ).
Are you sure : "Angular upcoming with Signals"?
When you were talking about rxjs & redux, it was a sin not to mention neither ngrx nor ngrx component store)))
Reactivity is a loaded Term - why not just call it "Observable-State"?
Why nested Objects doesn't works fine with Signals and Effects? Unnecessary re-run effect when non changing property. Is there any way to fix this?
Yes proxies with nested reactivity. In Solid we call these Stores, in Vue they call it Reactive, and MobX they call it Observables.
Where has Angular's potential for creativity gone? Is there no RxJs Guy after Rob Wormald has left the team!
Is Angular after Misko Hevery Quick left the team now Standalone?
Angular integration with RxJS will improve when they introduce signals
@@mfpears I am not sure they will introduce signals. It is a too simple strategy which can easily be replaced with RxJs BehaviorSubject!
I wish to have a list of what is used for what and when. Which trade-off is optimally used in which situation.
And all basic constructions and mechanisms inside JavaScript, with one basic syntax without any framework bloatware for specific purposes full of additional constantly changing plugs for this and that. Make JS modules doing anything in one system. And let me know which to use for which functionality I may in that moment need.
This Babilon tower is a confusing place for. newcomer. Bring me Abrahauron and give me one Ring to rule them all.
If anything is clear from this stream is that there are different philosophies and things are still constantly changing. Since there isn't agreement it will be some time before we get good standardization. Unfortunately we've been in this state for like 20+ years so I don't know if this is changing any time soon. Starting to think it is a characteristic of the platform.
I don't understand why a UI library can't support cold observables. because cold is not hot is not really explaining anything.
It could support them and there are places for it. But most frameworks internally are focused on synchronization and most things in our world are multicast and hot preferably.
Andre Staltz is an Rx guy so I will let him explain it better: staltz.com/why-we-actually-built-xstream.html
@@ryansolidI went down the rabbit hole of reactivity using observables. Based on my experiments I concluded that yes hot is better fit for view. You might know I wrote xania from benchmark by krausest which gets it's reactivity from observables. I extracted the internal `state` feature to a separate library and contributed to the benchmark of maverick-js to measure how efficient it solves the diamond problem and it is the fastest. you can check in github pull request #13.
I still belief that the UI library should not care about hot or cold. xania proves it is not a matter of performance when u use state library like xania's.
On the other hand using signals in solid it is not clear to me how that affects composability in the higher order components, my instict is telling is tricky to get it right with signals becuase signal are not time independent like observables but I admit I am not certain about my thoughts on that.
I also want it to ask what makes solid not able to adapt a state library like xania's as first class citizen?