Lynx: Unlock Native for More

Hey guys, what's up everyone? So it's Shen here. That thing is pronounced as Shen. People also call me Hux at HuxPro, because that's the Internet name I use everywhere on Twitter, GitHub, YouTube. So not gonna lie, this is my very first English talk at an in-person conference. So thank you. Also big thanks to React Summit and Geek Nation to invite me to here, and this definitely is different.

So I've actually been part of the React community for a while, especially during my time at Meta. I was involved with ReasonML very early on, and then helped Hermes become the best JavaScript engine for React Native. Yo, if you didn't forget that talk at React Conf 2021, that drops the idea of React Forget. That was me. I helped bootstrap that idea, and three years later we finally have React Compiler. Right? Yeah, it still sounds real that React with a memo is now real.

But today I want to show you something new. I've been working with another awesome team two years since then. It's called Lynx. Lynx isn't like React Forget. It's not like solving a PIN that everybody already filled. I'm curious, how many of you have already heard of Lynx? Hands up. Well, plenty of you. Wow. That's awesome. Like, nobody was probably asking for something, like, thanks. We thought. So it's... Ratter is here for more. It's like bringing more things to the table. And I will show you what that means in the rest of the talk. So we open sourced the Lynx back in March, with this blog. And honestly we didn't anticipate it was gonna go viral. Thanks to all the Twitter celebrities who tweeted about us.

But personally, what really hit me is that I started to see YouTube videos pop up in language that I don't understand at all. So I can't watch those without YouTube translations. And that was just why. Of course there are also English content. Did a really insightful live stream. Love it.

We also absolutely didn't see that coming. Fireship dropped a video about us the very next day we open sourced. And then there's Phil. It was still the blonde version of Phil. So, dropped a deep dive and I really appreciated he read through the entire blog post.

So, what is Lynx exactly? If you haven't heard of it, sorry I've been holding back to this point. I did it on purpose. I kind of want to make you feel a little bit formal. In essence, Lynx solves the same problem like Web, React Native, Flutter, right? It tries to let you to just write code once and be able to build user interface and applications on any possible platforms. Currently we support iOS, Android, and web and there are more coming later this year.

Lynx is production ready. Lynx is heavily used by TikTok. So all the services here are built with Lynx. So, if you ever touch any of those, you are like a user of Lynx already. There's something like search panel, the TikTok studio apps, the e-commerce site, the live stream gifting stuff, and interesting events like Disney 100 and MetaGallery. And as for developer experience because that's something we care about a lot. You kind of already knew, right?

And on the right hand side I'm just showing off as Lynx pages rendering on the web. So, you can see it's very interactive. An interesting bit comes to here. When it comes to styling user interface, you can use real CSS. That means CSS variable, CSS selectors, that beautiful gradient, and animation transition. Some of you may be like, is Lynx another web browser? If you Google, well, I probably shouldn't say that. If you chat GPT, it's probably going to say yes. Because there's actually a browser called Lynx. Wrong Lynx, sorry. But for us, yes. Yes-ish. We use languages from the web like markups, CSS, JavaScript, and frameworks like React. The purpose is to allow the developer community to reuse existing web knowledge and still build for any platform with native capabilities and UIs. We need to make changes to ensure that existing things exist because we believe the web isn't innovating fast enough, so we aim to try something better.

I love the web and its scalability, reachability, and velocity. The scalability and reachability are unmatched. If you build for Apple, you can only reach Apple users; with the web, it's literally everywhere. You can reach any user on any device. The speed of the web is unparalleled. If you build for native, it might take a while for the experience to reach users, but with the web, it ships incredibly fast. We love the web for its scalability, reachability, and velocity, and we believe the web should emerge victorious.

You can reach any users on any devices. That's the beauty of web. The other beauty of web is web offers unmatchable velocity. If you build for native, this probably take a while for your experience to get to the users. But when you build for web, it ships incredibly fast. Right? It's just too fast we have to see that again. Right? That's how fast web is. So, we love web. We love the scalability and reachability and velocity of web. And web is supposed to win.

