Leptos, Yew, Dioxus - Rust 웹 프레임워크 비교

1. 서론: Rust 웹 프레임워크의 부상

1.1 WebAssembly(WASM)와 Rust의 만남: 프론트엔드 개발의 새로운 패러다임

현대 웹 개발 패러다임은 WebAssembly(이하 WASM)의 등장으로 인해 근본적인 변화의 기로에 서 있다. WASM은 웹 브라우저에서 네이티브에 가까운 성능으로 코드를 실행할 수 있도록 설계된 바이너리 명령어 형식으로, 기존 JavaScript의 성능 한계를 극복하고 웹 애플리케이션의 가능성을 확장하는 핵심 기술로 자리 잡았다.1 C/C++, C#, Go 등 다양한 저수준 언어들이 WASM으로 컴파일될 수 있지만, 그중에서도 Rust는 이 새로운 생태계에서 가장 주목받는 언어이다.

Rust가 프론트엔드 개발의 강력한 대안으로 부상한 이유는 언어 자체가 가진 핵심 가치에 기인한다. 첫째, 컴파일 시점에 소유권(ownership)과 빌림(borrowing) 규칙을 통해 메모리 안전성을 보장함으로써, JavaScript 생태계에서 흔히 발생하는 null 참조 오류, 경쟁 상태(race condition)와 같은 런타임 에러를 원천적으로 방지한다.2 둘째, ’두려움 없는 동시성(fearless concurrency)’을 모토로 하는 만큼, 복잡한 비동기 처리나 병렬 연산을 안전하고 효율적으로 다룰 수 있어 데이터 집약적인 최신 웹 애플리케이션에 적합하다. 마지막으로, 제로 코스트 추상화(zero-cost abstraction)를 통해 고수준의 코드 작성을 지원하면서도 C/C++에 필적하는 실행 속도를 제공한다.4 이러한 특성들은 웹 애플리케이션이 점차 데스크톱 애플리케이션 수준의 복잡성과 성능을 요구하는 현시대의 요구와 정확히 일치한다.

이러한 기술적 전환의 배경에는 wasm-pack과 같은 성숙한 툴체인의 발전이 있었다. wasm-pack은 Rust 크레이트(crate, Rust의 패키지 단위)를 브라우저가 이해할 수 있는 WASM 모듈로 컴파일하고, JavaScript와의 상호 운용을 위한 바인딩 코드를 자동으로 생성하며, npm 패키지로 배포하는 일련의 복잡한 과정을 간소화한다.1 이로써 Rust 개발자들은 언어의 강력함을 웹 프론트엔드 영역에서 온전히 발휘할 수 있는 견고한 기반을 갖추게 되었다. 이처럼 WASM과 Rust의 결합은 단순히 새로운 기술 스택의 등장을 넘어, 웹 개발의 성능, 안정성, 생산성에 대한 기준을 재정의하는 패러다임의 전환을 이끌고 있다.

1.2 Leptos, Yew, Dioxus: Rust 웹 생태계의 3대 주자

Rust와 WASM이 마련한 새로운 토양 위에서, 각기 다른 철학과 아키텍처를 가진 세 개의 주요 프레임워크가 등장하여 Rust 웹 생태계의 발전을 주도하고 있다. 이들은 Leptos, Yew, Dioxus로, 각각 뚜렷한 목표와 장점을 내세우며 차세대 웹 애플리케이션 개발의 미래를 탐색하고 있다.

Yew는 이들 중 가장 먼저 등장하여 가장 성숙한 생태계를 구축한 프레임워크이다.6 Yew는 React와 Elm 아키텍처에서 깊은 영감을 받아, 컴포넌트 기반 아키텍처와 가상 DOM(Virtual DOM)을 채택했다.1 html! 매크로를 통해 JSX와 유사한 선언적 UI 작성을 지원하여 React 개발자들에게 매우 친숙한 개발 경험을 제공한다.8 오랜 기간 커뮤니티를 통해 검증된 안정성과 상대적으로 풍부한 라이브러리는 Yew의 가장 큰 자산이다.

Leptos는 성능의 극한을 추구하는 풀스택 프레임워크로, 가장 차별화되는 특징은 가상 DOM을 사용하지 않는다는 점이다.1 대신 JavaScript 프레임워크인 SolidJS에서 영감을 받은 ‘세밀한 반응성(fine-grained reactivity)’ 시스템을 기반으로 한다.7 상태(state)가 변경되었을 때 UI의 특정 부분만을 정밀하게 직접 업데이트함으로써, 가상 DOM 비교(diffing) 과정에서 발생하는 오버헤드를 원천적으로 제거하여 압도적인 런타임 성능을 자랑한다. 또한, #[server] 매크로를 통해 프론트엔드와 백엔드를 하나의 코드베이스에서 완벽하게 통합하는 ‘동형(isomorphic)’ 개발 경험을 제공하는 것을 핵심 철학으로 삼는다.4

Dioxus는 웹을 넘어 데스크톱, 모바일, 심지어 터미널 UI(TUI)까지 아우르는 크로스플랫폼 개발을 목표로 하는 가장 야심 찬 프레임워크이다.12 Dioxus는 스스로를 React의 개발 경험과 Flutter의 크로스플랫폼 비전을 결합한 ’더 나은 Flutter’로 자칭하며, 단일 Rust 코드베이스로 모든 플랫폼에 대응하는 것을 지향한다.14 React Hooks와 거의 동일한 API를 제공하여 개발자 진입 장벽을 낮추었고, 고도로 최적화된 자체 가상 DOM 구현을 통해 뛰어난 성능을 추구한다.12

이 세 프레임워크는 단순히 기능 목록의 차이를 넘어, 웹 애플리케이션을 구축하는 근본적인 접근 방식에서부터 차이를 보인다. 본 보고서는 Leptos, Yew, Dioxus의 핵심 아키텍처, 성능 벤치마크, 개발자 경험, 생태계 성숙도 등 다각적인 측면을 심층적으로 비교 분석함으로써, 특정 프로젝트의 요구사항에 가장 적합한 기술을 선택할 수 있는 명확하고 신뢰할 수 있는 기준을 제시하는 것을 목표로 한다.

2. 핵심 아키텍처 및 철학 비교 분석

프레임워크의 선택은 단순히 기능의 유무를 넘어, 그 근간을 이루는 아키텍처와 철학에 대한 깊은 이해를 바탕으로 이루어져야 한다. 아키텍처는 성능의 한계를 결정하고, 철학은 개발자 경험과 생산성의 방향을 제시하기 때문이다. Leptos, Yew, Dioxus는 렌더링 전략과 개발 패러다임이라는 두 가지 핵심 축에서 뚜렷한 차이를 보이며, 이는 각 프레임워크의 정체성을 규정하는 가장 중요한 요소이다.

2.1 렌더링 전략: 세밀한 반응성(Fine-Grained Reactivity) vs. 가상 DOM(Virtual DOM)

