2P by GN⁺ | ★ favorite | 댓글 1개
  • Blitz는 HTML/CSS 렌더링에 초점을 맞춘 모듈형 렌더링 엔진이며, 브라우저 전체 기능을 기본 제공하지 않고 필요한 추가 기능은 선택적으로 두려는 설계를 가짐
  • 현재 상태는 pre-alpha로, 렌더러는 이미 상당한 기능을 갖췄지만 버그와 누락 기능이 많아 앱 개발에 사용하는 것은 아직 권장되지 않음
  • 지원 목표는 modern HTML layout, advanced CSS, HTML form controls, AccessKit 기반 접근성, custom widgets 확장이며 WebRTC, WebSockets, Bluetooth, localStorage 같은 기능은 제공하지 않음
  • 구조는 core DOM 추상화와 네트워킹, 렌더링, 윈도우, 상태 관리 모듈로 나뉘며, blitzdioxus-native라는 상위 래퍼 crate가 HTML/Markdown 또는 Dioxus VirtualDom 렌더링을 담당함
  • 새 버전인 Blitz v0.2+는 Stylo를 사용하며, v0.1 소스는 legacy 브랜치에 남아 있지만 활발히 개발되지 않음

HTML/CSS 렌더링에 집중하는 엔진

  • Blitz는 HTML/CSS 렌더링 엔진이며, 기본 사용 사례인 HTML/CSS 렌더링에 비해 브라우저가 비대하다는 문제의식에서 출발함
  • 목표는 브라우저 기능 전체를 구현하는 것이 아니라, HTML/CSS 렌더링에 필요한 기능을 중심으로 두고 나머지 기능은 가능하면 opt-in으로 만드는 것임
  • 현재는 pre-alpha 상태임
    • 렌더러는 이미 상당한 기능을 갖췄음
    • 아직 버그와 누락 기능이 많음
    • 앱을 만드는 데 사용하는 것은 아직 권장되지 않음
    • 더 자세한 진행 상황은 roadmap issue에서 확인 가능함

지원하려는 기능과 제외하는 기능

  • Blitz가 지원하려는 범위는 HTML/CSS UI 렌더링에 맞춰져 있음
    • flexbox, grid, table, block, inline, absolute/fixed 등 modern HTML layout
    • complex selectors, media queries, CSS variables 같은 advanced CSS
    • HTML form controls
    • AccessKit 기반 접근성
    • custom widgets를 통한 확장성
  • Blitz는 WebRTC, WebSockets, Bluetooth, localStorage 같은 기능을 제공하지 않음
    • 네이티브 앱에서는 이런 기능의 상당 부분을 일반 Rust crate로 처리할 수 있음
    • 이런 기능이 렌더러와 결합될 필요는 없다는 입장임
  • JavaScript, Python 등 다른 언어 바인딩은 아직 없지만, 관련 기여는 받을 수 있음

실행 방법과 예제

  • 저장소를 클론한 뒤 browser 패키지를 실행할 수 있음
cargo run --release --package browser
  • 예제로는 작은 TODO 앱, Markdown 렌더러, raw WGPU 렌더링 통합이 제공됨
cargo run --release --package todomvc
cargo run --release --package readme ./README.md
cargo run --release --package wgpu_texture

모듈형 아키텍처

  • Blitz는 core DOM abstraction, 추가 기능 모듈, 두 개의 상위 래퍼로 구성됨
    • 네트워킹, 렌더링, 윈도우, 상태 관리 같은 기능이 별도 모듈로 나뉨
    • 이 조각들을 결합해 하나의 웹 엔진을 만들 수 있음
  • 상위 래퍼 crate

    • blitz: HTML 문자열을 렌더링할 수 있는 HTML/Markdown frontend
    • HTML 또는 Markdown 파일 미리보기에 유용함
    • 현재는 상호작용이 없음
    • blitz-dom, blitz-html, blitz-shell, blitz-renderer-vello를 사용함
    • dioxus-native: Dioxus VirtualDom을 렌더링하는 Dioxus frontend
    • Dioxus 이벤트 처리를 통해 완전한 상호작용을 지원함
    • blitz-dom, dioxus-core, blitz-shell, blitz-renderer-vello를 사용함
    • 두 래퍼 모두 하위 리소스를 가져오기 위해 blitz-net을 선택적으로 사용할 수 있음
  • 핵심 crate와 추가 crate

    • blitz-dom: style resolution, layout, event handling을 포함하는 core DOM abstraction
    • parsing, rendering, system integration은 포함하지 않음
    • Stylo, Taffy, Parley를 사용함
    • blitz-traits: 다른 crate들이 서로 직접 의존하지 않고 상호운용할 수 있게 하는 최소 기반 crate
    • blitz-net: HTTP, 파일시스템, encoded data URI에서 리소스를 가져오는 네트워킹 모듈
    • reqwest를 사용함
    • blitz-paint: blitz-dom 트리를 anyrender draw commands로 변환함
    • anyrender를 사용함
    • blitz-html: blitz-dom에 HTML parsing을 추가함
    • html5everxml5ever를 사용함
    • blitz-shell: Blitz가 윈도우에 렌더링할 수 있게 하는 shell
    • Winit event loop, AccessKit, Muda 등을 통합함
    • winit, accesskit, muda를 사용함
    • AnyRender 렌더링 추상화는 별도 저장소인 anyrender로 이동함

