Yeah, and honestly I don't think it's even down to the framework all the time either, but some frameworks make it easier than others. React, for instance, is f

Yeah, and honestly I don't think it's even down to the framework all the time either, but some frameworks make it easier than others. React, for instance, is famously the opposite of bloated ("it's just the V in MVC") and leaves it up to the user to shape it how they like. I think the trouble is that it's not really fast by default. You end up needing to be pretty careful to avoid excessive rendering, which in practice means thinking about referential equality a lot, and trying to make sure renders only happen when you mean them to. React can be plenty fast though, with care. I think Svelte does a better job of being fast by default, and part of that is because it's more truly "reactive". Change a variable, and that specific part of the page is updated; if other variables depend on that one, then those parts are re-rendered too. It needs a lot less babysitting to avoid extra CPU cycles. I've thought about this a bunch because I'm building a video editor with Svelte and Tauri. (Tauri is a Rust-based alternative to Electron that uses the system webview instead of Chromium). Of the things I'd expect to be hampered by being web-based, "video editor" is pretty high on that list! But I've yet to run into a performance problem that came down to the browser being just too slow. It has so far been something under my control, whether that's needing to optimize some canvas drawing, or finding the most efficient way to get video frames on the screen, or minimizing the messages I'm sending between Rust and the UI. There are certainly inefficiencies that wouldn't be a problem with a native app, but it's been possible to work around them so far. And as the sole developer on the project, it's nice to be able to serve a larger market without having to keep 2 code bases in sync.