The Benefits of Iframe Based Development
stakedy.com
stakedy.com
For an example, tech-based articles I loathe sifting through online are about anything related to recent events like a macOS update. Google Search: "macos big sur release notes" https://imgur.com/a/fmhyk6d
Imagine going to the first Apple link, not getting any details, and then moving onto the 3rd and 4th links hoping that some internet journalist broke down the details for you because the title includes "What's New?". Nope. The links all just resort to barely-updated articles that basically say "11.6.1 got released". Amazing, thank you tech journalists!
At least an article about iframes might give some boring facts to help crunch in your mind while your eyes glaze through.
3rd and 4th links:
- https://mrmacintosh.com/macos-big-sur-11-6-1-update-whats-ne...
- https://www.macworld.com/article/234324/macos-big-sur-faq.ht...
I'm getting weird uncanny valley vibes lol.
Like how everything is a zero day now.
but perhaps these issues have all been remedied? And Iframe is now the perfect container for a modern day component?
... passing messages directly between parts of a page distinctly unfashionable in the age of redux and context. Having each component be its own request to the server - bizarre-seeming in 2021 but maybe something transformational there if our future is moving back to server-rendered HTML ... some crazy blockchain webserver coordinating ui state across dozens of tiny frames in a webpage, each with its own crypto account ? ... could be great, who knows
[edit: if I have just engaged in debate with an AI programmed to generate absurdities (per @solarpunk's comment), I have some preconceptions I'll have to go and reevaluate now]
They were very handy for a variety of scenarios so it became part of the spec, but I think most self-respecting web developers avoided them out of principle.
Some look at it, but take it as a reason to argue knowingly.
not easy to take a conclusion ...
It reads like something a web developer might write. I googled two sentences as a test, and they were both unique to that page and site.
Edit: code quality is questionable - by my reckoning. Look at code buttons on this page: https://celody.com/modules.html
It's not impossible to generate new sentences with AI, we've been able to do this for a long time.
The footer on https://stakedy.com/long/how-staking-on-stakedy-works.html (the about page) says:
> Stakedy is a product from digital people within Celody
I'm not sure if that means that the Authors of the posts are AIs, or if it's just made from the same people that made Celody. Maybe the ambiguity is on purpose?
I don't see how this follows.
You seem to have started from the position that an AI can not write an article with correct facts and internal consistency, and then argued that since this article has correct facts and internal consistency, it can not have been written by an AI?
The overview is better than what you might find on stack exchange about using iframes for security sandboxes (Cue joke about intelligence and stack exchange).
Your comment is just saying “if you are responding to something that passes the Turing Test, how can you tell?”.
And it's not cool. They figured out a lot of dark patterns, like "number of photos, regardless of quality, is a strong driver to sale", so they started duplicating photos in a set to bump up the total photo count. They figured out they could reuse walk-around videos for any same make/model/trim/color across the country and nobody would notice when they walked in the lot the different door panel dings and such. Or they'd display a car that matches your very specific search, that was actually hundreds of miles away, to get you on the lot just to say "damn, we just sold it, but we got this other one in a different color".
I worked for them for about 3 months before I literally couldn't stomach it anymore. I threw up in my driveway, went to work, and gave my notice.
Like the questions in my exams where I don't exactly know the answer but I know the main defintion of the topic. Then in the last 5 minutes of the exam I just go ahead and write a bunch of stuff only based on the defintion of the main topic. I will reuse and rephrasee the same thing over and over to give some meat to the answer but it is not a great answer and provides zero insights.
I usually use FRAMESET and FRAMEs: they are positioned perfectly in a grid, with no need for CSS or TABLE. There's no postMessage API: you can write <A target=other-frame-name> to navigate to a page in another FRAME.
HTML5 doesn't have FRAMESET, but all the browsers still support HTML4 perfectly.
With "static" web pages people used iframes, so they didn't have to update navigation on all pages. With PHP you cod simply do <?php include ('menu.php');?> and had a single source of truth.
This makes about 90% of early PHP scripts :)
There are definitely a few scenarios where they are useful.
It's not amazing, but it works.
Avoiding cookies in iframes is important because browsers are getting more restrictive, so security for iframes is difficult to manage. We passed a unique session token to the iframes from the owning page using postMessage(), and the two servers (we controlled both) communicated directly for authentication (avoid putting authentication into the browser since your enemy controls it completely).
I have always found trying to use iframes as a visible section of your UI is really crappy. Troubles with keyboard focus, resizing, modal dialogs, scrolling, Mobile Safari quirks, detecting loading or other failures, yada yada yada.
After pursuing methods of getting user consent to use 3rd party cookies via the storage API, the end result was the user jumping through hoops by repeatedly clicking buttons to invoke user interaction in different contexts to eventually get a prompt to allow cookies. It did work, but there were strange bugs with it on mobile Safari... e.g., the prompt to allow cookies never appeared after clicking the button but after putting Safari in the background and going back to it, it did appear.
The UX of all this was pretty undesirable so we just gave up and had the tool open in a full window and wondered why we didn't think to do that from the beginning.