Panel discussion "Innovation in React"

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.

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?

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.

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. I think that is something, because React has always been include a JavaScript thing, have a babble build system, and you're good. And now it's like you need someone to provision servers for you and then split out server actions from your onclick handlers and deploy them as serverless functions and you're like, what? How? And so that story around how server actions is split out, et cetera, to be more demystified and more accessible. I think this is an accessibility thing as well, and I'd love to see that get better. I do want to say that I think React has gotten more complicated over the years, in a lot of senses. There are a lot of stuff that was added that is really good, but it's also incredibly complicated. As in, like, the curve went from, like, this to, like, this.

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.

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.

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.

I also was thinking about this. So thanks for raising the stability question, I mean topic. I think that the fact that React is stable is actually a huge advantage. For a very long time, React was primarily thought about as a rendering library. And thanks to that, it was very easy for, or like, maybe it inspired the developers to, the React community to innovate. So because of that, because this one part was stable and not movable, because of that, that gave space to innovate somewhere else, right? So for example, state libraries, state management, we had so many different approaches and so many different innovations that came out of the fact that React is stable. So I don't think that the, I don't think it's bad that the framework or library that so many, so much of the internet depends on is not innovating in a, like, crazy speed. I think it's kind of okay. Yeah, I'm going to cite an absolute veteran in the web industry, someone I look up to, his name is Jeremy Keith, you may or may not have heard of him. He has this amazing talk and idea where he presents, like, things on the web evolve in what he calls, and he cites this from a book, I can't remember the name, pace layers. So the more stable something is, the slower the pace of innovation. So HTML as the document format, some will say they don't innovate in HTML anymore. Makes sense. Right. And so as React approaches stability, exactly what you're saying, I think yes, innovation has slowed, but that means stability has increased. It's an inverse relationship. And that's actually quite good, if you think about it. I think we'll see with Astro, you all are iterating rapidly. The thing is that, we'll see where we get when we are on version 18 or 19. The thing is, we all know that software gets more complex when it grows and when it gets bigger. And when you have thousands of users, it's different. You have to think about other things. You have to think about some browsers that you might have to support, all of that stuff. And if you think about React is still innovating, probably. But also, they are still working on their internals, which probably take way more work than us with Astro 4, or with Quick 2, or with Quick 1, whatever. Software is complex, I guess. Yeah. Sorry, go ahead. No, go ahead. I was just going to say, there's, for example, JavaScript type of null and still object. Because people have built stuff on this. You can't break it. That's why innovation has to slow. But also, there's new browser APIs coming. And I know for a fact, React's internals are moving, are innovating to take advantage of those. There's a new thing called Message Channel in the browser, where you can form entangled channels for updates and things. And behind the hood, the scheduler is undergoing a lot of updates. We just don't see it. Because the whole point is to hide that behind great VMs. That's what I mean. You don't want to play around with the compiler all the time or put a thousand settings in your compiler, in your config. You just want to work it out, that it works out of the box. And to support that, and to make sure that it works in every case, is a lot of work. And a lot of internal work. Yeah. When we are talking about tools that most of the internet depends on, we cannot be aspirational about that. The innovation should remind us more of revolution. It should be an evolution, right? Because if you introduce breaking changes, that's going to be... Yeah. I mean, like the community backlash, imagine that, managing all the DMs, even that.

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.

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.

One other quick thought on Tija's thing there. So it's very true that there are a lot of new and exciting technologies coming out all the time. We still hear all the complaints about the JavaScript ecosystem is changing too rapidly. The thing that really frustrates me is when a new technology comes out, and it's not just this is new, it's hot and trendy, you should try this out right now. It's when the discourse turns into Tool X just came out, and now it kills Tool Y, and it's dead, and nobody should be using that anymore. No. The existence of new tools does not invalidate all the existing tools. It does not mean your app is totally obsolete. It's possible that the new tool has some advantages over the existing tools, but it also has unknown trade-offs. We probably haven't found the weaknesses with a new tool yet. So it's always worth having an idea of what new tools, or options, or configuration settings are out there. But you need to look at them and evaluate them and see where they fit in, and see if they even solve a problem that you actually have to deal with at all. Stylex is cool, but Tailwind. I love Tailwind. Oh, no, no, no. We don't want to start a war here. Tejas. But they give me the colors. I don't have to think about the colors. Okay. Let's move on. Let's move on. Yes. I wanted to say something, but I forgot, because you mentioned Tailwind, and I was like... You're ready to go. Yes. Okay. I want to talk a little bit about meta-frameworks. My question is genuinely, it's not are they bad or good, but more like, what do you think they bring to the table? As in, how do you think they innovate and help shape React? Well... I use Next. Should we all start? Hi, I'm Stylex. Hi, I'm Sylwia, and I use Next. And then everyone responds, hi, Sylwia. So, when I was thinking about meta-frameworks, I actually thought about that talk that Sebastian Mark Bauge, or Mark Beige for the Westerners around us, he gave this talk in 2015. It's a... I took a note. She has notes. So, I asked him as a second-class citizen, and he said, React is a tool for building your toolbox. It's not your job to come up with clever hacks to compose two wrong abstractions. Your job is to compose the right abstractions for the right job. And so, I feel like when I was thinking about the meta-frameworks, I thought that okay, so there are those React parents who are observing us, you know, trying to do something with React, and we are constantly building wrong abstractions after wrong abstractions, and now they are like, okay, you don't know how to use this toy.

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.

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.

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.

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.

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.

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.

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.