Roadmap for the Xilem back end in 2024

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.

I figure that's a given - you kinda have to build one, right?

I think the key thing that is trying to be conveyed here (based on discussions I have had with the blog post’s author beyond the contents of the blog post itself) is that you shouldn’t be required to create a custom widget unless your requirements are unusual.

I am confident that the ability to create custom widgets will be retained for those who do need it.

Personally, the main reason I'm looking to build a GUI in Rust is because the rest of my code is in Rust and I want to have an interface for it is because I don't want to write my own DSL to express it via command line arguments or file inputs and I don't want to have to start using multiple languages just to specify the input to or display the output of my program. I don't really care all that much about speed, I just want to use the language I'm already using for the other parts of the project.

The point about extensible widgets is I think more along the lines that what most people need isn't a way to create new and better versions of <input type=T>, but rather ways to say "if I want to input something of type T, you need to display these inputs in this layout and you can combine them to make a new object of type T". In other words, GUIs should focus on composition rather than inheritance.

> Does this statement include things like the canvas API and SVG? How restrictive are we talking here?

Your have good point for discussion. But to address this sentence I saw in the blog this:

> There will be escape hatches, from a fixed-size canvas surface where end-users can use arbitrary paint primitives to full-on custom widget code, but we should design the framework under the assumption people will almost never need those hatches.

Also instead of SVG you can probably use Kurbo like in Druid.