UI 프레임워크의 핵심은 ’상태가 변경되었을 때 어떻게 화면을 효율적으로 갱신하는가’에 있으며, 이 질문에 대한 Leptos의 답변과 Yew/Dioxus의 답변은 근본적으로 다르다. 이 차이는 두 가지 기술, 즉 ’세밀한 반응성’과 ’가상 DOM’으로 요약된다.

2.1.1 Leptos (No VDOM)

Leptos는 가상 DOM(Virtual DOM)을 완전히 배제하고, SolidJS와 Sycamore 프레임워크에서 영감을 받은 세밀한 반응성 시스템을 아키텍처의 심장부로 채택했다.7 이 모델의 작동 원리는 다음과 같다.

1. 반응성 그래프 구축: 컴포넌트가 처음 렌더링될 때, 그 함수는 단 한 번만 실행된다. 이 과정에서 UI를 구성하는 템플릿이 실제 DOM 노드로 생성됨과 동시에, 상태(State)와 그 상태에 의존하는 DOM 노드 간의 관계가 ’반응성 그래프(reactive graph)’로 구축된다.7 상태는 signal이라는 원자적 단위로 표현되며, 이 signal을 읽는 모든 UI 부분(예: 텍스트 노드, 속성)은 해당 signal의 구독자가 된다.
2. 정밀한 직접 업데이트: 이후 signal의 값이 변경되면, 프레임워크는 컴포넌트 함수를 다시 실행하거나 가상 DOM 트리를 비교하는 대신, 반응성 그래프를 따라 해당 signal을 구독하고 있던 DOM 노드에 직접 접근하여 필요한 부분만 정확하게 수정한다.4 예를 들어, let (count, set_count) = signal(0);으로 선언된 상태가 <p>{count}</p>에서 사용되었다면, set_count(1)이 호출될 때 오직 <p> 태그 내부의 텍스트 노드만 0에서 1로 변경될 뿐, 다른 어떤 코드도 실행되지 않는다.

이 방식의 가장 큰 장점은 가상 DOM diffing 및 reconciliation 과정에서 발생하는 모든 연산 오버헤드가 원천적으로 사라진다는 점이다. 애플리케이션의 규모가 커지고 상태가 복잡해져도, 업데이트 비용은 변경되는 상태의 수에만 비례하므로 극도로 높은 성능과 효율성을 유지할 수 있다. 이는 수많은 데이터 포인트가 실시간으로 변하는 대시보드나 데이터 시각화 애플리케이션에서 특히 강력한 이점을 제공한다.

2.1.2 Yew & Dioxus (VDOM)

반면, Yew와 Dioxus는 지난 10년간 웹 프론트엔드 개발의 표준으로 자리 잡은 React의 가상 DOM 모델을 계승하고 발전시킨다.1 이 모델은 실제 DOM을 직접 조작하는 비용이 비싸다는 전제에서 출발하며, 다음과 같은 과정을 거친다.

1. 가상 DOM 트리 생성: 상태가 변경되면, 해당 상태를 사용하는 컴포넌트의 렌더링(뷰) 함수가 다시 호출된다. 이 함수는 실제 DOM 구조를 모방한 순수 Rust 데이터 구조, 즉 가상 DOM 트리를 반환한다.8
2. 비교 및 조정 (Diffing & Reconciliation): 프레임워크는 새로 생성된 가상 DOM 트리와 이전 상태의 가상 DOM 트리를 비교하여 차이점을 찾아낸다(diffing).
3. 최소한의 DOM 업데이트: 발견된 차이점들을 바탕으로, 실제 DOM에 적용해야 할 최소한의 변경사항 목록(예: ‘id가 “counter“인 요소의 텍스트를 “1“로 변경하라’)을 계산하고, 이를 실제 DOM에 한 번에 적용(patch)한다.

이 접근 방식은 개발자가 DOM을 직접 다루지 않고 선언적으로 UI를 작성하는 데 집중할 수 있게 해주며, React 생태계에 익숙한 수많은 개발자들에게 낮은 학습 곡선을 제공한다.

• Yew는 초기에 Elm 아키텍처의 영향을 강하게 받았으나, 현재는 React의 함수형 컴포넌트와 Hooks 모델을 적극적으로 채택하여 발전했다.7 Yew의 독특한 점 중 하나는 백그라운드 웹 워커(Web Workers)를 활용한 멀티스레딩을 프레임워크 수준에서 지원한다는 것이다. 이를 통해 무거운 연산 작업을 별도의 스레드로 보내 UI 스레드의 반응성을 유지할 수 있어, 복잡한 계산이 필요한 애플리케이션에서 장점을 가진다.9
• Dioxus는 React Hooks와 거의 100%에 가까운 API 호환성을 목표로 하여, use_signal과 같은 훅을 통해 상태를 관리한다.12 Dioxus는 Sledgehammer라고 불리는 자체 개발 고성능 가상 DOM 엔진을 사용하여 기존 VDOM 구현체들의 성능 한계를 극복하고자 시도했다는 점이 특징이다.16 이는 React에 익숙한 개발자들이 거의 학습 비용 없이 Rust의 성능과 안정성을 누릴 수 있도록 하는 것을 목표로 한다.

결론적으로, 렌더링 전략의 선택은 프레임워크의 핵심적인 성능 특성과 개발자 경험을 결정한다. Leptos는 패러다임의 전환을 감수하더라도 최고의 런타임 성능을 얻고자 하는 프로젝트에, Yew와 Dioxus는 검증된 VDOM 모델의 안정성과 React 개발자들의 생산성을 극대화하고자 하는 프로젝트에 더 적합한 선택이라 할 수 있다.

2.2 개발 패러다임: 풀스택 통합 vs. 크로스플랫폼 지향

프레임워크가 지향하는 최종 목표, 즉 개발 패러다임은 기술 스택의 범위와 애플리케이션의 배포 형태에 지대한 영향을 미친다. Leptos는 웹의 프론트엔드와 백엔드를 하나로 묶는 ’풀스택 통합’에, Dioxus는 웹을 넘어 모든 플랫폼을 아우르는 ’크로스플랫폼’에, 그리고 Yew는 전통적인 ‘웹 중심’ 개발에 초점을 맞추고 있다.

2.2.1 Leptos (Full-Stack Isomorphism)

Leptos의 핵심 철학은 ‘동형(isomorphic)’ 또는 ‘보편적(universal)’ 개발, 즉 클라이언트와 서버에서 동일한 언어(Rust)와 동일한 코드를 사용하여 웹 애플리케이션을 구축하는 것이다. 이를 실현하는 가장 강력한 도구가 바로 #[server] 함수 매크로이다.4

개발자는 #[server] 어트리뷰트를 함수에 붙이는 것만으로 서버에서만 실행되는 코드를 작성할 수 있다. 프론트엔드 코드에서 이 함수를 호출하면, Leptos는 컴파일 시점에 자동으로 네트워크 요청(보통 API 호출)을 생성하는 코드로 변환해준다. 이 과정은 개발자에게 완전히 투명하게 이루어지므로, 마치 일반적인 Rust 함수를 호출하는 것처럼 서버의 데이터베이스에 접근하거나 파일 시스템을 조작할 수 있다.

