- Blitz là engine kết xuất dạng mô-đun tập trung vào kết xuất HTML/CSS; thiết kế của nó không cung cấp sẵn toàn bộ chức năng của trình duyệt, mà để các tính năng bổ sung cần thiết ở dạng tùy chọn
- Trạng thái hiện tại là pre-alpha; trình kết xuất đã có khá nhiều tính năng, nhưng vẫn còn nhiều lỗi và chức năng thiếu, nên hiện chưa được khuyến nghị dùng để phát triển ứng dụng
- Mục tiêu hỗ trợ gồm modern HTML layout, advanced CSS, HTML form controls, khả năng truy cập dựa trên AccessKit và mở rộng bằng custom widgets; các tính năng như WebRTC, WebSockets, Bluetooth, localStorage không được cung cấp
- Kiến trúc được chia thành phần trừu tượng core DOM cùng các mô-đun networking, rendering, window và quản lý trạng thái; hai crate wrapper cấp cao là
blitz và dioxus-native phụ trách kết xuất HTML/Markdown hoặc Dioxus VirtualDom
- Phiên bản mới Blitz v0.2+ sử dụng Stylo; mã nguồn v0.1 vẫn nằm ở nhánh
legacy nhưng không còn được phát triển tích cực
Engine tập trung vào kết xuất HTML/CSS
- Blitz là engine kết xuất HTML/CSS, xuất phát từ nhận thức rằng trình duyệt quá cồng kềnh so với use case cơ bản là kết xuất HTML/CSS
- Mục tiêu không phải là triển khai toàn bộ chức năng của trình duyệt, mà đặt trọng tâm vào các chức năng cần cho kết xuất HTML/CSS và biến phần còn lại thành opt-in khi có thể
- Hiện đang ở trạng thái pre-alpha
- Trình kết xuất đã có khá nhiều tính năng
- Vẫn còn nhiều lỗi và chức năng thiếu
- Hiện chưa khuyến nghị dùng để xây dựng ứng dụng
- Có thể xem tiến độ chi tiết hơn trong roadmap issue
Các tính năng muốn hỗ trợ và các tính năng loại trừ
- Phạm vi mà Blitz muốn hỗ trợ được định hướng cho kết xuất UI HTML/CSS
- modern HTML layout như flexbox, grid, table, block, inline, absolute/fixed
- advanced CSS như complex selectors, media queries, CSS variables
- HTML form controls
- Khả năng truy cập dựa trên AccessKit
- Khả năng mở rộng thông qua custom widgets
- Blitz không cung cấp các tính năng như WebRTC, WebSockets, Bluetooth, localStorage
- Trong ứng dụng native, phần lớn các tính năng này có thể được xử lý bằng các Rust crate thông thường
- Quan điểm của dự án là các tính năng này không cần gắn chặt với trình kết xuất
- Chưa có binding cho các ngôn ngữ khác như JavaScript, Python, nhưng có thể tiếp nhận đóng góp liên quan
Cách chạy và ví dụ
- Sau khi clone repository, có thể chạy package
browser
cargo run --release --package browser
- Các ví dụ được cung cấp gồm một ứng dụng TODO nhỏ, trình kết xuất Markdown và tích hợp kết xuất raw WGPU
cargo run --release --package todomvc
cargo run --release --package readme ./README.md
cargo run --release --package wgpu_texture
Kiến trúc mô-đun
- Blitz gồm core DOM abstraction, các mô-đun chức năng bổ sung và hai wrapper cấp cao
- Các chức năng như networking, rendering, window và quản lý trạng thái được tách thành những mô-đun riêng
- Có thể kết hợp các mảnh này để tạo thành một web engine
-
Crate wrapper cấp cao
blitz: frontend HTML/Markdown có thể kết xuất chuỗi HTML- Hữu ích để xem trước file HTML hoặc Markdown
- Hiện chưa có tương tác
- Sử dụng
blitz-dom, blitz-html, blitz-shell, blitz-renderer-vello
dioxus-native: frontend Dioxus kết xuất Dioxus VirtualDom- Hỗ trợ tương tác đầy đủ thông qua xử lý sự kiện Dioxus
- Sử dụng
blitz-dom, dioxus-core, blitz-shell, blitz-renderer-vello
- Cả hai wrapper đều có thể tùy chọn sử dụng
blitz-net để lấy các tài nguyên con
-
Crate lõi và crate bổ sung
blitz-dom: core DOM abstraction bao gồm style resolution, layout, event handling- Không bao gồm parsing, rendering, system integration
- Sử dụng Stylo, Taffy, Parley
blitz-traits: crate nền tảng tối thiểu giúp các crate khác tương tác với nhau mà không phụ thuộc trực tiếp lẫn nhaublitz-net: mô-đun networking lấy tài nguyên từ HTTP, hệ thống file và encoded data URI- Sử dụng reqwest
blitz-paint: chuyển đổi cây blitz-dom thành các draw command của anyrender- Sử dụng anyrender
blitz-html: thêm HTML parsing vào blitz-dom- Sử dụng html5ever và xml5ever
blitz-shell: shell cho phép Blitz kết xuất vào cửa sổ- Tích hợp Winit event loop, AccessKit, Muda, v.v.
- Sử dụng winit, accesskit, muda
- Phần trừu tượng kết xuất AnyRender đã được chuyển sang repository riêng là anyrender
Sử dụng phiên bản phát triển của Dioxus Native
- Phiên bản phát triển mới nhất của Dioxus Native nằm trong repository này
- Vì Dioxus Native đang được phát triển nhanh, nếu muốn dùng các tính năng mới nhất và bản sửa lỗi trước bản phát hành chính thức, có thể dùng phiên bản git
- Quy trình dùng phiên bản git như sau
- Loại bỏ hoàn toàn dependency crate
dioxus
- Thêm
dioxus-native = { git = "https://github.com/DioxusLabs/blitz";, rev = "e64a3d8", features = ["prelude"] }
- Thay
e64a3d8 bằng git commit id của phiên bản mong muốn
- Trong mã Rust, đổi
use dioxus::prelude::* thành use dioxus_native::prelude::*
- Nếu cần các tính năng
dioxus mà Dioxus Native prelude không export, hãy import từ từng sub-crate riêng như dioxus-html, dioxus-signals, dioxus-router
- Phiên bản git của Dioxus Native vẫn phụ thuộc vào phiên bản ổn định Dioxus v0.7.x trên crates.io
- Các thư viện bổ sung như
dioxus-sdk, dioxus-components, dioxus-free-icons vẫn nên tiếp tục hoạt động
Phiên bản và giấy phép
- Repository này chứa phiên bản mới Blitz v0.2+ và sử dụng Stylo
- Mã nguồn phiên bản cũ v0.1 vẫn nằm ở nhánh legacy
- v0.1 không được phát triển tích cực
- Dự án được phân phối theo dual license Apache 2.0 và MIT
- Crate
stylo_taffy còn áp dụng thêm MPL 2.0 để dễ tương tác với dự án Servo
- Vì vậy
stylo_taffy có triple license gồm Apache 2.0, MIT và MPL 2.0
- Các đóng góp được chủ ý gửi vào Blitz sẽ được xử lý theo dual license Apache 2.0 và MIT, trừ khi có điều kiện riêng
- Đóng góp gửi vào
stylo_taffy cũng bao gồm MPL 2.0
1 bình luận
Ý kiến trên Hacker News
Tôi là lập trình viên chính của Blitz. Nó vẫn chưa ở giai đoạn hoàn thiện, và hệ thống nhập văn bản/focus còn rất cơ bản, đồng thời chưa hỗ trợ cuộn ngoài viewport gốc Các bộ chọn CSS phức tạp như
nth-child,:hasvẫn chưa hoạt động đúng, và việc tích hợp xử lý sự kiện với Dioxus, một framework kiểu React chạy trên Blitz, cũng mới chỉ ở mức click được, thậm chí còn chưa cópreventDefaultPhần networking hiện rất đơn giản, đang thực hiện các request đồng bộ trên luồng chính, và cần có networking bất đồng bộ hoặc đa luồng đúng nghĩa Công việc tối ưu hiệu năng cũng gần như chưa làm, nên ở mỗi frame đều tính lại style/layout/paint, và còn có vài chỗ rò rỉ bộ nhớ do các node không được dọn dẹp Đổ bóng, web font,calc, float layout, và cả các form control ngoài nhập văn bản cũng vẫn còn thiếu. Nói cho cùng thì nó gần với kiểu “làm một webview là việc rất lớn và chúng tôi vẫn chưa tới được đó”, nhưng tôi kỳ vọng trong 2~3 tháng tới sẽ có một hình hài hoàn thiện hơn Ảnh chụp màn hình cũng có ở đây: https://github.com/DioxusLabs/blitz/issues/23Dự án này chỉ nhìn qua cũng đã thấy rất hữu ích Ý tưởng là tạo ứng dụng native bằng mô hình layout HTML/CSS được dùng rộng rãi, nhưng bỏ đi phần nặng nề ngầm đi kèm với JS/DOM/browser API đầy đủ. Nó có vẻ có thể mang lại cải thiện lớn hơn nhiều so với việc đóng gói cả browser engine như Electron Tình cờ là gần đây tôi nghe Casey Muratori nói rất phê phán về CSS trong podcast của Richard Feldman. Những ví dụ ông ấy đưa ra, như phải prerender webpage và đo đạc động chỉ để tạo quan hệ layout đơn giản, đặc biệt gây ấn tượng với tôi Như Muratori nói, viết CSS không giống xây dựng trên những phần tử cơ bản đơn giản, mà gần như giống đang tranh tụng một vụ án trước tòa Tất nhiên, vì độ quen thuộc, tính tương thích, và việc “CSS theo lối mòn chạy tốt” cực kỳ năng suất, nên nhu cầu mà các dự án kiểu này đáp ứng là rất lớn. Dù vậy, cũng có vẻ tồn tại cơ hội cung cấp một tầng đơn giản và tổng quát hơn để người dùng có thể đi xuống và dùng trực tiếp Có thể lấy cảm hứng từ CSS Houdini, nơi muốn làm CSS có thể mở rộng bằng JS API, và biết đâu đó cũng là điều “Custom Widgets” muốn nói đến
floatđi cũng đượcVài năm trước, không, phải là 20 năm trước, tôi đã làm một dự án mã nguồn mở tương tự tên là Flying Saucer. Đó là một renderer HTML + CSS2 thuần Java Tôi từng hình dung nó sẽ được dùng để render UI văn bản phong phú trong game, nhưng ứng dụng cốt lõi thực tế lại là tạo PDF phía máy chủ. Hồi đó, so với việc dùng các API tạo báo cáo PDF có sẵn, thì tạo HTML rồi render thành PDF dễ hơn nhiều Blitz trông rất ngầu, và tôi rất mong sẽ có thêm nhiều thư viện GUI bằng Rust hơn https://en.wikipedia.org/wiki/Flying_Saucer_(library) Thật đáng ngạc nhiên là nó vẫn còn được cập nhật: https://github.com/flyingsaucerproject/flyingsaucer/releases...
Nghe như “một webview nhẹ thay thế engine JavaScript bằng API Rust native”, có vẻ rất hứa hẹn. Về cơ bản, nếu nó giống Tauri không có JS trong luồng xử lý thì chỉ nghe thôi đã thấy thích rồi
Khá thú vị. Đúng hôm nay tôi vừa vật lộn kinh khủng với puppeteer và Chromium headless, và đang tìm một lựa chọn thay thế cho wkhtmltopdf Tuyệt đối đừng bao giờ chạy với jemalloc trong
LD_PRELOAD. Tôi đã giải quyết được vấn đề, nhưng vẫn thích hướng một trình kết xuất đơn giản hơnKhông hẳn là nói về chính Blitz, nhưng đây là lần đầu tôi biết đến Dioxus Tôi tự hỏi có phải có một luật bất thành văn nào đó rằng các framework biên dịch sang WASM либо không trình diễn demo cho ra hồn, либо không tự host chính website của họ bằng framework đó. Tôi nghĩ mình đã thấy chuyện này 5~6 lần rồi Trên trang chủ Dioxus tôi thấy file WASM được tải xuống, nhưng không rõ nó được dùng vào đâu hay có thực sự được dùng không
Dùng cùng backend và htmx có thể sẽ rất hay. Chỉ là có vẻ không hề có JS engine chen vào, nên tôi tò mò không biết sẽ làm được thế nào
vàmới có thể thực hiện yêu cầu HTTP, tại sao chỉ sự kiện click và submit mới có thể kích hoạt yêu cầu, tại sao chỉ có GET và POST, tại sao chỉ có thể thay thế toàn bộ màn hình Nhìn theo cách khác, HTMX làm cho các phần tử HTML bớt bị giới hạn và tổng quát hơn. Nếu web renderer tính đến điều đó ngay từ khi thiết kế thì có khi còn đơn giản hơnHôm nay là lần đầu tôi biết đến Dioxus https://dioxuslabs.com/
Thật sự rất ngầu. Tôi muốn thử dùng nó trong một dự án C++ Một câu hỏi hiện lên ngay là hiệu năng. Tôi tò mò liệu nó có thể render những trang tương đối phức tạp với tốc độ khung hình cao hay không Bình thường tôi dùng ImGUI, và nó tuyệt vời đến mức gần như không phải nghĩ về vấn đề hiệu năng khi hiển thị dữ liệu thời gian thực. Trong khi đó, render web của Chromium lại đốt CPU chỉ để cập nhật văn bản DOM đơn giản ở mức 10 khung hình/giây; nếu chuyện này được giải quyết thì có thể sẽ thay đổi cuộc chơi