3 ms·

>it's simply not possible to avoid re-rendering the entire page without using XHR Wrong on two separate levels. First up, technologies like iframes, frames, a

by dexen 6y ago

>it's simply not possible to avoid re-rendering the entire page without using XHR Wrong on two separate levels. First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever. Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs. The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity. If you pay even a little attention to order of loading you can avoid FOUC entirely. If you pay a little attention to defining sizes of leading elements, you'll have constant layout of the top part of the page, and avoid flash of white background. If you use anchors here and there your user will be scrolled to the proper position. Yes your page can easily look as if it got only updated with JS after doing a full load+render. The technology is already in the browser; no need to approximate it with three layers of JS.

shard972 6y ago
> First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever. Thats complete BS, Iframes are just loading other HTML pages so you still need another tech to allow for static HTML to re-render itself. If your just talking about some kind iframe jacking then I don't see how thats remotely relevant. Objects/Embeds? Sure you don't need javascript to make a page interactive if you have things like Flash/Silverlight/UnityWeb where your just executing through a completely foreign API usually via a plugin. > Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs. Maybe if your using something older than sandy bridge trying to use facebook I guess but outside of these kind of silly edge cases, ive rarely seen an iphone/macbook/desktop from the last 5 years spend more than half a second on any kind of heavy redrawing logic ever. > The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity. Then they can use another app website without JS that does all these features they want but with Iframes and flash.
amw-zero 6y ago
You can’t compare the UI of a web page built in this way to an SPA or a native client. Re-rendering an entire page on every interaction is strategically never going to get you the same experience. I understand wanting to be a browser purist, but web applications have had pretty laughable UX compared to native apps of even 20 years ago. I mean look at an iOS app designed by Apple. I always reference the AppStore app itself. You simply can’t build that app as a web app, certainly not by using iframes as a “solution.”

by dexen 6y ago

shard972 6y ago

> First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever. Thats complete BS, Iframes are just loading other HTML pages so you still need another tech to allow for static HTML to re-render itself. If your just talking about some kind iframe jacking then I don't see how thats remotely relevant. Objects/Embeds? Sure you don't need javascript to make a page interactive if you have things like Flash/Silverlight/UnityWeb where your just executing through a completely foreign API usually via a plugin. > Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs. Maybe if your using something older than sandy bridge trying to use facebook I guess but outside of these kind of silly edge cases, ive rarely seen an iphone/macbook/desktop from the last 5 years spend more than half a second on any kind of heavy redrawing logic ever. > The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity. Then they can use another app website without JS that does all these features they want but with Iframes and flash.

amw-zero 6y ago

You can’t compare the UI of a web page built in this way to an SPA or a native client. Re-rendering an entire page on every interaction is strategically never going to get you the same experience. I understand wanting to be a browser purist, but web applications have had pretty laughable UX compared to native apps of even 20 years ago. I mean look at an iOS app designed by Apple. I always reference the AppStore app itself. You simply can’t build that app as a web app, certainly not by using iframes as a “solution.”