이러한 ‘풀스택 컴포넌트’ 개념은 여러 고질적인 웹 개발 문제를 해결한다 4:

• 타입 안전성: 클라이언트와 서버 간 데이터 전송에서 발생할 수 있는 타입 불일치 문제가 컴파일 시점에 모두 잡힌다.
• 보일러플레이트 제거: 별도의 REST 또는 GraphQL API 엔드포인트를 설계하고, 직렬화/역직렬화 로직을 작성하고, fetch 코드를 관리할 필요가 없다.
• 개발 생산성: 프론트엔드 개발자가 백엔드 로직을 직접 수정하거나, 백엔드 개발자가 UI와 관련된 데이터 흐름을 쉽게 파악할 수 있어 컨텍스트 전환 비용이 크게 줄어든다.
• 유연성: 동일한 코드베이스를 사용하여 순수 클라이언트 사이드 렌더링(CSR), 서버 사이드 렌더링(SSR), 그리고 SSR 이후 클라이언트에서 상호작용을 추가하는 하이드레이션(Hydration) 모드를 모두 지원한다.17

Leptos는 웹 애플리케이션의 프론트엔드와 백엔드 사이의 인위적인 경계를 허물고, Rust라는 단일 언어를 통해 전체 스택을 아우르는 통합적이고 생산적인 개발 경험을 제공하는 것을 궁극적인 목표로 한다.

2.2.2 Dioxus (Write-Once, Run-Anywhere)

Dioxus의 비전은 Leptos보다 훨씬 광범위하다. “하나의 코드베이스, 모든 플랫폼(One codebase, every platform)“이라는 슬로건 아래, 웹(WASM)을 넘어 네이티브 데스크톱(Windows, macOS, Linux), 모바일(iOS, Android), 심지어 터미널(TUI)까지 지원하는 것을 목표로 한다.12

이러한 비전은 Flutter와 유사하지만, Dioxus는 몇 가지 중요한 차별점을 가진다 13:

• 네이티브 실행: 별도의 가상 머신(VM) 없이 코드가 네이티브로 실행되어 더 나은 성능과 슬림한 결과물을 제공한다.
• 웹 표준 기술 활용: UI는 커스텀 렌더링 엔진 대신 HTML과 CSS를 사용하여 선언한다. 데스크톱에서는 시스템의 WebView(Windows의 WebView2, macOS/Linux의 WebKitGTK)를 렌더러로 사용한다.
• 직접적인 시스템 API 접근: 필요할 경우 web-sys(웹), jni(안드로이드) 등을 통해 각 플랫폼의 네이티브 API에 직접 접근(FFI)할 수 있는 유연성을 제공한다.

Dioxus는 dx라는 강력한 CLI 도구를 통해 이 모든 복잡성을 추상화한다.19 개발자는 dx serve --platform desktop 또는 dx serve --platform web과 같은 간단한 명령어로 타겟 플랫폼을 변경하며 개발 및 테스트를 진행할 수 있다. UI 로직은 플랫폼에 구애받지 않도록 작성되고, Dioxus의 렌더러가 각 플랫폼에 맞는 최종 결과물로 변환해주는 구조이다. Dioxus의 철학은 Rust를 사용하여 진정한 의미의 ‘한 번 작성하고 어디서든 실행하는(Write-Once, Run-Anywhere)’ 애플리케이션을 만드는 것이다.

2.2.3 Yew (Web-Centric with Extensibility)

Yew는 앞선 두 프레임워크와 달리, 그 초점이 WASM을 활용한 고성능 단일 페이지 애플리케이션(SPA) 구축이라는 웹 영역에 명확하게 맞춰져 있다.9 Yew의 아키텍처와 기능들은 웹 브라우저 환경에서 최상의 성능과 개발 경험을 제공하는 데 집중되어 있다.

물론 Yew로 데스크톱 애플리케이션을 만드는 것이 불가능한 것은 아니다. Tauri와 같은 외부 프레임워크와 결합하면, Yew로 작성된 웹 프론트엔드를 네이티브 애플리케이션의 UI로 패키징할 수 있다.21 하지만 이는 Dioxus처럼 프레임워크 자체에 내장된 크로스플랫폼 비전이라기보다는, 잘 만들어진 웹 애플리케이션을 다른 환경으로 확장하는 방식에 가깝다. Yew 또한 서버 사이드 렌더링(SSR)을 지원하지만 8, Leptos처럼 풀스택 통합을 프레임워크의 핵심 정체성으로 내세우지는 않는다. Yew의 철학은 Rust와 WASM을 사용하여 가장 안정적이고 효율적인 웹 프론트엔드 애플리케이션을 만드는 데 있다.

표 1: 핵심 아키텍처 및 철학 비교

3. 성능 벤치마크 심층 분석

Rust 기반 프레임워크를 고려하는 가장 큰 이유 중 하나는 성능이다. 따라서 객관적인 벤치마크 데이터를 통해 각 프레임워크의 성능 특성을 정량적으로 분석하는 것은 기술 선택 과정에서 필수적이다. 본 장에서는 널리 알려진 js-framework-benchmark 결과를 중심으로 렌더링 속도, 메모리 사용량, 그리고 WASM 애플리케이션의 중요한 척도인 바이너리 크기를 심층적으로 분석한다.

3.1 렌더링 속도 및 CPU 사용량 (js-framework-benchmark)

js-framework-benchmark는 다양한 JavaScript 및 WASM 프레임워크의 클라이언트 사이드 렌더링(CSR) 성능을 측정하는 사실상의 표준 벤치마크이다. 주요 테스트 시나리오는 다음과 같다 23:

• Create rows: 1,000개 또는 10,000개의 행을 가진 테이블을 동적으로 생성하는 속도.
• Replace all rows: 테이블의 모든 행을 새로운 데이터로 교체하는 속도.
• Partial update: 10,000개의 행 중 10번째 행마다 텍스트를 업데이트하는 속도.
• Select row: 특정 행을 선택(클래스 변경)하는 속도.
• Swap rows: 테이블 내 두 행의 위치를 바꾸는 속도.
• Remove row: 특정 행을 삭제하는 속도.

최신 벤치마크 결과(Chrome 141 기준)를 분석하면 일관된 경향성이 나타난다.25 Leptos는 대부분의 렌더링 관련 테스트 항목에서 최상위권을 차지하며, 종종 순수 JavaScript(vanillajs) 구현에 근접하는 압도적인 성능을 보여준다. 이는 2.1절에서 분석한 바와 같이, 가상 DOM을 사용하지 않고 변경이 필요한 DOM 노드만 직접 수정하는 세밀한 반응성 아키텍처의 효율성이 데이터로 입증된 결과이다.7 특히 ’Partial update’나 ’Select row’와 같이 작은 규모의 업데이트가 빈번하게 발생하는 시나리오에서 VDOM 기반 프레임워크와의 성능 격차가 두드러진다.

