platform supported: windows / macOS / linux (x11)
Wew is a cross-platform WebView rendering library based on Chromium Embedded Framework (CEF). It supports mouse, keyboard, touch, input methods, off-screen rendering, and communication with web pages.
Note
This project is based on CEF, so the process model is the same as CEF and Chromium. Chromium and CEF (Chromium Embedded Framework) have a very modular process model design, adopting a multi-process architecture primarily to enhance security, stability, and performance. The overall architecture is a multi-process model (Multi-Process Architecture).
The main process responsible for managing the entire Chromium/CEF lifecycle. It handles window management, user input (events) processing, network requests (through network services or proxy network processes), scheduling Renderer processes, security policy control, and communication with the system.
Responsible for web page parsing, layout, rendering, JavaScript execution, etc. It executes HTML, CSS, JavaScript, integrates closely with the Blink engine, and each tab/iframe typically corresponds to an independent rendering process (more granular after Site Isolation).
Used for hardware-accelerated graphics rendering. It handles WebGL, Canvas, CSS accelerated rendering, etc., and communicates with the operating system's GPU drivers.
Run specific tasks unrelated to web page rendering. Network Service: responsible for all network requests, Audio/Video decode service, database storage, extension processes, etc.
Used for quickly spawning renderer processes to improve performance.
Inter-process communication (IPC) is used to synchronize state between Browser and Renderer, implement security controls and permission passing, and transmit events (such as clicks, scrolling, JavaScript calls). Security isolation is ensured by running Renderers in sandboxes, with each website/domain potentially running in an independent Renderer process, and high-privilege operations like GPU and network access not exposed to rendering processes.
In the current project, WebView and Runtime calls are best executed on the UI thread, which is the main thread of the application process.
Creating a Runtime must be completed on the UI thread, and all message loop calls must also be operated on the UI thread.
Other calls should be executed on the UI thread whenever possible, unless it is truly unavoidable. Although these calls can run on any thread, there is currently no guarantee that they will not cause other side effects.
However, it is important to note that if the WebView manages window events on its own, such as not using off-screen rendering, then the WebView can be created on any thread.
Note
Please note that due to CEF's packaging method, it cannot be integrated with Cargo. The CEF runtime requires many resource files and executables to be placed together, and on macOS, it also needs to follow strict and specific packaging requirements that Cargo cannot handle. Therefore, using it currently requires extensive manual operations or writing custom scripts to automate the process. You can refer to the (Windowless Rendering) example to understand how to package your application.
Let's assume your application name is Kyle.
First, you need to download the CEF preset file. Visit the CEF Automated Builds page to download the precompiled file version.
Assuming the executable file is located at /foo/Kyle.exe, copy all files from the cef/Release and cef/Resources directories to the /foo directory, placing them alongside the Kyle.exe file. However, exclude static library files .lib and debug files .pdb.
Kyle.exe
chrome_elf.dll
d3dcompiler_47.dll
dxcompiler.dll
dxil.dll
libcef.dll
libEGL.dll
libGLESv2.dll
v8_context_snapshot.bin
vk_swiftshader_icd.json
vk_swiftshader.dll
vulkan-1.dll
locales
chrome_100_percent.pak
chrome_200_percent.pak
icudtl.dat
resources.pak
On macOS, there are more and stricter restrictions, so special attention is needed. First, macOS requires a specific packaging format and needs to separate the subprocess from the main process.
Kyle.app
- Contents
- Info.plist
- Frameworks
- Chromium Embedded Framework.framework
- Kyle Helper (GPU).app
- Kyle Helper (Plugin).app
- Kyle Helper (Renderer).app
- Kyle Helper.app
- MacOS
- Kyle
Chromium Embedded Framework.framework is the same as on Windows, also coming from the cef/Release directory.
The several Helpers in Frameworks all need to be generated by yourself. Here's an example using Kyle Helper (GPU).app.
Kyle Helper (GPU).app
- Contents
- Info.plist
- MacOS
- Kyle Helper (GPU)
You need to create Helper (GPU), Helper (Plugin), Helper (Renderer), and Helper simultaneously. The executable files in these several Helpers are all the same, you just need to change the filename to match the .app name. The Info.plist also needs to be modified according to the actual situation.
This library's runtime will inject a global object into web pages for communication between Rust and web pages.
declare global {
interface Window {
MessageTransport: {
on: (handle: (message: string) => void) => void;
send: (message: string) => void;
};
}
}Usage example:
window.MessageTransport.on((message: string) => {
console.log("Received message from Rust:", message);
});
window.MessageTransport.send("Send message to Rust");WebViewHandler::on_message is used to receive messages sent by MessageTransport.send, while MessageTransport.on is used to receive messages sent by WebView::send_message. Sending and receiving messages are full-duplex and asynchronous.
MIT Copyright (c) 2025 Mr.Panda.