Why did web lose in the mobile market, at least? One of the key figures, Alex Russell, a key figure in our industry who had worked on Blink and Edge and Chromium and many web standards, shared his insights in his blog. He called it out. Like any other meta platform, meta platform means platform, right? Like web, thrives or declines, live or die, based on whether they can do most of the things we expect most computers to do. And this idea he named platform adjacency theory.

But when you build a meta platform like the web, it has to keep adopting capabilities from the host platforms to maintain adjacency and ensure the relevance gap does not become too large. However, when it fails to do so, this relevance gap grows, and crucial capabilities are missing. Without these, users stop caring, developers move away. Web developers have had to trade off some web advantages for necessary capabilities from native platforms to deliver a better user experience. Technologies like PhoneGap, Quo Java, React Native, and Flutter emerged, highlighting the significant relevance gap. The pursuit of balancing web's strengths with native capabilities is a common goal for these technologies.

Even though we could deliver the experience at reach, at scale, very fast, but the experience is not good enough, nobody will like it, then, you know, it's still not going to be the platform we are building for. So that is, unfortunately, what web has been suffering for a while, and I always quote Tom Holmes, like, this sentence from his initial introduction of React Native, it's like 2015, anytime somebody tries to implement native widgets with HTML, CSS and JavaScript, always feels like shit. I mean, nowadays, it's getting much better. I've seen a lot of great design engineer who started to, you know, recreating a lot of great stuff. But like, when it comes to some of the really tricky part, like, scroll, especially, like, multiple scroll and gesture, multi-finger gesture, that started to kind of fall apart.

And this, tools like PhoneGap, Quo Java, React Native Flutter, these tools, they appeared, they indicate that the relevance gap was too large. So we as web developers, we have to trade off some of the best part of the web in return for those necessary capability from the native platform so we can, you know, ship the real stuff. And LYNX is no different. We starting from the language of web and we need to go more native. So personally, I would think all these technologies are chasing the same north star, which is trying to hit the three points at once. So, LYNX actually use native primitive, like native views. In LYNX, text like text view, images, they are rendered into native UI, same as React Native. You could have UI view, actual UI view and actual view group.

And one of the most fresh example of this approach is that liquid glass, right? By adopting this approach, it's much easier to have that, basically for free. The other example is that very complicated and expensive layout, such as multi-column animation area, waterfall, like different people call it different name. It's very popular but it's still very tricky to get it right and perform it on web. With LYNX, because it use native primitive, you can actually have to build in. So, in LYNX, it's very easy. You just declare a type and you got it. The other part of native primitive are native module, right? Being able to access those OS level API. Our documentation only give you a tutorial on how you could build local storage with Android share preference in iOS APIs and based on the shared TypeScript declaration. That's cool, right? You can have that capability.

But if you've ever read the docs, you may notice that we mentioned LYNX is not ready for full-fledged app development just yet. That's because LYNX is more like an engine. You should think of it as more like Blink rather than Chromium, if you know what I'm talking about. That has been the biggest feature request since we open-sourced it. Honestly, we didn't expect things to grow this fast and we were not super ready for that. So, I'm excited to share that later this year, we were open-sourcing more native UI elements a set of advanced UI components like Swiper, ActionShare, TabBar, ViewPager, that kind of stuff.

And that's not all. We will also open-source the framework that TikTok has built on top of LYNX to support all their apps. With that, you will finally be able to build apps by having this whole set of toolkit. It's like the missing pieces there. Yeah, I can't wait to see it ship and to see what the community starts to build around it. Thank you. Thank you.

So now that we've completed the picture of native primitive, it's not enough. To be truly native, you also want native-like, close to native performance. And our secret sauce, like very notable architectural decision that we made is that we have two JavaScript runtimes running on two separate threads, the background threads and the main thread. We call it background thread scripting, so BTS, BTS, and main thread scripting, MTS. But we will come back to that later. When we say performance, I mean two things. First loading performance. Internally with same product migrating to LYNX, becomes significantly faster.