Dioxus와 Yew는 가상 DOM을 사용함에도 불구하고 매우 우수한 성능을 보여준다. Dioxus는 과거 특정 버전의 벤치마크에서는 Leptos를 앞선 적도 있을 만큼, 자체 VDOM 엔진의 최적화 수준이 높음을 증명했다.27 벤치마크의 가중치나 측정 방식 변경에 따라 순위는 변동될 수 있으나, 전반적으로 Dioxus는 고성능 VDOM 프레임워크 군에 속한다. Yew는 일반적으로 React나 Preact와 유사한 수준의 성능을 기록하며, 안정적인 성능을 제공한다.6

그러나 이 벤치마크 결과를 해석할 때는 그 한계를 명확히 인지해야 한다. js-framework-benchmark는 다음과 같은 중요한 측면을 측정하지 않는다 24:

• 서버 사이드 렌더링(SSR) 및 하이드레이션(Hydration) 성능: 초기 페이지 로딩 속도(Time to First Byte, Largest Contentful Paint)에 결정적인 영향을 미치는 SSR 성능은 이 벤치마크의 범위 밖이다.
• 페이지 전환(SPA Navigation) 성능: 사용자가 앱 내에서 다른 페이지로 이동할 때의 성능은 측정되지 않는다.
• 단일 컴포넌트 중심: 대부분의 테스트가 거대한 단일 테이블 컴포넌트를 대상으로 하므로, 수백 개의 작은 컴포넌트로 구성된 복잡한 애플리케이션의 실제 성능을 완벽히 대변하지 못할 수 있다.

따라서 이 벤치마크는 데이터 집약적인 CSR 환경에서의 순수 렌더링 성능을 비교하는 데는 매우 유용하지만, 이를 프레임워크의 전반적인 성능을 나타내는 유일한 지표로 삼아서는 안 된다.

3.2 메모리 점유율 및 스타트업 시간

메모리 사용량은 특히 장시간 실행되는 애플리케이션이나 리소스가 제한된 환경에서 중요한 성능 지표이다. js-framework-benchmark의 ‘Startup memory usage’ 항목은 애플리케이션이 로드된 직후의 힙 메모리 사용량을 측정한다. 일반적으로 WASM 기반 프레임워크는 자체 메모리 관리자(allocator)와 런타임 일부를 포함해야 하므로, 초경량 JavaScript 프레임워크에 비해 초기 메모리 점유율이 다소 높게 나타나는 경향이 있다.28

여기서 주목할 만한 점은 Dioxus의 내부 메모리 관리 방식에 대한 커뮤니티의 논의이다. 한 분석에 따르면, Dioxus가 사용하는 generational-box라는 의존성 라이브러리의 특정 구현 방식이, 이론적으로 메모리 사용량이 무한정 증가할 수 있는 시나리오를 만들 수 있다는 우려가 제기되었다.27 이는 signal을 Copy 트레이트를 만족하도록 만들기 위한 설계에서 비롯된 것으로, 잠재적인 메모리 누수 리스크를 내포할 수 있다. 반면, Leptos는 slotmap이라는 다른 자료 구조를 사용하여 이 문제를 회피하는 접근 방식을 취하고 있어, 장기 실행 안정성 측면에서 더 견고한 설계를 가졌을 가능성을 시사한다.27

스타트업 시간은 사용자가 애플리케이션과 상호작용하기까지 걸리는 시간(Time to Interactive)과 밀접한 관련이 있으며, 이는 주로 WASM 바이너리의 크기와 파싱 시간에 의해 결정된다. 다음 절에서는 이 바이너리 크기 문제를 더 자세히 다룬다.

3.3 WASM 바이너리 크기 비교 및 최적화 전략

WASM 기반 프론트엔드 애플리케이션이 가진 가장 큰 아킬레스건은 초기 로딩 시 전체 WASM 바이너리를 다운로드하고 컴파일해야 한다는 점이다. JavaScript 생태계에서는 코드 분할(code splitting)을 통해 필요한 코드만 동적으로 로드하는 것이 일반적이지만, Rust/WASM 생태계에서는 이 기술이 아직 성숙하지 않아 구현이 매우 어렵다.29 따라서 초기 번들 크기는 사용자 경험에 직접적인 영향을 미치는 매우 중요한 요소이다.

커뮤니티에서 진행된 간단한 “Hello, world” 애플리케이션 비교에 따르면, 릴리즈 모드로 빌드했을 때 Dioxus는 약 65kb의 바이너리를 생성한 반면, Leptos는 그보다 약 3배 더 큰 바이너리를 생성했다고 보고되었다.6 Yew는 통상적으로 중간 크기의 바이너리를 생성하는 것으로 알려져 있다.7 이 결과는 Dioxus가 초기 로딩 속도 면에서 잠재적인 우위를 가질 수 있음을 시사한다. 이는 특히 첫 페이지 로딩 속도가 중요한 콘텐츠 중심의 웹사이트나 이커머스 플랫폼에서 중요한 고려사항이 될 수 있다.

물론, 이 수치는 최적화되지 않은 기본 빌드 결과일 수 있으며, 실제 애플리케이션의 크기는 의존성과 코드 구조에 따라 크게 달라진다. 다행히 Rust/WASM 생태계는 바이너리 크기를 줄이기 위한 다양한 최적화 기법을 제공한다 30:

• 컴파일러 최적화: Cargo.toml의 [profile.release] 섹션에 lto = true(Link Time Optimization), opt-level = "z" 또는 "s"(크기 최적화), codegen-units = 1(더 나은 최적화를 위해 단일 스레드로 컴파일) 등의 플래그를 설정한다.
• 후처리 도구: Binaryen 툴킷에 포함된 wasm-opt 도구를 사용하여 컴파일된 WASM 바이너리를 추가로 최적화한다. -Oz 또는 -Os 플래그를 사용하면 보통 15-20%의 추가적인 크기 감소 효과를 볼 수 있다.
• 코드 크기 프로파일링: twiggy와 같은 도구를 사용하여 WASM 바이너리의 어느 부분이 크기를 많이 차지하는지 분석하고, 불필요한 의존성을 제거하거나 코드 구조를 변경하여 크기를 줄일 수 있다.

이러한 최적화 전략은 모든 Rust/WASM 프레임워크에 공통으로 적용될 수 있다. 또한, Leptos는 현재 개발 중인 새로운 렌더러를 통해 번들 크기와 성능을 더욱 개선할 것이라고 밝혀, 향후 이 격차는 줄어들 수 있다.29

결론적으로, 성능은 단일 척도로 평가될 수 없는 다면적인 특성을 가진다. Leptos가 런타임 렌더링 속도에서 명백한 우위를 보이는 반면, Dioxus는 초기 로딩 속도와 직결되는 바이너리 크기에서 강점을 보일 수 있다. 따라서 프로젝트의 핵심 성능 요구사항이 무엇인지(예: 빠른 초기 로딩 vs. 부드러운 실시간 인터랙션)를 명확히 정의하고, 그에 맞는 아키텍처를 가진 프레임워크를 선택하는 전략적 접근이 필요하다.

표 2: 성능 벤치마크 요약 (js-framework-benchmark 기반)

