I agree with you there: the web has a lot of built-in support already, and if you wanted more of a "local" app, there's always the electron framework that'll embed the browser into an application window.
But yeah, with this idea, I was thinking that the framework would be written completely in Rust as an alternative to Qt and Gtk like you were saying. Except the development experience is much more web-like as the views would be DOM elements, event handlers are attached directly to those elements, and views can be styled in a CSS-like syntax, except with stronger typing. This is where the my macro research would pay off, provided I don't go macro-crazy and end up building something that's not very Rust-like at all, which I can definitely see happening.
HTML5/CSS3 is really nice these days, but there are a LOT of ways to do any one thing due to decades of cruft and compatibility which of course naturally happens. Especially when a platform such as "the Internet" exploded in growth like it did lol. I've always thought it'd be fun to come up with my own markup and styling spec that removed all of that cruft, and focused on newer styling patterns. Especially where all styling is truly encapsulated like it is with the shadow DOM spec.
The framework would utilize reactive component methodologies like React, React Native, LitElement, yew, etc. so everything is declaratively-rendered.
If I got far enough, I'd probably write the renderer in OpenGL for starters. Modern OpenGL though, and then once I have enough of it working natively, I'd consider writing a replacement for the renderer in gfx-rs (which I would have to learn, so it's a farcry there). The project would benefit from being able to take advantage of Vulkan/Metal/DX12 where available which would further reduce CPU overhead of rendering stuff.
gfx-rs also yields WebGL support which at that point, you have an entire app written completely in Rust that could be built to WASM and completely rendered within a WebGL canvas. This would remove A LOT of browser compatibility problems/bugs as the entire app would render within a WebGL canvas. Capturing keyboard events from the browser/native window would have to be handled with care after a while. I'm honestly not sure about that yet... I'd be more concerned with porting my text OpenGL renderer over from C++ to Rust, and getting the word wrap algorithm to be performant when there are many lines of text to render.
Then, once I have that completed, I'd port the entire ecosystem of the software packages that I've been building and open sourcing initially for LitElement over to this new Rust app stack. That way the Rust app framework basically starts off with a state/validation framework for building forms (this is actually one of my own inventions that I came up with on my own, and it's killer), a router for rendering based off of location, a set of skinnable components for things like textfields, textareas, checkboxes, calendars, etc. Modal popup/slide-out overlay stack manager (works within the DOM-only, but native OS windows could be supported for native desktop builds).
Going further down the web app rabbit hole: it'd be neat to eventually break the rendering architecture up into a client/server architecture which at that point, you kind of have server-side rendering without any additional effort for WebGL deployments. A flag could be added to the built-in
link element which would actually render these links as anchor tags into the DOM with the
href set up to help with SEO.
Most importantly: an automation framework comparable to WDIO. Now THAT would be really fun to write. I'm honestly more excited to build that and the rest of the dev tools like the Inspect Element dock with the framework than building the framework itself haha. Those devtools windows could be bundled into the app's crate for dev builds, then stripped out in prod. At that point, your DOM tree is now hidden from the end-user if you'd like that layer of security in the browser.
That's a LOT of work for a single person though, but it's some cool pie in the sky to think about. I'm mainly interested in learning about macros, how to use them effectively, and learn more about ASTs.