History doesn't work right
Bookmarks don't work right -- this applies to link sharing and incoming links too
Back button doesn't work right
The concept is good. The implementation is bad.
Take the POSIX specs linked in a sibling comment.
Or take the classic Javadocs. I am currently looking at the docs for java.util.ArrayList. Here's a link to it from my browser's URL bar: https://docs.oracle.com/javase/8/docs/api/
But you didn't go to the docs for java.util.ArrayList, you went to the starting page. Ok, fine, I'll link you directly to the ArrayList docs, for which I had to "view frame source" and grab the URL: https://docs.oracle.com/javase/8/docs/api/java/util/ArrayLis...
Ok, but now you don't see any of the other frames, do you? And I had one of those frames pointing at the java.util class. So none of these links show you what I saw.
And if I look in my history, there is no entry that corresponds to what I actually saw. There are separate entries for each frame, but none of them load the frameset page with the correct state.
These are strongly hyperlinked reference documents. Classic use of HTML. No JavaScript or even CSS needed.
> Ok, fine, I'll link you directly to the ArrayList docs, for which I had to "view frame source" and grab the URL:
You could've just right click on the "frames" link, and copy the URL: https://docs.oracle.com/javase/8/docs/api/index.html?java/ut... . They use javascript to navigate based on the search params in the URL. It's not great, it should update the URL as you navigate, maybe you can send them a PR for that. (And to change state of the boxes on the left too.)
Also browser history handling is really messy and hard to get right, regardless of frames.
> And if I look in my history, there is no entry that corresponds to what I actually saw.
? If you write a javascript +1 button that updates a counter, there won't be a corresponding entry in your history for the actual states of your counter. I don't see how that is a fundamental problem with javascript(?).
I don't understand how pre-HTML5, non-AJAX reference docs qualify as an "SPA". This is just an ordinary web site.
> Bookmarks don't work right -- this applies to link sharing and incoming links too
> Back button doesn't work right
Statements that apply to many JS webpages too.
pushState/popState came years after frames lost popularity. These issues are not related to their downfall.
Relax, dude. I'm not claiming we should use frames today. I'm saying they were simple good tools for the time.
And, ironically, the best way to fix these problems with frames is to use JavaScript.
They were good enough.
> For some sites, it wasn't a big deal
Precisely my point.
> POSIX specs or Javadocs
Hey, they work for me.
> the best way to fix these problems with frames is to use JavaScript.
Some small amounts of javascript. Mainly, proxy the state for the main frame to the address bar. No need for virtual dom, babel, react, etc.
--
_Again_, you're arguing like I'm defending frames for use today. That's not what I'm doing.
Many websites follow a "left navigation, center content" overall layout, in which the navigation stays somehow stationary and the content is updated. Frames were broken, but were in the right direction. You're nitpicking on the ways they were broken instead of seeing the big picture.
Along with other issues, this gave rise to AJAX and SPAs and JS frameworks. A big part of how we got where we are today is because the people making the web standards decided to screw around with XHTML and "the semantic web" (another directionally correct but badly done thing!) and other BS for about a decade instead of improving the status quo.
So we can and often should return to ancestor but if we're going to lay blame and trace the history, we ought to do it right.
Frames gave place to (the incorrect use of) tables. The table era was way worse than it is today. Transparent gif spacers, colspan... it was all hacks.
The table era gave birth to a renewal of web standards. This ran mostly separately from the semantic web (W3C is a consortium, not a single central group).
The table era finally gave way to the jQuery era. Roughly around this time, browser standards got their shit together... but vendors didn't.
Finally, the jQuery era ended with the rise of full JS frameworks (backbone first, then ember, winjs, angular, react). Vendors operating outside standards still dominate in this era.
There's at least two whole generations between frames and SPAs. That's why I used the word "ancestor", it's 90s tech I barely remember because I was a teenager. All the other following eras I lived through and experienced first hand.
The poison on the frames idea wore off ages ago. The fact that websites not made with them resemble their use is a proof of that, they just don't share the same implementation. The "idea" is seen with kind eyes today.
The key point about frames in the original context of this thread as I understood it was that they allowed a site to only load the content that actually changes. So accounting for the table-layout era doesn't really change my perspective: frames were so bad, that web sites were willing to regress to full-page-loads instead, at least until AJAX came along -- though that also coincides with the rise of the (still ongoing) div-layout era.
I agree wholeheartedly that the concept of partial page reloading in a rectilinear grid is alive and well. Doing that with JavaScript and CSS is the whole premise of an SPA as I understand it, and those details are key to the difference between now and the heyday of frames. But there was also a time when full-page-loading was the norm between the two eras, reflecting the disillusionment with frames as they were implemented and ossified.
The W3C (*) spent a good few years working on multiple things most of which didn't pan out. Maybe I'm being too harsh, but it feels like a lot of their working groups just went off and disconnected from practice and industry for far too long. Maybe that was tangential to the ~decade-long stagnation of web standards, but that doesn't really change the point of my criticism.
* = Ecma has a part in this too, since JavaScript was standardized by them instead of W3C for whatever reason, and they also went off into la-la land for roughly the same period of time
Probably, yes!
> So accounting for the table-layout era doesn't really change my perspective: frames were so bad, that web sites were willing to regress to full-page-loads instead
That's where we disagree.
From my point of view, what brought sites to full page loads were designers. Design folk wanted to break out of the "left side navigation, right content" mold and make good looking visual experiences.
This all started with sites like this:
https://www.spacejam.com/1996/
This website is a interstitial fossil between frames and full table nightmare. The homepage represents what (at the time) was a radical way of experiencing the web.
It still carries vestiges of frames in other sections:
https://www.spacejam.com/1996/cmp/jamcentral/jamcentralframe...
However, the home is their crown jewel and it is representative of the years that followed.
This new visual experience was enough to discard partial loading. And for a while, it stayed like this.
JS up to this point was still a toy. DHTML, hover tricks, trinkets following the mouse cursor. It was unthinkable to use it to manage content.
It was not until CSS zen garden, in 2003, that things started to shift:
https://csszengarden.com/pages/about/
Now, some people were saying that you could do pretty websites without tables. By this time, frames were already forgotten and obsolete.
So, JS never killed frames. There was a whole generation in between that never used frames, but also never used JS to manage content (no AJAX, no innerHTML shinenigans, nothing).
Today, websites look more like the POSIX spec (in structure and how content is loaded) than the SpaceJam website that defined a generation. The frames idea is kind of back in town. It doesn't matter that we don't use the same 90s tech, they were right about content over style, right about partial loading, right about a lot of structural things.
I should clarify. I don't think JS killed frames, that's not what I meant. If anything, I think JS could have saved frames. But the failure of frames left a gap that eventually JS (esp. with AJAX) filled. Lots of other stuff was going on at this time too, including alternative tech like Java, Flash, and ActiveX, all of which were trying to do more by bypassing the "standard" tech stack entirely.
I think the ossification of web standards from ca. 1999 to 2012, combined with the rapidly growing user base, and with web developers/designers aggressively pushing the envelope of what the tech could do, put the standard stuff on the back foot pretty badly. Really, I'm talking about the whole ecosystem and not just the standards bodies themselves; there was an era where e.g. improving HTML itself was just not the active mentality. Both inside and outside of W3C (etc.), it seemed that nobody cared to make the standard stuff better. W3C focused on unproductive tangents; web devs focused on non-standard tech or "not the intended use" (like tables for layout).
So I think we can say that <frameset> frames died a somewhat unfair death, caused partly by their initial shortcomings, partly by people trying to break outside of the (literal) boxes they imposed, and partly by the inability of the standard tech to evolve and address those shortcomings in a timely fashion. But just as there was a reason they failed, there was a reason they existed too.