주: 위 데이터는 js-framework-benchmark의 2024년 10월(Chrome 141) ‘keyed’ 프레임워크 결과에서 발췌 및 재구성되었음. 점수는 기하 평균으로, 낮을수록 우수함. 이 벤치마크는 CSR 렌더링 성능에 초점을 맞추며 SSR, Hydration, 페이지 전환 성능은 측정하지 않음.

24

4. 개발자 경험(DX) 및 생태계 성숙도 평가

뛰어난 성능에도 불구하고 개발자 경험(DX)이 열악하거나 생태계가 미성숙하다면 프레임워크는 널리 채택되기 어렵다. 개발자 경험은 생산성과 직결되며, 생태계는 문제 해결 능력과 직결되기 때문이다. 이 장에서는 툴링, 핵심 기능 구현 방식, 컴포넌트 라이브러리, 문서화 및 커뮤니티 측면에서 세 프레임워크를 비교 평가한다.

4.1 툴링, 빌드 프로세스, 및 핫 리로딩

효율적인 개발 워크플로우의 핵심은 강력한 툴링과 빠른 피드백 루프, 즉 핫 리로딩에 있다. 세 프레임워크는 이 부분에서 각기 다른 접근 방식을 취한다.

• Leptos: cargo-leptos라는 공식 CLI 도구를 제공한다.10 이 도구는 프로젝트 생성부터 CSR, SSR, 하이드레이션 모드 간의 전환, 빌드, 서빙까지 모든 과정을 통합 관리하여 복잡한 설정을 추상화한다. 커뮤니티에서는 cargo-leptos의 핫 리로딩 속도가 빠르다는 긍정적인 평가가 많다.21 이는 개발자가 코드를 수정한 후 UI 변경 사항을 즉시 확인할 수 있어 반복적인 개발 주기를 단축시키는 데 큰 도움이 된다. 다만, 일부 사용자는 HTML 요소를 새로 추가할 때 6~7초 가량의 지연이 발생한다는 상반된 경험을 보고하기도 했다.27
• Dioxus: dx라는 자체 개발 CLI를 통해 통합된 개발 환경을 제공하는 데 가장 적극적이다.19 dx는 프로젝트 템플릿 생성, 개발 서버 실행, 다양한 플랫폼(웹, 데스크톱 등)을 위한 번들링을 모두 처리한다. Dioxus의 가장 큰 장점 중 하나로 꼽히는 것이 바로 매우 빠른 핫 리로딩 속도이다.12 이는 Dioxus가 내부적으로 RSX 마크업의 변경 사항을 즉시 반영하는 고도로 최적화된 메커니즘을 갖추고 있기 때문이며, 개발자에게 거의 실시간에 가까운 피드백을 제공한다.
• Yew: 주로 Trunk라는 범용 WASM 웹 애플리케이션 번들러에 의존한다.31 Trunk는 설정이 비교적 간단하고 Rust/WASM 프로젝트를 서빙하는 데 널리 사용되는 검증된 도구이다. 그러나 Yew와 함께 사용할 때 핫 리로딩 속도가 상대적으로 느리다는 평가가 존재한다.22 이는 전체 애플리케이션을 다시 컴파일하고 로드하는 과정에서 발생하는 시간 때문일 수 있으며, 빠른 반복 개발이 중요한 프로젝트에서는 단점으로 작용할 수 있다.

종합적으로 볼 때, Dioxus가 핫 리로딩 속도와 통합된 CLI 경험에서 가장 우수한 개발자 경험을 제공하는 것으로 보인다. Leptos 역시 전용 툴을 통해 높은 수준의 편의성을 제공하며, Yew는 범용 툴을 사용하여 안정적이지만 상대적으로 느린 피드백 루프를 가질 수 있다.

4.2 핵심 기능 구현 방식 비교

프레임워크의 핵심 기능들이 어떤 API와 방식으로 구현되어 있는지는 개발자의 학습 곡선과 코드 스타일에 직접적인 영향을 미친다.

• 상태 관리:
• Leptos: signal을 중심으로 한 반응성 프리미티브가 핵심이다. create_signal로 상태를 만들고, create_memo로 파생된 값을 계산하며, create_resource를 통해 비동기 데이터를 반응형으로 다루는 등, 상태 관리의 모든 측면이 signal 시스템과 긴밀하게 통합되어 있다.17
• Yew: React Hooks와 매우 유사한 API를 제공한다. use_state 훅을 사용하여 컴포넌트의 로컬 상태를 관리하며, 더 복잡한 상태 로직을 위해 use_reducer를 사용할 수 있다.31 이는 React 경험이 있는 개발자에게 매우 친숙하다.
• Dioxus: React Hooks와의 API 호환성을 가장 중요하게 생각한다. use_signal (SolidJS/Preact Signals와 유사) 또는 use_state 훅을 통해 상태를 선언하고 수정하는 방식이 React와 거의 동일하여, 기존 React 개발자들이 거의 학습 비용 없이 Dioxus를 사용할 수 있다.12
• 라우팅:
• Leptos: leptos_router라는 공식 크레이트를 통해 강력한 라우팅 기능을 제공한다. 중첩 라우팅, 동적 경로 매개변수, 경로 기반 데이터 로딩(route-specific data loading) 등을 지원하여 복잡한 SPA 구조를 효과적으로 관리할 수 있다.17
• Yew: yew-router라는 공식 라우터 라이브러리를 제공하여 SPA 내비게이션을 구현한다.31
• Dioxus: 타입 안전성을 보장하는 라우팅 기능이 프레임워크에 내장되어 있다. 특히 풀스택 렌더러와 긴밀하게 통합되어 서버와 클라이언트 간의 라우팅 로직을 일관되게 관리할 수 있다는 장점이 있다.12
• 스타일링:
• 세 프레임워크 모두 특정 스타일링 솔루션을 강제하지 않으며, 개발자가 선호하는 방식을 자유롭게 선택할 수 있다. 일반 CSS 파일을 링크하거나, styled-components와 같은 CSS-in-JS 패턴을 구현하거나, 유틸리티 우선(utility-first) CSS 프레임워크를 통합할 수 있다.
• 특히 TailwindCSS와의 통합 경험에서 차이가 나타난다. Leptos는 view! 매크로 내에서 TailwindCSS 클래스에 대한 자동 완성(Intellisense)이 완벽하게 작동하여 개발 생산성을 크게 향상시킨다는 평가를 받는다.21 Dioxus 역시 dx CLI와 build.rs 스크립트를 통해 TailwindCSS 통합을 지원하며, 관련 가이드도 잘 마련되어 있다.16 Yew 또한 Trunk를 통해 TailwindCSS나 Bootstrap과 같은 프레임워크를 쉽게 통합하여 사용할 수 있다.36

4.3 컴포넌트 라이브러리 및 생태계

성숙한 컴포넌트 라이브러리의 존재는 개발 속도를 비약적으로 향상시키는 핵심 요소이다. 이 영역에서는 프레임워크의 성숙도가 큰 차이를 만들어낸다.

