Panel discussion "Innovation in React"

Rate this content
Bookmark
32 min
08 Dec, 2023

AI Generated Video Summary

The Talk discussed various topics related to React, including the wishlist for future versions, the importance of accessibility, reducing bundle size, and improving deployment. It also explored React's innovation, stability, and the role of meta-frameworks. The challenges of contributing to React's open source project were highlighted, along with the need for a more community-driven approach. The Talk concluded with a lunch break announcement.

1. Introduction and React Wishlist

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

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.

5. React's Innovation and Vision

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

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.

9. React Community and Evaluating Hype

Short description:

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

Short description:

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.

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.

11. Meta-Frameworks and Innovation

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

JSNation Live 2021JSNation Live 2021
27 min
Building Brain-controlled Interfaces in JavaScript
Neurotechnology is the use of technological tools to understand more about the brain and enable a direct connection with the nervous system. Research in this space is not new, however, its accessibility to JavaScript developers is.Over the past few years, brain sensors have become available to the public, with tooling that makes it possible for web developers to experiment building brain-controlled interfaces.As this technology is evolving and unlocking new opportunities, let's look into one of the latest devices available, how it works, the possibilities it opens up, and how to get started building your first mind-controlled app using JavaScript.
ML conf EU 2020ML conf EU 2020
41 min
TensorFlow.js 101: ML in the Browser and Beyond
Discover how to embrace machine learning in JavaScript using TensorFlow.js in the browser and beyond in this speedy talk. Get inspired through a whole bunch of creative prototypes that push the boundaries of what is possible in the modern web browser (things have come a long way) and then take your own first steps with machine learning in minutes. By the end of the talk everyone will understand how to recognize an object of their choice which could then be used in any creative way you can imagine. Familiarity with JavaScript is assumed, but no background in machine learning is required. Come take your first steps with TensorFlow.js!
JSNation 2022JSNation 2022
21 min
Crafting the Impossible: X86 Virtualization in the Browser with WebAssembly
WebAssembly is a browser feature designed to bring predictable high performance to web applications, but its capabilities are often misunderstood.
This talk will explore how WebAssembly is different from JavaScript, from the point of view of both the developer and the browser engine, with a particular focus on the V8/Chrome implementation.
WebVM is our solution to efficiently run unmodified x86 binaries in the browser and showcases what can be done with WebAssembly today. A high level overview of the project components, including the JIT engine, the Linux emulation layer and the storage backend will be discussed, followed by live demos.
JSNation 2022JSNation 2022
22 min
Makepad - Leveraging Rust + Wasm + WebGL to Build Amazing Cross-platform Applications
In this talk I will show Makepad, a new UI stack that uses Rust, Wasm, and WebGL. Unlike other UI stacks, which use a hybrid approach, all rendering in Makepad takes place on the GPU. This allows for highly polished and visually impressive applications that have not been possible on the web so far. Because Makepad uses Rust, applications run both natively and on the Web via wasm. Makepad applications can be very small, on the order of just a few hundred kilobytes for wasm, to a few megabytes with native. Our goal is to develop Makepad into the UI stack of choice for lightweight and performant cross-platform applications. We intend to ship with our own design application and IDE.
JSNation 2022JSNation 2022
22 min
How I've been Using JavaScript to Automate my House
Software Programming is naturally fun but making something physical, to interact with the world that you live in, is like magic. Is even funnier when you can reuse your knowledge and JavaScript to do it. This talk will present real use cases of automating a house using JavaScript, Instead of using C++ as usual, and Espruino as dev tools and Microcontrollers such as Arduino, ESP8266, RaspberryPI, and NodeRed to control lights, doors, lockers, and much more.
JSNation 2022JSNation 2022
23 min
WebHID API: Control Everything via USB
Operational System allows controlling different devices using Human Interface Device protocol for a long time. With WebHID API you can do the same right from the browser. Let’s talk about the protocol features and limitations. We’ll try to connect some devices to the laptop and control them with JavaScript.