1. Introduction and React Wishlist
We have a bunch of people in the panel. I want to start with asking, what would you like to see from React in future versions? I would like to see some level of support for accessibility.
We have a bunch of people in the panel, so I first want to call in Tejas, who does not literally need an introduction, because he has already been introductioned. He's been introductioned, my man. Then, I want to welcome Elan. The alien. I tried so hard. Woo! Alien! His name is Alien. And your name is Tejas. Tejas. Yes. Okay, and Miguel. Miguel. See, if the name's Spanish, I can say it. Sylvia, please. Sylvia Vargas. Which also sounds Spanish, but it's not. And Mark Eriksson, please. Yes, Mark. Mark, we do not have one here. You don't have one? Already do. You're sitting on it, dear. No. You do have. Hi. Okay. So, if anybody wants some water, please.
Okay. So, how is everyone doing today? So good. Good. Okay. How many hours collectively have we slept? Three. Two. Like, four, I think. Are you going to be like, eight, and just ruin the whole thing for everyone? Let's say six. Okay. Seven-ish. Jealous. Okay, cool. It keeps going up, which is interesting. Except Miguel. He kind of ruined it. Oh, sorry.
Okay, so, I want to start with asking, what would you like to see from React in future versions, which I feel like is the overarching question of all of this, right? So, who wants to go first? Oh, Christmas. So, it's like a Christmas wish list, huh? Yes. Okay, great. So, if I were writing my letter to Santa today, I would say that I would really like to see is going to be unpopular opinion. So, let's just start with a hot take immediately. So, that he forget about it, because then everyone else goes. And actually, it is a thing that most probably people will forget about. I would like to see some level of support for accessibility. I know that generally this is something that always is overshadowed by performance conversations or whatever, CSS conversations.
2. React and Accessibility
I would really like to see React or Metaframeworks or the community encouraging, or even why just encouraging, forcing developers to care about accessibility. Because it's kind of, like, shameful that we are in 2023 and we still don't care about that. I agree very much with accessibility. I think it still has a problem there. But I do believe that it will improve in the future.
I would really like to see React or Metaframeworks or the community encouraging, or even why just encouraging, forcing developers to care about accessibility. Because it's kind of, like, shameful that we are in 2023 and we still don't care about that. Hot takes. I don't think that's... It's sad that that's a hot take. Does that make sense?
Yes. I was actually also going to give a hot take. Stable features. Oh, my gosh. You say stable? Stable features. I cannot do that. I know. That's the whole problem, right? But yeah. There is a couple of things. And exactly. I agree very much with accessibility. I think it still has a problem there. But I do believe that it will improve in the future. And if they don't do it, then you all should do it. Because it's open source. But also, Elian, you missed an opportunity to do a humble brag. Because Astro has just shipped wonderful accessibility DevTools. So a huge round of applause for Astro. Thank you. Yes. But I was going to disclose that in my talk later today. So yeah. I guess you should still come. I still have other features shipped as well. So yeah. Does anyone else want to go take a shot at it?
3. React Wishlist and Future Plans
The React context API has a weakness where any component that reads from a context will re-render when it's updated, even if they only care about part of the value. There have been proposals for a context selectors API, but it has not been implemented. I would like to see a focus on reducing bundle size and removing deprecated features. There are indications of the React team working on React 19 and removing some deprecated features. It would be important for React to have full compatibility with custom elements. In the short term, the Forget compiler could solve discourse around signals. In the longer term, I would like to see improvements in server components and easier deployment.
So the current weakness of the React context API is that any component that reads from a context will re-render when it's updated. Even if they only care about part of the value. And that's inherent in how the context API works. There's been proposals for a context selectors API floating around for years. There's even a proof of concept PR that Andrew Clark built back in, like, 2020 or so. But it's sitting there, unused. There's no indication when they might actually try to finish and build and ship this feature.
The ironic thing is that if they actually ship this, it would remove one of the arguments in favor of Redux at this point. Because Redux allows you to select just the data that you need. But it would still be a really, really useful feature to have. And it's kind of annoying me that they never got around to actually building this.
I'd like to see a focus on bundle size. Because the problem with React is that it's like the biggest framework library in the frontend web development. And it seems that it's lacking focus on removing features. Deprecated features. Like, I don't know, we have the default props and so on, that are adding some size to our bundles that we hope to remove. I'd like to see this kind of focus in order to improve the performance of our websites.
Wait, is React bigger than Angular? Well, it's... In terms of community, yes. And ecosystem. Yeah. Y'all know what I meant. I have heard some early indications that the React team is actually starting to use the phrase React 19. Now there's no indication when that will actually ship. But it does look like they are actually working to remove some deprecated features when React 19 happens. Like, I think string refs are finally gonna go away. There are a few other... I've seen a few other bits and pieces of discussions of, like, this very old deprecated feature will be removed in 19. So a little bit of that. But I honestly don't know how much of an effect it will have on bundle size.
Another one that I think is super important, even though I'm not a big fan of web components, but I think it's super important that React allows full compatibility to custom elements. I'm not a fan, but anyhow, we need this kind of support in order to provide this functionality to the community. I also think that it's, like, a loose end that we should just fix. Yes. Everyone is always like, oh, but you don't support webcomps. Just fix that. Not fully support. I mean, without problems. Yeah, there are a lot of problems. Without corner cases, yeah. And then you're just like, just do the thing. Like, then no one has anything to, like, point at. I was going to say, I don't want to plug anything, but there is a solution and it's called Astro. What is your talk about today? Astro? It's all you can say is like Groot from the Marvel movies. Yeah, they pay my bonuses on how much I say the word Astro. What I'd like to see added to React, I think in the short term, I say short term because Meta's already using it, which is the Forget compiler. I think that would immediately solve the discourse around, like, signals, no signals. Like, everything's fine grained if it can work in production. But I think longer term, you know, my talk about server components earlier, somebody was asking what are the limitations to deploying RSE? Server actions is something that you just have to trust the framework around. And what I'd love to see in React is education, even demos about, or even better, the story of deploying it yourself becoming much more simpler.
4. React Deployment and Complexity
I'd love to see React focus on simplifying the deployment process and making it more accessible. React has become more complicated over the years, with many new features added. It would be great to see a more streamlined and less complex development experience.
5. React's Innovation and Vision
The React team has had a specific vision for years around suspense. They convinced Vercel to buy into their vision. React came up with the concepts of suspense, streaming, and transitions. Other frameworks are pursuing different ideas, but there is cross-pollination.
So, yes. The next question that I would like to ask is how do you feel like React is innovating in relation to other frameworks that exist? No name dropping, though. That is illegal. As in, like, the police will come. Mark? Do you have thoughts, opinions? So the React team has had a very specific vision for a number of years now around the entire concept of suspense. There's been the arguments back and forth about, like, is Vercel driving React these days? It's sort of the other way around. Like, the React team, and really, Sebastian in particular, has apparently had this idea of how they think they want apps to be built for years now, and they basically went over and convinced Vercel, here's what we want to do it, do you buy into our vision or not? So, like, I still very much struggle to try to wrap my head around all the implications of, you know, suspense and streaming and transitions. I just haven't had enough reason to use them in practice myself. But it does seem to be a set of concepts that the React team came up with first, and they have this vision of where they want to end up and are pursuing it and building it out, Other frameworks are pursuing different ideas, and it is interesting to see the divergence, but also, like, the cross-pollination as those ideas go back and forth between different frameworks.
6. React's Innovation and Developer Experience
React is innovating towards find green reactivity and focusing on being a developer experience tool. They aim to solve implementation details like use memo and use callback for the ideal developer experience. The innovation is obfuscating more stuff behind the forget compiler, providing convenience. Other frameworks like Solid, Quick, and Astro offer lower-level options like signals.
Yeah. Yeah. I think this is a really interesting topic, because 2023 has been riddled with signals and find green activity. Attila is sitting right over there. He does a great talk showing this curve of how Ryan Carniato basically just got everybody to use signals, which for those who aren't familiar, signals is a reactive primitive that updates just the value in place versus React is not reactive, because instead of updating a value in place, you call recursive functions throughout your application. And the React team, I remember, there was a comment saying we're not excited about signals, we don't think it's ideal. And this led to a whole bunch of divisions. So I think React is innovating toward find green reactivity, but I heard their argument first-hand from the team, which I think a lot of people have not, which is it's not that they're saying signals is bad, but it's more the vision for React is to be a developer experience tool above and beyond just a library, and as part of the ideal developer experience, you don't think about the implementation detail of use memo or use callback or create signal. And these are implementation details that ideally the library just solves for you. And that is the end to which React is innovating today, is like you just write your app, you set state, and then just trust that this is going to happen as fast as possible. And that's the work with forget. So the innovation is obfuscating more stuff, including signals, use memo, use callback, all of that goes hidden behind the forget compiler versus adding support for signals and runes, which the React team believes is an implementation detail. So in terms of direction of innovation, React is hiding more stuff to give you more convenience versus solid, quick, astro are giving you signals, like, hey, here's some lower level stuff that you can use.
7. React's Stability and Focus
React is stable and right now they are focusing on something different than being innovative.
I'm feeling, I'm going to be brutal honest, I'm feeling that React is not innovating anything. But I mean, it's not a bad thing. Sometimes it's like we have to innovate, do more and new things. My feeling is that lately from React components that that's an idea from three years ago, two years ago, and still it's not everyone is comfortable with the idea. And my feeling is that it's OK. I mean, it's stable. It's something that people are using in their apps and they need this kind of stability. And that's why another framework like Quick, which is great, they could try to innovate more because they don't have this kind of pain that they have to support. Even the idea of server actions that we could say that it's something innovative, but we could think that Remix had something similar and they are grabbing the idea. And even so, it's more something that you need a framework to do it. So I'm not going to say that it's a bad thing, but I'm going to say that React is stable and right now they are focusing on something different than being innovative.
8. React's Stability and Innovation
React's stability is a huge advantage that has inspired innovation in other areas. As React approaches stability, innovation may slow down, but stability increases. Software complexity grows with user numbers and browser support considerations. React is still innovating internally and taking advantage of new browser APIs. The focus is on providing an out-of-the-box working experience without the need for extensive configuration. Breaking changes can lead to community backlash and management challenges.
9. React Community and Evaluating Hype
Not to mention that most of the internet will stop working. React breaks. A lot of the internet breaks. But if WordPress breaks, then all of the internet breaks. We need to get better as a community. Server components may be hyped, but it's important to evaluate if they truly add value. As we get older, we prioritize things that just work. It's not about rejecting progress, but about being more discerning.
Not to mention that most of the internet will stop working. Right? So... Yes. React breaks. A lot of the internet breaks. But if WordPress breaks, then all of the internet breaks. Exactly. Which is what I wish we would sort of do better as a community. Is when something new comes up, there's so much hype. Server components. Everybody has to go use it right now. Because it's sexy. And I want to tell you something. I've actually never used server components. Good! Great! I've tried it. I was like... No. Good. And that's how... I think you talked about revolution. Sorry. Evolution, not revolution. We can't be like... There's new things. We have to use it. You know? And I think that is... To go back to the first question, I think we need to get better at that as a community. Because now the discourse... I'm sure many of you here are feeling like... Server components is hot. I need to use it. You maybe don't. Because it's evolution. I genuinely believe that as you get older as a human being... I'm not even kidding. You start being like... I just wanted to work, you know? Exactly. Like... What fuck is that? Like... It's not that you don't want things to be faster. You don't want things to be better. But I think that kind of thing dies out a little bit. And you're just like... This looks cool. But like... That's it. I hope this makes any sense to any people here. Over 30. Any people who are over 30. Yeah.
10. New Technologies and Meta-Frameworks
There are a lot of new and exciting technologies coming out all the time, but the existence of new tools does not invalidate all the existing tools. It's worth evaluating new tools and seeing if they solve a problem you actually have. Stylex and Tailwind are both great options. Now, let's talk about meta-frameworks and how they help shape React. React is a tool for building your toolbox, and it's important to compose the right abstractions for the right job.
For the other people? Yes. And do you wake up and your back hurts? That's the question. Do you choose to stay in pajamas all day because you like comfort? That's the target audience. I wear shorts during the day, even if it's like 5 degrees. Because I'm like... I refuse to do pants inside the house. Nothing will cover the... No. COVID has ruined me in other ways.
11. Meta-Frameworks and Innovation
Meta-frameworks are great if they fit your use case, but struggle when you want to do something out of the box. They leave some questions unanswered, like mobile-first apps and single-page applications. This presents an opportunity for innovation and the development of new meta-frameworks.
I'm taking it back from... I'm taking it away from you. Now, you can only play with this toy if you are using a meta-framework. So this is how it appears to me. So, I feel like meta-frameworks are great when... I know that the question is not good or bad, but... That's fine. Yeah, like, they are great if they fit your use case, and they do that job really great, right? Really well. And typically, they are not entirely happy if you are... If you want to do something out of the box. Of course, you can. But, okay, you're going to struggle, and then maybe later on, there's going to be a new version, and you're going to have to, you know, re-hack your hack, and so on and so forth. So we all know that kind of story. But one thing that maybe is, let's say, an opportunity for innovation is that currently, meta-frameworks are, you know, leaving some questions outside of the discussion. Like, for example, mobile-first apps, right? Or mobile apps. There isn't really a great solution for that, or single-page applications. So, maybe I can say that it is the meta-frameworks that are currently, you know, on the market are maybe hindering innovation, but I want to think, in these areas, but I want to think that it is actually just an opportunity for any of you to come up with your new, shiny meta-framework that will tackle those questions.
12. Metaframeworks and React as a Library
Using meta-frameworks provides convenience and drives developer experience. They give you everything out of the box, but sometimes you want more control. The term 'metaframework' is disliked by some, as React is seen as a library and Next.js as a framework. GlueStack is a framework bridging the gap between web and native apps. React is a library that is missing some features found in other frameworks, but it allows for flexibility and evolution outside the library.
One thing I will say is that what it does for me, like, using meta-frameworks, it gives you everything that you need to just start quickly on something. And I do believe that they drive a lot of developer experience. They give you a lot of the tools so you don't have to repeat. Like React Router, who does that anymore? You just use Next. Wow. It's true, though. Sorry, sorry. No, no, no. It's true. It's true, right? It gives you everything out of the box. You can't do anything by yourself, but it will take you so much time, and if you didn't just do NPM install or whatever, just use Next. Just use Next, whatever. Astro.
But the other side of that is, the tradeoff is convenience or control. They give you a lot of convenience, but sometimes you want to do something with a little bit more control and you can't. And then you write hacks on hacks on hacks. So I think that's the real discussion, is how much control do I need? And ideally you assess this with your team before, and then you make that decision.
I have an issue. This is going to make me look really bad. But like metaframe, I don't like the term metaframework. Because it's a framework about a framework, but that posits that React is a framework, but it's a library. Don't hate me. We can discuss it after. I'm not gonna get into that now. I sort of feel inclined to die on the hill that React is a library. Next.js is a framework. And so a metaframework could be a framework on top of Next.js. Anyway, one final thing. You mentioned that native apps are left out of the store, mobile apps. And I think that's an excellent point. And I just want to mention that there's a framework, a metaframework, that's a framework, called GlueStack, that is doing this thing. It's basically Next.js, but also with a React native output. So it's web and native, and it's bridging that exact gap you mentioned. So I wanted to make everyone aware that that's a thing. But I have to say that I agree with your point. I don't know why it's a hot take. React is a library, because the vast majority... Learn. Because the vast... Of course, it's a library that is getting more complicated over the time. But the reality is that if you want to create like the 95% of the applications or websites that are on the internet, you need a router, you need a server. And from scratch, React is missing that. It's not like the same in other frameworks. That's what I mean. So for me, it's not like metaframework. I don't like the word as well. And I think that that's the point of React. It's the good thing that it's a library. That it allows you to evolve outside the library, like making it the foundation for whatever you want. You could create Astro and make it Astro framework agnostic or library agnostic, but use React for creating the components inside.
13. React as a Foundation
React is a great foundation, but for creating a good website or application, most of the time you would need to use frameworks like Next.js, Remix, or Astro. The React docs acknowledge that React can be both a library and a framework, depending on how it's used.
Foundation is actually a really good name for something like that. Yeah. I think it's that. React, it's a great foundation. And maybe there's some small use case to create a back office or maybe a demo. But the reality is that if you want to create a good website or application, in the 90% of the cases, you are going to go to Next.js, Remix, Astro, or some framework that is going to give you what you need to create a real product. Correct. This is the first time in my life that I feel like a well actually. No. There was this discussion when we were writing the React docs. We had this discussion about how to approach this question. And actually, in the React docs, there's a page that says, well, it's both. It depends on how you use it. No, but really. It depends.
14. React and Other Framework Features
Client directive from Astro and the first syntax from Angular 17 are both great and awesome. I hope they come to React soon. We need a middle ground where signals can be hidden but also accessible if desired.
Anyway, we can move on from the library or framework into the question of the innovation. Hit us. Sarah. Oh, God. Everyone is staring at me. Are there any interesting features that you've seen in other... In frameworks? Yes. Okay. Other frameworks. I'll just make everyone happy. Okay. Other frameworks, other meta frameworks, whatever that you think would be really good in React. And think that we have two minutes and 30 seconds. And it's ticking down. Please. Client directive from Astro. The first syntax from Angular 17. Both of them are great, are awesome. I hope that they come to React soon. Yes. Agree. And also, I get the point that we don't want to mess up the DX and we want to hide signals as a primitive that's lower level. Just give me signals and let me make that decision. Yeah. I think there has to be a middle ground of like you can hide it, but if I want to touch it, let me touch it. Give it to me. I want to reach it. I want to touch it. Right.
15. React as an Ecosystem and Community
I would like to see React become more independent and community-driven, like the Ember community. They have a well-written RFC system that allows for iterative processes and discussions on feature development.
So, now I'm referring to React as an ecosystem and community. I like that view, for example, is independent and also very much community driven. Nice. Wow. I would like to see that in React more. That is fair, yeah. It's not actually a feature, but I've always appreciated the way that the Ember community manages changes to their frameworks and tools and packages with a very well written RFC system where there's actual discussion about how they want to work on the features and then they manage to do things in like kind of a very iterative process. I've always generally thought that's a great way to manage things.
16. React's Open Source Contribution Challenges
The React team treats their RFCs as a we've tried this internally for the last ten months. I think React itself as an open source project is kind of open source, but what does that even mean? I can't read the source. And I think that is my big ask, is like if we can get the code to a point where I'm comfortable opening a pull request, that would be revolutionary. Giving a real code contribution to the React code base is almost impossible, because React's code base is extremely complex. The React team has a very specific vision of the features they want to build, and if the thing you're wanting to PR doesn't directly relate to that, then it's just kind of going to get ignored. It's possible, just not likely. There has to be a whole conversation about it, and be like, does this make sense? You can't just go there and fix a bug. I mean, that's how it should look always. There should be a conversation instead of just going and fixing things, no? Well, I don't think that I can just go cowboy style on the Vue one, but I can probably look at issues and be like, I'm gonna cry a little bit, and I might fix this. Okay. Fair point. Fair point. Okay, cool.
The React team treats their RFCs as a we've tried this internally for the last ten months. This is our design. You get a chance to comment why you don't like the name and then we will ignore that. Yeah. And to add to that, I think React itself as an open source project is kind of open source, but what does that even mean? I can't read the source. And I think that is my big ask, is like if we can get the code to a point where I'm comfortable opening a pull request, that would be revolutionary.
I think that like right now, I think there are two types of open source projects. I think you have like open source projects and you have corporate open source projects. And I think Vue is an actual open source project, for example. And I think React is not. I don't know if that's like a hot take. I'll be here all day but like I will not contribute to React. You can't. Not to underestimate your skill. No, I also can't. Fuck all the stupid... Is it because I'm a girl? Exactly. I'm cancelled. Thank you. It's been nice.
I will absolutely agree that giving a real code contribution to the React code base is almost impossible, because React's code base is extremely complex. The React team has a very specific vision of the features they want to build, and if the thing you're wanting to PR doesn't directly relate to that, then it's just kind of going to get ignored. The one caveat, counterexample though. So I work on Redux Toolkit and my RTK co-maintainer, Lens Weber, also works on Apollo, and he had a conversation with one of the React team members, Josh Story recently, where he complained that there's a next specific feature that really ought to be in the React core to support streaming data. Josh encouraged him, go file a PR that builds the new built-in React hooks that you think ought to be in the React core. He was able to put together an early proof of concept PR. I don't know if he's actually filed it yet, but he's got the hooks working. Who knows if or when they'll actually be merged. But he actually got encouraged, really really contribute this, because it needs to be built in. So it's possible, just not likely.
Yeah, but that's a whole conversation. Yeah. Does that make sense? Okay, let me explain. That's a whole, there has to be a whole conversation about it, and be like, does this make sense? You can't just go there and fix a bug. I mean, that's how it should look always. There should be a conversation instead of just going and fixing things, no? You should talk to the organ, like, no? I mean, I think that we have enough of the cowboy kind of attitude to developing software. I like when people communicate. That's cool. Okay. No, no, no. You're right. What I meant like, okay. English is not my primary language. Are you making fun of my English? Okay. Yeah, but what I meant is like, this has to be a very big conversation about a big feature and stuff like that. Well, I don't think that I can just go cowboy style on the Vue one, but I can probably look at issues and be like, I'm gonna cry a little bit, and I might fix this. Okay. Fair point. Fair point. Okay, cool.
17. Closing Remarks and Lunch Break
We are literally blinking out of time. We have food now, so please check your numbers again. We will be back in one hour at 1350. Thank you all for being here. Have a great lunch. Take care.
We are literally blinking out of time. So we have a, we have food now, so I hope you're all excited for food. Please check your numbers again, and we'll be back. I think it's in one hour. Is it in one hour? Can someone please just let me know? Yes. Okay. At 1350, we will be back, and yeah.
Have a great lunch, and thank you all for being here. Thank you, Sarah. Thank you. Take care. Take care.