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.

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.

Does that limit still apply with HTTP 2 and HTTP 3?

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

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?

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

I am a big fan of RMS and I find promising to promote his way of naming things everywhere. Here are two recent links which explain this word choice.

[1] https://www.stallman.org/archives/2023-jul-oct.html#26_Septe...

[2] https://www.stallman.org/archives/2023-jul-oct.html#11_Septe...

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.

Do you propose thin or thick client? How about Java applets or MS Silverlight?

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.

> Why such archaic examples?

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

> Does the idea of circumventing a refresh offend you?

Yes because I prefer to request things from online when I want but not when my device wants.

"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).

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

What privacy benefits are not being realized by the current approach? If I want privacy, I can just disable JS for not letting some website know too much about my device. But in general, privacy is a joke since Edward Snowden's revelations.

> I'm advocating for more capable websites (which IMO "ought" to protect user data--not leverage it).

What opportunities are not being realized with the current approach? Who will be responsible for protecting user data, given that every website/resource/service strives to sell Alphabet/Meta as much data about you as possible.

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.

That sounds like AJAX, no?

It does sound like it, but no it's just plain JS. I recorded a short clip; showing is better than attempting to explain.

Edit: It is almost AJAX. The more I think about it the more the boundaries get blurry. Essentially, it's AJAX that does not fetch or receive resources directly. It interacts with a buffer that holds JSON which describes the next batch of cards. The images are streamed via <img> tag, so the buffer is small relative to the media it represents.

https://www.youtube.com/watch?v=6eSDuAe3pHA

"We arent meant to know exactly what it will output because that’s what it was programmed to do."

Incorrect, we can't predict its output because we cannot look inside. That's a limitation, not a feature.

Regulation is the only tool for minimizing crime. Other mechanisms, such as police, respond to crime after-the-fact.

Aren't regulations just laws that are enforced after they're broken like other after-the-fact crimes?

Partially, I suppose.

The risk vs. reward component also needs to be managed in order to deter criminal behavior. This starts with regulation.

For the record, I believe regulation of AI/ML is ridiculous. This is nothing more than a power grab.

Humanity isn't stateless.

"Neither is text generation as you continue generating text."

LLM is stateless.

On a very fundamental level the LLM is a function from context to the next token but when you generate text there is a state as the context gets updated with what has been generated so far.

"On a very fundamental level the LLM is a function from context to the next token but when you generate text there is a state as the context gets updated with what has been generated so far."

Its output is predicated upon its training data, not user defined prompts.

If you have some data and continuously update it with a function, we usually call that data state. That's what happens when you keep adding tokens to the output. The "story so far" is the state of an LLM-based AI.

'If you have some data and continuously update it with a function, we usually call that data state. That's what happens when you keep adding tokens to the output. The "story so far" is the state of an LLM-based AI.'

You're conflating UX and LLM.

You're being pedantic. While the core token generation function is stateless, that function is not, by a long shot, the only component of an LLM AI. Every LLM system being widely used today is stateful. And it's not only 'UX'. State is fundamental to how these models produce coherent output.

"State is fundamental to how these models produce coherent output."

Incorrect.

I never said LLMs are stateful.

> Its output is predicated upon its training data, not user defined prompts.

Prompts very obviously have influence on the output.

"Prompts very obviously have influence on the output."

The LLM is also discrete.

the model is not effected by its inputs over time

its essentially a function that is called recursively on its result, no need to represent state

Being called recursively on a result is state.

if you say so, but the model itself is not updated by user input, it is the same function every time, hence, stateless.