[HN Gopher] Roadmap for the Xilem back end in 2024
       ___________________________________________________________________
        
       Roadmap for the Xilem back end in 2024
        
       Author : coffeeaddict1
       Score  : 50 points
       Date   : 2024-01-19 19:15 UTC (3 hours ago)
        
 (HTM) web link (linebender.org)
 (TXT) w3m dump (linebender.org)
        
       | jauntywundrkind wrote:
       | As mentioned at the start, this follows upon Raph's post a week
       | ago,
       | 
       |  _Rust GUI Xilem 2024 plans_.
       | https://linebender.org/blog/xilem-2024/
        
       | jcranmer wrote:
       | Something that I don't see in the roadmap which has me slightly
       | concerned:
       | 
       | One of the important utilities for a UI, especially if custom
       | widgets are to a degree deprecated, is something along the lines
       | of a lazy widget. For example, if I have a table of a few million
       | entries, I don't want to have to create a widget for every single
       | entry, but rather have a callback for the data to fill widgets
       | for the hundred or so currently being displayed.
       | 
       | With that caveat, I find myself largely agreeing with these
       | ideas. Rust desperately needs a GUI framework with a more
       | complete set of canned widgets.
        
         | zellyn wrote:
         | I figure that's a given - you kinda have to build one, right?
        
         | raphlinus wrote:
         | This is in fact touched on (if briefly), in the roadmap - it's
         | "virtual lists" and absolutely is a priority for this year.
         | Performant UI is not possible without it.
         | 
         | The idea is not so much that you have a custom widget, but
         | rather that you have a container view which is tightly coupled
         | to a corresponding container widget. As you scroll, that widget
         | requests its view to materialize (and de-materialize) views for
         | the child widgets that become visible. It doesn't need custom
         | widgets, the child widgets can be standard, and because it's
         | Rust the cost of allocating and deallocating the child widgets
         | (as opposed to recycling existing widgets as in Android
         | RecyclerView) is modest.
         | 
         | (Point of clarification for those following more closely: I'm
         | talking about views here, while the linked post is focused on
         | widgets. The widget tree will provide a documented protocol for
         | requesting child widgets, estimating layout sizes, syncing up
         | scroll adjustments, and so on. This protocol will be a bit
         | messy and complicated, because the underlying problems are
         | hard. We'll develop it in tandem with the corresponding Xilem
         | view, which will we hope will provide a really nice clean
         | developer experience, especially in conjunction with an
         | immutable list data structure which can produce sparse deltas.
         | Then, as people want to do their own reactive layer, they can
         | figure out how to do the plumbing from their own take on the
         | incremental computation engine into this protocol.)
         | 
         | We prototyped this last year, enough to be confident in the
         | direction, and it is absolutely a goal to wire it all up this
         | year.
        
       | skavi wrote:
       | This is exciting. I genuinely enjoyed working with Druid (though
       | my time with it was limited). I was wondering if Xilem would get
       | to that level of usability. Sounds like they're planning to go
       | way further.
        
       | zengid wrote:
       | Really excited for this work.
       | 
       | I'm curious about what the author means by "Avoiding Custom
       | Widgets".
       | 
       | > _On the other end of the spectrum, the web has shown that you
       | can implement complex custom UIs given a rigid but rich set of
       | primitives._
       | 
       | Does this statement include things like the canvas API and SVG?
       | How restrictive are we talking here?
       | 
       | I don't want to go off on a rant with my interpretation of what
       | the author means, but I feel like having extensible widgets is a
       | huge selling point for a framework written in and for Rust. If
       | you're just going to bake in a bunch of standard widgets without
       | extension points, I feel like developers aren't looking to write
       | that in Rust. They'll use a native GUI framework, or make a
       | webpage, because those are just so much easier to make in
       | Swift/Kotlin/Dart/JavaScript. If someone is making a Rust UI,
       | they very likely care about performance and they probably want to
       | make a "hot-rod" app that is going to do some crazy-fast shit. If
       | they're just looking for a comfy daily driver, they might as well
       | pick a slower but softer language/framework.
       | 
       | I could be totally misinterpreting things here so please forgive
       | me if I am, I just hope my feedback might be helpful.
        
       ___________________________________________________________________
       (page generated 2024-01-19 23:01 UTC)