• Leptos: 비교적 신생 프레임워크임에도 불구하고 생태계가 매우 빠르게 성장하고 있다. leptos-use(다양한 유틸리티 훅 모음), thaw-ui(Fluent Design 기반 UI 라이브러리), leptonic과 같은 초기 라이브러리 외에도, 최근에는 shadcn/ui에서 영감을 받은 leptos-shadcn-ui와 Radix UI를 포팅한 radix-leptos가 등장했다.10 특히 후자의 두 라이브러리는 높은 수준의 완성도와 접근성을 갖춘 수십 개의 컴포넌트를 제공하여, 복잡한 UI를 빠르고 견고하게 구축할 수 있는 강력한 기반을 마련해주었다.
• Yew: 가장 오랜 역사를 가진 만큼, 가장 풍부한 컴포넌트 라이브러리 생태계를 보유하고 있다. Google의 Material Design을 구현한 Material Yew, Bootstrap 컴포넌트를 제공하는 yew-bootstrap, 그리고 다양한 커뮤니티 기반 컴포넌트 모음인 yew-components 등이 존재한다.36 awesome-yew GitHub 리포지토리는 이러한 라이브러리와 예제 프로젝트들을 잘 정리해두어 새로운 개발자들에게 좋은 출발점을 제공한다.15 다만, 생태계가 오래된 만큼 일부 라이브러리는 최신 Yew 버전과 호환되지 않거나 유지보수가 활발하지 않을 수 있다는 점은 유의해야 한다.33
• Dioxus: 생태계는 아직 초기 성장 단계에 머물러 있다. 이로 인해 즉시 사용 가능한 고품질의 서드파티 라이브러리가 부족하다는 점이 여러 개발자들에 의해 단점으로 지적된다.45 dioxus-tw-components(TailwindCSS 기반), freyr와 같은 소규모 라이브러리가 존재하고, daisyUI와의 통합 가이드가 제공되지만, Leptos나 Yew에 비해 선택의 폭이 현저히 좁다.35 이 문제를 해결하기 위해 Dioxus 개발팀이 직접 Radix Primitives를 기반으로 한 dioxus-primitives라는 공식 foundational 컴포넌트 라이브러리를 개발하고 있어, 향후 생태계 발전의 기틀이 될 것으로 기대된다.48

4.4 문서화 및 커뮤니티

문서의 질과 커뮤니티의 활성도는 개발자가 문제에 직면했을 때 해결책을 찾을 수 있는지를 결정하는 중요한 척도이다.

• Leptos: ’The Leptos Book’이라는 이름의 공식 문서가 매우 체계적이고 상세하게 잘 작성되어 있다는 평가를 받는다.10 또한, 공식 Discord 채널이 매우 활발하여 프레임워크 개발자를 포함한 많은 사용자들이 실시간으로 질문에 답변하고 논의를 진행한다.39 이는 신속한 문제 해결과 최신 정보 습득에 큰 장점이다.
• Yew: 공식 문서와 튜토리얼을 제공하지만, 일부 고급 기능이나 특정 사용 사례에 대한 설명이 부족하다는 의견이 있다.5 커뮤니티는 가장 오래된 만큼 규모가 크고 안정적이지만, 핵심 개발자가 프로젝트를 떠난 이후 개발 모멘텀이 다소 둔화되었다는 평가가 지배적이다.7 이는 새로운 기능 추가나 혁신적인 변화보다는 안정적인 유지보수에 초점이 맞춰져 있음을 시사한다.
• Dioxus: 공식 문서가 불완전하거나 최신 버전의 변경 사항을 반영하지 못하고 있다는 비판이 꾸준히 제기된다.16 커뮤니티 규모 역시 아직 작아 Stack Overflow 등에서 답변을 찾기 어렵고, 주로 Discord에 의존해야 하는 상황이다. 이는 특히 마감 기한이 있는 프로젝트에서 큰 리스크로 작용할 수 있다. 그러나 Dioxus는 벤처 캐피탈 투자를 유치하는 등 강력한 재정적 지원을 받고 있으며, 이는 프로젝트의 장기적인 성장과 문서 및 커뮤니티 지원 개선에 대한 기대를 갖게 한다.14

이러한 분석은 프레임워크 선택이 기술적 측면뿐만 아니라 생태계의 성숙도와 개발 모멘텀 사이의 균형을 맞추는 전략적 결정임을 보여준다. Yew는 성숙함과 안정성을 제공하지만 미래 발전 가능성에 대한 의문이 있고, Leptos와 Dioxus는 빠른 혁신과 강력한 모멘텀을 보여주지만 생태계의 미성숙함과 API 변경 가능성이라는 리스크를 안고 있다.

표 3: 생태계 및 커뮤니티 지표 (2024년 4분기 기준)

주: GitHub Stars는 2024년 10월경의 데이터를 기반으로 하며 계속 변동될 수 있음.

1045

5. 종합 평가 및 전략적 권고

지금까지의 심층 분석을 바탕으로, 각 프레임워크의 기술적 장단점, 성능 특성, 생태계 성숙도를 종합하여 특정 사용 사례에 가장 적합한 프레임워크를 선정하기 위한 전략적 가이드를 제시하고, 미래 발전 가능성을 전망한다.

5.1 사용 사례별 최적 프레임워크 선정 가이드

어떤 프레임워크가 절대적으로 우월하다고 말할 수는 없다. 성공적인 기술 선택은 프로젝트의 고유한 요구사항과 프레임워크의 핵심 강점을 일치시키는 데 있다.

