Maybe the moral of the story is to stop confidently pushing these hot takes that are constantly proven wrong, but then the dude wouldn’t have any content.
lol, weird jump in logic. being regularly dishonest about your knowledge on stuff and then admitting your dishonesty when you're proven wrong is not honesty, it's just... backtracking on your statements
For now we can summarize about Remix/React Router in 2 points: 1. Remix === React Router returns true 2. Neither Remix nor React Router will ever die as long as Shopify never dies
praying this transition goes smooth, I will say 2 years into a remix app and I don't regret it yet. It's got its rough edges, but overall been able to do everything I needed. I'm worried about RSC but also it seems like if they confine it to being used in the loaders primarily it shouldn't mess with the rest of the way that react works outside of the loaders.
My react projects from my company still uses old version of react-router and my team has no plans on shifting to next.js but with this new update from react-router I'm 100% sure that my team will be glad to upgrade soon
So am I understanding it correctly? I have fresh Remix app right now currently in active development. I started it with vite plugin. So when RR V7 is out I will migrate to it. And AFTER THAT when the new Remix comes out with RSC i can migrate again to Remix to use RSC??? Is that right? Or RSC will be avaliable in RR V7??
@@infantfrontender6131 yes basically, as an example wherever you use Link, the import would look like "@remix-run/react" -> "react-router-dom" or whatever they are calling it now
I've been experimenting with Tanstack Router for a dynamic app prototype, but React Router was much more fit for the task: I can nest route trees within my components with JSX and which is way easier to read and maintain. The only gripe I have with RR is that I can't `useMatches` hook with nested routes to build a breadcrumbs component. Still, an insanely cool and useful library which is go-to for most of my frontend projects
My App was started with CRA a Long time ago. And it used React Router v6 How and Why would I Switch to Vite and React Router v7 Would I have to Switch to Vite as well?
Well, if you don't want to....then you don't have to lol. this is for people who want to. If you are interested in, I am sure they will write a blog or documentation about it.
@@j0hannes5 Depending on how custom your current build config right now. If you changed nothing in default config of some build system, default config for vite will probably do the same thing. Overall, switch on small and middle-size project is probably will end in few google searches. Overall, there's no reason not to migrate.
00:01 React Router is here to stay despite initial doubts 01:50 React Router V7 updates include non-breaking upgrade and remix integration 03:29 React Router version 7 introduces significant new features. 05:19 Remix migrated to Vite much faster than expected 07:00 Remix is a v plugin that makes react router more convenient to use and deploy. 08:47 Transitioning V plugin to React Router V7 for future enhancements. 10:32 Server components in React Router future-proof React apps 12:15 Shopify's acquisition of Remix allowed the team to grow and improve significantly. 14:00 Server components in React Router enable easy rendering from server to client. 15:54 Server components simplify data handling for components. 17:39 Loader in React Router handles content loading and requests.
Interesting. As a dedicated NextJS developer, I always kept an eye on Remix and tested it to understand it better and stay updated. It's been a healthy and friendly competitor, pushing NextJS to improve and make good decisions (like RSC and Forms). I used to think of Remix as another fullstack framework, almost as big as NextJS. However, the rename changed my perspective. Now it feels more like, "Hey, we are just a useful library, by the way" 🙂
@@t3dotgg I tried it in a project recently. The crazy things TanStack router does to achieve its "type safe" routes kills the TypeScript language server, making things like intellisense less snappy, and overall I would say the dev experience is worse.
@@damon8541I feel like that's more of a JavaScript thing than a problem with the library. Also, I am saying JavaScript because TypeScript is not a language, it's a linter. It has to conform to JavaScript rules which is the problem.
I am super hyped. I recently converted and next 14 app to vite and react router v6 and it felt like a dream. Iwas struggling and fighting with next constantly. The routing sucked, especially if you wanted to pass data from page to page. When I got to use the ssr stuff it was cool, but still a bit of a pain. I just loved the react router documentation. There were less gaps and it just made sense. I have been a remix fan for a while, this experience reminded me why. I just don't like next very much and I think the remix team is far more innovative and transparent. Next isn't as clear under the hood.
why is that article dated May 26th 2024? are they time travelling or something? I mean I can see it happening with how Ryan has aged so fast after starting Remix, but damn, took me by surprise
I really really like Ryan and Remix for this. A lot of people wondered if Remix was selling out when acquired by Shopify. I would argue this is quite the opposit. Shopify providing the foundation and ability to find the best form of React Router AND Remix. He let innovation take the lead over brand even though Remix Router would be a cool name too!
9:25 - finally a based opinion by Theo. Took you time enough but we finally got there. When we get *asynchronous functional components* on the client exclusively, then we are talking. Not everyone can or has any obligation to maintain a Node image - or, heck, wants to serve their UI, through primarily an express-y thing that runs on Node. Plus, not everyone needs or even wants SSR.
"I'm excited for a future where you can use server components in more dynamic ways, and compose them, and do all the cool things I'm used to doing in NextJS". Can you speak on this? What's so much better about how Next does RSC in your mind?
I don't know what he's thinking of either. Like I said in the chat a few times to all the "can it?" questions: it's RSC, it can do all the RSC things! 😆
@@blessdarah1256 that's fair. Sometimes I wonder if the Next crew feel like they have to make changes to keep up with everyone else and use React Canary releases. I haven't had any issues with Next releases, but Remix promotes a form of simplicity that I can't ignore. Excited for their take on RSC.
I dumped next js for react router v6 for this reason. Glad I can now use it even for projects that require more advanced server side rendering and RSCs etc. SO EXCITING
Currently, I'm using Expo to write my mobile apps (Android and iOS), desktop apps (Mac, Windows, Linux), and my website. :D I've been using React since 2014, and I've tried every single React framework. Having worked on dozens of React and React Native projects, I can confidently say that Expo will surpass them all in the next two years!
@@MsVsmaster Why should I use Next.js, Remix, or Gatsby for building websites when I can use React and React Native (Expo) to build everything? I mentioned two years because, at present, Expo lacks support for all desktop features. However, they are making significant progress in addressing this.
I’m super excited to learn more. Also super pumped to see a community that genuinely seems to be collaborative and cooperative, seeking the best results for everyone.
Returning markup from the server is not an HTMX thing. That was already the standard pattern and one that any react app that uses SSR is also benefiting from.
@RyanFlorence Yes, you are moving on to step 2 of EEE; Extend, The tweet from Jacob Paris shown at 3:29 describes how EEE works. For what it's worth I won't mourn the extinguishment of RR (React Router) the major version upgrades have been horrible, upgrading a large project to V6 recently required writing some absolutely horrific HOC (Higher Order Components) to aid in backwards compatibility in order to get the migration across the line, stepping stones that other good tools would have provided... And all for what? A functionally identical outcome, just different. Almost all of the software I've written has a lifetime measured in decades so keeping up with this churn is incredibly frustrating. I look forward to seeing what extensions are made for users that will be de facto Remix users when it awakens from a "Nap", we will likely be one such user as a migration away now is prohibitive. I do sincerely thank you for your contributions to open source Regards a future Remix user
@@t3dotgg I'm glad I've been using Git for two decades. 0.4.1 caused my app to render to a white screen with no error message due to changes in the way state was handled. The next time I updated was 0.9.0. They changed the way state was handled again which broke components, as well as components built for production to be squished together different than locally developed versions. 0.14 wouldn't update child components when the parent changed unless you chained state on all of the children that needed it. That means doing wacky crap passing functions as properties to children so they could call it as a callback to pass a function to the parent in order for the parent to call that function to let the child component update it's state. The next upgrade was 15.0.1 which caused the previously mentioned fix to completely lock up the app and components. This meant keeping most state in a near-top-level component and passing functions down the ladder to allow children to affect state, or, as most people suggested, cloning the element entirely and adding properties to it, but now you have to give all children access to it so it can clone all children to give them access to changing the state if it needed it. Now you have this all-father component and you're using a method from that component to wrap around all child components,.I'm sure that won't be problematic. 16.8 was apocalyptic. Asynchronous functions like the one from the last fix are now broken because the parent component is not guaranteed to be mounted. They also took down most of their documentation surrounding class components, without having real existing documentation about function components and useState was a large mental shift. It also (oh so quietly) broke state. Where you could previously pass instances of Non-React code as props and store things like websocket connections , you would now have to throw them into the global scope, or as most suggested, initialize them them when you created the react app and along with any elements they needed using document.createElement, attaching them to the dom, and then detaching them later so that they could be referenced later. Then I get to clone the child elements, along with all properties, reroute events and attributes in order to stop React from doing funny business on the elements themselves. document.querySelectorAll("#id").appendChild() or whatever. useRef exists at this moment, but from my memory almost nobody seems to know about it (at that time). And you know by now how that went. Soon react , and but soon after useRef was better understood.
@@t3dotgg I wrote a long response and hit comment but I'm guessing it vanished. Migrating 0.4 to 0.9, migrating from 0.9 to 15 all handled state differently and broke things. 15 caused dev versions and production versions to look very different. 16.8 broke handling non-react objects very badly and required really annoying hacks in order to stop react from mangling the elements (passing to the react app when it's initialized and passing through the prompts along with attaching them post-render, and redirecting HID events through callbacks and sending events through those callbacks to outside elements, then sometimes needing to rip those elements out before you can update state safely. The combo of useEffect and useRef was superior nowhere I could find explained it. Along with the release of 16.8 they ripped out all of the documentation they had and it kind of forced most of us to upgrade, which was rough because the documentation was screwed up. Broken links everywhere. The only way I can imagine you didn't experience this crap is if you started using React in 2018 or so and only on a React-only code-base. I don't think that is the case though. You just is crazy. Edit: Still less breaking changes than Angular. Angular 1 was nice to use, Angular 2 broke everything, and Angular 4... I gave up. I'm full a full stack developer working with small companies, I don't have time for Angular shenanigans.
Is this a serious comment or are people just too lazy to read what is really going on? The new ReactRouter will have remix inside so nothing changes or goes away all you do is stop calling it Remix and you just change imports😂 damn people please read before commenting.
good. it was getting confusing with next.js vs remix vs react router. next.js has won on the server and react router has won SPA's, so retiring remix and working on react router completely is a really good decision.
Ryan: "It's not dead, it's just taking a nap!"
Who flutter
Let's talk about how theo is wrong about many things but people blindly follow him
“nap” is the single word that threw the world into a fit
Remix is dead, long live Remix!
I saw the live and now this video, overall a nice summary lesson, thank you for your work. Hugs from PT
Every other Theo video starts with, i was so wrong about my following take on my last video. 😂
Gotta love his honesty!
Maybe the moral of the story is to stop confidently pushing these hot takes that are constantly proven wrong, but then the dude wouldn’t have any content.
I do appreciate his honesty, but people need to stop blindly taking his word and takes as the truth
I was just thinking the same thing 😂
lol, weird jump in logic. being regularly dishonest about your knowledge on stuff and then admitting your dishonesty when you're proven wrong is not honesty, it's just... backtracking on your statements
"Gotta love his honesty" The reason he's wrong all the time is because he's so incredibly dishonest
For now we can summarize about Remix/React Router in 2 points:
1. Remix === React Router returns true
2. Neither Remix nor React Router will ever die as long as Shopify never dies
praying this transition goes smooth, I will say 2 years into a remix app and I don't regret it yet. It's got its rough edges, but overall been able to do everything I needed. I'm worried about RSC but also it seems like if they confine it to being used in the loaders primarily it shouldn't mess with the rest of the way that react works outside of the loaders.
My react projects from my company still uses old version of react-router and my team has no plans on shifting to next.js but with this new update from react-router I'm 100% sure that my team will be glad to upgrade soon
I'm a long time Remix advocate. Really excited for the future of Remix and RR...
One of your best video Theo, keep up the good work!
My boy Jacob got name dropped in a Theo video! How cool! Been friends since the gamedev days, he's movin up in the world.
So am I understanding it correctly? I have fresh Remix app right now currently in active development. I started it with vite plugin. So when RR V7 is out I will migrate to it. And AFTER THAT when the new Remix comes out with RSC i can migrate again to Remix to use RSC??? Is that right? Or RSC will be avaliable in RR V7??
Looks like all Remix features will be available in RR v7+ going forward. Remix as a separate standalone package won't be needed.
Everything will be in RRv7
@@infantfrontender6131 nice!
@@infantfrontender6131 yes
@@infantfrontender6131 yes basically, as an example wherever you use Link, the import would look like "@remix-run/react" -> "react-router-dom" or whatever they are calling it now
Thanks for the commentary! Excited.
I am at the really start of one of my projects done with Remix. What would you guys recommend to do? Switch immediately to RR, or continue with Remix?
Like you being wrong 90% of the time?
I've been experimenting with Tanstack Router for a dynamic app prototype, but React Router was much more fit for the task: I can nest route trees within my components with JSX and which is way easier to read and maintain. The only gripe I have with RR is that I can't `useMatches` hook with nested routes to build a breadcrumbs component. Still, an insanely cool and useful library which is go-to for most of my frontend projects
This reminds me of when Rails and Merb merged in 2008! Yahuda Katz has a great post on how that all went
My App was started with CRA a Long time ago. And it used React Router v6
How and Why would I Switch to Vite and React Router v7
Would I have to Switch to Vite as well?
You can use RRv7 in your code without problems. But if you want all Remix features, then you need to migrate to Vite and Remix plugin for Vite
Well, if you don't want to....then you don't have to lol. this is for people who want to. If you are interested in, I am sure they will write a blog or documentation about it.
What does it entail to switch to Vite?
@@j0hannes5 because it's currently the best tool.
@@j0hannes5 Depending on how custom your current build config right now. If you changed nothing in default config of some build system, default config for vite will probably do the same thing. Overall, switch on small and middle-size project is probably will end in few google searches. Overall, there's no reason not to migrate.
00:01 React Router is here to stay despite initial doubts
01:50 React Router V7 updates include non-breaking upgrade and remix integration
03:29 React Router version 7 introduces significant new features.
05:19 Remix migrated to Vite much faster than expected
07:00 Remix is a v plugin that makes react router more convenient to use and deploy.
08:47 Transitioning V plugin to React Router V7 for future enhancements.
10:32 Server components in React Router future-proof React apps
12:15 Shopify's acquisition of Remix allowed the team to grow and improve significantly.
14:00 Server components in React Router enable easy rendering from server to client.
15:54 Server components simplify data handling for components.
17:39 Loader in React Router handles content loading and requests.
We got a remix of react router a f'in js library before GTA 6
Wouldn't be the first time :^)
Is that supposed to be surprising?
What would be a good place to start learning about RSC?
Did the previous version of React router also eat some other new and shiny router?
did you just fire shots on Taylor Otwell??? :D
I fail to see how a browser based solidity editor fits into react, but I can’t keep up with all the tech anymore
I felt the vibe, full of adventure
Some of the comments💀👌just get lost already...its about react router darn it!
Dude You uploaded it right in the middle of me watching why react router is dead lmao.
@@banfiesta7158 lmao same
@@banfiesta7158 i think theo been upto some 🌿 herbs 🤣
@@anamitraupadhyay ha, I don’t know why did I put my comment there but I’ll leave it like it is
@@banfiesta7158 dude i think my herb 🌿 comment was removed💀okay...whoever did that it was a joke aight? Sorry.
Amazing video :D ty
Every company I've worked has needed to upgrade react-router. It's VERY hard to keep it up to date.
Holy crap, the calibre of developers on that sream! I feel a bit starstruck!
Interesting. As a dedicated NextJS developer, I always kept an eye on Remix and tested it to understand it better and stay updated. It's been a healthy and friendly competitor, pushing NextJS to improve and make good decisions (like RSC and Forms).
I used to think of Remix as another fullstack framework, almost as big as NextJS. However, the rename changed my perspective. Now it feels more like, "Hey, we are just a useful library, by the way" 🙂
i am so confused. what is the difference between remix and this react-router?
I am so curious to know how React Router v7 and Tanstack Router differ now.
I've already migrated to TanStack Router (un)fortunately
Tanstack router is pretty hype ngl
@@t3dotgg I tried it in a project recently. The crazy things TanStack router does to achieve its "type safe" routes kills the TypeScript language server, making things like intellisense less snappy, and overall I would say the dev experience is worse.
@@damon8541 Are you sure you're not doing something wrong?
@@damon8541I feel like that's more of a JavaScript thing than a problem with the library. Also, I am saying JavaScript because TypeScript is not a language, it's a linter. It has to conform to JavaScript rules which is the problem.
Tanstack router is good enough man, no worries
I am super hyped. I recently converted and next 14 app to vite and react router v6 and it felt like a dream. Iwas struggling and fighting with next constantly. The routing sucked, especially if you wanted to pass data from page to page. When I got to use the ssr stuff it was cool, but still a bit of a pain. I just loved the react router documentation. There were less gaps and it just made sense. I have been a remix fan for a while, this experience reminded me why. I just don't like next very much and I think the remix team is far more innovative and transparent. Next isn't as clear under the hood.
3:09 Remix wasn't aligned to React Router versions :) Remix v0/v1/v2 all based on RR v6
I don’t know what’s going on 😮
why is that article dated May 26th 2024? are they time travelling or something? I mean I can see it happening with how Ryan has aged so fast after starting Remix, but damn, took me by surprise
I really really like Ryan and Remix for this.
A lot of people wondered if Remix was selling out when acquired by Shopify.
I would argue this is quite the opposit. Shopify providing the foundation and ability to find the best form of React Router AND Remix.
He let innovation take the lead over brand even though Remix Router would be a cool name too!
So you're not getting sponsored by remix instead of next?
9:25 - finally a based opinion by Theo. Took you time enough but we finally got there. When we get *asynchronous functional components* on the client exclusively, then we are talking. Not everyone can or has any obligation to maintain a Node image - or, heck, wants to serve their UI, through primarily an express-y thing that runs on Node. Plus, not everyone needs or even wants SSR.
Remix became a rapper? In this economy? During the WWIII of rap? Good luck.
For what it's worth, I appreciated the dumb questions; "Its just RSC" didn't do shit for my brain, lol.
Also got one of those dynamite shirts XD
"I'm excited for a future where you can use server components in more dynamic ways, and compose them, and do all the cool things I'm used to doing in NextJS". Can you speak on this? What's so much better about how Next does RSC in your mind?
I don't know what he's thinking of either. Like I said in the chat a few times to all the "can it?" questions: it's RSC, it can do all the RSC things! 😆
What’s happening with shopify hydrogen
Remix just became better than Next just for the ease of use
I'm enjoying Remix right now. In no real rush to go back to Next, but it wouldn't be bad if I had to.
@@incarnateTheGreat I'm all into Remix. NextJs has been changing too much and I hate that.
@@blessdarah1256 that's fair. Sometimes I wonder if the Next crew feel like they have to make changes to keep up with everyone else and use React Canary releases.
I haven't had any issues with Next releases, but Remix promotes a form of simplicity that I can't ignore. Excited for their take on RSC.
I dumped next js for react router v6 for this reason. Glad I can now use it even for projects that require more advanced server side rendering and RSCs etc. SO EXCITING
I agree.
Upgrading from v5 to v6 took 3 months of full-time dev work in a large code base. Honestly I don't trust the react router team.
I feel this deep in my soul.
unless you wanted to use new Data router, that migration would be useless and a waste of time
Currently, I'm using Expo to write my mobile apps (Android and iOS), desktop apps (Mac, Windows, Linux), and my website. :D
I've been using React since 2014, and I've tried every single React framework. Having worked on dozens of React and React Native projects, I can confidently say that Expo will surpass them all in the next two years!
Before or after lunch time?
@@MsVsmaster Why should I use Next.js, Remix, or Gatsby for building websites when I can use React and React Native (Expo) to build everything?
I mentioned two years because, at present, Expo lacks support for all desktop features. However, they are making significant progress in addressing this.
lil bro expo uses react native.
@@darana1142 Anyway, anyone who knows React also knows React Native since they share the same concepts.
ayyyo wtf are these comments
Strange. React Router will be now a framework?
the bulk of a modern framework *is* its router
the core of all frameworks is the router.
@@ivan.jeremic It's quite weird to have a framework called "react router", though.
this is really cool
@theo State of HTML 2023 results analysis please.
The bots are already here? lol
As an AI language model I don't appreciate you calling me a "bot"
Glad I didn’t listen to Theo when choosing Remix our last major project. It’s been great.
Remix bring the ssr/rsc to react natively while next took react to next to do it in their own way
I’m super excited to learn more. Also super pumped to see a community that genuinely seems to be collaborative and cooperative, seeking the best results for everyone.
ppl who use tanstack router are real chads
You’re often wrong, as anyone usually since forecasting is complex (even more when we talk about technologies, it seems).
I ❤💿
This looks like it's a React-ified HTMX.
Aggy dagger on the front end bubble. Unexpected!
@@cuca_dev We've talked about frontend before in aggy daggy.
because RSC are Reactified HTMX. It is the same idea of sending markup of part of app(A.K.A. Component).
Returning markup from the server is not an HTMX thing. That was already the standard pattern and one that any react app that uses SSR is also benefiting from.
0:40 O.O
"As dead as Laravel??" The disrespect. 😂
People, report the bots.
Theo clickbaits and is wrong.. whats new?
Embrace Extend Extinguish
Actually it has been: Embrace ... let the team do whatever they want
@RyanFlorence Yes, you are moving on to step 2 of EEE; Extend, The tweet from Jacob Paris shown at 3:29 describes how EEE works. For what it's worth I won't mourn the extinguishment of RR (React Router) the major version upgrades have been horrible, upgrading a large project to V6 recently required writing some absolutely horrific HOC (Higher Order Components) to aid in backwards compatibility in order to get the migration across the line, stepping stones that other good tools would have provided... And all for what? A functionally identical outcome, just different. Almost all of the software I've written has a lifetime measured in decades so keeping up with this churn is incredibly frustrating. I look forward to seeing what extensions are made for users that will be de facto Remix users when it awakens from a "Nap", we will likely be one such user as a migration away now is prohibitive.
I do sincerely thank you for your contributions to open source
Regards a future Remix user
Says a lot about how seriously we should take what comes out of your mouth. :D
Very seriously because I was so close to 100% accurate? :D
"React almost never had breaking changes." LMFAO. You's crazy.
Name 3.
@@t3dotgg I'm glad I've been using Git for two decades. 0.4.1 caused my app to render to a white screen with no error message due to changes in the way state was handled.
The next time I updated was 0.9.0. They changed the way state was handled again which broke components, as well as components built for production to be squished together different than locally developed versions.
0.14 wouldn't update child components when the parent changed unless you chained state on all of the children that needed it. That means doing wacky crap passing functions as properties to children so they could call it as a callback to pass a function to the parent in order for the parent to call that function to let the child component update it's state.
The next upgrade was 15.0.1 which caused the previously mentioned fix to completely lock up the app and components. This meant keeping most state in a near-top-level component and passing functions down the ladder to allow children to affect state, or, as most people suggested, cloning the element entirely and adding properties to it, but now you have to give all children access to it so it can clone all children to give them access to changing the state if it needed it. Now you have this all-father component and you're using a method from that component to wrap around all child components,.I'm sure that won't be problematic.
16.8 was apocalyptic. Asynchronous functions like the one from the last fix are now broken because the parent component is not guaranteed to be mounted. They also took down most of their documentation surrounding class components, without having real existing documentation about function components and useState was a large mental shift.
It also (oh so quietly) broke state. Where you could previously pass instances of Non-React code as props and store things like websocket connections , you would now have to throw them into the global scope, or as most suggested, initialize them them when you created the react app and along with any elements they needed using document.createElement, attaching them to the dom, and then detaching them later so that they could be referenced later.
Then I get to clone the child elements, along with all properties, reroute events and attributes in order to stop React from doing funny business on the elements themselves.
document.querySelectorAll("#id").appendChild() or whatever.
useRef exists at this moment, but from my memory almost nobody seems to know about it (at that time).
And you know by now how that went. Soon react , and but soon after useRef was better understood.
@@t3dotgg I wrote a long response and hit comment but I'm guessing it vanished. Migrating 0.4 to 0.9, migrating from 0.9 to 15 all handled state differently and broke things. 15 caused dev versions and production versions to look very different. 16.8 broke handling non-react objects very badly and required really annoying hacks in order to stop react from mangling the elements (passing to the react app when it's initialized and passing through the prompts along with attaching them post-render, and redirecting HID events through callbacks and sending events through those callbacks to outside elements, then sometimes needing to rip those elements out before you can update state safely.
The combo of useEffect and useRef was superior nowhere I could find explained it. Along with the release of 16.8 they ripped out all of the documentation they had and it kind of forced most of us to upgrade, which was rough because the documentation was screwed up. Broken links everywhere.
The only way I can imagine you didn't experience this crap is if you started using React in 2018 or so and only on a React-only code-base.
I don't think that is the case though. You just is crazy.
Edit: Still less breaking changes than Angular. Angular 1 was nice to use, Angular 2 broke everything, and Angular 4... I gave up.
I'm full a full stack developer working with small companies, I don't have time for Angular shenanigans.
You are wrong about a lot of things tbh LOL
The first few comments are always kind of stupid. It’s annoying. Contribute to the topic darn it.
can't believe remix is already dead. wtf. i don't want to work in front end anymore, i'm tired boss.
Is this a serious comment or are people just too lazy to read what is really going on? The new ReactRouter will have remix inside so nothing changes or goes away all you do is stop calling it Remix and you just change imports😂 damn people please read before commenting.
???
Bruh, please at least watch the first 2min first
Your also wrong about Laravel being dead! SMH
Another day, another breaking change in react-router. Migration has never not been painful.
React-router considered harmful.
0:38
*_Theo unbuttoning his shirt_*
Me: woah woah woah woah🤣
idk why anyone would use React native when you could just use Capacitor. One code base to rule them all.
you've been wrong about a lot of things lately
Name 3
Bruh why is Laravel dead haha
Early? Damn
Meh, RSC is one thing, but to actually be resumable instead of hydration is even better future tech.
RIP anyone who has production apps on Remix 😅
Bloated package with bad DX. It was good but we have better alternatives now.
good. it was getting confusing with next.js vs remix vs react router. next.js has won on the server and react router has won SPA's, so retiring remix and working on react router completely is a really good decision.
Not needing to specify types is a huge advantage when coding. This type safety nonsense is a fad.
9:47 "If you were around when Hooks happened...."
👴
earlyyyyy
Almost first
First. (Quality comment)
I don't get what's the quality in commenting "First."...
React router may be my least favorite thing in the entire front end ecosystem
If you are looking for an alternative router for react, try react-sprout
I hate react router and it's manual. And also just a router and not a big deal. Video smelling like a PR... Theo you are not like that... please...
You're also fear mongering and snatching views from newbies not expecting from you
0:40 O.O