Afrigather Olivier Faure, January 19, 2024
As you could have heard by now, Google Fonts is funding me this 12 months to work on Xilem.
I am not alone in that: Aaron Muir Hamilton, Daniel McNab and Matt Campbell have been funded as effectively to work on varied elements of the ecosystem. I imagine that is Matt’s third 12 months getting funding from Google Fonts.
Now, what I used to be employed to do is likely to be unclear to you. The scope we agreed on was pretty broad and was said as “contributing to Xilem’s view tree and developer expertise”, however that would imply quite a lot of issues.
The very first thing I need to do is talk a clearer image. I’ve a quite a lot of plans for Xilem, they usually contain main adjustments from the present architectures, adjustments that is likely to be worrying to the neighborhood at massive and even to Raph Levien. I actually do not need to give the impression that I am wresting the venture away from the Linebender neighborhood for Google’s curiosity, and meaning being clear early and infrequently in regards to the issues I need to rework.
What I need for Xilem
Xilem is a research-and-development venture, the most recent in a collection (Xi-Core, Druid, Crochet, Lasagna, Idiopath), that goals to discover how UI growth will be made suitable with Rust.
This would possibly really feel just a little banal now, as a result of Rust GUI frameworks are popping up in every single place and beginning to choose comparable patterns, however these patterns weren’t apparent in 2019! Xilem may be very completely different from Druid, and attending to its present structure has been a course of.
Xilem has been perma-experimental since Might 2022. As soon as it obtained began, the principle Druid maintainers stopped contributing virtually completely with the expectation that Xilem would change Druid as soon as it was prepared. Sadly, it nonetheless hasn’t made sufficient progress to be on parity with Druid, but Druid nonetheless lies deserted, which is not nice when individuals had began counting on it.
It is debatable how a lot this might have been prevented. As I’ve identified earlier than, the Rust GUI ecosystem is topic to large yak-shaving: many people got here right here as a result of we wished to construct a textual content editor, and now we’re all studying about text rendering, text editing, compositing1, accessibility trees, using monoids to implement stuff on the GPU, ECS, and a few ideas that I am completely sure Raph made up like Bézier paths and C++.
And to a sure extent, yak-shaving is nice! “I will do higher than X with out studying how X works” is a toddler’s angle. It is the angle all of us begin with, and it fills us with braveness, however that braveness is naive. True enchancment comes from protecting that braveness after spending years studying how immense the issue area is, and protecting religion that it is attainable to do higher. The Rust neighborhood is one which values not simply doing issues from scratch, but in addition studying from the previous to get them proper.
That is good, however the “get them proper” half takes quite a lot of time, and within the meantime, I would argue that we have uncared for finish customers a bit. We have deserted Druid earlier than Xilem was prepared instead, after which we labored on foundational and experimental tasks that might make Xilem stronger and sounder in the long run, however left the venture in an ungainly state within the meantime (aside from the net backend, which made quite a lot of progress).
Within the ECS-backed GUI framework article I linked, Bevy maintainers have this to say:
To not be too harsh, however quite a lot of the prevailing Rust GUI options… simply aren’t superb. There’s quite a lot of satisfactory choices, however all of them have non-trivial drawbacks. Nobody has actually risen to the highest as a transparent winner. […] Deep down, everyone knows that we will do higher, and we should always.
My ambition is to makes this paragraph out of date earlier than the top of the 12 months. I need Xilem to get again to being prompt to newbies in the identical breath as Iced and SlintUI. Within the subsequent few years, I need your entire ecosystem to get to some extent the place individuals speak about Rust GUI like they speak about ripgrep or rustls.
To provide one particular instance: my private aim is to implement seamless scorching reloading for Xilem earlier than the top of 2024. I imagine it is possible, and I imagine doing it should seriously change the best way individuals take into consideration Rust GUI, together with other improvements I hope to unlock over time.
Within the shorter time period, my plan is to deal with primary options, widgets and styling choices so individuals can experiment with Xilem, constructing on Raph’s work on Vello over the previous 12 months. John Skottis’s Xilem UX Notes give a superb image of the sorts of issues I will be engaged on.
The opposite massive short-term precedence goes to be documentation. We have seen lots of people complain that the Linebender venture have been poorly documented and exhausting to get into; it was the most well-liked response to our 2024 announcement, but it surely echoed sentiments we might seen earlier than. We’re conscious of the issue, and we intend to work on it.
Within the medium time period, I additionally plan to work on the efficiency facet of Xilem. Folks from Google Fonts have expressed curiosity in seeing how a lot efficiency we will get from Rust UI. Whereas my mission is not restricted to efficiency work, will probably be an ongoing focus, particularly because it’s an space the place the Rust language brings distinctive alternatives. I am going to go into extra particulars on Rust efficiency and energy effectivity in a later article.
Main adjustments I need to implement quickly
These are the massive adjustments I need to work on quickly. Realistically, “quickly” goes to be relative, as a result of a few of these adjustments are going to be controversial, and a part of the work goes to be convincing individuals of their worth.
Switching to Masonry as a backend
Okay, this one makes me blush just a little.
I am the one maintainer of Masonry, a GUI crate with barely over 300 stars on Github and little outdoors curiosity. Can I actually justify taking the cash Google pays me to enhance Xilem and spending my time on Masonry as an alternative?
That selection is not random, thoughts you: Masonry was forked from Druid, Xilem’s ancestor, and in reality Xilem and Masonry share quite a lot of code proper now.
In actual fact, I would argue that Masonry’s codebase is of higher high quality than Xilem’s present native backend. This is not meant to be a put-down of the work of Xilem maintainers; slightly, it is the end result of a distinction in priorities. No person was very fascinated about Xilem’s native backend (although Raph was conscious of its significance, therefore me getting paid to write down this), and many individuals have been very within the frontend and the net backends, due to this fact the frontend and net backends noticed essentially the most work.
From our RFC#0001:
In consequence, Xilem’s native backend is in a poor state:
- There may be code commented out.
- There are entire modules commented out.
- There may be documentation referring to items from Druid that no longer exist.
- There are TODOs without an associated issue.
Masonry’s backend codebase is a more healthy start line. Masonry additionally comes with some built-in perks, like highly effective unit exams and a structured widget graph.
It is not clear whether or not we need to import the Masonry codebase, the crate, or your entire repository, and it is not clear what the last word branding must be. The RFC lays out the completely different potentialities, and dialogue remains to be ongoing, so the neighborhood can attain a consensus earlier than doing extra work (together with presumably not utilizing Masonry in any respect).
If we do transfer ahead with this, then Masonry will want some porting work:
- Utilizing Vello and Parley as an alternative of Piet.
- Utilizing Glazier as an alternative of druid-shell.
- Integrating AccessKit.
- Eradicating the dependency on GTK.
AccessKit help particularly is desk stakes, by now. The Rust ecosystem is converging on the concept accessibility (or at the very least, display reader help) must be built-in early on within the design of GUI frameworks, not tacked on on the finish.
There are different issues Xilem added over Druid (notably digital lists and async help), however I imagine Masonry would not have to implement them instantly for parity. Each shall be crucial for eventual efficiency work.
Avoiding customized Widgets
I am informed by Raph it is a “molotov cocktail” which, uh, truthful.
We should always write Xilem’s backend beneath the idea that finish customers of the library (together with the Xilem frontend) will very not often create their very own widgets. As an alternative, they’ll often compose the primitives given to them the identical manner they compose DOM components within the browser. There shall be escape hatches, from a fixed-size canvas floor the place end-users can use arbitrary paint primitives to full-on customized widget code, however we should always design the framework beneath the idea individuals will virtually by no means want these hatches.
Clearly, it is a radical transfer. There shall be a prototyping section earlier than we select whether or not we decide to it, and RFCs to put out the main points. I am assured it should repay.
Builders of pastime GUI frameworks have a tendency to supply a severely anemic set of primitives, beneath the idea that if anybody needs different options of their widgets, they will implement them themselves. Each Druid and Xilem endure from this.
On the opposite finish of the spectrum, the net has proven you could implement advanced customized UIs given a inflexible however wealthy set of primitives.
Extra importantly, the net is shifting in the direction of a strong paradigm: declarative UI. As time goes on, persons are realizing you may get higher efficiency and composition by describing what issues ought to seem like and composing them than by imperatively making them do issues.
A part of that is that native code is extra performant than JS, however a part of it simply that declarative code is less complicated to work round than crucial code: its bounds are higher outlined, it helps you to commit to limitations that make the engine’s job simpler, and it is simpler to investigate.
A set of proposals referred to as CSS Houdini got here out that went within the precise wrong way: pushing the format engine in the direction of extra customization and JavaScript code. The proposal hasn’t seen a lot motion since 2021, and I do not suppose it is a coincidence that the half that might have given essentially the most energy to crucial code, the Structure API, hasn’t been stabilized in any browser.
The underside line is that, whereas implementing customized widgets will all the time be attainable, I need to encourage builders to go so far as they will composing declarative components as an alternative, and see how far it is attainable to go utilizing these constructing blocks.
Extra opinionated format
One main customization level I need to limit in Xilem is format.
In the present day all Rust GUI frameworks ship their very own format algorithm, however none of them are competing on their format algorithm. Usually the format algorithm is only a means to an finish; builders that do need to work on a state-of-the-art format engine will present it in a modular crate like Morphorm and Taffy.
And here is the factor: realistically, most format engines aren’t that artistic. Each Rust framework and each main GUI framework I am conscious of makes use of format that boils right down to “FlexBox with small variations”. The variety of meaningfully other ways to do GUI format will be counted on, generously, two palms.
I would argue we solely want CSS Circulation, FlexBox, CSS Grid, and perhaps Morphorm to cowl most individuals’s wants. Conveniently, that is what Taffy goals to supply. There’s already an experimental Taffy integration in Xilem, and I need to make it deeper.
That being mentioned, there will not be a hard-coded set of format algorithms. Somewhat, format will depend on a web-inspired protocol between widgets (in different phrases, trait strategies), and that protocol shall be strongly opinionated to make implementation of those format algorithms simpler.
Extra on this in a latter weblog publish.
No boxing
Having a semi-fixed set of widgets means you possibly can keep away from utilizing Field, which has some attention-grabbing efficiency implications.
It means you possibly can add quite a lot of strategies to the Widget trait with out worrying about bloating the vtable. And you may write strategies beneath the idea that they will be inlined, which opens up attention-grabbing DX enhancements.
Utilizing ECS, perhaps, type of
In present Xilem code, if you’d like your FlexWidget to have kids, it will need to have a Vec member. Every Pod straight owns a Widget.
I feel that is an attention-grabbing quirk of Rust GUI, tying on to Rust’s possession semantics. Non-Rust frameworks typically use tips that could baby widgets, true, however they’re typically shared with the framework, with an understanding that the framework is charged with protecting observe of what number of widgets there are and which is a toddler of which. In Qt, as an illustration, it is most popular (however not necessary) for folks to name delete_later() on their kids as an alternative of delete, as a result of it performs higher with occasion dealing with.
Xilem’s method of “you personal your kids” is just a little bespoke. It means the framework has a tough time iterating over your entire widget tree (say, as a part of a DOM inspector) until every Widget particularly implements the iterating technique. And it means if you wish to goal an occasion at a selected widget (say, the one with keyboard focus), it’s good to undergo your entire possession chain, utilizing some heuristics to keep away from visiting too many widgets.
I imagine Widgets must be owned by the library. In case your container has kids, then the one factor the container will truly personal is keys right into a construction (most likely a slotmap) the place the widget is saved. This makes quite a lot of issues simpler, like serialization and debugging, but it surely has an impression on your entire backend. It is an infrastructure funding.
These days, I’ve seen increasingly more dicussion of implementing GUI by means of an ECS. Numerous that dialogue comes from Bevy, which is pure, for the reason that bevy neighborhood is made up of ruthless cultists striving to feed ever extra sacrifices to the ECS god till it consumes the Earth is intimately aware of the ECS sample and has reached a section the place UI work is getting quite a lot of consideration2. However I’ve seen discussions about it within the Linebender neighborhood too.
Whether or not we truly need to use ECS is one thing we nonetheless have to analysis.
The way in which I perceive it, the massive draw of ECS is the “S” half, the Techniques: it is about dealing with a number of comparable information directly in arbitrary order. Which is why eg archetypes in bevy are helpful: you are grouping collectively entities with the identical elements, so that you could say “execute this code for all entities with part X and part Y” and have this code be executed on arrays of values with minimal indirection or branching. And the “arbitrary order” half makes them work very well with slotmaps: since you possibly can simply learn from the start of the slotmap, you do not pay the double-indirection penalty.
In different phrases, the perfect use case for ECS is code of the kind for (entity in entities) entity.place += entity.pace.
GUI is fairly removed from that very best use-case: updates are sparse and may solely run on a small variety of modified widgets. Order typically issues. And I am undecided archetypes would work in a framework with a big number of widgets and completely different attributes.
I feel there are two belongings you actually need from a Rust ECS library for GUI: slotmaps, and environment friendly methods so as to add and take away elements from an entity.
Implementing these goes to be a serious enterprise, which we’ll must divide into small experiements, however one I count on to pay many occasions over.
Group involvement and extra to return
I need to actually put emphasis on one thing: not one of the above is ready in stone.
A part of what Raph needs to realize this 12 months is to make Xilem extra of a neighborhood venture, and meaning working extra choices by the neighborhood.
I’ve created an RFC repository for this, and every of the sections above will get its personal RFC, the place I am going to broaden on my rationale in additional element.
This is not a rubber-stamping course of both: I need to implement these concepts, but when the neighborhood3 decides that they’re unhealthy, then we’ll go one other course.
There’s different concepts I have not mentioned but that I need to come again to:
- Declarative styling: Giving Widgets attributes just like CSS properties, with modifiers for animations, pseudo-classes, media queries and container queries. Whereas impressed by CSS, it would not contain any CSS parsing, selector decision, specificity decision, and so on.
- Compositing: Xilem is heading in the direction of a “do the whole lot within the GPU” method. That is good for efficiency, however Firefox engineers who’ve gone down this street earlier than us have warned us of the numerous perils they confronted, particularly concerning battery life. Usually, after format and portray, you actually desire a
composite()section to take care of scrolling and a few easy animations with out touching the GPU in any respect if attainable. This is a complex subject, and it will be good if we may disguise most of that complexity from app builders whereas nonetheless giving them good efficiency. - Useful resource loading: That is one other space the place we’d need to crib from sport engines. On the very least, we would like to have the ability to ask “Load me this texture/shader/font/and so on” with out having to write down disk I/O in consumer code. Then we will begin fascinated by progressive loading, fallbacks, sharing, and so on.
These concepts are more likely to be the topic of additional articles and/or RFCs within the close to future.
Relations with different tasks
Presenting the present state of the Rust GUI ecosystem would most likely take its personal article.
Issues are shifting rapidly, and something I write now may not be updated in two weeks. The tasks we’re most fascinated about proper now are Winit and Bevy, and there is some potential for cooperation with Servo. The COSMIC ecosystem appears fairly cool, however to this point it appears like we’ve got much less to share with them.
Folks from parallel tasks are speaking and exchanging a lot, a lot greater than they have been in 2022. Between Vello, Parley, wgpu, Taffy, COSMIC-Textual content and others, tasks are converging and maintainers are making extra effort to succeed in out and combine different individuals’s code.
Keep tuned for extra!
Hey, that is actually cool!
One thing that got here up in discussions I’ve had with Raph is that it is simple to overlook the forest for the bushes. In the midst of all of the paperwork, blog-writing, RFC-writing, we will find yourself specializing in the method a lot that we neglect how excited we’re.
So, I am taking the second to remind myself: that is actually freaking thrilling!
For all my criticisms and caveats and lifelike assessments of the issues we have to overcome, I am nonetheless feeling completely nice about this!
I am tremendous grateful to Raph for getting us this far, to Google Fonts for sponsoring us, and to everybody else who contributed to the Linebender ecosystem. I feel we will do one thing superb and I am truthfully just a little startled to be on this place in any respect.
To reiterate what I mentioned: within the subsequent few years, I need your entire ecosystem to get to some extent the place individuals speak about Rust GUI like they speak about ripgrep or rustls.
I legitimately suppose Rust has the potential to get best-in-class GUI frameworks, and now the time has come to show it.
