shanebellone

If the problem seems vague, then the solution is not for you.

The concept of a "mom test" is condescending as well. Many moms code.

Yes, but multiplexing does minimize the problem. You could multiplex batched requests for hundreds of resources with my strategy.

They don't reduce request count. For example, Chrome only allows 6 concurrent connections (requests).

If you load 10 images in 1 request, you've reduced network latency and avoided the connection limit.

As a publisher. One who seeks to decrease load times on pages that require many resources.

I already have a working prototype that batches media requests. In my example case, I'm sending 1 request and receiving 6 images in return.

I'm familiar with css sprites too. That's still just 1 image per request though.

Say you wanted to populate a social media feed... you'd need to dynamically call media. That produces a huge amount of requests.

What if you want to batch 10 images per request? Does anyone currently do that?

"I haven't understood why apps are not what you ask, so I tried to remember some well-known technologies/approaches."

I'm talking about websites that function like apps but have the privacy/security benefits of being sandboxed inside the browser (accessed by URL or link).

It seems we may be talking about different things. I am not advocating for downloadable apps (I've never liked the app store paradigm nor the access it grants random developers). I'm advocating for more capable websites (which IMO "ought" to protect user data--not leverage it).

Why such archaic examples?

Imagine visiting this website, Hacker News, to read a few posts/discussions. Does the idea of circumventing a refresh offend you? You could click into a threaded discussion (from the homepage) and back without triggering a reload or needing the data beforehand.

Other than the indexability problem, it seems like an ideal solution. In many use cases, the indexability problem is actually a feature too.

Ah, but that's not that case here at all. It's not an app. It's still a sandboxed web page. The only difference is the communication method. Rather than a transactional client-server relationship, we adopt the media-steaming approach post-load.

That is to say: You would load your desired website (the standard way) and then experience a "refresh-less" session for the duration of your visit.

By snoop-phone, do you mean stalkerware? I have not heard this phrase before. Thanks in advance for the clarification.

Let me clarify with some context. I've been tinkering with an infinite grid concept that consumes a streamed JSON feed (plus a sufficient data buffer to hide any delay from the user) to create and then display content with the help of a JS factory. All related media is then streamed to the browser and lazy loaded when needed. With this setup, you can traverse a database without refreshing the page by redrawing the window.

The only potential drawback I see is whether or not search crawlers could index content that's introduced via JS after a page load.

Edit: It also appears to protect from scraping... so I suspect it would conflict with indexability. That's a pretty big downside if true.