Dioxus Native 개발 버전 사용

  • 최신 개발 버전의 Dioxus Native는 이 저장소에 있음
  • Dioxus Native가 빠르게 개발 중이기 때문에, 공식 릴리스보다 먼저 최신 기능과 버그 수정을 사용하려면 git 버전을 쓸 수 있음
  • git 버전 사용 절차는 다음과 같음
    • dioxus crate 의존성을 완전히 제거함
    • dioxus-native = { git = "https://github.com/DioxusLabs/blitz";, rev = "e64a3d8", features = ["prelude"] }를 추가함
    • e64a3d8은 원하는 버전의 git commit id로 바꿈
    • Rust 코드에서 use dioxus::prelude::*use dioxus_native::prelude::*로 변경함
    • Dioxus Native prelude가 내보내지 않는 dioxus 기능이 필요하면 dioxus-html, dioxus-signals, dioxus-router 등 개별 sub-crate에서 import함
  • Dioxus Native의 git 버전은 crates.io의 안정 버전 Dioxus v0.7.x에 여전히 의존함
    • dioxus-sdk, dioxus-components, dioxus-free-icons 같은 추가 라이브러리는 계속 동작해야 함

버전과 라이선스

  • 이 저장소에는 Blitz v0.2+ 새 버전이 들어 있으며 Stylo를 사용함
  • 이전 버전인 v0.1 소스는 legacy 브랜치에 남아 있음
    • v0.1은 활발히 개발되지 않음
  • 프로젝트는 Apache 2.0과 MIT dual license로 배포됨
  • stylo_taffy crate는 Servo 프로젝트와의 상호운용을 쉽게 하기 위해 MPL 2.0도 추가로 적용됨
    • 따라서 stylo_taffy는 Apache 2.0, MIT, MPL 2.0의 triple license임
  • Blitz에 의도적으로 제출한 기여는 별도 조건이 없는 한 Apache 2.0과 MIT로 dual licensed 처리됨
    • stylo_taffy에 제출한 기여는 MPL 2.0도 포함함

댓글과 토론

