Panel Discussion: Write Once, Render Anywhere

So, as Nathaniel introduced me, I'm Taz Singh, and a little bit about me, I've been writing JavaScript for 25 years now. Wow, that's a long, long, long time. Back then I was trying to make a video game, and I thought JavaScript was just scripting in Java to make a video game, and so you'd imagine my surprise when I couldn't even do that. Well, it turns out today you can, right?

Many years later, I was at JSConf US 2013 watching React get announced for the first time, and we actually booed them all off stage. Can you believe the garbage they were showing back then? I mean, mixing your HTML with your JavaScript, what were they even thinking, right? It's insane. Well, to my surprise, I tried it out and I was sold. I came back a year later and they were there as well and I loved it, and since then I've been a React developer.

But still, you couldn't build a mobile app. So I came back again and many years later they released React Native, I could finally build a mobile app with JavaScript and React, which was super cool, but then how do I get that to work on the web? Right? Crazy. I spent a lot of time working on React Native web open source, optimizing the Twitter feed from an open source context, that's all built using React Native on the web, fun fact, much if you knew that. So today I'm so happy to be here up on stage with some of these lovely individuals.

Can I introduce Nicola Corti from the React core team, Jorge from the React team as well at Meta and Swan from Linx at ByteDance. I got my notes here. Awesome. Well, it's my pleasure to be up on stage with all of you today.

So my very first question here, it's actually for Swan. Swan, how dare you? How dare you work on the React core team as well? Do all this amazing work, do all this stuff that I love and I've been using for so long, and how dare you go work on something as good as Linx now? Have you heard of JavaScript fatigue? I'm going to have to rewrite my whole app now?

I mean, this whole thing, 25 years, I've got to rewrite everything. How dare you, Swan? Yeah, that's fine. Are you sure? Yeah, yeah. If you want, I can hold him down, we can beat him up. No, no, no, we love Linx. You love Linx? Yeah. It's okay? Yeah. You sure? Uh-huh. All right, cool. I have the same hoodie, by the way. And where's the hoodie from? I think this is from, I got it from Eli. I was not there at the event where this t-shirt was given, but... Did you also get yours from Eli? Yeah.

But tell me more about Linx. Tell me more about your experience from working on React to now building Linx. Can you tell me about that journey? Well, that's a long story, but I'm going to tell the on-toe story. Before I joined Invitus, Linx exists, but it doesn't use React. And now it's used React. So in a sense, I'm actually spreading React to more cross-platform technologies. Nice.

Okay, okay. I think you got out of that one. Well done, well done, Xuan. But I mean, legitimately, it looks so nice, and it looks so good, and congratulations for everything you've built. If you haven't seen it, for those of you watching on the video, definitely check out their talk on Linx UI. It's deeply, deeply impressive, and I'm saying that as someone that loves React Native. And so it was deeply, deeply, deeply impressive. So congratulations. Thank you.

But yeah, talking more about React Native, I guess tell me a bit more about yourselves. Yeah, so I've been joining the team, I think, five years ago. I don't know, for those of you who know React Native, probably you heard about the new architecture. And that's the first project I worked on. It was funny because basically when I joined the team, I had no idea about React, I had no idea about React Native. I was an engineering engineer, and they told me, like, yeah, the team has been working on this thing called the new architecture, and we would love you to roll it out to open source.

And I was like, okay, this sounds fun. And then I started looking into it. And then after one month, I was like, this is going to be a tragedy. So, like, I mean, at Meta we have this culture of, you know, building fast. And then eventually, like, the React team really wants to ship things to open source. And sometimes, because of how complex is our code base, getting things open source ready is not that easy.

So, yeah, basically my career at Meta has been, like, 90% defined on shipping the new architecture. But the great thing is that actually we shipped it. Now, it's the only architecture for React Native since React Native 82. We heard a lot of stories from, like, Shopify, and Coinbase, and a lot of other big companies using it in production and getting a lot of performance improvements. So, yeah, that's my journey at Meta, I would say. How about you, Jorge?

Yeah. I joined Meta about four years ago. I was originally working on in reality labs on augmented reality glasses, which, believe it or not, a lot of stuff there is built with React Native. And at some points, someone from the React team reached out to me and was like, hey, you want to come over and help us build this stuff? I was an iOS engineer my entire career. So, I heard React, I heard React Native, I was like, I don't know, maybe. And the more I looked into it, the more I spent time with the team, the more I looked into the tools and all the stuff that was available, I was like, yes, I'm sold. So I joined about two years ago.

