I hope we build Single-page apps with iFrames one day like how the web originally used <frame>. Everyone only talks about iFrames as if their only purpose is cross-origin content and <frame> is forgotten.
No, thats the misconception. All the security is around cross-origin usage and optional if using same-origin html like a SPA. Each iframe gets its own window element but that can simplify component design a ton if embraced.
A <frame> was a system for loading same-origin html files from an Index. It was the original Single-page multi-page system and at the time seemed good enough for 90% of html 1.0 sites. <iframe> was supposed to replace it but then everyone used it for Ads and closed-source widgets.
I remember the days back when <frame> was still common, and I wouldn't call it good enough because of the way it interacted with URL and history. It was basically impossible to bookmark a specific page on a website that used frames.
It's a shame that was never solved because there is no reason it should be "impossible". Nowadays we have more control of URL and history. There must be a way.
Well, the way frames are specified, each has an URL in its own right, so the way to do it would be to come up with some algorithm that combines them all in a single URL without losing any data. The resulting URLs would inevitably be messy, though.
These days we basically hack around all this in JS by manually controlling history. Which is brittle as hell, and why so many web apps break "Back" etc.
Managing state is always a hard problem. Versionable extensible persistence is harder still. Now add the requirement that this state has to be captured in a concise but human-readable way, and it's really hard to do in a way that doesn't introduce numerous footguns. I'm not saying that there isn't some good solution, but I don't know what it is, and I don't think anyone has figured this out yet.
I think OP's point is that our current approaches are hacks around HTML - what the browser sees isn't individual components, but their combined output. It would sure be nice if this was something directly supported by browsers without the need for server-side frameworks.
People should stop treating the dom and browser abstraction as golden standard. It's just an abstration that happens to be standardized. Sometimes it makes sense to follow the standard, sometimes "the standard" is just too shitty to follow.
That's my point - if the standard is so shitty in this area that everybody reinvents this particular wheel in a hacky way, the standard should be improved.
That's cool but people need to ship products while their ideas for improvement are endlessly debated, bikeshedded and possibly rejected eventually.
At the end the standard is never what they exactly wanted. So it's kinda a futile effort, and for what? Most don't write code for 3rd party consumption, where standards shine.