• 고성능 데이터 시각화 / 실시간 대시보드
• 최우선 권고: Leptos
• 근거: 수천, 수만 개의 데이터 포인트가 실시간으로 업데이트되는 시나리오에서 가상 DOM의 부재는 결정적인 성능 우위를 제공한다. 세밀한 반응성 시스템은 상태 변경에 따른 UI 업데이트 비용을 최소화하여, 복잡한 인터랙션에도 높은 프레임레이트와 부드러운 사용자 경험을 보장한다.7 js-framework-benchmark에서 입증된 압도적인 런타임 렌더링 속도는 이러한 유형의 애플리케이션에 가장 중요한 요구사항을 충족시킨다.
• 단일 코드베이스 크로스플랫폼 애플리케이션 (웹 & 데스크톱)
• 강력 추천: Dioxus
• 근거: 프레임워크의 핵심 비전과 아키텍처 자체가 이 사용 사례에 완벽하게 부합한다.12 dx CLI를 통해 웹과 데스크톱 빌드를 매끄럽게 전환할 수 있으며, UI 로직을 한 번만 작성하면 되므로 개발 및 유지보수 비용을 획기적으로 절감할 수 있다. Tauri와 같은 외부 도구에 의존하는 다른 프레임워크에 비해 훨씬 더 통합적이고 일관된 개발 경험을 제공한다. 단, 현재 시점에서는 미성숙한 생태계로 인해 필요한 UI 컴포넌트나 유틸리티를 직접 구현해야 할 가능성이 높다는 점을 반드시 감수해야 한다.45
• 전통적인 풀스택 웹 애플리케이션 (CRUD, SSR 중심)
• 최적 선택: Leptos
• 근거: #[server] 함수를 통한 프론트엔드-백엔드 간의 긴밀한 통합은 데이터베이스와 상호작용하는 CRUD(Create, Read, Update, Delete) 애플리케이션 개발을 매우 단순하고 효율적으로 만든다.4 별도의 API 레이어를 관리할 필요가 없어 개발 생산성이 극대화되며, Rust의 타입 시스템이 전체 스택에 걸쳐 데이터 무결성을 보장한다. 또한, 강력한 서버 사이드 렌더링(SSR) 및 하이드레이션 지원은 초기 페이지 로딩 성능과 검색 엔진 최적화(SEO)에 매우 유리하게 작용한다.18
• 안정성과 성숙도가 최우선인 중/대규모 엔터프라이즈 프로젝트
• 고려 대상: Yew
• 근거: 세 프레임워크 중 가장 오랜 기간 커뮤니티에 의해 검증되었으며, 상대적으로 API 변경이 적어 장기적인 안정성과 유지보수 예측 가능성이 높다. 이미 구축된 라이브러리 생태계는 복잡한 요구사항을 해결하는 데 도움이 될 수 있다. 그러나 핵심 개발자의 부재와 상대적으로 느린 개발 모멘텀은 장기적인 기술 리스크로 작용할 수 있다.7 따라서 새로운 기술 도입에 보수적인 조직이나, 이미 Yew에 대한 내부 전문성을 갖춘 팀에게 적합한 선택일 수 있다.
• React/JS 생태계에서 마이그레이션하는 팀
• 추천: Dioxus 또는 Yew
• 근거: 두 프레임워크 모두 React 개발자에게 매우 친숙한 개발 모델을 제공한다. Dioxus는 React Hooks와 거의 동일한 API를 제공하여 학습 곡선을 최소화하며 1, Yew 역시 JSX와 유사한 html! 매크로와 함수형 컴포넌트 모델을 통해 부드러운 전환을 돕는다.8 Leptos의 세밀한 반응성 모델은 강력하지만, React의 ‘컴포넌트 재실행’ 멘탈 모델에 익숙한 개발자들에게는 패러다임 전환에 따른 추가적인 학습 비용이 발생할 수 있다.7

5.2 미래 전망 및 발전 가능성

각 프레임워크는 현재의 강점과 약점을 바탕으로 서로 다른 미래 경로를 그리고 있다.

• Leptos: 현재의 강력한 성능 우위와 활발한 커뮤니티를 바탕으로, 고성능을 요구하는 웹 애플리케이션 시장에서 사실상의 표준으로 자리 잡을 가능성이 매우 높다. 특히 leptos-shadcn-ui와 같은 고품질 컴포넌트 라이브러리의 등장은 생태계의 빠른 성숙을 이끌고 있으며, 이는 더 많은 개발자와 프로젝트를 유인하는 선순환 구조를 만들 것이다. 풀스택 통합이라는 명확한 비전은 단일 언어로 웹 개발의 모든 영역을 다루고자 하는 최신 트렌드와도 잘 부합한다.
• Dioxus: 벤처 캐피탈 투자 유치라는 강력한 성장 동력을 확보했으며, ’크로스플랫폼’이라는 명확하고 야심 찬 비전은 Rust GUI 생태계 전체에서 핵심적인 역할을 할 수 있는 잠재력을 부여한다.14 성공의 관건은 현재 가장 큰 약점으로 지적되는 문서의 질을 개선하고, 개발자들이 의존할 수 있는 견고한 서드파티 라이브러리 생태계를 구축하는 것이다. Dioxus Deploy라는 상용 배포 플랫폼 계획은 프로젝트의 장기적인 재정적 지속 가능성을 확보하려는 의지를 보여주며, 이는 생태계에 대한 신뢰를 높이는 긍정적인 신호이다.51
• Yew: 가장 큰 도전 과제는 새로운 비전과 리더십의 부재이다. 커뮤니티 주도의 안정적인 유지보수는 계속되겠지만, Leptos와 Dioxus가 제시하는 혁신적인 기능과 빠른 개발 속도에 점차 시장의 관심과 점유율을 잃을 수 있다. 만약 현재의 상태가 지속된다면, Yew는 새로운 프로젝트에서 적극적으로 채택되기보다는 기존에 구축된 애플리케이션을 유지보수하는 ‘레거시’ 프레임워크로 남을 위험이 존재한다. 생태계의 재활성화를 위한 커뮤니티의 구심점 마련이 시급하다.

5.3 최종 결론

2024년 현재 Rust 웹 프레임워크 생태계는 세 가지 뚜렷한 축을 중심으로 역동적으로 진화하고 있다. 이는 ‘성숙과 안정의 Yew’, ‘압도적 성능과 통합의 Leptos’, 그리고 ‘광범위한 비전과 잠재력의 Dioxus’ 구도로 요약할 수 있다.

본 보고서의 심층 분석 결과, 모든 사용 사례를 만족시키는 단 하나의 ‘최고’ 프레임워크는 존재하지 않는다는 것이 명백해졌다. 최적의 선택은 프로젝트가 추구하는 핵심 가치(성능, 개발 속도, 플랫폼 확장성, 안정성), 팀이 보유한 기존 기술 역량, 그리고 새로운 기술 도입에 대한 리스크 감수 수준에 따라 달라지는 전략적 결정의 문제이다.

• 최고의 런타임 성능과 완벽한 풀스택 통합을 원한다면 Leptos가 가장 강력한 해답을 제공한다.
• 웹을 넘어 데스크톱과 모바일로의 확장을 염두에 두고 있다면 Dioxus의 비전에 투자하는 것이 현명한 선택일 수 있다.
• 검증된 안정성과 React에 가장 가까운 개발 경험을 우선시한다면 Yew가 여전히 유효한 대안이다.

Rust가 웹 프론트엔드 개발의 주류로 부상하는 이 중요한 시점에서, 본 보고서가 각 프레임워크의 본질적인 차이와 트레이드오프를 명확히 이해하고, 각자의 비즈니스 목표와 기술 전략에 부합하는 가장 현명한 결정을 내리는 데 있어 깊이 있고 신뢰할 수 있는 나침반이 되기를 바란다.

6. Works cited

