You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Through Lynx, we provide first-class browser support for developers' code.
18
+
With Lynx, we provide first-class browser support for developers.
19
19
20
-
As Lynx is a cross-platform infrastructure which provides a "write once runs anywhere" experience , we believe that the Web is an essential platform for the Lynx ecosystem to enlighten developers to extend their boundaries of creativity and innovation. With the browser support offered by Lynx, developers can easily preview and engage more users, avoid spending a lot of time on rewriting and maintaining a split code base, as well as deliver features in more agile ways.
20
+
The Lynx Web Platform is now in beta. Here are some highlights of the Web Platform.
21
21
22
-
We have many use cases in Tiktok. Here is a simple showcases.
Our web platform—a Lynx FFI implementation for browsers—provides the same rendering and appearance as the Lynx engine.
27
+
28
+
## Inspired by Concurrency in Lynx
29
+
30
+
On the Lynx Web Platform, we're bringing Lynx's dual-threading model to the web community.
31
+
32
+
We're trying to give Web community an idea about the multi-threading web application.
33
+
With Lynx's dual-thread architecture, we use the [Web Workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API) to implement Lynx's multi-threaded rendering.
34
+
On Lynx's Web Platform, developers can easily render their ReactLynx pages in an HTML document.
35
+
With ReactLynx, your code is automatically and gracefully split into two threads.
36
+
With fast First Meaningful Paint (FMP) and non-blocking effect execution, we help you catch users' eyes as soon as possible.
37
+
38
+
39
+
As we all know, over the past decade, multi-threaded performance has outpaced single-thread performance on modern hardware.
40
+
In a single-threaded model, applications can only process tasks sequentially.
41
+
When faced with computationally intensive tasks, the interface may become unresponsive or even freeze, severely affecting the user experience.
42
+
43
+
Here's a demo showing a page with complex effects that don't block the main thread.
Our Web Platform's core proposal is to provide a solution that allows developers to render their Lynx page in a browser in a high performance way and at a minimal cost.
65
+
## One codebase, one Lynx
35
66
36
-
Therefore, we provided built-in support by Rspeedy and reused the entire JavaScript compilation pipeline for Web Platform. The only difference in the output file is that for the Web Platform we skipped the AOT optimization.
67
+
The core idea of our web platform is to provide a solution that lets developers render their Lynx pages in a browser with high performance and minimal cost.
Therefore, we provide an implementation of the Lynx Engine APIs for browsers.
39
70
40
-
This means that developers and Rspeedy(Rsbuild) plugin authors don't need to do extra work on supporting web platforms. There are no variants of your code for different platforms. We offer you One Lynx!.
Under the hood of ReactLynx, Preact runtime updates the page by invoking Lynx's [PAPIs](https://lynxjs.org/api/engine/element-api.html) like \_\_SetAttribute that resemble DOM APIs. To ensure architectural consistency, we have re-encapsulated browser-based DOM APIs on the Web platform, providing DOM APIs consistent with PAPI. Below is an example.
Also, in case the Web is one of the official supported rendering platforms. We really care about its performance. Fortunately, with modern Web APIs and modern ECMAScript APIs, like [CSSOM](https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model), [WebWorker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API), [Shadow DOM](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM), [Scroll Driven Animation](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scroll-driven_animations), etc,., we're able to deliver better performance for web rendering. Focusing on those browsers with 90%+ usage share helped us to achieve it.
95
+
This means that developers and Rspeedy (Rsbuild) plugin authors don't need extra work to support the web platform.
96
+
There are no platform-specific variants of your code.
97
+
The only difference in the output is that for the web platform we skip AOT optimizations.
98
+
One Lynx!
83
99
84
-
### One CSS Spec, Web CSS Spec
100
+
### One CSS Spec — the Web CSS Spec
85
101
86
-
For most Lynx supported CSS properties and all selectors, Lynx Engine is implemented in W3C specs or a sub set of corresponding W3C specs. Therefore, we just dump these declarations as-is into the document.
102
+
For most Lynx-supported CSS properties and all selectors, the Lynx Engine follows W3C specs or subsets of the corresponding specs.
103
+
This lets us emit these declarations as-is into the document.
However, there are some special properties and values that are implemented for performance. That's why our web platform integrates a CSS transformer to transform some values into CSS custom properties. Then we use some CSS tricks to switch and apply different properties on HTMLElement. This makes us achieve max compatibility with higher performance.
107
+
However, there are properties and values implemented for performance reasons.
108
+
That's why our web platform includes a CSS transformer that converts some values into CSS custom properties.
109
+
Then we use CSS techniques to switch and apply different properties on HTML elements.
110
+
This achieves maximum compatibility while maintaining high performance.
One of the highlights of Lynx's promise is that we provide a "write once, run every platform" development pattern and rendering based on native UI components, which means that , on every platform, we have a corresponding UI component implementation with the same behavior.
103
-
We have similar system designs on different platforms. Just like Lynx's elements on iOS/Android, in browsers we provide a series of custom elements using the [Web Components technology](https://developer.mozilla.org/en-US/docs/Web/API/Web_components).
104
-
By using lifecycles directly provided by web browsers, we don't need to depend on any JavaScript framework. This helps us to provide a minimal IO overhead for applications shipped with Lynx.
105
-
106
-
## Empowered by Concurrency on Lynx
107
-
108
-
Moreover, Lynx is inspiring web development by bringing a multi-threading model. With Lynx's dual thread architecture design based on WebWorker, we've implemented a multi-threading rendering model.
109
-
Now on Lynx's Web Platform, we shipped a well-designed dual-threading programming pattern : ReactLynx. By using ReactLynx, the user code will be automatically and gracefully split into two threads. With the fastest FMP and non-blocking effects execution, we help you to catch users' eyes as soon as possible.
120
+
One of Lynx's core ideas is rendering based on native UI components, which means that on every platform we provide a corresponding UI component implementation with similar behavior.
121
+
Just like Lynx's elements on iOS and Android, in browsers we provide a series of custom elements using [Web Components](https://developer.mozilla.org/en-US/docs/Web/API/Web_components).
122
+
By using the lifecycles provided by web browsers, we don't depend on any JavaScript framework. This minimizes I/O overhead for applications built with Lynx.
110
123
111
-
Here is a demo to show a page with complex effects that the effects won't block the main thread running.
In this demo, we have one `effects` to load detailed information for users. On Lynx, the effect won't wait for the rendering to finish and won't block rendering. This design boosts the high priority rendering tasks and keeps the effects to be executed fast.
As we all known, in the past decade, the multi-thread performance growth of hardware is faster than the single-thread performance growth. In a single thread model, applications can only process tasks sequentially. When faced with computationally intensive tasks, the interface may become unresponsive or even freeze, severely affecting the user experience.
120
-
121
-
## Faster, Easier and Rust-ize Future
122
-
123
-
### Boosted by Rust and WASM
124
-
125
-
An ongoing optimization will introduce Rust implemented WASM module. Our in-house benchmarking shows that by rewriting style transformer in rust, it will have 30~40% rendering cut down.
130
+
An ongoing optimization will introduce a Rust-implemented WebAssembly module. Our in-house benchmarking shows that rewriting the style transformer in Rust can reduce rendering time by 30–40%.
126
131
127
132
### Ready for [PWA](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps)
128
133
129
-
We're going to explore more possibilities with PWA technologies, such as Push and Service Workers, to improve user experience. Imagine that non-blocking content dumping without an SSR server? Let's make it work with workers!
134
+
We're exploring more possibilities with PWA technologies, such as push notifications and service workers, to improve user experience. Imagine non-blocking content streaming without a separate SSR server. Let's make it work with workers!
130
135
131
136
### [SSR](https://developer.mozilla.org/en-US/docs/Glossary/SSR) support
132
137
133
-
We do know the SSR is one of the important ways to improve user experiences. The Web Platform's SSR support will be shipped with built-in "zero JavaScript ready" SSR output. We will integrate with the [HTML `<template>` Element](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/template) powered solutions.
138
+
We know SSR is an important way to improve user experience. The web platform's SSR support will ship with built-in 'zero-JavaScript-ready' SSR output. We will integrate with solutions powered by the [HTML template element](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/template).
139
+
140
+
## See our presentation on [React Universe Conf 2025](https://www.youtube.com/watch?v=-uUcYrl51JM)
we're still deeply entrenched in active development—our team is working closely and intensively to refine and expand the platform. As a result, there are a few capabilities that remain in the pipeline and haven’t been fully implemented yet. For instance, Hot Module Replacement (HMR) is one such feature we're actively working on but haven’t rolled out just yet. We're working hard to make it better.
150
+
We're still in active development—our team is working closely to refine and expand the platform. As a result, a few capabilities remain in the pipeline and haven't been fully implemented yet. For instance, Hot Module Replacement (HMR) is under active development and hasn't rolled out yet. We're working hard to make it better.
0 commit comments