--- title: A critical review of Xilem in 2026 | daily.dev description: A maintainer-level critical review of the Xilem Rust GUI framework argues its architecture is fundamentally broken, citing two-way data bindings, sprawling... canonical: https://daily.dev/posts/a-critical-review-of-xilem-in-2026-nb59bqqag twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: A critical review of Xilem in 2026 | daily.dev og:description: A maintainer-level critical review of the Xilem Rust GUI framework argues its architecture is fundamentally broken, citing two-way data bindings, sprawling... og:url: https://daily.dev/posts/a-critical-review-of-xilem-in-2026-nb59bqqag og:image: https://api.daily.dev/og/posts/Nb59bqQaG.png og:image:alt: A critical review of Xilem in 2026 og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # A critical review of Xilem in 2026 **[Lobsters](https://daily.dev/sources/lobsters)** · 8 min read · 0 upvotes · 0 comments ## Summary A maintainer-level critical review of the Xilem Rust GUI framework argues its architecture is fundamentally broken, citing two-way data bindings, sprawling generics, awkward higher-order component APIs, and side-effect-laden views as the root causes of poor developer experience. The piece proposes a major overhaul: a non-generic Component type, stringly-typed keys, a 'type smuggling' pattern to move some type checking to runtime, side-effects confined to component callbacks, and a background-worker model for async requests. It also argues Xilem must drastically cut scope, dropping features like virtual scrolling, some type-erasure abstractions, and duplicated code in xilem_core, calling this a roadmap rather than an immediate plan. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why is Xilem's current architecture considered broken by its own maintainers? Xilem's reliance on two-way data bindings forces every view to carry a generic State argument, producing awkward function signatures, poor compile error messages, and spaghetti composition when combining state and effects through higher-order components like Fork, Lens, and MapState. This architectural pattern is described as causing at least half of Xilem's usability problems. _Rust developers weighing GUI framework tradeoffs can follow architecture debates like this on daily.dev._ ### What is the proposed Component type meant to fix in Xilem? A proposed non-generic Component type would replace generic View state parameters with stringly-typed keys checked eagerly during view tree creation, local state accessed through a CompCtx, and event callbacks passed with a metadata token enabling a 'type smuggling' pattern. This moves some type checking from compile time to runtime to simplify component composition and reduce generic complexity. _Developers evaluating Rust UI frameworks can track proposals like this on daily.dev before committing to one._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 8 comments across lobsters (as of 2026-08-13). **TL;DR:** Commenters largely agree with the critique that Xilem's complexity outweighs its performance benefits, while several note it still has genuinely good ideas and appreciate that the project keeps getting serious attention. **Sentiment:** 25% positive · 45% mixed · 30% skeptical **The case for** - Some find real value in parts of Xilem's design despite the friction of using it. - People appreciate that Xilem keeps receiving sustained, serious development attention in an otherwise weak Rust GUI ecosystem. **The pushback** - Several argue Rust's language features tempt API designers into overcomplicating things chasing performance that most GUI apps don't actually need. - One person compares building without concrete use-case-driven requirements to their own experience of sprawling, unfocused engine codebases, suggesting Xilem suffers from the same lack of grounding. - Electron-style alternatives are criticized for memory bloat, and GTK4 is called out as not much better either, showing no framework is seen as a clear winner. **By community** - lobsters (mixed): Broad agreement with the critique's push for simplicity over performance, tempered by acknowledgment of Xilem's genuine strengths and comparisons to alternative UI approaches like QML/Slint. **Hottest debate:** Whether Rust GUI frameworks should prioritize simplicity and lower performance ceilings over the maximal-performance, generics-heavy approach Xilem currently takes. **Open questions** - What would a Rust GUI framework look like if it deliberately traded performance for a simpler API, similar to how QML/Slint separate markup from logic? **Highlights** > > In general, we should be more willing to write code that's slightly less performant or elegant if it means that it's also less complex. This, a thousand times this. I love Rust, but the language features make it really tempting to overcomplicate your APIs by going for maximum performance. Yet judging by the popularity of React/Electron, GUIs don't *need* to be maximally performant: many users are willing to accept the overhead of a (relatively fast) single-threaded GC language. So long as the API is simple and compile times are fast, people will use it. I'm partially joking and also out of my depth here, but I'm wondering if the ideal Rust GUI library is actually something like Rust wrapper→Lua framework→C bindings for your platform's GUI. > — [bitshift on lobsters · 6 points, 2 comments](https://lobste.rs/s/bccwjx/critical_review_xilem_2026#c_kf72yi) > I've made concerted attempts at using xilem, and even masonry underneath it a few times and it's been pretty brutal. So I agree on pretty well the points here. The problem is there are some *really* good bits to xilem, but they're hindered badly by the experience of trying to develop something even moderately complex in it. You have to be really dedicated to get something out of it that matches what you originally envisioned without a lot of compromises along the way. As I've played with more and more different gui frameworks, I really like the QT slots and signals mechanism and I wish there was sort of an evolution of that we could target and bring into xilem alongside an easier path to declaring a UI. I harp on the web all the time, but it's really easy to cobble together a UI with some HTML. Slint took a similar route. Separating the concern of declaring the views and UIs from the code a bit makes things feel clearer and might make it feel easier to get something up and working faster. > — [objectif\_lune on lobsters · 4 points](https://lobste.rs/s/bccwjx/critical_review_xilem_2026#c_9kf3wi) > This has been my own experience when trying to build things bottom up rather than building things driven by concrete use cases. In the past, I have noodled away at multiple game engines without a clear idea of what the game I'm trying to make is and invariably ended up with a complicated, sprawling code base that is difficult to work with and nowhere near an actual game. On the other hand when working on an actual AAA game we had constant direct feedback of what was missing, what needed to change or what was causing slowdown. The resulting game engine was lean, surprisingly reusable and is AFAIK still in use today. I think starting or refocusing on the actual goal ("We are building THIS application with THESE needs") would be very clarifying as to what is actually helpful and necessary and what can be trimmed. > — [krig on lobsters · 1 points](https://lobste.rs/s/bccwjx/critical_review_xilem_2026#c_km1wd6) > > Yet judging by the popularity of React/Electron, GUIs don't need to be maximally performant: many users are willing to accept the overhead of a (relatively fast) single-threaded GC language. The primary issue with electron+whatever bloated js framework isn't really speed, it's the memory consumption. With the current RAM prices, seeing something like Slack or Discord eat up a whole gigabyte feels really bad. > — [hjvt on lobsters · 1 points, 1 comments](https://lobste.rs/s/bccwjx/critical_review_xilem_2026#c_icsswx) **Source threads** - [lobsters](https://lobste.rs/s/bccwjx/critical_review_xilem_2026) · 19 points · 8 comments ## Similar posts on daily.dev - [GitHub - linebender/xilem: An experimental Rust native UI framework](https://daily.dev/posts/github---linebender-xilem-an-experimental-rust-native-ui-framework-q074au2rm) · Hacker News · 21 upvotes · 1 comments - [A 2026 Survey of Rust GUI Libraries](https://daily.dev/posts/a-2026-survey-of-rust-gui-libraries-e93cfc0b7) · Lobsters · 1 upvotes · 0 comments - [Thanks for All the Frames: Rust GUI Observations](https://daily.dev/posts/thanks-for-all-the-frames-rust-gui-observations-4x2gjqln2) · Lobsters · 16 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#rust](https://daily.dev/tags/rust), [#reactive-programming](https://daily.dev/tags/reactive-programming) [View this post on daily.dev](https://daily.dev/posts/a-critical-review-of-xilem-in-2026-nb59bqqag) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"A critical review of Xilem in 2026","url":"https://daily.dev/posts/a-critical-review-of-xilem-in-2026-nb59bqqag","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/a-critical-review-of-xilem-in-2026-nb59bqqag"},"datePublished":"2026-08-13T14:01:13.326Z","dateModified":"2026-08-13T14:01:55.095Z","description":"A maintainer-level critical review of the Xilem Rust GUI framework argues its architecture is fundamentally broken, citing two-way data bindings, sprawling...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3d0f8fa8f9292a5f2d9cbe00cb442179?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3d0f8fa8f9292a5f2d9cbe00cb442179?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/a-critical-review-of-xilem-in-2026-nb59bqqag","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"architecture,rust,reactive-programming","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"A critical review of Xilem in 2026"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/a-critical-review-of-xilem-in-2026-nb59bqqag#faq","mainEntity":[{"@type":"Question","name":"Why is Xilem's current architecture considered broken by its own maintainers?","acceptedAnswer":{"@type":"Answer","text":"Xilem's reliance on two-way data bindings forces every view to carry a generic State argument, producing awkward function signatures, poor compile error messages, and spaghetti composition when combining state and effects through higher-order components like Fork, Lens, and MapState. This architectural pattern is described as causing at least half of Xilem's usability problems. Rust developers weighing GUI framework tradeoffs can follow architecture debates like this on daily.dev."}},{"@type":"Question","name":"What is the proposed Component type meant to fix in Xilem?","acceptedAnswer":{"@type":"Answer","text":"A proposed non-generic Component type would replace generic View state parameters with stringly-typed keys checked eagerly during view tree creation, local state accessed through a CompCtx, and event callbacks passed with a metadata token enabling a 'type smuggling' pattern. This moves some type checking from compile time to runtime to simplify component composition and reduce generic complexity. Developers evaluating Rust UI frameworks can track proposals like this on daily.dev before committing to one."}}]} ```