My team's mostly been working on the developer experience side of things, so React Native dev tools, React dev tools, Metro Bundler, a bunch of the JavaScript infrastructure at Meta. And I also help Nico and Ricardo on a lot of the open-source fronts. So, yeah, it's been quite a journey and pretty fun. Yeah, he's my manager, so be nice to him. I just address my complaints to you then. Yeah, yeah.

Yeah, exactly. That's amazing. So I guess, like, all of you work at big tech companies, shipping what you're building internally open source as well. So can you tell me a bit more about how you think about that? Like, do you listen... You're listening to the community when you're building things, but you're also building things internally as well. Like, can you tell me about how you manage that or how you think about that? I think the biggest challenge for me has been to basically adjust my narrative in a way that leadership will understand the value of open source. It sounds quite political, in a sense, but basically, I'm deeply passionate for open source. I've been doing open source for my entire life, even before React.

There was one of the arguments where I said, like, I joined Meta, Facebook, back then, but I want to do open source. So that's how I landed in the React team. But eventually, as you go higher up in the chain, the value of open source becomes really blurry, you know? And then at some point, like, managers, especially those that are not so much exposed on doing open source and being in touch with the community, might just think, like, why are we even spending time open sourcing this, you know? So a lot of my work is actually in explaining to those managers and directors higher up, like, what's the value of the work we're doing? We get out of the community. Why is it important to be engaged? So yeah, that's the biggest challenge for me. Yeah.

I think that one of the other things that's maybe interesting to hear and maybe learn about is, when we build stuff in React, we always build for Meta. I mean, that's the purpose of the team. We're building UI infrastructure for the products that Meta builds. But we always try to do it thinking about what's happening in the ecosystem and what's going on with each one of you here in the room. And that's actually a good thing because we can build things with that in mind, but that's really focused on solving a real actual problem at, like, Meta scale. So we would fix something for build a new feature for Marketplace, for example, which has billions and billions of users, and that at some point, that would be shipped out. But we do first think of the Meta use case, try to build it for that scale, and then we do the open source aspect of it. Is it similar for you, too, Xuan? Can you tell us more about links and ByteDance?

Yeah, I think this is really great and tricky question. People outside big companies sometimes feel like open source is nature of this big company, but it's actually not. It's mostly because of those people who figure out how to align internal priority with external ecosystem growth. So we definitely face similar challenges as well. So one way that I try to set direction and justify it is that links is already quite successful at ByteDance scale. And React is so successful, it's not just because it's originated and successful at Meta scale, it's successful at the world's scale. So in a sense, the world is larger than Meta or ByteDance or any other company. So the way we think about it is that we try to open source it. Yeah, maybe we are giving technologies for you, but also we're trying to scale this technology to even broader scale. And that's how we learn different edge cases, learn from the community, like insights and your intelligence and everything. So that's how I think about it.

I love that. I think that's a... You nailed it. I love that so much. And I'm curious about that a bit more because I guess in my brief stint working in big tech building for internal teams, sometimes the technical organization is so big, it's kind of like you're talking to a third party team anyway. And so you kind of need to bring them along the journey with you because those teams are just so large. I think something that you've done with LYNX, Xuan, is it's very web developer-friendly. You're using HTML tags, it's like CSS and all of that. And I think you can just straight up use Tailwind in there, too. It's deeply impressive, the architecture that you've built. Was that to make it more appealing for web devs to kind of bring them along? How did you think and architect that? Yeah. I feel like what nowadays, looking back, we made the right choices.

But really, back then, infrastructure from big tech, they have to serve internal needs to get funding and resources. So this technology in particular is originated in a community where they still have deep faith to the web. So if you don't support those, they're just not going to want to use it. So it's like, yeah, we made the right choices. One part of the story. But the other part is the environment reinforced us to do that. So it's like this joint effort. That's interesting.

And I guess from the React Native side, correct me if I'm wrong, because I probably am. But I think the React Native component system, it's modeled off of iOS's view system. And can you tell me a bit more about that exploration as well? So yeah. I mean, there has been a recurrent topic on the community on us moving away from legacy renders. So on Android, it will be the Android view system, for example, and moving to more modern frameworks like JPEG Compose and Zwift UI. I mean, obviously, there has been explorations in the past.

The reason why we haven't moved over yet is because we don't have a strong argument to do the move other than driving the hype wave. Like everyone wants to be on the latest and greatest. But the reality is that, for example, on Android, the Android view system has been used at scale from Google for like 10, 15 years. JPEG Compose is way more recent. And there are performance bottlenecks. And so we will be moving over the entire ecosystem to something that is not as mature. And at the end of the day, it doesn't really matter for you. Because your API is like the React API.

