From 576208590462e6617bab5c016e87d56f79522427 Mon Sep 17 00:00:00 2001 From: Raph Levien Date: Thu, 4 Jan 2024 12:41:28 -0800 Subject: [PATCH] Xilem 2024 blog This commit adds a blog subdirectory to the content tree, sets up a chronological blog index, and an Atom XML feed. There are minimal CSS changes to support that. The initial blog post is the announcement of Xilem 2024 plans. --- config.toml | 2 + content/blog/2024-01-09-xilem-2024.md | 79 +++++++++++++++++++++++++++ content/blog/_index.md | 8 +++ sass/main.scss | 12 ++++ templates/base.html | 1 + templates/blog_index.html | 16 ++++++ 6 files changed, 118 insertions(+) create mode 100644 content/blog/2024-01-09-xilem-2024.md create mode 100644 content/blog/_index.md create mode 100644 templates/blog_index.html diff --git a/config.toml b/config.toml index 4606851..d61639d 100644 --- a/config.toml +++ b/config.toml @@ -10,6 +10,8 @@ compile_sass = true # Whether to build a search index to be used later on by a JavaScript library build_search_index = true +generate_feed = true + [markdown] # Whether to do syntax highlighting # Theme can be customised by setting the `highlight_theme` variable to a theme supported by Zola diff --git a/content/blog/2024-01-09-xilem-2024.md b/content/blog/2024-01-09-xilem-2024.md new file mode 100644 index 0000000..b820123 --- /dev/null +++ b/content/blog/2024-01-09-xilem-2024.md @@ -0,0 +1,79 @@ ++++ +title = "Xilem 2024 plans" +authors = ["Raph Levien"] +date = "2024-01-09 07:34:42" ++++ +2024 promises to be an exciting year for Xilem. The big news is that Google Fonts is funding the work of four open source contributors to the project: Aaron Muir Hamilton, Daniel McNab, Matt Campbell, and Olivier Faure. + +Aaron will be working on text layout, building on [parley](https://github.com/dfrg/parley), [text input](https://lord.io/text-editing-hates-you-too/) including IME, and Android platform integration. Daniel will be working on GPU infrastructure and performance, with much of the work upstreamed to [wgpu]. Matt will be working on accessibility, and Olivier will be building the core widget tree, with a focus on developer experience. + +Xilem is an ambitious project to explore the limits of UI performance, as described in my [High Performance Rust UI](https://youtu.be/zVUTZlNCb8U) talk. The goals include gathering knowledge about the viability of Rust for UI, and what patterns work well. While there is a research focus, we plan to gather this information by building a real toolkit, solving many of the hard problems. The current state of the project is a fairly rough, though promising, prototype, so there is much work to be done. It’s exciting to have the bandwidth and experience of these people working toward that goal, but perhaps the most exciting prospect is bringing together more of the community, people passionate about building high quality UI. Our goal as an open source community is to facilitate that, and to coordinate the work efficiently. What we have now is not a production-ready product, but we wish to move in that direction, including quality documentation - some of the consistent feedback we’re getting about the current state. + +Xilem is designed in layers, with a reactivity layer on top, a widget tree adapted from [Druid](https://github.com/linebender/druid), and with [Vello](https://github.com/linebender/vello) as the 2D rendering engine. These layers are designed to work well together, but the individual pieces may be useful in other contexts. The funded work will focus on Android as a target, but is intended to work well on desktop platforms as well; this is one of the core strengths of the Rust ecosystem. We don’t have iOS as an immediate priority, but attention from the open source community could change that, and the foundations should support it. + +Another goal is to bake in accessibility from the start. Too often, it’s an afterthought, tacked on at the end. We’re excited to have Matt Campbell, primary author of [AccessKit](https://github.com/AccessKit/accesskit), on board. + +The status of the web backend for the Xilem widget set is more complex. Simply put, it is not a priority for us right now. It is most likely that we will implement a version using canvas-based drawing. That has the advantage of more consistency with mobile and desktop, but limitations in accessibility and native look and feel for interactions such as scrolling and text input. Such a web backend would be most suitable for online demos. We have done some explorations into generating DOM nodes from Xilem (see the [Xilem Vector Graphics](https://www.youtube.com/watch?v=XjbVnwBtVEk) talk), but doing it well would increase scope and complexity beyond what we’re comfortable with. For applications deployed *primarily* on the web, xilem_web (which generates DOM nodes) should be a viable choice, with the possibility of Tauri or Electron for desktop deployment. + +## 2023 retrospective + +Looking back at 2023, there was a great deal of foundational work. Much of the effort was on Vello, the 2d rendering engine that serves as the graphical foundation of the project. A particular strength is high performance path rendering on GPU, which enables fully dynamic text effects including animation of variable font parameters. Though we had a reasonably good implementation of path rendering in place, much of the second half of the year was taken up by “stroke rework” which computes all stroke styles on the GPU, and also improves the performance and accuracy of antialiasing for all paths. To this end, we invented new computational geometry algorithms for computing parallel curves, the newest based on [Euler spirals](https://raphlinus.github.io/curves/2021/02/19/parallel-curves.html), with some elegant math tuned for GPU evaluation.. A writeup explaining the details is in the pipeline. + +There was slow and steady work on the higher levels of the stack as well, including factoring out the reactive layer into a generic xilem_core module, and validating that with generation of DOM nodes for browser deployment. The widget tree saw some development as well, including integration with the [Taffy](https://github.com/DioxusLabs/taffy) layout engine. + +## Governance and community + +Though we now are funding work on the project, the open source nature of the projects continues unchanged. We’ve been building up infrastructure for open source community, including a [Zulip instance](https://xi.zulipchat.com/), weekly office hours, [wiki](https://linebender.org/wiki/), and, as of this post, a shared [blog](https://linebender.org/blog/). Our [contributor guidelines](https://linebender.org/contributor-guidelines/) explain a bit about our processes. Almost all decision making is by consensus. Only very rarely do I need to step in and tie-break. As we scale up, we’re going to be more systematic, starting to use [RFC documents](https://github.com/linebender/rfcs) for major changes. + +We’re intentionally designing our community to foster learning and collaboration. For example, discussions are on Zulip rather than Discord because it’s searchable, meaning that the same questions are less likely to come up over and over. Its grouping into topics lets participants quickly skim activity as opposed to getting drowned in chatter. It’s working well for us. We also invite others in the Rust UI ecosystem to use our Zulip and wiki. As the Kurzgesagt video [The Internet is Worse Than Ever – Now What?](https://www.youtube.com/watch?v=fuFlMtZmvY0) observes, large social spaces are degrading, and the video recommends seeking out smaller, more focused communities. I hope ours is one such. + +In any case, we are happy to share bits of infrastructure with other Rust UI efforts, and are always eager to learn from them. I see many of us working toward common goals rather than competing, even if there are different approaches and priorities. + +## Thoughts on the Rust UI ecosystem + +I’ve been thinking about doing UI in Rust for about 8 years now, and have explored many, many approaches. I’m not alone in this, there have been well over two dozen projects started. + +As mentioned in a [previous blog](https://raphlinus.github.io/rust/gui/2022/07/15/next-dozen-guis.html), any given application will have a set of requirements. Is Web one of the main deployment targets? Will there be embedded video? Is there a need to integrate with some other subsystems, such as a game engine? Each of these has profound implications. Some problem spaces (compilers are an example) are “smooth,” in that continual refinement will lead to fairly similar outcomes no matter the starting point, but over time I’ve come to the conclusion that UI is especially lumpy. I believe this contributes to the continuing pattern of new UI toolkits coming out every couple months or so; the author surveys what’s available, finds none that match the specific set of requirements, and creates a new one. + +In some ways, Xilem is in the same pattern, but there are *some* things we’re doing differently. For one, it’s explicitly a research project, with knowledge about how to build UI in Rust an outcome at the same level as the codebase. We’re trying to be systematic about finding the best ways to do things, which ideally will make some solutions more general. And, increasingly, we’re designing things as modular layers that can be swapped out. With luck, even if people don’t end up adopting the entire stack, there will be some useful components for the ecosystem. + +A good overview of the opportunities and challenges in Rust UI, particularly for making mobile apps, is [parallel futures in mobile application development](https://wingolog.org/archives/2023/06/15/parallel-futures-in-mobile-application-development) by Andy Wingo. The linked blog posts in that series also go into considerable detail about Javascript and Typescript based approaches, which have important lessons as well. + +### Declarative UI patterns + +The trend in UI programming has been overwhelmingly away from a soup of mutable objects with interlinked references and toward various declarative or reactive patterns. That’s a good thing for Rust UI, because the former is very un-ergonomic. + +In the Javascript world, there is a Cambrian explosion of reactive techniques. React is by far the most popular, but there is a strong sentiment it’s possible to be better, particularly on performance, but also robustness, as the logic for deciding [when to re-render](https://www.joshwcomeau.com/react/why-react-re-renders/) is fickle, and can [miss re-renders](https://arxiv.org/abs/2310.04368). Elm deserves special mention, as its avoidance of global shared mutability makes it particularly easy to adapt to Rust, so it serves as the reactive core of the iced, relm, and vizia UI toolkits, as well as yew on the WASM side. But there is also Ember Octane (based on Adapton), a number of fine-grained reactivity approaches such as SolidJS, and many, many more. + +We’re seeing much of that diversity mirrored into the Rust world. On the WASM side, we see Dioxus as a fairly faithful adaptation of React, leptos (also sycamore and tachys) adhering fairly closely to SolidJS, yew as an adaption of elm, and [more](https://github.com/flosse/rust-web-framework-comparison). + +A reactive layer such as Dioxus or leptos can be compiled to WASM and run in a browser to generate DOM nodes. More recently, we’re seeing that it can be decoupled from that environment, and a reactive core can drive a widget tree. Examples include [Freya](https://github.com/marc2332/freya) which uses Dioxus, and [floem](https://github.com/lapce/floem) which implements fine-grained reactivity inspired by leptos. + +Xilem doesn’t directly correspond with any Javascript framework; it relies on static typing and is actually closer to SwiftUI than anything web based. + +A major development with xilem is its factoring into xilem_core, supporting both xilem_web for DOM, and our own bespoke widget set. + +One of the central questions in Rust UI going forward is: which approach to declarative UI is best? It’s possible a clear winner will emerge, or perhaps there will be a different answer depending on the use case, or it might just come down to a matter of personal style, with a number of viable contenders (arguably that’s where Javascript is). We’re taking a two pronged approach. First, we’re moving forward with Xilem. There’s a specific reason - Xilem is designed to support multithreaded rendering easily, while many of the other frameworks rely on thread local storage for access to a store of observables, an approach with high impedance mismatch to multithreading. Since performance is a goal, we didn’t want to give that up by adopting another framework. I also think Xilem is pretty good, but that remains to be seen. + +But Xilem is untested, and it may be that some other approach is better. If so, we’re prepared to pivot. We’ll be designing the widget set so that it doesn’t have a hard-coded dependency on the xilem declarative layer, and could, at least in theory, be driven from other frameworks. One of the people on the project is Olivier Faure, author of the [masonry](https://github.com/PoignardAzur/masonry-rs) crate, where being agnostic to the declarative layer was an explicit goal. He’ll be adapting many of the ideas from that. + +Making a widget set agnostic has other potential benefits. While writing app logic in Rust is very promising, there are still compelling reasons to use other languages. A widget tree implemented in Rust with fast graphics and smooth interactivity, scripted in some other language, is compelling. I made a rough [prototype](https://github.com/linebender/druid/pull/2185) in Python, which shows promise. + +## Infrastructure + +A UI toolkit depends on a great deal of infrastructure. We’re making careful choices around that, and also looking for opportunities to collaborate with the rest of the ecosystem. One choice I’m particularly excited about is investing in [wgpu]. I think WebGPU will move modern GPU usage forward considerably, especially compute shaders, which are heavily used in Vello. This technology will make truly portable applications requiring high compute throughput possible for the first time, and we’re shooting for smooth UI integration. + +Whether to use winit or build our own platform integration has long been a subject of discussion. We’re reopening that discussion with the winit maintainers as of this writing, but it’s still too early to say whether we’ll join forces, or decide that the goals of the project support having a separate codebase. + +A huge part of any UI effort is text, and that’s also a long-standing interest of mine. I’m impressed with [cosmic-text](https://github.com/pop-os/cosmic-text) but ultimately we decided to move forward with [parley](https://github.com/dfrg/parley), in part so we can test out ideas with variable fonts and the like. The lower levels of the text stack will be rebased on the [fontations](https://github.com/googlefonts/fontations) work of the Google Fonts team, which is rapidly becoming a production-quality implementation. + +Building common infrastructure for accessibility also benefits the entire ecosystem, and we're thrilled to see the increasing adoption of AccessKit. Indeed, on all these topics, we’re happy to share what we’re doing with other projects, as most of the infrastructure described above is general in application, rather than specific to our projects. + +## Conclusion + +The potential for Rust in UI is huge. The Rust language enables top-notch performance and reliability and is also expressive for high-level application logic. We plan to prove that out, based on encouraging existing research and explorations, as well as new research to discover the patterns for Rust UI that work best at scale. This involves work at all levels of the stack, including infrastructure we are happy to share with other Rust UI efforts. + +Xilem is still an early prototype. For those who desire a “batteries included” toolkit for building UI, we ask your patience. For those who are interested, you are invited to come build this future with us. + +[wgpu]: https://wgpu.rs/ + diff --git a/content/blog/_index.md b/content/blog/_index.md new file mode 100644 index 0000000..4ee8adf --- /dev/null +++ b/content/blog/_index.md @@ -0,0 +1,8 @@ ++++ +title = "Blog" +sort_by = "date" +description = "Shared blog for Linebender projects" +template = "blog_index.html" ++++ + +## Blog posts diff --git a/sass/main.scss b/sass/main.scss index 42a215f..2511708 100644 --- a/sass/main.scss +++ b/sass/main.scss @@ -577,3 +577,15 @@ table td { .highlight .il { color:#099 } +.blog-list { + list-style: none; +} +.blog-list li { + margin-bottom: 1em; +} +.list-post-date { + color: #666; +} +.list-post-title { + font-size: 120%; +} \ No newline at end of file diff --git a/templates/base.html b/templates/base.html index a9574b0..4062301 100644 --- a/templates/base.html +++ b/templates/base.html @@ -44,6 +44,7 @@
{% block navlinks %} About + Blog Wiki {% endblock navlinks %}
diff --git a/templates/blog_index.html b/templates/blog_index.html new file mode 100644 index 0000000..42b4741 --- /dev/null +++ b/templates/blog_index.html @@ -0,0 +1,16 @@ +{% extends "base.html" %} + +{% block content %} +{{ section.content | safe }} + +{% endblock content %}