GPUI 비판

GPUI, egui, Elm 계열의 상태 모델은 작은 UI에서는 단순하지만, 복잡한 데스크톱 앱에서 정밀한 갱신을 구현하려면 그 단순성을 잃을 수 있음 GPUI의 notify는 엔티티만 식별하고 변경된 필드를 알리지 못함. 자체 벤치마크에서는 행마다 캐시된 뷰를 둔 3,000행 UI의 라벨 하나를 바꾸는 데 8.4ms가 걸렸으며, 비용이 변경량보다 트리 크기를 따라 증가함 뷰를 보존하는 gpui-fast도 최소 재사용 단위가 뷰라는 제약이 있음. 라벨 단위 갱신에 필요한 엔티티와 구독 등을 직접 관리하면 사실상 무거운 부품으로 시그널 그래프를 수작업 구성하게 됨 대안은 읽기 추적과 한 번만 실행하는 컴포넌트임. 변경된 값을 읽는 클로저만 다시 실행하되, 일반적인 if와 for 대신 반응형 구조를 써야 하는 사용성 비용이 있음 시그널이 성능을 자동 보장하지는 않음. 레이아웃 엔진의 전체 순회, 초기 생성 비용, 메모리, 효과의 연쇄 갱신이 남으며, 수치는 프레임워크 유지관리자의 검토를 받지 않은 단일 머신 자체 측정이라는 한계가 있음 문제의 출발점: 값 하나가 바뀌면 무엇이 실행되는가 네이티브 Rust GUI 채택이 늘고 있으며, Discord의 GPUI 기반 재작성 발표와 egui를 선택하는 여러 LLM 복제 앱이 논의의 출발점임 비판의 대상은 프로젝트 자체의 완성도보다 복잡한 데스크톱 앱의 기본 선택지로서 상태 모델이 적합한가임 Zed는 실제로 빠르고 사용감이 좋으며, egui는 Bevy 게임의 디버그 인터페이스에 유용하게 쓰이고 있음 다만 정밀한 갱신이 필요해지면 GPUI와 egui의 상태 모델이 막다른 길에 이를 수 있음 Raph Levien의 UI 아키텍처 논의처럼, 모든 UI 프레임워크에는 일종의 증분 계산 체계가 숨어 있음. 상태의 작은 변화로 화면을 효율적으로 갱신하려면 무엇이 바뀌었고 누가 그것에 의존하는지 알아야 함 모델별로 상태 쓰기 이후 실행 범위가 다름 즉시 모드, egui: 다음 프레임에 모든 UI 코드를 실행하며 변경 지점을 별도로 찾지 않음 Elm, Iced: 전체 view를 실행한 뒤 차이를 비교함 뷰 기반, GPUI: 유효한 캐시가 없는 모든 뷰를 실행하며, 애플리케이션이 notify로 알림 시그널과 컴포넌트 재실행, Freya/Compose: 해당 값을 읽은 컴포넌트를 프레임워크가 찾아 실행함 시그널과 일회 실행, Floem/Solid/zgui: 해당 값을 읽은 클로저를 프레임워...