1. Top Rust frameworks for 2024 — Part 2 | by Davide Ferrero - Level Up Coding, accessed October 27, 2025, https://levelup.gitconnected.com/top-rust-frameworks-for-2024-part-2-b589280f207d
2. Exploring the top Rust web frameworks - LogRocket Blog, accessed October 27, 2025, https://blog.logrocket.com/top-rust-web-frameworks/
3. Should You Ditch React for Yew? A Look at Rust’s Frontend Challenger. - Medium, accessed October 27, 2025, https://medium.com/@vaibhavkhinvasara/should-you-ditch-react-for-yew-a-look-at-rusts-frontend-challenger-ad6425465bcc
4. Leptos: Home, accessed October 27, 2025, https://leptos.dev/
5. Yew: The Top Rust Front End Framework for 2024 - OpenReplay Blog, accessed October 27, 2025, https://blog.openreplay.com/yew–the-top-rust-front-end-framework-for-2024/
6. Leptos vs Dioxus vs Sycamore (vs Svelte?): Part 1 — Syntax comparison : r/rust - Reddit, accessed October 27, 2025, https://www.reddit.com/r/rust/comments/155iqd1/leptos_vs_dioxus_vs_sycamore_vs_svelte_part_1/
7. Yew or leptos : r/rust - Reddit, accessed October 27, 2025, https://www.reddit.com/r/rust/comments/1526qo3/yew_or_leptos/
8. Yew, accessed October 27, 2025, https://yew.rs/
9. yew - Rust - Docs.rs, accessed October 27, 2025, https://docs.rs/yew
10. Leptos - GitHub, accessed October 27, 2025, https://github.com/leptos-rs
11. Introduction - Leptos, accessed October 27, 2025, https://book.leptos.dev/
12. dioxus - Rust - Docs.rs, accessed October 27, 2025, https://docs.rs/dioxus
13. Dioxus | Fullstack crossplatform app framework for Rust, accessed October 27, 2025, https://dioxuslabs.com/
14. Fullstack crossplatform app framework for Rust - Dioxus, accessed October 27, 2025, https://dioxuslabs.com/learn/0.6/
15. yewstack/yew: Rust / Wasm framework for creating reliable and efficient web applications - GitHub, accessed October 27, 2025, https://github.com/yewstack/yew
16. Leptos vs Dioxus vs Sycamore (vs Svelte?): Part 1 — Syntax comparison - Vedant Pandey, accessed October 27, 2025, https://blog.vedant.dev/leptos-vs-dioxus-vs-sycamore-vs-svelte-part-1-syntax-comparison-c58ed631896c
17. leptos - Rust - Docs.rs, accessed October 27, 2025, https://docs.rs/leptos/latest/leptos/
18. Getting Started - Leptos Book, accessed October 27, 2025, https://book.leptos.dev/getting_started/index.html
19. dioxus - crates.io: Rust Package Registry, accessed October 27, 2025, https://crates.io/crates/dioxus
20. Getting Started - Dioxus | Fullstack crossplatform app framework for Rust, accessed October 27, 2025, https://dioxuslabs.com/learn/0.6/getting_started/
21. Leptos is becoming best rust web framwork and How to set up #125 - GitHub, accessed October 27, 2025, https://github.com/leptos-rs/leptos/discussions/125
22. Dioxus vs Leptos vs Yew for a textboard. : r/rust - Reddit, accessed October 27, 2025, https://www.reddit.com/r/rust/comments/1lycg2i/dioxus_vs_leptos_vs_yew_for_a_textboard/
23. krausest/js-framework-benchmark: A comparison of the performance of a few popular javascript frameworks - GitHub, accessed October 27, 2025, https://github.com/krausest/js-framework-benchmark
24. The greatness and limitations of the js-framework-benchmark | Read the Tea Leaves, accessed October 27, 2025, https://nolanlawson.com/2024/10/13/the-greatness-and-limitations-of-the-js-framework-benchmark/
25. Official results for js web frameworks benchmark - GitHub Pages, accessed October 27, 2025, https://krausest.github.io/js-framework-benchmark/
26. Interactive Results - GitHub Pages, accessed October 27, 2025, https://krausest.github.io/js-framework-benchmark/current.html
27. Dioxus vs Leptos : r/rust - Reddit, accessed October 27, 2025, https://www.reddit.com/r/rust/comments/1ex1g0n/dioxus_vs_leptos/
28. Comparison of asset sizes for various front-end technologies - Software - TMPDIR, accessed October 27, 2025, https://community.tmpdir.org/t/comparison-of-asset-sizes-for-various-front-end-technologies/213
29. Best Rust Web UI Framework for 2024? - Reddit, accessed October 27, 2025, https://www.reddit.com/r/rust/comments/18schae/best_rust_web_ui_framework_for_2024/
30. Shrinking .wasm Size - Rust and WebAssembly, accessed October 27, 2025, https://rustwasm.github.io/book/reference/code-size.html
31. Getting Started | Yew, accessed October 27, 2025, https://yew.rs/docs/getting-started/introduction
32. Tutorial | Yew, accessed October 27, 2025, https://yew.rs/docs/tutorial
33. Does anybody actually use Leptos framework in production? : r/rust - Reddit, accessed October 27, 2025, https://www.reddit.com/r/rust/comments/191vxcb/does_anybody_actually_use_leptos_framework_in/
34. Guides - Dioxus | Fullstack crossplatform app framework for Rust, accessed October 27, 2025, https://dioxuslabs.com/learn/0.6/guides/
35. Install daisyUI for Dioxus — daisyUI Tailwind CSS Component UI Library, accessed October 27, 2025, https://daisyui.com/docs/install/dioxus/
36. wiseaidev/yew-components: A Collection of Yew Framework Components. - GitHub, accessed October 27, 2025, https://github.com/wiseaidev/yew-components
37. leptos-shadcn-ui - crates.io: Rust Package Registry, accessed October 27, 2025, https://crates.io/crates/leptos-shadcn-ui
38. radix-leptos - crates.io: Rust Package Registry, accessed October 27, 2025, https://crates.io/crates/radix-leptos
39. The Leptos Community and leptos-* Crates, accessed October 27, 2025, https://book.leptos.dev/getting_started/community_crates.html
40. Leptonic — Rust GUI library // Lib.rs, accessed October 27, 2025, https://lib.rs/crates/leptonic
41. thaw-ui/thaw: An easy to use leptos component library - GitHub, accessed October 27, 2025, https://github.com/thaw-ui/thaw
42. Material Yew, accessed October 27, 2025, https://material-yew.rm.rs/
43. yew-bootstrap - crates.io: Rust Package Registry, accessed October 27, 2025, https://crates.io/crates/yew-bootstrap
44. A curated list of awesome things related to Yew / WebAssembly. - GitHub, accessed October 27, 2025, https://github.com/jetli/awesome-yew
45. Why I’m Dropping Dioxus for My Project (For Now) | by Sreeved Vp - Medium, accessed October 27, 2025, https://medium.com/@sreevedvp/why-im-dropping-dioxus-for-my-project-for-now-a1811fa63bdc
46. cbdefontenay/freyr: A Dioxus UI component library - GitHub, accessed October 27, 2025, https://github.com/cbdefontenay/freyr
47. dioxus-tw-components - crates.io: Rust Package Registry, accessed October 27, 2025, https://crates.io/crates/dioxus-tw-components
48. Accessible, unstyled, foundational components for Dioxus. - GitHub, accessed October 27, 2025, https://github.com/DioxusLabs/components
49. How did you choose Dioxus? There are about a dozen Rust frameworks [1] that are … - Hacker News, accessed October 27, 2025, https://news.ycombinator.com/item?id=39852831
50. Dioxus 0.5: Web, Desktop, Mobile Apps in Rust | Hacker News, accessed October 27, 2025, https://news.ycombinator.com/item?id=39852167
51. Deploying - Dioxus | Fullstack crossplatform app framework for Rust, accessed October