And just to be clear, the web version we're loading from local files, not network IO, so we were measuring rendering time, basically. And these are average numbers. In some cases, we can see things like ten seconds become one second, that kind of stuff. So it's, yeah, it's just average. So it's easier to believe with your eyes, rather than those digits, I guess. And you can see that's like the first tutorial we kind of demoed on the website, and that's how fast it is. The first frame almost hits instantly. And this is like the three, 0.3 times slow motion, and you can still see it's kind of instant.

So this feature earned its nickname internally, before we even started to think about the concept. Internally, people started to call it Instant First Frame Rendering, or IFR. And that was the killer feature to make LYNX heavily adopted within TikTok and other products. We don't have time to deep dive into it, but at a high level, it does a lot of stuff. LYNX has been a multi-year project. It takes your source code and pre-renders, think of SSR, or the partial pre-rendering of Next.js, to some lower level of abstraction, closer to the structure of HTML or tree operations.

And then the Prem.js, which is the JavaScript engine forked from Quake.js to be more optimized for LYNX, adds new GC and changes the FFI, that kind of stuff. It also benefits from pre-compiling source code into bytecode. By having these two tiers of preprocessing, at runtime, it only needs to do the little red part, that little red arrow. So that's why the first frame is instantly rendered. If you are on React LYNX, you get this for free, the compiler and bundler will handle it. There's no API. But the second part of performance is about interactivity. You want your interaction to feel snappy. This swiper is silky smooth, driven by JavaScript on the main thread, giving you full control. It's not a native widget, completely controlled by JavaScript running on the mantra.

So you have full control of it. It's not like some of the pre-scheduled animation system. So we call that feature MTS, Man-Thread Scripting. We will give a quick look at the code so you can kind of have an idea. So in this example, it kind of demonstrates the difference between having the background JavaScript thread to manage a juggable, versus having the mantra to manage a juggable. And with MTS, it stays perfectly in sync with native scrolling. And the BTS version kind of lags by one frame or so.

The API is like you use this mantra directive to mark a certain function that should be code splitted and scheduled to the mantra runtime. And at that runtime, you have access to some of the API to get the DOM nodes, like our version of DOM nodes. And you can start it to wrap it in the ref for sure. And you can use a DOM-like API, we call Elm API, to do some imperative operations. So shout out to Reanimator from Software Mansion and React Server Component, Next.js, for all the inspiration. So yeah, we definitely take a lot of inspiration from them. Thank you.

And if you are coming from the web background, MTS might sound a bit confusing, right? Because on the web, everything happens on a mantra. The web has historically been single-threaded. So it has to do all the heavy lifting. The downside is that whenever something, you know, is very busy, then everything is slow, right? And that's why LYNX wants to make this difference. By shipping two JavaScript runtimes on two separate threads, we can minimize the workload on the mantra by offloading more work to the background JavaScript thread whenever possible. But it's not like you don't have web worker on the web, right? We have web worker for years.

And in fact, the Chrome dev rel team has advocated for something similar. Like they call off-demand thread architecture, OMT. But the problem is it never really took off on the mainstream web ecosystem. I think the reason is kind of like we are too used to single-threaded model and it's just super convenient and easy to use. So it's kind of pretty tricky for everyone to manually figure out, okay, which code should be run at which runtime and how to do synchronization. Right? There are a lot of mental overhead to think about. So what we did is that we didn't just provide two runtimes. We also enforced how they should be used. At the level of APIs, like what kind of API we expose to that runtime, all the way up to how frameworks can be designed to enforce those static enforcement, like concurrent safety and how to synchronize a UI, that kind of stuff.

The BTS is where most of the user code goes, like re-rendering, reconciliation, side effects like fetch something, and data processing. And MTS is reserved for privileged, synchronized UI access, right? You can, for instance, the IFR is one pass of MTS code, and you can do MTS. And that's also a very high-priority UI task. And that's how we make them very performant, because there's nothing competing with it. And also that's why MTS is a concept in the first place. Again, we won't go into too much detail, but the architecture gives us a lot of opportunities. I'm probably going to save it for next talk.