So whatever runs under the hood should not be a concern. It's only if you're building custom components that maybe you want to use JPEG Compose and Zwift UI. But you can, in theory, already do that today with tools like Expo and Expo modules. So yeah, it's an exploration that we did in the past. And it keeps on coming up. But I don't think it's super high priority for us right now. I don't see us working on it in the immediate future.

Yeah. I think Shawn had an interesting point when he was talking about how the environment kind of forces you to do certain things. When React Native came out, that was a time where Facebook, it wasn't meta, it was Facebook, was super-focused at becoming a mobile-first, mobile-native-first company. It was deeply rooted in web. But the whole point was, we're going to do Native better than anyone else. And I think that that influenced a lot of the decisions on how to build the thing.

It was supposed to give you the exact platform experience. So there's a lot of stuff that web didn't have an equivalent for or didn't really actually was able to do. So it had to be modeled over, like, on top of something that was that. So the iOS framework, I guess. And that's why it started that way. You had stuff like Navigator iOS and a bunch of stuff like that, right, if I remember correctly. I wasn't there at the time. But it does make sense to kind of draw more and more from the web experience.

And I think that we've been doing that internally for some of our products that are actually now in production, where there's more co-chairing with what we did on the web side of things to build the Native experiences with stuff like React strict DOM and things like that. So it started from a place of the environments forcing us to make this thing as fully platform-specific. And then we made it bigger and bigger so that it would also take on the web stuff as well. That's awesome. And yeah, I mean, the person working on React strict DOM is Nicholas Gallagher, who created React Native web as well. And so it's awesome to see the progression and future of kind of that approach evolving, essentially, with a matter of resources and a matter of support on the React team. And I think that's really, really cool.

I guess, for me, though, using React Native, it felt more true to React. If you're trying to support web, you're trying to support kind of legacy in a way, and you're trying to take this beautiful compositional component pattern and try to make it work with web, versus React Native that kind of started fresh in some ways. You can kind of think of a fresh component architecture, kind of think of a fresh view system. And do you find now going back to web in some ways starts to remove some of that? How do you think about that? I'm curious for all of you, really. How do you think about that? Like, supporting Tailwind is kind of crazy, you know, as an example. Supporting Tailwind on an iOS and Android, that's very much like a web CSS thing. CSS has gotten a lot of hate over the years for the cascading nature of it, and yet you've chosen to put that back in while React Native doesn't cascade. You just define a style on a view, as an example. So are you looking at cascading as well? How do you think about that essential style isolation?

Yeah, I think that for React Native, for example, a lot of the styling decisions just came from – I wasn't there, I don't know, but my assumption is, from how I know the team, is that a lot of the decisions came from this is what we need for the particular products that we're building, and this is what the platforms are providing us. So we're going to try and do that as true to the platform as possible. For example, we got things like certain filters that CSS provides that are not – there's no way of doing them on iOS unless you're dropping into private APIs, for example. And that's something that I don't think we would want to do, or we would be very careful about doing, because we have a responsibility for millions and millions of developers that are building I don't know how many apps. So you wouldn't necessarily want to mimic things as closely as possible. You have to take a more responsible approach. For example, Expo has been doing some good work on the CSS filter stuff, but they have to drop into SwiftUI to implement some of those things. It's not something that, for example, an iOS UI kit would have. Yeah, Nico?

I think we always need to remember that React Native started as an Akaton project, and we carry over some of those decisions for a long time. For example, my focus in the last years has been a lot around stability. React is shipping major versions while we are still at 0.80, 0.82, and so on. And that's because our APIs are not as polished as we would want to. This last year, we invested a lot on reducing our API surface and exposing only the things that should be exposed, and so on. But in the past, there has been wrong choices. And you will see that sometimes in using the APIs, especially in components that are iOS only or Android only, things are not properly named in a cohesive way.

So yeah, what my team has been doing over the last, I would say, two years or so is taking a look at some of those APIs to see what can be basically re-harmonized also with web. Which of those properties are available on web, and are the naming even the same? We try to lower the barrier of entry to React Native as much as possible. Sadly, because this started as an Akaton project, some of those API decisions, we're going to pay the cost now, like in defecation and so on. But on the other hand, I'm glad that this started as an Akaton project. Perhaps if this would have started with a huge RFC with like, hey, this is like the glorious multi cross-platform framework that we wanted, it would have never shipped. And we would not be here talking about it.

