I prefer the metaphor about the framework getting a new home in upstate New York, at a farm, behind a red barn. And that shotgun-sounding noise was the welcome confetti for Remix when it got inducted into its new home.
@@blazer511 can you define "follow"? Do you mean people blindly follow him, by subscribing to his channel? Or, do you mean people follow him, by accepting his (sponsored, nearly always) takes, as if they are generally applicable and trustworthy advice?
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
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.
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
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
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 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.
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 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!
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'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
What's dispiriting for a lot of React users is that the churn in the tools and infrastructure doesn't seem to be stabilizing. After 10 years there's still a "revolution" every year and I'm sure everything I do today will have to be completely rewritten when the next paradigm shift happens next year😥
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.
@@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.
@@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
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
RSC is Expensive in $$$$ server cost. Its an important technology to have, but now you need to manage a server to keep your app running. No more just having a CDN for your files and an API for the backend. Serverless cost for an RSC application can quickly for exponential in the thousands with just 5k of traffic if not optimized just right
I've debunked this a billion times but I'll do it here quick because you're a checkmark tl;dr - if your requests require authentication, your only options are deduping through Relay (GraphQL) or RSCs, otherwise you're reauthing dozens of times per page request. If I load a page in a React SPA, and there are 6 components requiring personalized data, it's very likely all 6 make their own requests. If each one requires the request to be authenticated, that's 6x more network requests, auth checks, DB queries, etc. If the server renders the page, it has the "massive" cost of running JS for a few ms. But it exponentially decreases the number of requests going to the server per page load, which has obvious benefits to the server bill. The only way RSC is "$$$$" compared to SPA is if your data never changes. Which means you're not shipping real software. 🫡
"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! 😆
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.
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.
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.
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
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.
![Lethal Company Music Video 🎵 "Follow The Orders" [VERSION A]](http://i.ytimg.com/vi/QeooZB4Z7RA/mqdefault.jpg)
Remix is dead, long live Remix!
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
I prefer the metaphor about the framework getting a new home in upstate New York, at a farm, behind a red barn. And that shotgun-sounding noise was the welcome confetti for Remix when it got inducted into its new home.
@@blazer511 can you define "follow"?
Do you mean people blindly follow him, by subscribing to his channel?
Or, do you mean people follow him, by accepting his (sponsored, nearly always) takes, as if they are generally applicable and trustworthy advice?
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
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.
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
haha good points
I'm a long time Remix advocate. Really excited for the future of Remix and RR...
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
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.
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 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.
One of your best video Theo, keep up the good work!
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" 🙂
This reminds me of when Rails and Merb merged in 2008! Yahuda Katz has a great post on how that all went
Thanks for the commentary! Excited.
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!
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.
Holy crap, the calibre of developers on that sream! I feel a bit starstruck!
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.
Like you being wrong 90% of the time?
ayyyo wtf are these comments
I felt the vibe, full of adventure
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
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?
What's dispiriting for a lot of React users is that the churn in the tools and infrastructure doesn't seem to be stabilizing. After 10 years there's still a "revolution" every year and I'm sure everything I do today will have to be completely rewritten when the next paradigm shift happens next year😥
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.
Remix became a rapper? In this economy? During the WWIII of rap? Good luck.
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
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.
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
RSC is Expensive in $$$$ server cost. Its an important technology to have, but now you need to manage a server to keep your app running. No more just having a CDN for your files and an API for the backend. Serverless cost for an RSC application can quickly for exponential in the thousands with just 5k of traffic if not optimized just right
I've debunked this a billion times but I'll do it here quick because you're a checkmark
tl;dr - if your requests require authentication, your only options are deduping through Relay (GraphQL) or RSCs, otherwise you're reauthing dozens of times per page request.
If I load a page in a React SPA, and there are 6 components requiring personalized data, it's very likely all 6 make their own requests. If each one requires the request to be authenticated, that's 6x more network requests, auth checks, DB queries, etc.
If the server renders the page, it has the "massive" cost of running JS for a few ms. But it exponentially decreases the number of requests going to the server per page load, which has obvious benefits to the server bill.
The only way RSC is "$$$$" compared to SPA is if your data never changes. Which means you're not shipping real software. 🫡
I don’t know what’s going on 😮
3:09 Remix wasn't aligned to React Router versions :) Remix v0/v1/v2 all based on RR v6
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
I fail to see how a browser based solidity editor fits into react, but I can’t keep up with all the tech anymore
The bots are already here? lol
As an AI language model I don't appreciate you calling me a "bot"
"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! 😆
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.
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
Every company I've worked has needed to upgrade react-router. It's VERY hard to keep it up to date.
What would be a good place to start learning about RSC?
Depends on where you are with your dev journey. If you already know react just stick to the docs and youtube videos
Glad I didn’t listen to Theo when choosing Remix our last major project. It’s been great.
You’re often wrong, as anyone usually since forecasting is complex (even more when we talk about technologies, it seems).
The first few comments are always kind of stupid. It’s annoying. Contribute to the topic darn it.
I am so curious to know how React Router v7 and Tanstack Router differ now.
Can anybody tell me how React router and Remix is related? I am confused
i am so confused. what is the difference between remix and this react-router?
Amazing video :D ty
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.
So you're not getting sponsored by remix instead of next?
Did the previous version of React router also eat some other new and shiny router?
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
@theo State of HTML 2023 results analysis please.
did you just fire shots on Taylor Otwell??? :D
Your also wrong about Laravel being dead! SMH
Also got one of those dynamite shirts XD
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
theo why are your videos so dark.
What’s happening with shopify hydrogen
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.
I ❤💿
Remix bring the ssr/rsc to react natively while next took react to next to do it in their own way
ppl who use tanstack router are real chads
call it Remiouter Xeact
Another day, another breaking change in react-router. Migration has never not been painful.
React-router considered harmful.
For me i think RSC is like AI - Not ready. I'll wait a year or 2 to rewrite. Still on next version 12 😅
you've been wrong about a lot of things lately
Name 3
Meh, RSC is one thing, but to actually be resumable instead of hydration is even better future tech.
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.
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
idk why anyone would use React native when you could just use Capacitor. One code base to rule them all.
"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.
"As dead as Laravel??" The disrespect. 😂
this is really cool
People, report the bots.
0:40 O.O
0:38
*_Theo unbuttoning his shirt_*
Me: woah woah woah woah🤣
You are wrong about a lot of things tbh LOL
Bloated package with bad DX. It was good but we have better alternatives now.
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...."
👴
RIP anyone who has production apps on Remix 😅
Bruh why is Laravel dead haha
Early? Damn
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
First. (Quality comment)
I don't get what's the quality in commenting "First."...
Almost first
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...
earlyyyyy
You're also fear mongering and snatching views from newbies not expecting from you
0:40 O.O