But it really just boils down to one principle. Use the main thread more purposely and responsibly. Only tap into it when it's necessary. And we kind of build this platform and framework to help you to get there. So to wrap up, we intentionally kind of rethink and change some of the existing web practices, but not because we don't love web, but it's more like we want to fill the gap and to bring this community closer to the native ecosystem with native relevance. But there's one more thing, right? Something we really want to say yes to web. And that's the web community. One thing I'm super, like, the whole thing is really proud of Lynx is how advanced it supports a lot of CSS visual effects, right? You have gradients and masks, click paths, we even add super ellipse curve into that as extension. So the best part of this approach is that you do not need to start from scratch. You can kind of reuse code from the web ecosystem, right? Because UI technologies, when I think about it, at its core, it's about deliver exceptional design and product, right? We shouldn't waste time to, like, rebuild everything again and again. So if we can share, like, assets and ecosystem, that would be the best. So how about Tailwind? Right? It has been the best, kind of, most popular styling library, especially in the age of AI. Because Lynx supports CSS natively, you can use tools like SASS, CSS module, and even Tailwind. The only thing to keep in mind is that our CSS feature coverage is definitely different from all the browsers.

So we are experimenting with maintaining a Tailwind preset, and we definitely welcome the contributions there. Guanyu, one of the design engineers on the team, was able to port Shed-CN UI, Twig-CN Daisy UI, and build a theme generator for Lynx. You can see from there. And the code is basically just plain Tailwind. And you use the same CSS variable, same Tailwind classes, same Tailwind config. It just works. Yeah, it's going to be open source, so definitely check out his, Herd, for the work.

And how about the other very popular libraries in the web ecosystem? Motion, right? Motion. I'm a big fan of Motion. How many of you are fans of Motion? It's so good. So Yang, aka Fordream on Twitter, he experimented with bringing Motion to Lynx. And besides shimming some of the DOM API, because we don't have the exact same signature, the entire Motion core just works. It only took him one or two days to make that demo. Wait, I should probably... Okay, now you see the demo. Yeah, and that's the code.

When we first designed MTS, we just naturally wanted something low-level and more imperative, because we wanted to give the framework authors more control. But it turns out it's really good to integrate with this kind of universal ecosystem, like libraries using vanilla JavaScript. And finally, the web isn't limited to one library, right? The community can build however libraries in the framework they want. And we want to embrace that same spirit at Lynx. That's why we say we want to democratize cross-platform technologies in the first place. I don't have time, so I'm just going to skim over this. Vue has been one of the most requested frameworks, and Evan also shared this idea of having Vue native, and they're starting to have some community participation and contribution. And yeah, that's very exciting. Another thing is Svel. Rich Harris also mentioned Lynx in his very recent talk at Svel Summit, and the main matter is kind of led this effort, and if you are interested, definitely talk with them. It's super inspiring to see that happen. But personally, I'm most surprised to see this. How many of you can recognize this logo? Not too much, I guess. It's Haskell.

It's one of the kind of weirdest languages in the world, heavily used by academia. I'm a fan of functional programming, so that's why I know a bit about it. But yeah, someone from the community poured a Haskell framework to Lynx, and that works. Yeah, that's the Haskell code. So that's the power of, I would say, embracing something in a very open manner. Yeah, that's the web community. That's the open web community, I would say.

At this point, I hope the answer that what Lynx is, is a little bit more clear to you. So yes, we reserve the language because we want to preserve you. I've come to realize what makes web amazing is not just the technology. It's about this community that is so wildly creative. You see how many people are recreating liquid class in the States? That's crazy. We really want you to... And also, it kind of raised the generation of developers who can think cross-platform by default, because we were kind of from there.

So we really want you to think Lynx spiritually as alternative web for app development. So that you as web developers can confidently build upon. The reason why we diverge is because we want to give you this new vocabulary, new primitive to hit the native experiences and native performance. And maybe a better question to ask is not yes or no, is how we can tear down the wall between the web and native a bit better so that we can together do more. Is it easy to go from React Native to Lynx? Oh, I have the mic. Yeah, I believe so.