But Nico, just to be clear, this is more than a hackathon project now, right? It's like a fully stable, mature, not fully stable, but stable and mature framework people can use in production. People are doing billions on React. So I'm glad to see that. That's awesome. And for you at ByteDance. I just want to come back to that question. First off, definitely a huge shout out to React Native nowadays. Focus more on the web side of things, partially because of internal priorities. Because really, during my time at Emeta and React, I feel like supporting web as first class platform is like a huge missing opportunity. We hired Nicholas, but somehow, it's not doing enough work there. But anyways, what I try to get is that it's actually great to have different people have different tastes. As you mentioned, React Native is a bit focused more on the React side.

As you mentioned, React Native is a bit focused more on the React side. It's originated by the React group of people who want to spread React everywhere and to build mobile apps. And they love React. I love React. And the Linx team, and also for now, the leading member, I would say, they started this project because they want to make web work. Because for a long time, mobile web just doesn't work. Before I started to love React, I used to love PWA, Progressive Web App. I was one of the first advocates. And I go to Google IO, but still, PWA just failed. So a lot of the team members were browser engineers in our team. We just want to make web work. And that's why we started by adding CSS. And eventually, I felt like, no, we should also add React. So it's just coming from different funding members. It's going to reinforce the technology differently. But it's great now that we have two groups of people to work on the same problem space. And now we can learn from each other. Prior to that, we don't even have healthy competition to grow this ecosystem together, to learn from each other.

You mentioned a key word there that I want to focus on, ecosystem and community. And obviously, as I mentioned, I was part of the React community from the early days. I like to imagine, obviously not internally, but when it was open sourced. And I've been there for that journey. And I've seen the progression. Can you tell me about how you're thinking about ecosystem and community? And what's the future of that? I guess let's start with Meta. Yeah, one huge milestone for us as an ecosystem is definitely the React Foundation. I remember the first time, when I joined, I was like, why is this project not a foundation? Why? And I had a lot of conversations with people. And then I settled down on, OK, this will eventually never happen, because Meta and whatever. But then seeing it happening right now, I think, is amazing. Because obviously, Meta has been driving the development of React and React Native for the last 12, 10 plus years. But especially in React Native, we saw so many valuable contributions.

Amazon is shipping React Native on their operating system. So that's groundbreaking. And having a foundation gives us more like a democratic approach to the evolution of React and so much looking forward to it. So yeah, I believe that will be the next chapter for the React ecosystem and community. Yeah, I think that one of the other things that is kind of cool about it is that now, and this actually happened before the foundation too, but this kind of solidifies it. You have teams that are building contributions to React Native or React and React Native that are not necessarily focused or planned through Meta's priorities. So Expo, for example, really cares about CSS. So they're adding a bunch of CSS features into React Native, which is something that Meta also cares about, but like a different portion of it, for example. So we can kind of, the fact that we have this robust ecosystem and these partners that are now part of the foundation is something really cool because each kind of has their own contribution to how the whole system works.

And Xuan, how are you thinking about ecosystem and community? We just want to steal ecosystem from React Native, that's it. No, like seriously. We originated from web, so we kind of have some head start over there because that's where we come from. But then, I think other than adopting React and being able to share the React programming model part of the ecosystem, I do feel like nowadays, because we have multiple JavaScript based cross-platform solutions, and we should try to collectively grow a native extension or native module system. I kind of feel like even within the React Native ecosystem, there are so many different contracts. We have TurboModule, but then there's AxponModule, and then you've got NitroModule. And what about some of the other people want Node API to connect with native scripts? So now you have all different contracts to basically do the same thing. So what if we can somehow find a standardized way to share those native module ecosystems? That's going to be great.

Yeah, and you make another good point there that it's leaning on the JavaScript ecosystem at the end of the day as well, which is very established as well. And I think the talk that you just gave on links UI, I love that because of course with the React Native, there's no official UI library. There's a few different ones, but now you're kind of standardizing UI and kind of bringing that community and ecosystem along with you as well. So I really liked that approach there. Cool. So I'm not sure exactly how much time we have left, but oh, it's on that one over there. Yes, cool. So I guess we'll wrap it up soon. I think I have one more thing that I'm just curious about and kind of how you think about it. And for me, I have to address the elephant in the room. I've heard it from a few of you already and it's making headlines. And honestly, I'm not quite sure how to address this one. So I'm going to try my best.

