Yeah, I mean stuff you can't or won't put into the client-server communication. At some level of detail it becomes wasteful. For example a multi-step form, whe

Yeah, I mean stuff you can't or won't put into the client-server communication. At some level of detail it becomes wasteful. For example a multi-step form, where you can browse for options, have a lot of filters such as logic that displays different options based on previously selected ones and so on. It's not that you can't do it via HTTP. But it's also wasteful. For this kind of stuff you don't need to pay for the round-trips. The server doesn't need to know anything about the UI state here. The only transactional parts are the entry point and the final result. Things like these are a great place for "interactive islands". You can architect the skeleton and all the actually transactional parts as a normal HTTP/REST site, that exchanges HTML and so on. But for the parts that are really _just_ UI related state like the above, it's unnecessary work (compute/complexity/networking) to do so. Other examples include: interactive visualizations via SVG/WebGL, rich text editing and so on. All of those things are relatively common things. What I was getting at above, is that it will get messy if you have JS state like that and but you don't write it in a way where the JS "owns" the DOM, from start to finish, for that component or island. It doesn't have to be react/redux or w/e. There are simpler, more performant solutions that lean on web standards and are much lighter weight like Lit etc.