> 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).
> (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.
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!
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!
We do have the networking abstracted behind a trait (so people can bring their own implementation if they want), but we need something for testing (and it's convenient for users if we provide a default option for them too). I would also note that our networking support is a pretty thin layer (~200 LoC) around the https://docs.rs/reqwest/ crate. As well as HTTP, reqwest is handling things like cookies and form encoding for us.
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'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 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.
I believe it’s possible, but it’s going to take a little bit of outside of the box thinking in that it’d be most practical if the UI toolkit isn’t bound strictly to a single paradigm.
Both imperative and declarative UIs have serious problems. Imperative toolkits can get hairy with their boilerplate and can make staying in sync with data state a real challenge, while declarative toolkits have a strong tendency towards rigidity that makes for awkward DX and ugly code in all but the simplest todo app kind of examples and don’t lend themselves to fine grained control.
I think there’s a happy medium to be found between the two in a well-designed hybrid. This hypothetical framework would allow full declarative in situations where that’s highly suitable, but would also allow the dev to do widget configuration in a more traditional imperative style or if necessary fall back to full imperative. Support for reactivity on both sides of the coin would be robust so staying in lockstep with data is simplified.
This would bring down boilerplate substantially since the broader layout of most screens could be done declaratively, but it wouldn’t come at the cost of more advanced functionality, flexibility, and developer control on the individual widget level.
I’d like to dig further into these ideas at some point if I get time.
I’ve been thinking about this myself and really UI development is mostly about design up front, many times with a well built design system UI changes can be trivial.
But as you alluded to, data binding can be difficult. For some things, and even most web pages fall into this, you effectively load the data up front render something and then don’t touch it again, on change you can absolutely just rerender everything because it is truly trivial to render.
But for other things you need extremely complex data binding with constraint systems and things are extremely complex to render (CAD, Games, etc). For that you need cacheing and partial updates etc
These is a spectrum between that and I just don’t see the ability to abstract over it.
And taking a11y into consideration no matter how you choose to render you also need to construct a tree or graph for screen readers, this also needs data binding. You will probably also be tying keyboard navigation to that graph (other than for a game but even then maybe)
I feel like though a lot of performance problems on web is 1) people not understanding fundamentally how expensive certain operations are 2) lack of hardware acceleration for some vector operations in CEF / browsers
For 1 just think about some UI element, a rounded button or something. A mesh had to be dynamically generated for that UI element and then drawn, if you for some reason are causing that mesh to be regenerated every frame that becomes expensive very quickly.
Text is generally generated on the fly and cached as well, if its not software rendered.
Once you get down to the nuts and bolts modern UI is a complex problem, and to build a framework for that, you need to get into the nuts and bolts.
This is part of why I believe that smart hybridization is the key. In a complex application, you need qualities from all major schools of UI framework design, but broadly speaking we’ve been obsessed with trying to find a “silver bullet” one true paradigm that fits every use case, when no such thing exists.
I also think that UI frameworks try to hard too be “magic” and unopinionated where they should instead be highly communicative and naturally guide developers into the happy path. So following your example of the excessively re-rendered button, the framework should really be detecting the unneeded redraws and complaining to the dev about them and potentially even presenting as compiler errors in production builds until they’re fixed (which the compiler offers hints on how to do).
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
No support for RTL or CJK text, IMEs, or accessibility tools leaves it pretty firmly in the "toy" category for me for now, sadly.
This isn't meant to bash on the project specifically, basically the only tools that meet that criteria are platform native UIs, the web stack (including Electron), Qt and Flutter.
AccessKit is promising to change that but I haven't checked in a while how it's going. I did see GTK looking into it as a cross platform option as GTK's accessibility support only works on the Linux desktop currently
> No support for RTL or CJK text, IMEs, or accessibility tools leaves it pretty firmly in the "toy" category for me for now, sadly.
I18n, L10n and A11y tend to be very challenging features, making your wishlist a tall order. Solving that will require a larger developer mindshare. (I'm not sure how much of the existing frameworks can be reused here).
> basically the only tools that meet that criteria are platform native UIs ...
Here's the good news! Iced is already a platform native UI toolkit. It powers the Cosmic desktop and a few important applications are based on it. Iced is sure to receive a lot of attention once Cosmic stabilizes. Hopefully, you will get your wish sooner than later.
すごい！Japanese is one of our localization targets, so this is amazing!
I'm building a graphically heavy app, so two more questions:
1) Is iced appropriate for building a canvas-type drawing app with image inclusions? Right now we're using Konva.js and we'd be losing a tremendous amount of out of the box flexibility in porting to iced, but the performance wins would be a major selling point.
2) Can you include Bevy panes? We're also doing some 3D visualization, and we currently use Three.js. But we have a lot of Bevy experience too.
Awesome! Glad to hear that and I hope you do give it another try.
1. Yes but not necessarily a "resounding yes" because images right now are drawn on the top of each layer, so if you want to write on top of images you'll need to create different layers for each of them which is more expensive than not doing that. You may be OK with that for now (I am, for my slideshow editor), but there's pending work to be done there to remove the requirement of explicit layering and thus improve performance.
2. I'm not familiar enough with Bevy to opine. I know there's https://github.com/tasgon/bevy_iced but I think that might do the opposite of what you want. Having said that, iced lets you write custom shaders so you can go as deep in the stack as you'd like for any 3D visualization. The caveat then being that you're implementing all that logic yourself, but there's no stopping you.
Importantly, I think it's worth joining the Discord and asking around, seeing what people are building, trying the library, and pointing out where you think you need help. This helps the core team understand use cases better and in some ways guides development IMHO. I'm not part of the core team, so I could be wrong, but that's my perception.
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)
Makepad [0] is indeed quite impressive. You can directly try Makepad Studio in your browser [1]. Don't know if that's the latest or the demo version. Their demo vids are a good watch.
Slint does not use a browser. Instead, it has its own runtime written in rust and uses a custom DSL to describe the UI.
It has API for different programming language.
For Javascript, it uses node or deno for the application logic, and then spawn the UI with its own runtime without the browser.
In a way it is the opposite which took the JS runtime out of electron to replace it with a Rust API, while Slint keeps the JS runtime but swaps the browser for its own runtime (for the JS dev point of view)
> 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
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'm not sure. I tried opening an issue at https://github.com/w3c/csswg-drafts but that didn't get me very far. I suspect it's a case of making connections and then getting yourself an invite to present at a meeting.
I succeeded with opening an issue and getting something to be supported in browsers (although I think it's not yet in the standard). It was a very small and fairly uncontraversial tweak which was easy to specify, implement, and test, though - bigger things are probably harder.
If you can socialize your idea to a few of the people that show up frequently in the issues, it can really help. See if there's someone with open DMs, tell them you work on CSS in Servo, and ask what they think.
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.
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.
> 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
I think higher speeds should be allowed, but they should be liscensed like any other motocycle (perhaps they're their own class with their own rules, but they should be registered with a license).
I can hit that speed on a regular bike with a good wind, which is perfectly legal. Adding an extra licensing step could slow the adoption of people switching from cars to e-bikes for commutes (a very positive step in my opinion).
A coworker of mine has a medium-speed e-bike, maybe goes 25-30mph in the (mostly empty) bike lane of a 45mph road for a lot of the journey. Tries to take 35mph side roads for the rest. It’s a very suburban/stroad-y area.
His commute is about 4-5 miles, so he gets to work in ~10 minutes. This is a great solution for all - less cars, more efficient vehicle, less stressful for him not needing to drive.
Any impediment to that reduces the likelihood of other people catching on to what he does.
Maybe those medium-speed e-bikes should have a license in the same way as a fishing license. It’s trivial to obtain, but if you violate certain rules, the license acts as a means to revoke your privileges. I’d be perfectly ok with that.
Does that bike lane go next to parked cars? You can imagine that even conscientious drivers could fail to see a bike approaching that fast and open their door into its path.
I admit I rode my bike up to 35-45 MPH sometimes in my youth, just with pedaling and gravity. But, I was wise enough to realize I belong in a normal traffic lane at that point, not flying along the edge near pedestrians, parked cars, etc. And I wasn't exceeding the posted speed limit for that road.
I had a less wise friend, with a very aerodynamic road bike, who hit ~60 MPH (in a 25 MPH zone) and T-boned a car because they did not consider unsafe it was with the limited sight lines. I felt sorry for the driver who, by all accounts, didn't do anything wrong.
Bringing these points back to ones made in the previous comments:
- Is there a meaningful difference of some people being able to actively hit 30 mph vs everyone being able to passively go 30 mph the whole way
- Should vehicles capable of those speeds just be licensed in some way based on that rather than whether or not they have an ICE and 4 wheels
- Is there a way to separate the classifications so devices which are more truly "e-bike" in typical speed do not need to follow the same regulations as something more "electronic motorcycle".
Your friend going to work and back bike lanes and streets at 30 mph sounds a lot closer to the "electronic motorcycle" side of things, so doesn't necessarily say one thing or the other about more truly "e-bike" types of devices or why they should be considered the same.
I would be more sympathetic to YouTube's plight here if they weren't aggressively pushing addictive features like "Shorts" with no option to disable them.
Disable your yt history, it disables pretty much everything yt wants to push.
When I open yt I get an empty page with a search box, even clicking on the Shorts page it just says "Recommendations are off
Your watch history is off, and we rely on watch history to tailor your Shorts feed. You can change your setting at any time, or try searching for Shorts instead. Learn more."
But that is unfortunately a nuclear option that should not need to be taken to perform such a thing. Like the op, I have no interest in Shorts, especially considering the type of content that seems to proliferate that format.
However, I feel like YouTube does a genuinely good job — at least for me personally — of curating my feed with videos I have genuine interest in; mostly being tech talks and home DIY.
I'd hate to lose the discoverability I currently have for the sake of having to disable a feature like Shorts.
I use youtube without an account, only a cookie which I can nuke anytime. My experience with this is as you describe; it does a great job of giving me videos relevant to my interests. If it ever goes off the rails, I nuke the cookie and start over; reseeding the recommendations by watching a few videos from high-brow channels like Applied Science. It recommends no shorts to me.
The amount of adult content creators using YouTube as soft advertising has exploded too. I only subscribe to tech/gaming/etc. channels and my feed is filled with this content. They use services like linktree to add one hop to obfuscate their channels from the 'adult' (pornography) content they have on other platforms.
All the government really needs to do here is ban YT shorts for kids under 16 or whatever age. Watch YT finally give us parents the ability to block YT shorts for our kids.
Every time I hear some AI video my kids watching, it's a short.
YouTube is such an invaluable learning resource that I would have serious qualms about denying a school-age child access to it. You're right that I wish it was possible to turn off the predatory features, though.
But ultimately I can't see how a blanket law banning kids makes sense instead of a law banning the platform from targeting kids.
> YouTube is such an invaluable learning resource that I would have serious qualms about denying a school-age child access to it.
Give a 5 years old unlimited access to youtube and witness the cesspool it is. Nobody is saying youtube is 100% bad, but people who don't know better (kids for example) are easily manipulated in watching the most brain rot content you can imagine, for hours and hours. It's an ocean of shit within which you might find a few gems if you know what you want or if you get extremely lucky.
> Maybe children should be banned from everywhere.
Content wise they used to be until very recently, what did I have access to as a kid before internet ? Some books from my parents, some booked from school, whatever was allowed on public TV when my parents allowed me to watch it, maybe the odd porn mag from the older brother of a friend of a friend. That's very tame compared to what you have access to from even heavily censored search engines like google
Or the algorithm focusing on engagement over everything else, instead of actual good, related videos. I've said this here before, I'm a huge Phish fan and I listen to old concerts on youtube. I will literally get far right-wing videos as a recommendation after a Phish concert video. I have watch history off. I don't watch political videos on youtube, right or left. And Phish's fan base would lean hard left. Why am I seeing Candace Owens after a 94 Phish show? With actions like that, I understand the ban.
> And the patient made that choice by establishing that family dynamics and by not having specific instructions even while seeing over decades the family dynamics they created themselves.
Most people who are old today (or in the last few decades) probably wouldn't have thought about it because it wasn't something that affected their parents who likely didn't live that long in the first place.
People really need to consider the alternative though. I've seen a lot of old people who were desperate to depart this world but whose younger relatives wouldn't let them.
Perhaps in the US, but nobody is getting paid that in most public European systems. A quick google suggests that the absolute highest pay band for a doctor in the UK is ~£142k (~$190k USD). And there won't be many making that.
I think most of the increase in healthcare costs is coming from elderly people (because people are living longer). So while otherwise a good thing, I'm not sure that will help this particular problem.
CNAs (Certified Nursing Assistants) have low up-front training costs, but don't make a lot of money: an average of $19/hr [1]. So at least some of the less skilled work is being done with economic efficiency.
I find that interpolating strings works pretty well for this use case (which actually switchd TO string interpolation from ORMs at a previous job of mine).
But this is conditional on either your database or your minimal abstraction layer having support for bindings arrays of data with a single placeholder (which is generally true for Postgres).
reply