upvote
Yes, of course for web applications you can't do full page reload (you weren't either back in the days, where web applications existed in form of java applets or flash content).

Let's face it, most uses of JS frameworks are for blogs or things that with full page reload you not even notice: nowadays browsers are advanced and only redraw the screen when finished loading the content, meaning that they would out of the box mostly do what React does (only render DOM elements who are changes), meaning that a page reload with a page that only changes one button at UI level does not result in a flicker or loading of the whole page.

BTW, even React now is suggesting people to run the code server-side if it is possible (it's the default of Next.JS), since it makes the project easier to maintain, debug, test, as well as get better score in SEO from search engines.

I'm still a fan of the "old" MVC models of classical frameworks such as Laravel, Django, Rails, etc. to me make overall projects that are easier to maintain for the fact that all code runs in the backend (except maybe some jQuery animation client side), model is well separated from the view, there is no API to maintain, etc.

reply
> full page reloads

grug remember ancestor used frames

then UX shaman said frame bad all sour faced frame ugly they said, multiple scrollbar bad

then 20 years later people use fancy js to emulate frames grug remember ancestor was right

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

reply
Classic frames were quite bad. Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want. The header/footer/sidebar frames are subordinate and should not navigate freely. Bookmarks should return me to the frameset state as I left it, not the default for that URL. History should contain the frameset state I saw, not separate entries for each individual frame.

Even with these problems, classic frames might have been salvageable, but nobody bothered to fix them.

reply
> Every frame on a page was a separate, independent, coequal instance of the browser engine. This is almost never what you actually want.

Most frames are used for menu, navigation, frame for data, frame for additional information of data. And they are great for that. I don't think that frames are different instances of the browser engine(?) but that doesn't matter the slightest(?). They are fast and lightweight.

> The header/footer/sidebar frames are subordinate and should not navigate freely.

They have the ability to navigate freely but obviously they don't do that, they navigate different frames.

reply
With a frameset page:

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.

reply
Yup, they are not enough for an SPA, not without javascript. And if you have javascript to handle history, URL, bookmarks and all that, you can just use divs without frames.
reply
This has nothing to do with SPAs.

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.

reply
This is exactly what I wrote? But let me rephrase it: frames are not enough solely for an SPA, they can't keep state, you need javascript/dynamic webserver for that.

> 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(?).

reply
It's cool that they have that link. Most frame sites didn't. JS actually isn't necessary to make that work, they could have just interpolated the requested page server-side. But it only correctly points to one frame. It's the most important frame, to be fair, but it doesn't do anything for the other two frames.

I don't understand how pre-HTML5, non-AJAX reference docs qualify as an "SPA". This is just an ordinary web site.

reply
deleted
reply
deleted
reply
> 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

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.

reply
They were never good. They were always broken in these ways. For some sites, it wasn't a big deal, because the only link that ever mattered was the main link. But a lot of places that used frames were like the POSIX specs or Javadocs, and they sucked for anything other than immediate, personal use. They were not deprecated because designers hated scrollbars (they do hate them, and that sucks too, but it's beside the point).

And, ironically, the best way to fix these problems with frames is to use JavaScript.

reply
> They were never good

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.

reply
Directionally correct but badly done can poison an idea. Frames sucked and never got better.

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.

reply
You can see frames in action on the POSIX spec:

https://pubs.opengroup.org/onlinepubs/9799919799/

They can navigate targeting any other frame. For example, clicking "System Interfaces" updates the bottom-left navigation menu, while keeping the state of the main document frame.

It's quite simple, just uses the `target` attribute (target=blank remains popular as a vestigial limb of this whole approach).

This also worked with multiple windows (yes, there were multi-window websites that could present interactions that handled multiple windows).

The popular iframe is sort of salvaged from frame tech, it is still used extensively and not deprecatred.

reply
An iframe is inherently subordinate. This solves one of the major issues with classic frames.

Classic frames are simple. Too simple. Your link goes to the default state of that frameset. Can you link me any non-default state? Can I share a link to my current state with you?

reply