Comment by nicoburns
5 days ago
> The current roadmap lists Shadow DOM and CSS Grid as priorities
I've been working on the CSS Grid support. About to land "named grid lines and areas" support which should make a bunch more websites layout correctly.
I'm biased because it's my project, but IMO the approach Servo is using for CSS Grid is pretty cool in that the actual implementation is in an external library (Taffy [0]) that can be used standalone and is widely used accross the Rust UI ecosystem, including in the Blitz [1] web engine (which also uses Taffy for Flexbox and Block layout), the Zed [2] text editor, and the Bevy [3] game engine.
I'm hopeful that this approach of breaking down a web engine into independently usable modules with public APIs (which builds upon Servo's earlier work on modular libraries such as Stylo and html5ever) will make it easier for people to get involved in web engine development (as they can understand each piece in isolation), and make it easier for people to create new web engines in future (as they won't have to start completely from scratch).
[0]: https://github.com/DioxusLabs/taffy [1]: https://github.com/DioxusLabs/blitz [2]: https://zed.dev [3]: https://bevy.org/
> (Taffy [0]) that can be used standalone and is widely used accross the Rust UI ecosystem, including in the Blitz [1] web engine (which also uses Taffy for Flexbox and Block layout)
This is the first time I hear about Blitz. Looks equally interesting and ambitious. It is probably the real undercover web engine. Servo was widely known around when Rust debuted.
> this is the first time I hear about Blitz. Looks equally interesting and ambitious. It is probably the real undercover web engine
It's certainly a newer and lesser-known engine. It's mostly been me working on it for the past year or so (with a couple of other occasional contributors). But I do have funding to work on it full time through DioxusLabs (who are building Dioxus Native - a Flutter / React Native competitor on top of it) and NLnet (who are a non-profit interested in the alternative web browser use case).
We're trying to really push on the modular side of things to create a web engine that's flexible / hackable and can be moulded for a variety of use cases.
We'd love more contributors, so if anyone is interested in getting involved then drop by our GitHub (https://github.com/DioxusLabs/blitz/) or Discord (https://discord.gg/AnNPqT95pu - #native channel)
You have my admiration and support for this work! I guess it goes without saying how monumental and critical the work on alternative engines like servo and libweb are. We are genuinely tired of the current duopoly (I'm starting to lose hope with Firefox and gecko as well. They seem to have priorities different to our expectations.) But I guess we now have one more to look forward to, thanks to you and the rest of the team! Personally, I hope to pitch in as soon as I have some spare time available. Regards!
1 reply →
Just skimmed through the Blitz source. Really interesting. I don’t have experience with UI rendering or Rust, but I couldn’t help wondering: if you leave out things like local storage and websockets, why include networking at all? Feels like a separate concern. Genuinely curious. Great project. Wishing you all the best!
2 replies →
> or Discord
Oh, no, why do alternative web browser engine devs love Discord so much? The Ladybird project also does this… that's certainly a barrier to entry for would be contributors attached to free software and software freedom… It's a shame, I suspect the intersection between people like this and people interested in alternative web browser engines is not small (comparatively speaking)…
Anyway, it's nice to see alternative web browser engines appearing like this. We need browser tech that does not rely on Big Ad funding. Even better if they cooperate on some common libraries like this.
Thanks for working on such things.
Web browser engines have always interested me, I might one day jump in.
3 replies →
Questions for the Rust UX experts:
Is Dioxus (or Leptos) much more performant than Tauri/Electron?
I want to (1) build blindingly fast, low-latency, super performant UX for users, which precludes Tauri/Electron (something I'm currently using and unhappy about), but I also want to (2) maintain developer velocity, (3) have access to nice UX primitives and widgets, and (4) have it look nice and modern.
Javascript/browser-oriented frameworks make requirements 2-4 easy, and it has the side benefit of also making hiring easy (not a requirement per se). But the results feel so bloated and anti-Desktop/native. It gobbles up RAM and renders slowly, even when best practices are used. It's the very definition of a double-edged sword.
Are these four requirements simply impossible to satisfy together for native Rust UX toolkits right now?
Rust's egui looks amazing, but I doubt you'd be able to build a very complicated UX with it. Or if you could, it might take you half a year to deliver.
Iced also looks cool, but looks less featureful.
Are there any "non-browser" Rust UX toolkits that aren't dated GTK/KDE frameworks, but that can build graphically-oriented (not just text/button widget) programs?
If I were building a "slimmed down photoshop", are there any Rust GUI toolkits to reach for? Or if I were incorporating a Bevy or 3D render pane?
> I want to (1) build blindingly fast, low-latency, super performant UX for users, … (2) maintain developer velocity, (3) have access to nice UX primitives and widgets … (4) have it look nice and modern.
Find me when you find this, because I actually think it is impossible.
I think there is fundamentally too much inherent complexity to abstract away to keep 2 and not sacrifice 1. Specifically for something properly cross platform.
If you are only targeting MacOS or windows then I think it’s absolutely possible but then you are using the wrong language, nothing against rust at all on that, the platform defaults are just swift / C# for those use cases.
And I’m not sure but unless you are just using a gtk/Qt style framework you would absolutely run into a11y problems that you would need to build around yourself.
Sounds like you probably want egui though… if your primary UI is a big canvas that needs to be hardware accelerated and interaction is just to assist that use case egui is probably a good bet for you. But you wouldn’t be hiring web devs to do that.
3 replies →
I'm no UX expert, but I regularly try out new (and old) toolkits to understand the problem space.
It really sounds like you want an immediate mode toolkit. Retained mode will never be "super-snappy", there's an entire sandwich between your code and the pixels. Look at Blender or Reaper, this is the kind of "feel" you'd be getting.
If you want retained mode + "true" native widgets on all platforms, investigate: Toga (Python), WxWidgets (C++), and Tk (Tcl). The native toolkits are often best in class on each platform, and these wrappers are about as thin as they can reasonably get (e.g. Toga uses pyobjc). Integration with Rust is left as an exercise to the reader ;)
A rich widget library is nice, but consider the depth as well. Egui went to great lengths to integrate assistive technologies, which depending on your target audience may be impactful. (Also: accessibility is for everyone. https://shortcat.app/)
If you want easy hiring, you have to go with mainstream. We've +/- named all of the options by now. Otherwise, hire a talent who's worked on the next closest thing to what you're building, and trust them to decide the direction.
Looks and beauty are in the eye of the beholder. There are many apps that have a distinct, sometimes quirky, but appreciable style. Reaper looks out of place on every platform, but I prefer it over Logic or Ableton.
I'm super biased in favor of iced.
Yes, there are missing features (it's not even version 1.0 yet!) but I think the number is very small now and the solution is usually to fill in the gaps yourself—which is possible because iced is totally modular
I've made a spreadsheet editor and a slideshow editor with it so "slimmed down photoshop" seems feasible although admittedly you will likely need to get deep into the renderer (possibly write your own renderer traits and there), but I suppose you're comfortable with that given your goal.
If you're not allergic to Discord, come join us. It's a helpful, awesome tight community IMHO
Link for the lazy: https://discord.gg/3xZJ65GAhd
Project link: https://iced.rs
7 replies →
I know it’s usually taken as a given around here that Electron is slow, and many of the big-name apps using it are cited as examples with good reason.
From working on a Tauri app myself for a few years (video editor) I just think the blame is misattributed. These things are not inherently slow. Slower than native? Maybe, probably, at the level of milliseconds. Visibly laggy? No, that’s the badly-written UI code’s fault. (see also: the latest iterations of the macOS System Settings UI, where the search box lags like crazy)
A webview can be extremely responsive. It won’t be if you treat it like a web page (where clicking buttons fires off HTTP requests) or if you let the JS framework code get out of hand, but those are not the fault of the wrapper.
If you like building with HTML/CSS/JS then I’d recommend doing some perf experiments to see how far these tools can take you. Of course if you don’t want to use that stack then pick something else :)
If you’re building photoshop, the main UI will probably be canvas anyway, where drawing is fully under your control, no matter which framework you go with. That stuff can be very fast or very not-fast depending on how the code is written.
Slint recently added Bevy support. I’ve been keeping an eye on it since I’ve used Qt and love working in Qml.
4 replies →
Makepad is neither gtk generation nor browser based. Might check the "just text/button widget" box though, I'd certainly place it on the minimalistic end of the spectrum. (haven't worked with makepad, just enjoyed the demo)
1 reply →
> Is Dioxus (or Leptos) much more performant than Tauri/Electron?
For now it's largely the same. Both Dioxus and Leptos render using Tauri (or a web browser). For Dioxus, a Blitz-based renderer (Dioxus Native ) is in development which will change the story slightly.
I would suggest Iced if you're looking for efficient (I don't think it's any less featureful than any other Rust-based GUI). With honourable mentions for Slint and Vizia.
Certainly not a "Rust UX _expert_", but I do find GPUI interesting. Some nice examples here of not-"just text/button widget programs": https://github.com/longbridge/gpui-component
Check out https://www.gpui.rs/ too
1 reply →
Wasn’t rust and servo co-developed?
Yes. That's what I meant, in case my framing is confusing.
Does having experience implementing a web browser engine feature change the way you write HTML or CSS in any way? Do you still google "css grid cheatsheet" three times a week like the rest of us?
> Does having experience implementing a web browser engine feature change the way you write HTML or CSS in any way?
I think I'm more concious of what's performant in CSS. In particular, both Flexbox and CSS Grid like to remeasure things a lot by default, but this can be disabled with a couple of tricks:
- For Flexbox, always set `flex-basis: 0` and `min-width: 0`/`min-height: 0` if you can without affecting the layout. This allows the algorithm to skip measuring the "intrisic" (content-based) size.
- For CSS Grid, the analogous trick is to use `minmax(0, 1fr)` rather than just `1fr`.
(I also have a proposal for a new unit that would make it easier to get this performance by default, but I haven't managed to get any traction from the standards people or mainstream browsers yet - probably I need to implement it and write it up first).
> Do you still google "css grid cheatsheet" three times a week like the rest of us?
Actually no. The process of reading the spec umpteen times because your implementation still doesn't pass the tests after the first N times really ingrains the precise meanings of the properties into your brain
I wish there was a CSS analyzer that would give tips like this based on your CSS.
3 replies →
How do you propose standards to the web groups?
I want to propose CSS-inheritance—by-name (#box {inherit:$(#menu)})
and the reintroduction of marquee tags for horizontal scrolling (a frequently used UI pattern on shopping sites).
3 replies →
(Just say yes, you have to look it up all the time so we don't feel as bad)
To me, this is like asking if having built a sql engine if you write SQL differently.
I think the answer is yes. Having a strong understanding of the underlying engine helps you debug and optimize more quickly
Needing reference stuff never changes unless it’s so frequently used.
> breaking down a web engine into independently usable modules with public APIs
I love that. Years ago I looked at WebRTC and asked myself, why does it seem like making a crummy Skype knockoff is either 50 lines of JavaScript or a nightmarish week of trying to get half of Chromium to compile in your C++ project?
I think there is a WebRTC Rust crate finally, which is good. Web apps shouldn't be the only beneficiaries of all this investment
Do you not worry that instead it will lead to feature bloat and fragmentation? If you’re going to strike at Google, you need laser focus.
Not really. Everything has a spec, so it's pretty clear what's in scope and what isn't. Also, we don't have time for bloat with our team size. We have to be laser focussed on what actually makes a difference to real websites. It's Chrome that has bloat!
Also the specs don't change much (there are additions, but almost always backwards-compatible), so once written the code shouldn't need too much maintenance.
I see it as writing a piece of foundational infrastructure. You can write your own HTTP library. But you don't need to: there are high-quality libraries readily available (e.g. curl or hyper). Similarly for HTML parsers or 2D graphics rendering. Nobody's done that for web layout yet (except arguably React Native's Yoga [0], but that's much less ambitious in terms of how much of the spec it attempts to support), so everybody has to write their own. But it's possible so we're doing it.
[0]: github.com/facebook/yoga/
Shadow DOM and CSS Grid don't strike me as bloat or fragmentation in any way? CSS Grid in particular is table stakes that would be part of any laser focus.
That's so fun to hear, I've been using taffy for layouting my little rusty eink calendar