Hacker News 의견들
  • Blitz의 리드 개발자임. 아직 완성 단계는 아니고, 텍스트 입력/포커스 시스템은 기본적이며 루트 뷰포트 외 스크롤은 지원하지 않음
    nth-child, :has 같은 복잡한 CSS 선택자는 아직 제대로 동작하지 않고, Blitz 위에 올라가는 React 유사 프레임워크인 Dioxus와의 이벤트 처리 통합도 클릭만 되는 수준이며 preventDefault도 없음
    네트워킹은 현재 매우 단순해서 메인 스레드에서 동기 요청을 하고 있고, 제대로 된 비동기 또는 멀티스레드 네트워킹이 필요함
    성능 작업도 거의 안 해서 매 프레임마다 스타일/레이아웃/페인트를 다시 계산하고 있으며, 정리되지 않는 노드 때문에 메모리 누수도 몇 군데 있음
    그림자, 웹 폰트, calc, 플로트 레이아웃, 텍스트 입력 외 폼 컨트롤도 아직 빠져 있음. 결국 “웹뷰를 만드는 건 큰 작업이고 아직 거기까지 못 갔다”에 가까우며, 2~3개월 안에 좀 더 완성된 형태를 기대하고 있음
    스크린샷은 여기에도 있음: https://github.com/DioxusLabs/blitz/issues/23

    • 개인적으로는 렌더링하기 쉬운 더 단순한 의미론을 가진 새 문서 형식을 설계하고 싶음
      HTML은 꽤 복잡하게 느껴지고, 동적 렌더링을 위해 설계된 것도 아님. lean과 KISS를 좋아하는 입장에서는 HTML이 충분히 가볍거나 단순해 보이지 않음
    • 웹사이트 스크린샷을 캡처하는 솔루션을 찾고 있었고, 가능하면 이전에 크롤링한 표현에서 만들고 싶었음
      기존 서비스들은 대체로 Chromium 인스턴스를 띄워 스크린샷을 요청하는 방식이라 운영 비용도 SaaS 비용도 꽤 비싸 보임. 그렇다면 Blitz가 잘 맞을 것 같은데, 현재 헤드리스 모드로 실행해서 스크린샷을 저장할 수 있는지 궁금함
    • Servo나 WebKit 같은 것 위에 만들지 않고, 여러 컴포넌트를 직접 조합하는 동기가 궁금함
    • 다뤄야 하는 가장 복잡한 공학적 부분이 무엇인지 궁금함. 아직 작업 중이어도 설계 문서를 공유할 수 있으면 좋겠음
      개인적으로 Blitz, Servo 같은 엔진을 앞으로 형식 기법으로 어떻게 만들 수 있을지에 관심이 있음. 예를 들어 정의에서 시작해 시스템 일부를 생성하는 방식이고, 요즘은 여기에 LLM도 포함되지만 AI 시스템보다는 훌륭한 도구에 가깝게 봄. Z3 같은 것도 떠오름
      내 회사들 중 일부도 이런 주제의 연구 조직을 두고 있음
    • Blitz가 다른 사람들이 브라우저를 만들 수 있게 하려고 만든 것인지 궁금함
      Wootzapp(https://github.com/wootzapp/wootz-browser)을 만들고 있는데, 웹 데이터나 이미지 라벨링에 시간을 쓰고 보상을 받을 수 있는 데이터 라벨링용 Robinhood 같은 서비스임
      현재는 Chromium 기반이고, Blitz가 다른 브라우저에 꽂아 쓸 수 있는 렌더러가 되려는지 궁금함. 모바일도 하고 있으며 지금은 Android, 다음은 iOS임
  • 이 프로젝트는 얼핏 봐도 매우 유용해 보임
    널리 쓰이는 HTML/CSS 레이아웃 패러다임으로 네이티브 앱을 만들되, 완전한 JS/DOM/브라우저 API가 암시하는 무거운 부분은 빼는 방식임. Electron처럼 브라우저 엔진을 패키징하는 것보다 훨씬 큰 개선을 가능하게 할 수 있어 보임
    마침 최근 Richard Feldman의 팟캐스트에서 Casey Muratori가 CSS를 매우 비판적으로 이야기한 것을 들었음. 단순한 레이아웃 관계를 만들려고 웹페이지를 미리 렌더링하고 동적으로 측정해야 했다는 사례들이 특히 와닿았음
    Muratori 말처럼 CSS 작성은 단순한 기본 요소 위에 쌓아 올린다기보다 법정에서 사건을 변론하는 느낌에 가까움
    물론 익숙함, 호환성, “잘 되는 경로의 CSS”가 엄청나게 생산적이라는 점 때문에 이런 프로젝트가 만족시키는 수요는 큼. 다만 사용자가 내려가서 쓸 수 있는 더 단순하고 일반적인 계층을 제공할 기회도 있어 보임
    CSS를 JS API로 확장 가능하게 하려는 CSS Houdini에서 영감을 얻을 수도 있고, 혹시 이것이 “Custom Widgets”가 의미하는 바일 수도 있음

    • 거의 그게 Blitz의 제안에 가까움
      플러그 가능한 레이아웃 알고리즘은 Blitz에서 꼭 가능하게 만들고 싶은 부분임. 레이아웃을 JS로 하면 대부분의 경우 너무 느릴 것 같지만, API가 Rust라는 점에서 유리함
      레이아웃 엔진 Taffy(https://github.com/DioxusLabs/taffy)도 이미 상당히 모듈식임
      커스텀 위젯은 레이아웃을 넘어 전통적인 GUI 도구킷의 위젯처럼 완전한 커스텀 레이아웃, 페인트, 접근성, 이벤트 처리 등을 허용하려는 것임
      CSS 자체에 새 단위를 추가하는 제안도 갖고 있음. 웹이 아닌 많은 UI 시스템의 레이아웃 방식에서 영감을 받은 것으로, 일반적인 경우 웹 레이아웃을 크게 단순화할 가능성이 있음: https://github.com/w3c/csswg-drafts/issues/8267
      한동안 뒤로 밀려 있었지만 언젠가 다시 해야 하고, 실제로 알고리즘을 구현해 보고 싶음
    • 개선된 Dillo 같은 느낌인지 궁금함: https://en.m.wikipedia.org/wiki/Dillo
      단순한 웹 브라우징이나 앱에는 그런 것이 있으면 좋겠음. 알고 있던 비슷한 것은 Sciter뿐이었고, 독점 소프트웨어였지만 라이선스 방식은 혁신적이었음
    • 군더더기를 제거하고 성능 향상을 약속하는 엄격한 CSS가 필요함. 브라우저들이 왜 아직 제공하지 않는지 모르겠고, 예를 들어 float만 빼도 됨
  • 몇 년 전, 아니 20년 전에 Flying Saucer라는 비슷한 오픈소스 프로젝트를 만들었음. 순수 Java 기반 HTML + CSS2 렌더러였음
    게임에서 풍부한 텍스트 UI를 렌더링하는 데 쓸 거라고 상상했지만, 실제 핵심 용도는 서버 측 PDF 생성이었음. 당시 제공되던 여러 PDF 리포트 생성 API를 쓰는 것보다 HTML을 생성해 PDF로 렌더링하는 편이 훨씬 쉬웠음
    Blitz는 멋져 보이고, Rust GUI 라이브러리가 더 많아지는 게 기대됨
    https://en.wikipedia.org/wiki/Flying_Saucer_(library)
    놀랍게도 아직도 업데이트되고 있음: https://github.com/flyingsaucerproject/flyingsaucer/releases...

  • “JavaScript 엔진을 네이티브 Rust API로 대체한 가벼운 웹뷰”라니 유망해 보임. 기본적으로 JS가 경로에 없는 Tauri 같은 것이라면 듣기만 해도 좋음

    • 어느 정도는 맞지만, Tauri는 시스템 웹뷰를 쓰는 반면 우리는 자체 웹뷰를 만들고 있음
      일부는 Servo 컴포넌트와 범용 라이브러리 위에, 일부는 직접 만든 것임. 어떤 면에서는 JS 없는 Sciter에 더 가까움
    • Sciter가 더 나은 비교 대상일 것 같음: https://sciter.com/
      HTML과 CSS 렌더링을 처음부터 구현한 것임. 기억하기로는 예전에는 자체 프로그래밍 언어가 있었고 지금은 JS를 씀
      이런 종류에 오래 관심은 있었지만 Sciter를 깊이 써보지는 않았음. 예전에는 라이선스가 걱정이었는데 지금 사이트를 보니 조건이 훨씬 유연해진 듯함
      시스템 웹뷰에서 JS 없이 쓰고 싶다면 그냥 시스템 웹뷰에서 JS를 끄면 된다는 점도 덧붙일 만함
    • Tauri는 네이티브 웹뷰를 쓰기 때문에 플랫폼마다 다름. Blitz는 자체 렌더러
  • 흥미로움. 바로 오늘 puppeteer와 헤드리스 Chromium 때문에 끔찍한 일을 겪고 wkhtmltopdf 대체재를 찾고 있었음
    LD_PRELOAD에 jemalloc을 넣고 실행하는 건 절대 하지 말아야 함. 문제는 해결했지만, 단순한 렌더러 쪽이 더 마음에 들었음

    • PDF 렌더링 용도에 관심을 보인 사람이 처음은 아님
      아마 인쇄 지향 CSS 속성과 페이지 기반 레이아웃 지원이 더 필요할 것 같음. 여러 개의 개별 페이지에 걸쳐 레이아웃을 나누고 페이지 나눔 위치를 제어하는 기능임
      그래도 언젠가는 확실히 지원할 수 있어야 하는 영역이라고 봄
    • 내 용도는 조금 달랐음. Playwright에서 Chromium Headless를 써서 페이지의 한 요소를 렌더링하려 했는데, Playwright에서 "Page crashed"와 "Timed out after 30s"가 무작위로 많이 발생했음
      Firefox Headless로 바꾸자 이런 문제가 사라졌고, 실제로 Firefox로 바꾸니 렌더러가 Chromium Headless보다 약 3배 빨라졌음
      Blitz는 매우 흥미롭고 내가 필요로 하던 것에 가까움. 직접 Java Graphics2D로 전부 렌더링하는 대신 헤드리스 브라우저를 쓰고 있었는데, 렌더링할 대상의 레이아웃이 좀 복잡해서 자체 레이아웃 엔진을 만들어 바퀴를 다시 발명하고 싶지 않았음
    • gotenberg[0]를 확인해 보면 필요를 충족할 수도 있음. GitHub Actions에서 이력서를 PDF로 변환하는 데 쓰고 있음
      [0]: https://github.com/gotenberg/gotenberg
    • 맞음, Wkhtmltopdf는 정말 자원 먹는 괴물
      다른 솔루션들은 HTML 명세 지원이 불완전해서 원하는 PDF를 제대로 만들기 어려움. 누군가 덜 현대적인 기능만으로 방법을 찾아내지 않는 한 그렇음
  • Blitz 자체에 대한 얘기는 아니지만 Dioxus를 처음 알게 됨
    WASM으로 컴파일되는 프레임워크들은 데모를 제대로 보여주지 않거나 자기 사이트를 해당 프레임워크로 직접 호스팅하지 않는 암묵적 규칙이라도 있는지 궁금함. 이런 걸 5~6번은 본 것 같음
    Dioxus 홈페이지에서 WASM 파일이 로드되는 건 보이지만, 어디에 쓰이는지 또는 실제로 쓰이는지 명확하지 않음

    • Dioxus 사이트는 자기 프레임워크로 호스팅되고 있지만, 서버 측 렌더링과 하이드레이션을 지원하기 때문에 WASM 번들은 상호작용 기능에만 쓰임
      동영상 데모도 준비 중임. 특별히 보고 싶은 것이 있는지 궁금함
  • 백엔드와 htmx를 같이 쓰면 멋질 수 있겠음. 다만 JS 엔진이 아예 섞이지 않는 것 같아서 어떻게 할 수 있을지 궁금함

    • 전설적인 조합이 될 것 같음
      이상적으로는 웹 렌더러가 HTMX를 네이티브로 지원해야 함
      HTMX의 일반적인 발상은 HTML을 더 완전하게 만드는 기능을 지원하는 것임. 왜 <a><form>만 HTTP 요청을 할 수 있어야 하는가, 왜 클릭과 제출 이벤트만 요청을 트리거해야 하는가, 왜 GET과 POST만 가능해야 하는가, 왜 전체 화면만 교체할 수 있어야 하는가
      다르게 보면 HTMX는 HTML 요소를 덜 제한적이고 더 일반적으로 만듦. 웹 렌더러가 설계할 때 이를 고려하면 오히려 더 단순해질 수도 있음
    • 핵심 HTMX 기능을 HTML 명세에 넣으려는 흐름이 있어서 JS가 필요 없어질 수도 있음
      https://www.reddit.com/r/htmx/comments/1ehjw7v/comment/lg09w...
    • 간단함. htmx를 Dioxus로 바꾸거나, 나중에는 어쩌면 leptos로 바꾸면 됨
  • Dioxus를 오늘 처음 알게 됨
    https://dioxuslabs.com/

  • 정말 멋짐. C++ 프로젝트에서 써보고 싶음
    한 가지 떠오른 질문은 성능임. 비교적 복잡한 페이지를 높은 초당 프레임 수로 렌더링할 수 있는지 궁금함
    보통 ImGUI를 쓰는데, 실시간 데이터를 표시할 때 성능 문제를 거의 생각하지 않아도 될 만큼 훌륭함. 반면 Chromium의 웹 렌더링은 단순한 DOM 텍스트 업데이트를 초당 10프레임으로만 해도 CPU를 태워버리는데, 이게 해결되면 판도가 바뀔 수 있음

    • 현재 성능은 형편없음
      하지만 최적화에는 아직 전혀 힘을 들이지 않았고, 꽤 빠른 의존성들 위에 만들고 있어서 훨씬 좋아질 가능성은 있음
      “공정한 싸움”에서 Chromium을 이기지는 못할 것 같지만, Chrome에서는 불가능한 것들을 가능하게 할 잠재력이 있음. 예를 들어 훨씬 강력한 canvas 유사 API 같은 것임