But essentially, they're training them. They're training them and they're coming over here and they're taking our jobs. And they come by a lot of different names as well. And if you aren't sure what I'm talking about, I'm talking, of course, about AI. So I'm curious, how do you think about cross platform in an AI world? All the efficiencies that we have are shipping to multiple platforms. If you can just write a prompt and build an app for multiple platforms, does all of this go away? Essentially, what's the future there? I'm curious how you're thinking about that.

Yeah. So we were discussing about it yesterday. I thought about it overnight. So, I mean, obviously, we could argue that you could just kick off multiple agents in parallel that build the same app, starting from the same prompt with the native implementation. But you will end up with a lot of subtle differences. And then you will have to reharmonize. And it's going to be a lot of back and forth. I think cross-platform solutions are still a winning approach here. Because you can use an agent. First, thanks to the amount of documentation that is available for React, agents are really well-trained to do React and React Native code. And then you can start just doing one platform.

That's what I generally do. I do mostly Android. So I develop on Android. And once I reach a point that I'm satisfied with, I ask the agent, OK, now let's make sure that this works for iOS. Most of the time, it's just a matter of one or two further interactions. If you were to do everything native, you will have to basically restart the app. OK, you have the agent. It's going to help you. But good luck making sure that the two apps don't diverge. I remember back then, when I was doing native development, we always had this struggle that a product manager for the company I was working for, we were shipping features. For Android, two weeks after they won for iOS, because the iOS team was bigger.

And even if you have AI, you're going to have more or less the same problems. If things are not aligned, if the code base is not the same, things will be shipped with different timelines, which is a bad experience for users. Now you will have Android users pissed off because they can't use all the new shiny feature of your products.

So yeah, I don't see major changes for us. Nico, I don't think that matters. I think AI is going to solve all of this. Well, let me tell you a story. So the other day, I had to go to the gym. I woke up at 8 AM. I had to get there at 9. And I was like, I wonder if I can like vibe code an entire workout app like the time I have before I go to the gym.

And 33 minutes later, I actually put a stop timer. I had a fully working workout app that would track all my exercises, my reps, everything. It synced with HealthKit on the Apple ecosystem. It did cloud syncing with multiple devices. It also created a watch app for Apple Watch. It was like crazy in 30 minutes. And then I went off to the gym, and I used it.

It was like crazy in 30 minutes. And then I went off to the gym, and I used it. So I think the AI has kind of got it to some extent. Where this broke, actually, was so it did this for this. It decided to build with SwiftUI. And next day, when I wanted to take my crappy Android phone to the gym and just use that because I don't care if it gets messed up, I didn't have anything. So yes, to some extent, AI is going to solve a lot of problems for us. But the cross-platform solutions and specifically the ones based on JavaScript, TypeScript, all the web-type ecosystem are actually going to help us a lot and are still going to make sure we have one code base, one context window. So yeah.

OK. Xuan? Do we still have time? I can wrap up relatively quick. So I'm going to answer this in a bit more theoretical perspective. I remember when GPT-3 or something came out, people started to rethink like what would be the next UI framework in the AI era. And they'd be like, OK, maybe React is going to be obsolete because you can just generate DOM and JavaScript. And then even crazier, people would be like, oh, what if you can just generate CPU instruction, GPU instruction? Then your UI framework is basically a live streaming. But I had a very opposite intuition, even in the very beginning. Because we know large language models speak human natural language. And human language are of really higher order of abstraction. And if you think about the evolution of formal language and programming language, you have assembly 1, 0, which are the most chaotic. And then it's getting a little bit more higher level, more structural, so that you can just say, OK, I want a function, I want a memory, and you don't need to figure out those entropy.

And then you got React upgraded from imperative programming to declarative programming. So you just say, oh, I want this dialogue to display there after I tap the button instead of find this container of tree and insert 1, 2, 3 nodes and whatever. So in this sense, I come to a conclusion that maybe whatever that is more ergonomic to human are actually better for AI, at least for this generation of AI. And in that sense, React and nowadays components become even more important foundation for AI to do this UI framework. And cross-platform is the same. It reduces the entropy of the language spoke by us, by engineer, by human, but also by AI. So I'm pretty optimistic about this. To take the link tagline, write once, render anywhere, and it's really that in practice. So with that, we are out of time.

And so I just want to take a very short, quick moment to say something I often say in private, actually, and I'll say it in public now, which is thank you. Thank you so much for doing what you do, but specifically for releasing it as open source, releasing it for free, and releasing it for all of us to use. This whole room of people are really here because of what you're shipping. And I don't think that's said enough. So thank you so much for all of that. And thank you so much for the panel. Thank you.