Thanks for the video. I think this is a pretty fair first impression for someone coming from the perspective of "Here is something like React is it worth it?" and hasn't had chance to actually sit with it. I think it also is a reasonable response to the React vs Solid narrative that has been floating around. It isn't one we've ever tried to suggest. A lot of the similarities to React come from admiration of APIs and perspective on the problem space and not any sort of desire to provide the same experience. Solid's reactive approach well predates Hooks (by a lot when you consider Knockout, MobX) so the argument of which way the bicycle wheel is facing is a bit up to debate. To reverse it, if you are proficient riding backward then continue to but there are reasons this set of tradeoffs are beneficial. It is this simplification that makes the bigger difference for something like Svelte than any of the syntax stuff that gets people excited. It isn't like React is ever going to go down this path as the execution model is completely different. So dismissal as a React clone is generally unwarranted but we've made that easy to do. I see no technical need to push or hype superficial differences to carve out new space. But I also understand how people like to make those associations because they reflect on themselves and so I understand this psychology hurts adoption. But ease of adoption has never been a priority of the core design here (built on proxies before mainstream support, no React compat). I'm just a pragmatic optimist. You keep doing the best possible things and putting yourself out there and good things will happen. That's the only way to stay on a project like this for 5 years as I have.
Hey Ryan, thank you so much for the fair and evenly considered reply. I do think it's unfortunate that comparisons arise, even when they're not prompted - it's a sad state of human behavior. Even if you had gone with some lisp derivative to describe the UI tree I think comparisons to React would have still occurred as it remains in the web UI space, which React is impossible to ignore. As the old saying goes, no press is the only form of bad press. To that end if you're comfortable and desirous of chatting more I would love to have you on this channel to delve deeper into some of the points I raised, and some of the ones I didn't. Really just to answer the question, "Why SolidJS Deserves Your Attention" Happy to coordinate via Twitter DMs if you'd like - hswolff is my handle.
We prefer SolidJS having used React for previous projects (class based and functional React), on our small team. Speed and lightweight are important for us - and while React would probably get the job done just fine, SolidJS ticks all the right boxes. You're doing a pretty good job marketing it yourself, Ryan - the documentation came along at just the right time for us and although it wasn't immediately obvious how the reactivity works (until I discovered the JS proxy object), once you get your head around what's actually happening, it all 'clicks'. Needing to understand what's happening (and therefore why you can't destructor the props in the parameter list or why you have to specify functions rather than a value in some places) is a small price to pay for the speed and size benefits, but I suspect it is a price large enough to potentially delay that avalanche of new users... That's partly because when people are coming from React, they have expectations about how things "should" work, due to the similarity. No fault of the library though. Different things are different.
you're doing a great job Ryan I love the fact that solidjs preserve your javascript knowledge which react doesn't, I also like that the components renders only once which makes a lot of sense to me, thanks again and keep up the good work.
I'm making the leap from React to Solid, as an observation the Solid component is a constructor compared to the React functional component being a renderer. There are ways to flip a mental perspective. I'm also relieved to see how Solid treats data, fetched data, etc more as a beloved family member than a dirty detail for the backend guys to figure out (haha). Would like to see routing get more attention, as it's critical for the layout of large projects and worth being opinionated.
I appreciate hearing your first impressions. But once you try and build something with SolidJS you quickly adapt to how they do things. With React there is much more cognitive overload in terms of manually tracking dependencies, and trying to keep re-renders to a minimum. Where with SolidJS that entire class of problems doesn't exist.
I think the overarching thing Harry was saying is that, almost all of the time, when coding in React, you _don't_ have to worry about keeping re-renders to a minimum because doing so only saves a few milliseconds and users never notice.
I think even this guy understands that if they came out at the same time, he'd favor Solid. He favors react because that's where is experience is and doesn't have a whole lot of reasons beyond that. I personally have never used Solid and I've been using React since 2018. But this vid kinda convinces me that Solid is better and I'll prob use it for my next app.
I think you answered badly to the question you raised in 13:04: "Is Solid worth your time, when you already have something you're used to". Yes, it's, even if you're certain that Solid isn't better. Since it urges you to learn a new way of thinking, rather that just sticking to your comfort zone. This helps you become an adaptable programmer. For a direct measure of benefit to prove my point: If you already know React, and you took the time to learn Solid, then you are also a Vue programmer. Since Vue 3 through the composition API has considerable similarities to Solid (every component renders only once, you can't destructure props). And I think Vue is mainstream enough to worth anyone's time, isn't? 😀
I just started the video and being at 2:05, the argument of "Is that worth the trade-off to the {phmbountains?} and years of community and history that exists with ReactJS?" kinda sounds like "Eh, we dont need no C#, F, JS and alike, there is COBOL!" From my short and limited view it clearly seems to be a far better designed framework to get the work done quick and efficiently. But the design and writing of your code as well as the execution of it on all the end users out there. Now dont get me wrong, I am fairly new to full stack and thus front-end myself. I dont have years of experience in that field, but learning React with withs Flux pattern, paired with Redux with its actions and reducers running to get states propagated through your app ... it just feels more painful than it should be. Leaving the perspective of a seasoned front end dev, even the real of coding itself, the performance and thus lower resource costs are a gobal economic point in my book too. As for the performance, I personally do care a lot about the performance and response of a website. Sure we all dont care if a website that "responds perfectly" maybe runs just half a fast as it could be, if it already runs fast enough for our subjective perception. But once it starts stuttering and performance tanks, then we notice, and that happens quite often for several pages on different systems like older phones or laptops. Essentially, we expect our websites to respond in real time. So long that happens, we subjectively dont care, but we do once that requirement is no longer fulfilled. Also I assume that with the ongoing trend of moving more and more into "webifying applications", with more and more dynamics and interactivity, performance will become a bigger key. So why not settle for a newer and better framework? If the only reason is "because we are so used to something worse and rethinking is hard", then a new generation of devs will make you obsolete on the long run as the tech itself gets faded out. (That is of course overdramatic, as we still got COBOL and Java 1.8 everywhere) But thanks for your opinion and I of course respect this view, as it is "very human" *beep boop*. Many people reject new things because "it is different" and thus it is a reality any new technology has to go through. BUT I totally agree on the mint topic in general. Keep that mint outta my life! Diz aint no taste I shouda endure! O_)O Thanks for the kinda quirky, enjoyable video.
I'm not here to change minds, but I'm wondering what are the tips for a new framework which is clearly more performant and as close to existing popular framework can survive and thrive?
I can't see why wrapping your reactive data inside a memo rather than having it at the top level of your function is a "tradeoff". A babel plugin for that could even be written
I just started using solidJS and one thing I would add is that their discord community is a great resources if you get stuck. Even though there isn't years of community posts floating around Google, you can definitely get the help you need from their discord community.
"Do you need things that much faster?" - I believe we tend to argue from a status quo much too often. React may well be fast enough for almost all applications, thus the performance advantage of Solid over React might practically not really be an issue. At the same time we are using a whole plethora of tools that transform our source code, split code, shake trees, rebundle code with every month seeing breaking changes in tool chains, all to squeeze out the last little bit of performance so that we developers can continue to produce sloppy code, while we need to become tool-chain wizards just to keep our applications up to date. If Solid succeeds in achieving a performance that is nearly as good as vanilla JS and at the same time the price to pay are some quirks, then it seems to be a far superior technology to rely on than React. The fact that Solid introduces unintuitive quirks shows that it is not perfect, but neither is React. React requires a virtual DOM, which is an abstraction layer on top of the DOM which in itself is a highly optimised but flawed construct. We went a long way from Internet Explorer to modern browser, a way meandering around rivers of sweat and hormones. The purpose of the virtual DOM is to improve performance while allowing React to be easy to use. The first part of that became obsolete. If we are willing to go through all the pain of configuring tsconfig, eslint, jest, webconfig, babel, XcssX, nx, and all the rest of the stuff and then engage in mortal combat with CRA, all to have a blazingly fast and efficient tool chain and then product, how demanding is it to learn to be aware of these quirks introduced by Solid to make the product twice as fast and 80% smaller?
for me the idea that i can use signals out of components and components render only once is very good also not being able to destructor is actually better, sometimes when you destructor you loose track of which object owns those properties and voila, in term of code solid is so much better and you write less code in my opinion, am hoping to see routing out of the box and with that you won't need npm install xD after installing solid.
good chance that there will never be routing out of the box, because there may be different routing packages out there that use better machanisms or DX. However, to ease your mind, solid-app-router is officially maintained by solid maintainers and that's what's currently the most popular in solidjs community. It's also used internally by solid-start, a metaframework (think solidjs version of NextJS).
That 'destruct parameter is not working' is the same problem as MobX, also, the createSignal can be implemented in React like useSignal? The built in reactivity is really cool though!
Trying to combat React's component rerenders is a major drawback, especially with projects that have multiple developers. However, with solidjs this isn't a problem.
To be fair you did say you were bias to begin with. I think as web developers we are spoiled, having the browser do all the optimization for us. I do not think React is really that amazing, its different and cool, but really it is slow and laggy, especially when you are pulling a lot of animations off, or at least trying to. But I am not bashing on react. It does have a community behind it, especially when looking for things like testing and how-to's. But when I am dealing with Solid I find myself makind choices about my state as a first class citizen, and the component second. Where as with react it was not always the same. Patterns like pub-sub and Observer are meant to decentrailize mutations to state, keep them small and localized, react does not think so. Excellent video, I think you were fair. But I will be sticking with Solidjs.
People are complaining about ageism in tech, but this is the exact same reasoning people are still booting up new projects with Java when DART is close on benchmarks while using 3x less memory and Go being 10 times faster and you don't have to manage your memory. Some of the points you brought up were null and void like "oh im going to have to relearn stuff again", but this is why people get into stem - they want to learn and try new shit. Learning new shit is fun and exciting and I haven't been this excited in a long time. Svelte didn't excite me as much as this because it still has some overhead, but Solid does not. Yes React is tried and true, but it has huge mental overhead, both to the person coding it and to the CPU that's diffing everything. 90% of problems that you think about in React simply dont exist here because it's a buff state library that spits out dom elements. If solid gets traction and community it's basically going to be the new standard. The performance difference is just too insane to overlook. Imagine not thinking about dependencies and rerenders and whatnot, well you dont have to.
"are still booting up new projects with Java when DART is close on benchmarks while using 3x less memory and Go being 10 times faster" I don't know were this hot take is coming from, but Java is actually faster than Go and far faster than Dart (albeit using a far bigger heap). The JVM also has by far the highest quality ecosystem of libraries... and is not even remotely close, Go and specially Dart are _literal_ decades behind in that respect.
And aslo Kevin Ghadyani's two streams because they better than other streams in terms of talking how the SolidJS works from inside. Which the creator of the SolidJS tells all of that
@@sergenorin Kevin's videos are amazing! I just watched them yesterday. Are there any learnings from those videos which are not documented and can be moved to documentation/tutorials/resources which are easy to discover?
I think you didn't find the development or technical sweetness of SolidJS. It may be because you love to react or hate to learn new reactive things. Or maybe a lack of deep technical understanding of why react is still complicated when it comes to handling complex states. The concept of Virtual DOM developer doesn't like even those who are working with ReactJS for 5 years. Rather than saying SolidJS is better than reactJS, I am happier to say that SolidJS will better developer experience.
Working at american airlines soild over react all day. React is big problem in big enterprise applications due to performace due to component rendering. Soid way of thinking about is perferct and we can predict how components will behave if you expect the componet to always re-render that's a lazy approach and why React isn't popular in enterprise appications.
Hey man, love these review video's! Before this video I had never heard of SolidJS. It seems a very nice alternative of react and surtenly has it's advantages over it in some projects. Deffo will try it out. That said, coming from React myself I doubt that I'll use Solid over React if I have the choice. React is what I am used to and it is still a modern technology.
I don't think its only about speed with SolidJS, In most ways its better designed then reactJS. It learned from React and handles most of the react gotchas without us doing anything. Here is a great comparison of this two library by Jack Herrington ruclips.net/video/ZR7tdZ51MQ8/видео.html
I like this dude, seems like an awesome person to enjoy a beer with! Thanks bud! Keep up the inspiring stuff! (Reminds me of a very cool Seth Rogan that's super smart) (you should hire me then we can grab a beer and talk code for days)
Give up reacts ecosystem. Be able to use literally every web component in a natural way without a ton of adapters… you can literally use jquery with solid.
solidjs forcing functional paradigm. Again. Doesn't allow the actual developer what to use. Also it seems like it sacrificed convenience for reactivity. In short: another hyped trash.
that's a great video idea? "What will kill React?" Thanks! Clickbait ftw? I think my answer in that proposed video will probably just be...."who knows?" and also...it probably won't look like react, cuz it's very hard to kill something with more of the same. React didn't look like Angular, right?
Yeah, I agree. Solidjs is ridiculous and barely useful in building spa. Terrible that the child components don’t even refresh when passing the signal through. Big thumbs up to you❤
![[Special Clip] ATEEZ(에이티즈) 홍중 'Why Do You Love'](http://i.ytimg.com/vi/I6XYXQKN_pY/mqdefault.jpg)
![Tee Grizzley - Detroit (Feat. 42 Dugg) [Official Video]](http://i.ytimg.com/vi/aeKfTtt0x14/mqdefault.jpg)
Thanks for the video. I think this is a pretty fair first impression for someone coming from the perspective of "Here is something like React is it worth it?" and hasn't had chance to actually sit with it. I think it also is a reasonable response to the React vs Solid narrative that has been floating around. It isn't one we've ever tried to suggest. A lot of the similarities to React come from admiration of APIs and perspective on the problem space and not any sort of desire to provide the same experience. Solid's reactive approach well predates Hooks (by a lot when you consider Knockout, MobX) so the argument of which way the bicycle wheel is facing is a bit up to debate. To reverse it, if you are proficient riding backward then continue to but there are reasons this set of tradeoffs are beneficial.
It is this simplification that makes the bigger difference for something like Svelte than any of the syntax stuff that gets people excited. It isn't like React is ever going to go down this path as the execution model is completely different. So dismissal as a React clone is generally unwarranted but we've made that easy to do. I see no technical need to push or hype superficial differences to carve out new space. But I also understand how people like to make those associations because they reflect on themselves and so I understand this psychology hurts adoption. But ease of adoption has never been a priority of the core design here (built on proxies before mainstream support, no React compat). I'm just a pragmatic optimist. You keep doing the best possible things and putting yourself out there and good things will happen. That's the only way to stay on a project like this for 5 years as I have.
Hey Ryan, thank you so much for the fair and evenly considered reply.
I do think it's unfortunate that comparisons arise, even when they're not prompted - it's a sad state of human behavior. Even if you had gone with some lisp derivative to describe the UI tree I think comparisons to React would have still occurred as it remains in the web UI space, which React is impossible to ignore.
As the old saying goes, no press is the only form of bad press. To that end if you're comfortable and desirous of chatting more I would love to have you on this channel to delve deeper into some of the points I raised, and some of the ones I didn't. Really just to answer the question, "Why SolidJS Deserves Your Attention"
Happy to coordinate via Twitter DMs if you'd like - hswolff is my handle.
We prefer SolidJS having used React for previous projects (class based and functional React), on our small team. Speed and lightweight are important for us - and while React would probably get the job done just fine, SolidJS ticks all the right boxes. You're doing a pretty good job marketing it yourself, Ryan - the documentation came along at just the right time for us and although it wasn't immediately obvious how the reactivity works (until I discovered the JS proxy object), once you get your head around what's actually happening, it all 'clicks'. Needing to understand what's happening (and therefore why you can't destructor the props in the parameter list or why you have to specify functions rather than a value in some places) is a small price to pay for the speed and size benefits, but I suspect it is a price large enough to potentially delay that avalanche of new users... That's partly because when people are coming from React, they have expectations about how things "should" work, due to the similarity. No fault of the library though. Different things are different.
you're doing a great job Ryan I love the fact that solidjs preserve your javascript knowledge which react doesn't, I also like that the components renders only once which makes a lot of sense to me, thanks again and keep up the good work.
I'm making the leap from React to Solid, as an observation the Solid component is a constructor compared to the React functional component being a renderer. There are ways to flip a mental perspective. I'm also relieved to see how Solid treats data, fetched data, etc more as a beloved family member than a dirty detail for the backend guys to figure out (haha). Would like to see routing get more attention, as it's critical for the layout of large projects and worth being opinionated.
I appreciate hearing your first impressions. But once you try and build something with SolidJS you quickly adapt to how they do things. With React there is much more cognitive overload in terms of manually tracking dependencies, and trying to keep re-renders to a minimum. Where with SolidJS that entire class of problems doesn't exist.
I agree! I def think if I tried it I'd get a more nuanced take.
I think the overarching thing Harry was saying is that, almost all of the time, when coding in React, you _don't_ have to worry about keeping re-renders to a minimum because doing so only saves a few milliseconds and users never notice.
The title should add "(from a ReactJS fanboy)"
I think even this guy understands that if they came out at the same time, he'd favor Solid. He favors react because that's where is experience is and doesn't have a whole lot of reasons beyond that. I personally have never used Solid and I've been using React since 2018. But this vid kinda convinces me that Solid is better and I'll prob use it for my next app.
I think you answered badly to the question you raised in 13:04: "Is Solid worth your time, when you already have something you're used to".
Yes, it's, even if you're certain that Solid isn't better. Since it urges you to learn a new way of thinking, rather that just sticking to your comfort zone. This helps you become an adaptable programmer.
For a direct measure of benefit to prove my point: If you already know React, and you took the time to learn Solid, then you are also a Vue programmer. Since Vue 3 through the composition API has considerable similarities to Solid (every component renders only once, you can't destructure props). And I think Vue is mainstream enough to worth anyone's time, isn't? 😀
I just started the video and being at 2:05, the argument of "Is that worth the trade-off to the {phmbountains?} and years of community and history that exists with ReactJS?" kinda sounds like "Eh, we dont need no C#, F, JS and alike, there is COBOL!"
From my short and limited view it clearly seems to be a far better designed framework to get the work done quick and efficiently. But the design and writing of your code as well as the execution of it on all the end users out there.
Now dont get me wrong, I am fairly new to full stack and thus front-end myself. I dont have years of experience in that field, but learning React with withs Flux pattern, paired with Redux with its actions and reducers running to get states propagated through your app ... it just feels more painful than it should be.
Leaving the perspective of a seasoned front end dev, even the real of coding itself, the performance and thus lower resource costs are a gobal economic point in my book too.
As for the performance, I personally do care a lot about the performance and response of a website. Sure we all dont care if a website that "responds perfectly" maybe runs just half a fast as it could be, if it already runs fast enough for our subjective perception. But once it starts stuttering and performance tanks, then we notice, and that happens quite often for several pages on different systems like older phones or laptops.
Essentially, we expect our websites to respond in real time. So long that happens, we subjectively dont care, but we do once that requirement is no longer fulfilled.
Also I assume that with the ongoing trend of moving more and more into "webifying applications", with more and more dynamics and interactivity, performance will become a bigger key.
So why not settle for a newer and better framework? If the only reason is "because we are so used to something worse and rethinking is hard", then a new generation of devs will make you obsolete on the long run as the tech itself gets faded out.
(That is of course overdramatic, as we still got COBOL and Java 1.8 everywhere)
But thanks for your opinion and I of course respect this view, as it is "very human" *beep boop*.
Many people reject new things because "it is different" and thus it is a reality any new technology has to go through.
BUT I totally agree on the mint topic in general. Keep that mint outta my life! Diz aint no taste I shouda endure! O_)O
Thanks for the kinda quirky, enjoyable video.
I'm not here to change minds, but I'm wondering what are the tips for a new framework which is clearly more performant and as close to existing popular framework can survive and thrive?
I can't see why wrapping your reactive data inside a memo rather than having it at the top level of your function is a "tradeoff". A babel plugin for that could even be written
I just started using solidJS and one thing I would add is that their discord community is a great resources if you get stuck. Even though there isn't years of community posts floating around Google, you can definitely get the help you need from their discord community.
the joy of your antics is itself a reason to watch your videos....love your content man!
If it ain't fun to watch then how will people watch it? Maybe if I pay them 🤔
"Do you need things that much faster?" - I believe we tend to argue from a status quo much too often. React may well be fast enough for almost all applications, thus the performance advantage of Solid over React might practically not really be an issue. At the same time we are using a whole plethora of tools that transform our source code, split code, shake trees, rebundle code with every month seeing breaking changes in tool chains, all to squeeze out the last little bit of performance so that we developers can continue to produce sloppy code, while we need to become tool-chain wizards just to keep our applications up to date.
If Solid succeeds in achieving a performance that is nearly as good as vanilla JS and at the same time the price to pay are some quirks, then it seems to be a far superior technology to rely on than React. The fact that Solid introduces unintuitive quirks shows that it is not perfect, but neither is React. React requires a virtual DOM, which is an abstraction layer on top of the DOM which in itself is a highly optimised but flawed construct. We went a long way from Internet Explorer to modern browser, a way meandering around rivers of sweat and hormones. The purpose of the virtual DOM is to improve performance while allowing React to be easy to use. The first part of that became obsolete.
If we are willing to go through all the pain of configuring tsconfig, eslint, jest, webconfig, babel, XcssX, nx, and all the rest of the stuff and then engage in mortal combat with CRA, all to have a blazingly fast and efficient tool chain and then product, how demanding is it to learn to be aware of these quirks introduced by Solid to make the product twice as fast and 80% smaller?
10:22 doesn’t that just force us to start more like how we would end up if we refactored the react style?
for me the idea that i can use signals out of components and components render only once is very good also not being able to destructor is actually better, sometimes when you destructor you loose track of which object owns those properties and voila, in term of code solid is so much better and you write less code in my opinion, am hoping to see routing out of the box and with that you won't need npm install xD after installing solid.
good chance that there will never be routing out of the box, because there may be different routing packages out there that use better machanisms or DX. However, to ease your mind, solid-app-router is officially maintained by solid maintainers and that's what's currently the most popular in solidjs community. It's also used internally by solid-start, a metaframework (think solidjs version of NextJS).
I like your mellow style and medium pace of teaching, it gets in my old head much more easily.
glad to hear!
That 'destruct parameter is not working' is the same problem as MobX, also, the createSignal can be implemented in React like useSignal? The built in reactivity is really cool though!
Trying to combat React's component rerenders is a major drawback, especially with projects that have multiple developers. However, with solidjs this isn't a problem.
To be fair you did say you were bias to begin with. I think as web developers we are spoiled, having the browser do all the optimization for us. I do not think React is really that amazing, its different and cool, but really it is slow and laggy, especially when you are pulling a lot of animations off, or at least trying to. But I am not bashing on react. It does have a community behind it, especially when looking for things like testing and how-to's. But when I am dealing with Solid I find myself makind choices about my state as a first class citizen, and the component second. Where as with react it was not always the same. Patterns like pub-sub and Observer are meant to decentrailize mutations to state, keep them small and localized, react does not think so. Excellent video, I think you were fair. But I will be sticking with Solidjs.
People are complaining about ageism in tech, but this is the exact same reasoning people are still booting up new projects with Java when DART is close on benchmarks while using 3x less memory and Go being 10 times faster and you don't have to manage your memory. Some of the points you brought up were null and void like "oh im going to have to relearn stuff again", but this is why people get into stem - they want to learn and try new shit. Learning new shit is fun and exciting and I haven't been this excited in a long time. Svelte didn't excite me as much as this because it still has some overhead, but Solid does not.
Yes React is tried and true, but it has huge mental overhead, both to the person coding it and to the CPU that's diffing everything. 90% of problems that you think about in React simply dont exist here because it's a buff state library that spits out dom elements. If solid gets traction and community it's basically going to be the new standard. The performance difference is just too insane to overlook. Imagine not thinking about dependencies and rerenders and whatnot, well you dont have to.
"are still booting up new projects with Java when DART is close on benchmarks while using 3x less memory and Go being 10 times faster"
I don't know were this hot take is coming from, but Java is actually faster than Go and far faster than Dart (albeit using a far bigger heap).
The JVM also has by far the highest quality ecosystem of libraries... and is not even remotely close, Go and specially Dart are _literal_ decades behind in that respect.
Have you watched streams about Solidjs like Kevin Ghadyani's stream about SolidJS or did you just read the documentation?
Read documentation
I really recommend you take a look at
Kendo UI - React Wednesdays: Let's Learn Solid JS
It has some demo projects which other videos dont have
And aslo Kevin Ghadyani's two streams because they better than other streams in terms of talking how the SolidJS works from inside.
Which the creator of the SolidJS tells all of that
@@sergenorin Kevin's videos are amazing! I just watched them yesterday.
Are there any learnings from those videos which are not documented and can be moved to documentation/tutorials/resources which are easy to discover?
can you check more svelte js and compare with react to know if is svelte is better or not, thank u bro
Literally he can't. Because he is from React background. And his excuse is "community"
@@Shahriar.CSE40 i don t think so because he has already old videos to test sveltejs + interview with creator svelte
@@Shahriar.CSE40 Correct. I'm incapable of growing. /s
I think you didn't find the development or technical sweetness of SolidJS. It may be because you love to react or hate to learn new reactive things. Or maybe a lack of deep technical understanding of why react is still complicated when it comes to handling complex states. The concept of Virtual DOM developer doesn't like even those who are working with ReactJS for 5 years. Rather than saying SolidJS is better than reactJS, I am happier to say that SolidJS will better developer experience.
Working at american airlines soild over react all day. React is big problem in big enterprise applications due to performace due to component rendering. Soid way of thinking about is perferct and we can predict how components will behave if you expect the componet to always re-render that's a lazy approach and why React isn't popular in enterprise appications.
Hey man, love these review video's!
Before this video I had never heard of SolidJS. It seems a very nice alternative of react and surtenly has it's advantages over it in some projects. Deffo will try it out.
That said, coming from React myself I doubt that I'll use Solid over React if I have the choice. React is what I am used to and it is still a modern technology.
I don't think its only about speed with SolidJS, In most ways its better designed then reactJS. It learned from React and handles most of the react gotchas without us doing anything. Here is a great comparison of this two library by Jack Herrington ruclips.net/video/ZR7tdZ51MQ8/видео.html
Good developers are mathematicians.
0:23 🤭🤭Harry always make me laugh
💪
Can't you just solve all these new things with linting rules? Then you don't have to remember everything
First in! Thanks for your opinion.
Very welcome!!
(0:36 to 0:42), That smile😂😂😂
minute 3:33 ! yes people do, everybody does, this is now scientifically proven, look it up, I'm sure you know how to...
I like this dude, seems like an awesome person to enjoy a beer with! Thanks bud! Keep up the inspiring stuff! (Reminds me of a very cool Seth Rogan that's super smart) (you should hire me then we can grab a beer and talk code for days)
I hope my laugh is less painful than Seth Rogan's!
Give up reacts ecosystem. Be able to use literally every web component in a natural way without a ton of adapters… you can literally use jquery with solid.
bruh you sound like snape from harry potter
Mint chocolate on pineapple pizza
you devious mind
solidjs forcing functional paradigm. Again. Doesn't allow the actual developer what to use.
Also it seems like it sacrificed convenience for reactivity. In short: another hyped trash.
Every week we hear that who will be the react killer? I am tired of it
that's a great video idea? "What will kill React?" Thanks! Clickbait ftw?
I think my answer in that proposed video will probably just be...."who knows?" and also...it probably won't look like react, cuz it's very hard to kill something with more of the same. React didn't look like Angular, right?
Boy, RUclips devs really just BS for 15 minutes these days.
Get a decent microphone!
It’s more like, get decent room acoustics.
@@hswolff Or... get a decent dynamic microphone to get rid of the ambient room noise.
*yawn*
Go on!
@@hswolff lol just so tired of all these frameworks
There’s more than all the sand in all the deserts!
Yeah, I agree. Solidjs is ridiculous and barely useful in building spa. Terrible that the child components don’t even refresh when passing the signal through. Big thumbs up to you❤
I use createSignal() to create store outside of components and get/set it from anywhere/components : Global reactive store! 😎 Svelte