I am doing something similar. The problem is not just HTML/CSS it's also JS. You need a strongly typed language, and have a scripting language on top. What I'm doing now is a Rust based framework, with an Erlang like scripting language to define complex interactions. Taking inspiration from Flash, all animations and transitions can be keyframed with tweens. Taking inspiration from the C/C++ to python interoperability, I want the same with Rust and Erlang. Now my entire backend can be written in Rust.

Unfortunately, I'm not open sourcing it. Not until I get a proper graphics context, and implement my own rendering engine. I think web assembly is going to revolutionize the web. I see browsers allowing you to cache common libraries/assets, and html/css being replaced by several competing UI paradigms. The one I favour is inspired from functional reactive paradigm, but there are equally valid alternatives. I don't think there will be a single frame work to rule them all, just competing schools of thought. Right now the web doesn't have any competing paradigms, just html, css,and js.

Reason web sucks:
HTML/CSS are not suited to define complex UIs with intricate layouts and complex transitions and key frame animation. This problem was better addressed 30 years ago. Look at the menu UIs in games from the n64/ps1 to ps2/gamecube era (I'm talking about the game menus, not the game themselves). Some of them had far more impressive UIs than the webpages of today. This type of UI is an order of magnitude harder with html/css than just doing it all via X11 and C (even with memory management concerns).

The reason for this is that HTML first isn't strongly typed. If you make something complicated, and make a small change, it messes everything up. Your compiler can't help you. HTML tags are somewhat inconsistent. React, Rails etc. are all trying to address this problem. They are all taking inspiration from android, iOS, QT and gtk+ to make it somewhat component based. However, you fundamentally can't achieve this. HTML is in a land of its own, when you create an HTML tag, sure you can wrap it in a JS class, and mimic some of the characteristics that desktop frameworks provide you. You won't get the whole thing. I've seen many times different frameworks reinventing html templates (like handle bars). Templates can't solve all issues.

CSS sucks. The first thing about css that sucks is the "cascading" part of css. It should just be ss. CSS was originally designed to limit bandwidth by having it cascading. That's not the case today, and it messes everything up. The second thing that sucks, similar to why html sucks, is that again css is in a land of its own. It's hard to control css from JS (for interactive site you want this). I'm not even going to talk about how hard it is to position things properly via css when you are building layouts dynamically.

JS just sucks. I don't think I need to elaborate, I've mentioned enough points already.

Every single web framework out there is trying to address some aspect of the problems I mentioned, but my claim is that you can't solve it, you need to start over. Imagine if CPU makers made crappy inconsistent assembly code. Every year a new compilers and languages come out that tries to fix their predecessors. The most logical choice is instead to ditch that chip maker, make a better CPU with a consistent assembly code. You can't do that with web, you can't ditch assembly(html,js,css).

It only took 30 years for the web to get web sockets, webgl and now wasm. I think in another 20 years we'll come a full and get the remaining amenities that modern operating systems provide.

The reason I chose Rust is because it's a low level language with strong typing. It's not quite Haskell, but good enough. Writing a web server and UI with Rust is very nice. It just connects to the backend processes with ease, and doesn't make things awkward the way npm does. I do a lot of low level numerical and mathematical simulations, all done in C/Rust with all coordination & distributed computing done in Rust. I want Rust to take over. The sequence should be: Erlang -> Rust -> C

I chose Erlang because years ago I saw how reactive programming is extremely useful for complex interactions in a AAA game I was working on. In a game system you have the play interacting with the world, with enemies. The enemies interact with the player and each other. The player can pause the game at any point, then you need to bring up a menu screen with its own interactions. I've seen this work flow done in many different ways, and by far the reactive paradigm is the most sane. This was done in a bastardized version of Lua and Lisp.