I feel like Svelte (especially now with SvelteKit 1.0) has everything it needs to truly start challenging React and with a bit more adoption we might really see the ball rolling soon.
What about Solid and SolidStart ? I haven't used it but it looks really promising. I feel like React devs would be less afraid of Solid because of the similarity of syntax (JSX), versus Svelte that to me looks more like Vue (my experience with Vue is limited to a few weeks using it, but I'm talking about this separation of markup+special syntax, and JS code).
@@Hexalyse definitely solid is so good. Haven't try it personally yet but watch a lot of Ryan's videos and will be trying it out somewhere mid this year
I recommend the talk "Rethinking Reactivity" by Rich Harris (creator of Svelte). It shows that while, of course, React can get the job done very well, there's just some fundamentals about it that make it slow, and doctoring around on symptoms with things like "concurrent react" is just that: doctoring around. I am really thankful for having had React, it moved everything further in a good way. But from now on, Svelte, baby ;-)
I’ve been pretty critical of the web development community historically because it has a tendency to re-invent their entire stack every startup cycle (18 months to a few years). I think the good thing about React is that it allowed everyone to agree on a set of best practices for writing web apps that has stabilized somewhat, but I also think in order to improve in a way that conservative engineering management will accept it, it’s going to have to happen without forcing everyone to re-learn everything they know just to make a silly push-button-get-data webpage.
Ye solid/ryan is playing the game really smart imo. His streams really helped in gathering a community of tech wizards around solid, people who are interested in building their own frameworks (like leptos or voby) or who like to build libraries, creating an amazing eco-system around solid, especially for as young as it is. And there is this general camaraderie / cross-pollination with the new generation of js-frameworks, thinking mostly solid - astro - qwik (although they market pretty hard) - marko, and with people like tanner, that will be what moves the needle imo. Bling, the collab between solid-tanner-astro ryan/tanner announced last stream, is super exciting and a piece in that big puzzle. The impact of tanner's work on the js eco-system really can not be understated. Moving from react-query/react-router to tanstack really announced that next step in the evolution.
I hope svelte or something very similar to svelte becomes the next big thing. It just feels so natural compared to something like react. Having said that, I am also waiting for the next big thing in web development. There is a lot of new features in new frameworks but at the same time they feel so similar.
I think, React will evolve into a something that combines the best part of each competitor. React team were bold for going to hooks, I don't think they would be that conservative when the time comes.
one of the underrated benefits of React, i learned React and when my company wanted a mobile app i was able to create and deploy the basic mobile app intergrated with our existing API within a month of time, the transition from React to React Native was so smooth. lot of the other frameworks lack this main benefit i guess
I also found THE PERFECT use case for SolidJs, in the mobile world. I'm working right on an ionic mobile app running on capacitor, and since it's running in a webview as a "website" the performance implications are VERY noticeable. The other very game changer would be a solid react-native-renderer, to mitigate the react perf issues on low to mid end devices there as well!
I'm a heavy REact user, love to use Gatsbyjs for my projects, but now, I'm looking more and more into Svelte and Sveltkit, started two projects with it, with VIT under the hood, everything is soo freaking fast, is hard not to use it.
I think the web frameworks on top of the ui libraries make the difference between these tools, and with next 13, react has the best web framework once again since a long time.
8:33 I'm glad you asked :) I'm working on a new React meta-framework that starts out as a CRA replacement (including compatibility with a lot of existing CRA code to ease migration) but it can be used to build interactive apps (I would say to Remix level) with SSG/SSR as well. It's called QGP app.
seriously asking, is it REALLY that frequent a SPAs that so rich in features etc made the performance wise really concerning? I personally looking forward to better frameworks/libs, but honestly, after 2+ years professionally working with react apps, I have NEVER, even once, felt the need of better performance. With react lazy, code-splitting, memo, useMemo, useCallback etc, its just really hard for me to imagine what kind of components are there that so heavy in computation that the need of better performance in SPAs became so dire. I understand the need of meta frameworks such as next, svelte kit, etc. But switching from react to another SPAs framework feel useless for me in terms of performance.
It is not really the raw performance of React (and VDom, diffing, and committing algos) that is the issue here. The issue is the mental model you have to have when working with hooks and the handholding you have to do constantly as a developer. You have to abide by rules of hooks. You have to manually manage _every_ dependency in _every_ dep array in each of `useMemo`, `use Callback`. Why is not `React.memo` the default (internally implemented) memoization mechanism if without it render functions run all the time? It is very easy to regress in performance of a tree of components simply because you missed a dep or forgot a `useCallback` somewhere. `React.memo` by default only does shallow comparison only. If you want anything else you need custom comparators, but they are such a bad idea. By using them you introduce another mental map of props x performance impact that you (and the entire team) have to keep in mind. Any change to the props requires you to change the memo comparator or otherwise you have just either regressed the performance or, worse, broke the component because it no longer re-renders when it should because that new prop is not included in the comparator logic. Then there is state management challenges, using React.Context and ensuring everything is immutable. But I don't even want to go there :D This is what you have to keep in your head at all times, on top of the domain logic and just writing performance (framework-agnostic) algorithms. This problem grows the more the codebase and the team grows (so very hard to out-pace). I have been looking into SolidJS as I think it "fixes" a lot of these problems and provides a much better model of reactivity. Another "solution" might be a state management library that frees you up from worrying about those pesky and ever-present performance consideration (at least in the domain layer). An example would be MobX.
It really depends on personal likings now. Do you want ship less js? how much third party support you need? Do you want to be part of a big eco system, etc
I learned React, but ended up getting my first dev job at a project that uses Vue/Nuxt.js ¯\_(ツ)_/¯ In fact, the guys said they used to use React, but moved over to Vue.
The biggest hurdle in getting the pragmatists away from react is the ecosystem built around it. It just makes you way less productive when you go to another framework and you have a tiny fraction of the off the shelf solutions that you do in react. Its a show stopper.
React in and of itself is just a tool for effectively creating UI. It solves fundamental problem of FE, nothing more. That’s the reason why it is so popular, and won’t die in the nearest future.
It has done the "Java/C++" thing. We've all used it so much and since enterprise don't change as much as startups... well we would continue to use it for 40 years and say it's not dead.
@@DEVDerr ignorant to say "react is bad." You may not like it, but it's the most popular FE framework for a reason. And when it was created it was revolutionary. Comparing it to tools that wouldn't even exist if react hadn't paved the way is just silly
What I'm working on is a method of killing the whole damn framework system. The entire webdev effort has devolved into a collection of Band-Aids slapped over a core wound. And we all just limp along like undead, patchwork mummies because we don't know any better. I believe I've identified that core wound. I believe I have an actual remedy. Before this year is done, we'll see if I'm right. (I am)
Using ”killing react” as a click bait title is totally fine. But to then in the video try to shoehorn it to mean something polar opposite of killing react, that’s just confusing.
So what should a newbie learn today? If the end goal for me is to work with SolidJS, should I learn React first to then learn SolidJS faster and better? Or should I learn NextJS and then SolidJS?
I feel like bootstrapping an app adding UI library + authentication+ state management + other tooling like prettier (or if setting up mono repo then god it takes more than 1-2 days) eats a lot of time. Redwoodjs and couple other frameworks now provide one single command to just add these. So, if new frameworks make adoption easy then its easier to make a switch. In my opinion, I am willing to learn a framework but not willing to leave the ecosystem (third party libs and all).
“Let me know if you want to kill React” I don’t want to kill it but having to take a 48hr course on Udemy just to learn the fundamentals where other libraries can be learnt in a fraction of the time makes me look elsewhere. I started on a little library side project a few months back as I really like web-components and Vue, I probably would have been better off finishing the React course as I could add it to my tool belt but I had more fun and probably learned more rolling my own little library.
Honestly you don't really need to know much React to use it, though it is harder to pick up then other frameworks. I hate React but only because of how much I've used it--really what I hate is JS
@@jacoblockwood4034 Yeah JS/CSS/HTML are the only things that you can take from one of these library's to another but I seemed to have more problems taking them to React than other libs but maybe down to little time with it.
@Theo - t3․gg Am I allowed to post my library? Its not taking on any other lib anytime soon but as a FE dev its more of how I would like a FE library to be.
Well, I'm confused between Next and Solid, cause Solid has better performance but Next is more popular and more likely to get a job with, which one should I pick?
nobody seeing react three fiber and threlte (for svelte) an open GL rendering approach as ultimate frontend goal? I getting so hyped by this, someones ?
I honestly like the idea. Istarted to learn react when webpack was still the onl;y real bundler of choice. Then i migrated to vue because it was just soo much simpler and aesthetic (ofc this is an opinion) I much more like the vue way with .vue files than the react way with javascript/JSX and ofc. vue has its pitfalls... but is more forgiving than react
If you put these frameworks side by side without big companies backing them up and just focus on how they do the job RIGHT ... Svelte will standout in my opinion.
I think that many other frameworks like AstroJS will appear and support React, and people will still use it until there is no other library as popular as React. But when we get to the point where something like SolidJS is well known and supported, React will start to die.
React is the best starting point before making your hands dirty with other frameworks. React gives you a slap of errors & bugs if you're carelessly building projects. Once you get used to the architecture of React JSX/TSX with hooks, IMO, it's a lot easier to switch to any other (similar or different) JS frameworks whether it's Next.js, Remix, Svelte, even Vue.js, etc. Above all, it all depends on the problems you wanna solve and I agree with you that any framework that would solve the problems that React developers face, will definitely get the attention of the community.
He meant, that NEW adoption to php is not high as it used to be. The people who use laravel or TALL stack in particular are most likely companies that have been heavily invested on Laravel. Switching to other tech stack when Laravel in itself is stable already would likely outweigh the benefits of using another framework.
🙏Some 200 IQ beast watching this video rn, says "Challenge Accepted, Theo" and by summer has built something from scratch that perfectly combines the best pieces of all the existing high-profile frameworks/libraries.
Surely, NextJS has gained as much popularity as it has because Vercel want to sell their services and have poured a lot of money into its development and promotion. It’s to attract more devs to their platform and make more money in the long term.
I belief that number of hooks React has to solve issues and introduce new issues at the same time is unnecessary Fmtamentals that made me fell in love with react could be solved by better rendering engine I wouldn’t say I am trying to kill react but I certainly trying to improve on it by building @xania/view although still struggling with documentation obviously and SSR
Solid and Svelte are killers. I just wish there were better ways to learn more about Solid/Solid updates than Ryan's streams. He is a SEEEUUUPER smart/good guy... But, 4-5 hours every other week/month explaining the nuances of a Solid Js feature that we average devs can't make us of today isn't going to make anyone abandon React. Let alone use Solid over Svelte. Learn from Rich Harris, please. Rich shows us how to get something done with his work in 20-40 minutes with time for questions. Ryan shows us how to play with his work... for 4-5 hours (Or shows up to other streams and runs over the time going on tangents) and ends up not getting anything done. Anyway, there needs to be more coverage of Solid because it really is a great framework and deserves more shine.
So you are telling me don't learn react while 80%'s framework are based on react? If new developers learn react first, then adopt to other framework, won't they have better sense about framework? Thought?
Frameworks should adopt the "compiler way". If I use only 4 functions in your framework, I should get only 4 functions in my app. Also why don't we fix JavaScript and the DOM (or encourage developers to properly study the browser) instead of producing another abstraction that we would abandon in 3 months?
Uuuhhh fix JS and the DOM? What? Give me 3-5 things that are actionable this year and give me your estimations on what browsers would implement them. 😂💀
'Frameworks should adopt the "compiler way". If I use only 4 functions in your framework, I should get only 4 functions in my app'. this sentence contains a contradiction: the 'compiler way' is the exact opposite of getting what you have written.
Svelte is still the best DX to date. It makes everything else feel like a downgrade. I love the solid project though. Hopefully Svelte 4 will have signals!
If we are so ready to sacrifice the huge comunity that comes with react, why not move into Yew and use Rust for compiled web asembly components? If its about performance, good luck beating that...
Aren't those slower though because of the extra overhead? And presumably they have larger bundle sizes because of the glue code. I think unless you're using WebGL/WebGPU to render the UI, WASM only really makes sense to use for raw compute stuff or for porting native libraries. Unless maybe a new UI framework comes along that can only work so well because it doesn't use JavaScript, I guess Yew does that to some degree with the extra stability of Rust though
@@hedgehog125 They do use WebGPU, and there is no glue code, hits the same api as JS do. But yeah.... I find it stupid, solves nothing new and gives performance that nobody asked for
@@Fernando-ry5qt Oh yeah, I forgot you can just pass the browser API functions to it. Is glue code mostly just for when you're interfacing with WASM via JavaScript?
Given the current climate. React is "good enough". Unless there is a major paradigm shift (like AI does something revolutionary), I don't see React _ever_ going away... just like I don't see Apple or Microsoft or Google or Amazon or Facebook _ever_ going away.
I love React & was using it (with Next.js of course) for almost 3 years), but from a half a year I init every new side project in other meta/framework, like SvelteKit, Solid.js, Vue (Svelte is my new ♥) etc. just because of curiosity & because I'm a little bored with React so far 😏
I think that there will come a time in which reactive frameworks written in Rust will take over. It's an inevitability that WASM becomes substantially better than what it is today, and there will be this massive performance difference that upends the status quo of things. There's potential for highly optimized SSR; WASM has no interpretation time penalty and will have better time to first render; there's serious cross-platform benefits especially for companies that build apps for console devices and smart TVs
It's not inevitable. It will take immense hard work. It is _almost_ there right now (getting started with leptos, for example, is a pretty good experience). But it is incorrect to say it is inevitable unless the tech, product, DX, use cases, and case studies exist already - THEN it is inevitable and will be moving along the graph/curve of adoption. Until then, it requires work - work that **is always capable of being de-prioritized**. Nothing is guaranteed until it is shipped. Whether fully open source from people's free time, or being funded by people at work, nothing exists until someone births it into the world. Maybe Leptos is the answer - but not it its current form. Maybe something else will take the cake and garner mainstream adoption, and if so then it doesn't exist or is just starting now.
UI will stay being JS because of its ability write UI and iterate quickly. Rust has not only a steep learning curve, but it also, by design, enforces you to write things in a way that increases friction. It's very good when you're writing software where memory safety is important, or where you need low level performance. For UI, this is less than ideal because UI. You don't want to think about memory allocation, etc. when you're writing UI. "What about logic? UI has logic! Logic can leak memory!" you say. Yes, but most of that logic should be event driven and concerns only about the UI. The browser does 95% of these things, the last 5% is coordinating those things. Think Buttons, Dropdowns, Modals, Typeahead, Forms and Animations.
@@dealloc I'm extremely skeptical of this argument of being able to iterate quickly; in my experience, Rust scales way better with complexity and being able to iterate effectively on a mature product seems like of a greater concern, but I digress. The primary reasons to use Rust for UI have more to do with correctness, ergonomics, portability and expressiveness; traits and macros let Rust do things TS can never dream of.
@@dealloc that's why I say apps in js, dev tools in rust, the effort/benefit ratio is more acceptable that way, as a dev I want lightning fast tools. E.g. a compiler should be written in rust rather than js.
React is Java's spring. Like Javascript, java had new frameworks every week more than a decade ago. Like React, Spring won the framework wars. React will continue to be king in JS, but it will be boring and just pays the bill
I feel like Svelte (especially now with SvelteKit 1.0) has everything it needs to truly start challenging React and with a bit more adoption we might really see the ball rolling soon.
All we need now is a rich ecosystem, which is probably the point that holds people back the most from switching between things
@@ninhdang1106 "Rich" ecosystem 🤣
I would like to say I see what you did there but i don't know if it was intended
What about Solid and SolidStart ? I haven't used it but it looks really promising.
I feel like React devs would be less afraid of Solid because of the similarity of syntax (JSX), versus Svelte that to me looks more like Vue (my experience with Vue is limited to a few weeks using it, but I'm talking about this separation of markup+special syntax, and JS code).
@@Hexalyse definitely solid is so good. Haven't try it personally yet but watch a lot of Ryan's videos and will be trying it out somewhere mid this year
But svelte syntax.. I can’t stand it
I recommend the talk "Rethinking Reactivity" by Rich Harris (creator of Svelte). It shows that while, of course, React can get the job done very well, there's just some fundamentals about it that make it slow, and doctoring around on symptoms with things like "concurrent react" is just that: doctoring around. I am really thankful for having had React, it moved everything further in a good way. But from now on, Svelte, baby ;-)
Fantastic talk. He's a great speaker and thought leader for Svelte and JS frameworks in general.
I am so freaking happy that we are finally getting away from the horrendous concept of shadow dom and bringing the syntax back to halfway sane
I’ve been pretty critical of the web development community historically because it has a tendency to re-invent their entire stack every startup cycle (18 months to a few years). I think the good thing about React is that it allowed everyone to agree on a set of best practices for writing web apps that has stabilized somewhat, but I also think in order to improve in a way that conservative engineering management will accept it, it’s going to have to happen without forcing everyone to re-learn everything they know just to make a silly push-button-get-data webpage.
React was successful because it had the right idea. Solid just does it much better.
Summed up.
I would love to see Sveltekit being adopted by companies. Out of all the frameworks I have the best DX when building with it
Ye solid/ryan is playing the game really smart imo. His streams really helped in gathering a community of tech wizards around solid, people who are interested in building their own frameworks (like leptos or voby) or who like to build libraries, creating an amazing eco-system around solid, especially for as young as it is.
And there is this general camaraderie / cross-pollination with the new generation of js-frameworks, thinking mostly solid - astro - qwik (although they market pretty hard) - marko, and with people like tanner, that will be what moves the needle imo. Bling, the collab between solid-tanner-astro ryan/tanner announced last stream, is super exciting and a piece in that big puzzle. The impact of tanner's work on the js eco-system really can not be understated. Moving from react-query/react-router to tanstack really announced that next step in the evolution.
I hope svelte or something very similar to svelte becomes the next big thing. It just feels so natural compared to something like react. Having said that, I am also waiting for the next big thing in web development. There is a lot of new features in new frameworks but at the same time they feel so similar.
React is the best thing that could happen to js community. I hate it
Do I recommend it, no! Man I love it.
hahahaha
I love react, but I wouldn't even recommend it to my worst enemy
So much enjoy using Nuxt and Vue3 in real world projects. No matching solution yet in my opinion.
💯
Indeed.
to the moon 🌔🚀
Have you tried SvelteKit yet?
Nuxt 3 is the best
I think, React will evolve into a something that combines the best part of each competitor. React team were bold for going to hooks, I don't think they would be that conservative when the time comes.
Developers who were core team members of React recognize that there are things that simply cannot be changed, because they would break the web.
I really enjoy making SPAs with React. Don't think it's the best tool for other types of web apps though, Solid really looks like a winner there.
React also gives you a option of React Native which let you push your app to app store faster....and I don't think startups won't consider that
one of the underrated benefits of React, i learned React and when my company wanted a mobile app i was able to create and deploy the basic mobile app intergrated with our existing API within a month of time, the transition from React to React Native was so smooth. lot of the other frameworks lack this main benefit i guess
flutter is so much better than react no-native
I also found THE PERFECT use case for SolidJs, in the mobile world. I'm working right on an ionic mobile app running on capacitor, and since it's running in a webview as a "website" the performance implications are VERY noticeable. The other very game changer would be a solid react-native-renderer, to mitigate the react perf issues on low to mid end devices there as well!
What this industry needs is people that solve the problem they have instead of focusing in details that just move the problem around.
The h is silent in chasm btw.
I wish React could rapidly evolve to work as SolidJS and adopt all the new good patterns introduced by new frameworks like Svelte and Qwik
I'm hoping Solid wins, comparatively simple migration from React.
My only gripe with Solid is the jsx side of things, Svelte is revolutionary in many ways.
I'm a heavy REact user, love to use Gatsbyjs for my projects, but now, I'm looking more and more into Svelte and Sveltkit, started two projects with it, with VIT under the hood, everything is soo freaking fast, is hard not to use it.
This is the first truly worthwhile "how to React" guide on RUclips, ty Theo
I tried Svelte and now I cry everytime I have to even think of React.
I think the web frameworks on top of the ui libraries make the difference between these tools, and with next 13, react has the best web framework once again since a long time.
8:33 I'm glad you asked :) I'm working on a new React meta-framework that starts out as a CRA replacement (including compatibility with a lot of existing CRA code to ease migration) but it can be used to build interactive apps (I would say to Remix level) with SSG/SSR as well. It's called QGP app.
seriously asking, is it REALLY that frequent a SPAs that so rich in features etc made the performance wise really concerning? I personally looking forward to better frameworks/libs, but honestly, after 2+ years professionally working with react apps, I have NEVER, even once, felt the need of better performance. With react lazy, code-splitting, memo, useMemo, useCallback etc, its just really hard for me to imagine what kind of components are there that so heavy in computation that the need of better performance in SPAs became so dire.
I understand the need of meta frameworks such as next, svelte kit, etc. But switching from react to another SPAs framework feel useless for me in terms of performance.
It is not really the raw performance of React (and VDom, diffing, and committing algos) that is the issue here. The issue is the mental model you have to have when working with hooks and the handholding you have to do constantly as a developer.
You have to abide by rules of hooks. You have to manually manage _every_ dependency in _every_ dep array in each of `useMemo`, `use Callback`. Why is not `React.memo` the default (internally implemented) memoization mechanism if without it render functions run all the time? It is very easy to regress in performance of a tree of components simply because you missed a dep or forgot a `useCallback` somewhere.
`React.memo` by default only does shallow comparison only. If you want anything else you need custom comparators, but they are such a bad idea. By using them you introduce another mental map of props x performance impact that you (and the entire team) have to keep in mind. Any change to the props requires you to change the memo comparator or otherwise you have just either regressed the performance or, worse, broke the component because it no longer re-renders when it should because that new prop is not included in the comparator logic.
Then there is state management challenges, using React.Context and ensuring everything is immutable. But I don't even want to go there :D
This is what you have to keep in your head at all times, on top of the domain logic and just writing performance (framework-agnostic) algorithms. This problem grows the more the codebase and the team grows (so very hard to out-pace).
I have been looking into SolidJS as I think it "fixes" a lot of these problems and provides a much better model of reactivity. Another "solution" might be a state management library that frees you up from worrying about those pesky and ever-present performance consideration (at least in the domain layer). An example would be MobX.
So... t3 with Solid Start?
1. Let the equal operator do its job
2. SSR first
3. Use JSX syntax
the main problem now is what to pick (solid - great, remix - great, svelte - great).....
It really depends on personal likings now. Do you want ship less js? how much third party support you need? Do you want to be part of a big eco system, etc
we need t3 stack for solid start
I learned React, but ended up getting my first dev job at a project that uses Vue/Nuxt.js ¯\_(ツ)_/¯ In fact, the guys said they used to use React, but moved over to Vue.
SvelteKit is it. React made me hate frontend, svelte has made me love it again!
The biggest hurdle in getting the pragmatists away from react is the ecosystem built around it. It just makes you way less productive when you go to another framework and you have a tiny fraction of the off the shelf solutions that you do in react. Its a show stopper.
I like remix, kinda a learning curve but better then just react only
@@liberalwrecker949 Yeah i'm with you on that. I'm not use to using folders and file names to define my routes.
@@liberalwrecker949 doesn't svelte kit aslo use file based routing?
*furiously taking notes*
I'm just happy backend devs aren't trying to reinvent REST or MVC every 2 weeks like frontend devs and their frameworks
React in and of itself is just a tool for effectively creating UI. It solves fundamental problem of FE, nothing more. That’s the reason why it is so popular, and won’t die in the nearest future.
It has done the "Java/C++" thing. We've all used it so much and since enterprise don't change as much as startups... well we would continue to use it for 40 years and say it's not dead.
Even for creating UIs, React is still bad. And it is the exact reason why Solid, Svelte, and Qwik were created in the first place
@@DEVDerr solid is the best
@@DEVDerr ignorant to say "react is bad." You may not like it, but it's the most popular FE framework for a reason. And when it was created it was revolutionary. Comparing it to tools that wouldn't even exist if react hadn't paved the way is just silly
That zoom out at 1:18 was sweet
FYI: chasm is pronounced kazim
What I'm working on is a method of killing the whole damn framework system. The entire webdev effort has devolved into a collection of Band-Aids slapped over a core wound. And we all just limp along like undead, patchwork mummies because we don't know any better. I believe I've identified that core wound. I believe I have an actual remedy. Before this year is done, we'll see if I'm right. (I am)
!RemindMe 9 months
Using ”killing react” as a click bait title is totally fine. But to then in the video try to shoehorn it to mean something polar opposite of killing react, that’s just confusing.
!
It is that Wednesday afternoon I am watching. You have terrified me.
So what should a newbie learn today? If the end goal for me is to work with SolidJS, should I learn React first to then learn SolidJS faster and better? Or should I learn NextJS and then SolidJS?
Nextjs 14 should just run on Svelte
/s
idk what changed but the lighting is good in this
I feel like bootstrapping an app adding UI library + authentication+ state management + other tooling like prettier (or if setting up mono repo then god it takes more than 1-2 days) eats a lot of time. Redwoodjs and couple other frameworks now provide one single command to just add these. So, if new frameworks make adoption easy then its easier to make a switch. In my opinion, I am willing to learn a framework but not willing to leave the ecosystem (third party libs and all).
“Let me know if you want to kill React”
I don’t want to kill it but having to take a 48hr course on Udemy just to learn the fundamentals where other libraries can be learnt in a fraction of the time makes me look elsewhere.
I started on a little library side project a few months back as I really like web-components and Vue, I probably would have been better off finishing the React course as I could add it to my tool belt but I had more fun and probably learned more rolling my own little library.
Honestly you don't really need to know much React to use it, though it is harder to pick up then other frameworks. I hate React but only because of how much I've used it--really what I hate is JS
@@jacoblockwood4034 Yeah JS/CSS/HTML are the only things that you can take from one of these library's to another but I seemed to have more problems taking them to React than other libs but maybe down to little time with it.
@Theo - t3․gg Am I allowed to post my library? Its not taking on any other lib anytime soon but as a FE dev its more of how I would like a FE library to be.
t3 stack equivalent for sveltekit and nuxt coming up?
Well, I'm confused between Next and Solid, cause Solid has better performance but Next is more popular and more likely to get a job with, which one should I pick?
nobody seeing react three fiber and threlte (for svelte) an open GL rendering approach as ultimate frontend goal? I getting so hyped by this, someones ?
Been learning threejs on the side in these past months, I am very excited with threlte since our new MVP project is done using Svelte.
@@daleryanaldover6545 cool dude. I wanted to make a RPG game as web app with it, but I am at a steep learning curve
I honestly like the idea. Istarted to learn react when webpack was still the onl;y real bundler of choice. Then i migrated to vue because it was just soo much simpler and aesthetic (ofc this is an opinion) I much more like the vue way with .vue files than the react way with javascript/JSX and ofc. vue has its pitfalls... but is more forgiving than react
If you put these frameworks side by side without big companies backing them up and just focus on how they do the job RIGHT ... Svelte will standout in my opinion.
I think that many other frameworks like AstroJS will appear and support React, and people will still use it until there is no other library as popular as React. But when we get to the point where something like SolidJS is well known and supported, React will start to die.
React is the best starting point before making your hands dirty with other frameworks.
React gives you a slap of errors & bugs if you're carelessly building projects. Once you get used to the architecture of React JSX/TSX with hooks, IMO, it's a lot easier to switch to any other (similar or different) JS frameworks whether it's Next.js, Remix, Svelte, even Vue.js, etc.
Above all, it all depends on the problems you wanna solve and I agree with you that any framework that would solve the problems that React developers face, will definitely get the attention of the community.
React is a library, it's not a framework :)
2:18 php's death ? I don't think so, there's a big community around Laravel + Vue + Tailwind combo you should know of
He didn't say like "dead" dead. There's a whole community revolving around php. And he acknowledged this.
And I feel bad for every single one of them
He meant, that NEW adoption to php is not high as it used to be. The people who use laravel or TALL stack in particular are most likely companies that have been heavily invested on Laravel. Switching to other tech stack when Laravel in itself is stable already would likely outweigh the benefits of using another framework.
Is there a framework you can recommend to solve the problem of the current job market?
React is going to be a cobol.
Wide adoption across, corporate momentum keeping it alive
1. Kill React
2. Kill JavaScript
3. ???
4. Return to Monke
After I learned Svelte, I couldn't write in React anymore.
soo react is the new java?
Surprised I discovered this video only now, wondering if someone who recently decided to unsubscribed your channel ever watched this one. lol
killing the virtual dom is a huge selling point imo
How can Next kill react when next is using react ?
I was actually considering switching to a different framework like Vue or Solid.
But then Next 13 came out and I didn't do the switch.
🙏Some 200 IQ beast watching this video rn, says "Challenge Accepted, Theo" and by summer has built something from scratch that perfectly combines the best pieces of all the existing high-profile frameworks/libraries.
Already done: Misko Hevery -> Qwik
Surely, NextJS has gained as much popularity as it has because Vercel want to sell their services and have poured a lot of money into its development and promotion. It’s to attract more devs to their platform and make more money in the long term.
I belief that number of hooks React has to solve issues and introduce new issues at the same time is unnecessary
Fmtamentals that made me fell in love with react could be solved by better rendering engine
I wouldn’t say I am trying to kill react but I certainly trying to improve on it by building @xania/view although still struggling with documentation obviously and SSR
Push React into the chaz-um
Only thing sveltekit is lacking is huge library support like react.
react is here bois, cherish it
The battles aren't hard when you can lock your enemies.
3:07 always loved this lol
React saved my marriage and rescued my 4 year old from a burning building. I can't wait to commit tax fraud and frame React for it
And what are the problems you have with react?
Solid and Svelte are killers. I just wish there were better ways to learn more about Solid/Solid updates than Ryan's streams. He is a SEEEUUUPER smart/good guy... But, 4-5 hours every other week/month explaining the nuances of a Solid Js feature that we average devs can't make us of today isn't going to make anyone abandon React. Let alone use Solid over Svelte. Learn from Rich Harris, please. Rich shows us how to get something done with his work in 20-40 minutes with time for questions. Ryan shows us how to play with his work... for 4-5 hours (Or shows up to other streams and runs over the time going on tangents) and ends up not getting anything done. Anyway, there needs to be more coverage of Solid because it really is a great framework and deserves more shine.
isn't vue almost as old as react?
React is 3 years older then Vue
@@yourivanmill it is actually 1 year.
React: 2013
Vue: 2014
Hey Theo. Lots of noise in the background of the video and weird exposure "flashing". Great content though!
So t3 stack will die as well? 🤔
3:25 Me watching this at 11pm on a Monday
Does anyone have a link to the chart he was referencing?
State of js survey
So you are telling me don't learn react while 80%'s framework are based on react?
If new developers learn react first, then adopt to other framework, won't they have better sense about framework?
Thought?
the thumbnail is great
Frameworks should adopt the "compiler way". If I use only 4 functions in your framework, I should get only 4 functions in my app.
Also why don't we fix JavaScript and the DOM (or encourage developers to properly study the browser) instead of producing another abstraction that we would abandon in 3 months?
Uuuhhh fix JS and the DOM? What?
Give me 3-5 things that are actionable this year and give me your estimations on what browsers would implement them. 😂💀
I'm still using vanilla 😂 but I would like to see the compiler approach also
isn't that exactly what Svelte is doing (the compiler way at least, not the lack of abstractions)?
'Frameworks should adopt the "compiler way". If I use only 4 functions in your framework, I should get only 4 functions in my app'. this sentence contains a contradiction: the 'compiler way' is the exact opposite of getting what you have written.
I have made an chat bot with t3 stack
This uses open ai api to respond
Thank you for t3 stack.
Anyone didnt reply??
are you Adam Scott's brother ?
The way he said “chasm” 😂
I don't feel that I've learned react though I'm working with it and it's getting killed already? Sure why not
I dont wanna kill anybody, im not a killer, but hunting fookin redux... with scss would be lovely...
Svelte is still the best DX to date. It makes everything else feel like a downgrade. I love the solid project though. Hopefully Svelte 4 will have signals!
If we are so ready to sacrifice the huge comunity that comes with react, why not move into Yew and use Rust for compiled web asembly components?
If its about performance, good luck beating that...
Aren't those slower though because of the extra overhead? And presumably they have larger bundle sizes because of the glue code. I think unless you're using WebGL/WebGPU to render the UI, WASM only really makes sense to use for raw compute stuff or for porting native libraries. Unless maybe a new UI framework comes along that can only work so well because it doesn't use JavaScript, I guess Yew does that to some degree with the extra stability of Rust though
@@hedgehog125 They do use WebGPU, and there is no glue code, hits the same api as JS do.
But yeah.... I find it stupid, solves nothing new and gives performance that nobody asked for
@@Fernando-ry5qt Oh yeah, I forgot you can just pass the browser API functions to it. Is glue code mostly just for when you're interfacing with WASM via JavaScript?
@@hedgehog125 yup, mostly
Given the current climate. React is "good enough". Unless there is a major paradigm shift (like AI does something revolutionary), I don't see React _ever_ going away... just like I don't see Apple or Microsoft or Google or Amazon or Facebook _ever_ going away.
as long as its not something like angular
I love React & was using it (with Next.js of course) for almost 3 years), but from a half a year I init every new side project in other meta/framework, like SvelteKit, Solid.js, Vue (Svelte is my new ♥) etc. just because of curiosity & because I'm a little bored with React so far 😏
Plz don't kill React.
It's official! Theo has blown the horn!!! My fellow developers, let's march together to battle React.
Note taked. See you in 5 years.
I read the write more, do less under jQuery and was like that sounds nice, record scratch wait shouldn't that be the other way around? lmao
you found that nice 😂
Don't get me wrong. I guess, you talking about VUE? ^^
I think that there will come a time in which reactive frameworks written in Rust will take over. It's an inevitability that WASM becomes substantially better than what it is today, and there will be this massive performance difference that upends the status quo of things. There's potential for highly optimized SSR; WASM has no interpretation time penalty and will have better time to first render; there's serious cross-platform benefits especially for companies that build apps for console devices and smart TVs
It's not inevitable. It will take immense hard work. It is _almost_ there right now (getting started with leptos, for example, is a pretty good experience). But it is incorrect to say it is inevitable unless the tech, product, DX, use cases, and case studies exist already - THEN it is inevitable and will be moving along the graph/curve of adoption.
Until then, it requires work - work that **is always capable of being de-prioritized**. Nothing is guaranteed until it is shipped. Whether fully open source from people's free time, or being funded by people at work, nothing exists until someone births it into the world.
Maybe Leptos is the answer - but not it its current form. Maybe something else will take the cake and garner mainstream adoption, and if so then it doesn't exist or is just starting now.
I don't believe this, I think apps will stay in js but tooling will be written in rust.
UI will stay being JS because of its ability write UI and iterate quickly. Rust has not only a steep learning curve, but it also, by design, enforces you to write things in a way that increases friction. It's very good when you're writing software where memory safety is important, or where you need low level performance. For UI, this is less than ideal because UI. You don't want to think about memory allocation, etc. when you're writing UI.
"What about logic? UI has logic! Logic can leak memory!" you say. Yes, but most of that logic should be event driven and concerns only about the UI. The browser does 95% of these things, the last 5% is coordinating those things. Think Buttons, Dropdowns, Modals, Typeahead, Forms and Animations.
@@dealloc I'm extremely skeptical of this argument of being able to iterate quickly; in my experience, Rust scales way better with complexity and being able to iterate effectively on a mature product seems like of a greater concern, but I digress. The primary reasons to use Rust for UI have more to do with correctness, ergonomics, portability and expressiveness; traits and macros let Rust do things TS can never dream of.
@@dealloc that's why I say apps in js, dev tools in rust, the effort/benefit ratio is more acceptable that way, as a dev I want lightning fast tools. E.g. a compiler should be written in rust rather than js.
React is Java's spring. Like Javascript, java had new frameworks every week more than a decade ago. Like React, Spring won the framework wars.
React will continue to be king in JS, but it will be boring and just pays the bill
Taking about "killing React Native"
React ain't a framework. Angular is a framework