The article starts with historical anecdote from 1996, and talks about later frame-busting JS. At the time, you could also bust out of frames before JS was widely supported, simply by setting your HTML `A` element `target` attributes to `_top`.
If you were already generating your HTML back then, including having a function to generate a link, this was possibly a one-line change.
If you did this HTML-only frame-busting, you'd still appear within whatever questionable frames setup some other side had going, but as soon as someone tried to follow a link-- bam, now the site you host has either taken over the window, or are in an all-new window.
Frames initially seemed like a godsend, for arguably useful purposes, like keeping a floating table-of-contents sidebar on a large document (before CSS). My once employer, Electronic Book Technologies (EBT), makers DynaText that TBL considered, jumped on frames for this purpose, and were able to convert DynaWeb to leverage frames "overnight" from the same SGML source.
But frames did have some downsides even within a site, even if you didn't mess up the HTML (e.g., bookmarking of individual pages wasn't as usable/possible, and you could also somehow land on a page intended to be in a frameset but outside the frameset navigation UI context).
Besides the TotalNews example the article mentions, there were a lot of sites putting other sites inside frames, maybe as often due to misunderstanding or not realizing, rather than aggressively trying to freeload.
(At the same time as TotalNews, I'd built a fuzzy Web scraper in Java, and a prototype "personalized newspaper" that used it to get news articles and weather from other sides. I didn't know what to do about ads, which were brand new and image banners, so I just captured them while I was scraping, and re-presented them in the UI, at the bottom of the page whenever presenting data from the pages they were on. Such were the clumsy days of young Web innocence. :)
i've made a frameset site recently. With modern stuff you can have a single document display different content (or a frameset) depending on the name of the frame and push state a more representative url. This also solves the history navigation.
loading videos and pdf files into frames is also nice.
If you were already generating your HTML back then, including having a function to generate a link, this was possibly a one-line change.
If you did this HTML-only frame-busting, you'd still appear within whatever questionable frames setup some other side had going, but as soon as someone tried to follow a link-- bam, now the site you host has either taken over the window, or are in an all-new window.
Frames initially seemed like a godsend, for arguably useful purposes, like keeping a floating table-of-contents sidebar on a large document (before CSS). My once employer, Electronic Book Technologies (EBT), makers DynaText that TBL considered, jumped on frames for this purpose, and were able to convert DynaWeb to leverage frames "overnight" from the same SGML source.
But frames did have some downsides even within a site, even if you didn't mess up the HTML (e.g., bookmarking of individual pages wasn't as usable/possible, and you could also somehow land on a page intended to be in a frameset but outside the frameset navigation UI context).
Besides the TotalNews example the article mentions, there were a lot of sites putting other sites inside frames, maybe as often due to misunderstanding or not realizing, rather than aggressively trying to freeload.
(At the same time as TotalNews, I'd built a fuzzy Web scraper in Java, and a prototype "personalized newspaper" that used it to get news articles and weather from other sides. I didn't know what to do about ads, which were brand new and image banners, so I just captured them while I was scraping, and re-presented them in the UI, at the bottom of the page whenever presenting data from the pages they were on. Such were the clumsy days of young Web innocence. :)