Thinking about user seeing pixels is seeing just a part of the picture. As all software projects you don't optimize just for immediate user experience but also development time. Time to first draw rarely coincides with development time.

▲

osigurdson 2 days ago | parent | next [-]

Dealing with over-fetch / under-fetch most certainly does chew up development time. Creating endless api endpoints that are only used by the web UI is also very time consuming (the industry is finally recognizing how dumb this is and moving back to older SSR approaches). How about, "the user is allowed to access this information on the server - system you figure out what / when to fetch portions of this information for viewing"?

▲

redwall_hp 2 days ago | parent | prev [-]

And I don't care about pixels; I want to see structured documents. How I choose to view those is my business.

▲

osigurdson 2 days ago | parent [-]

Got it, you don't care about how the sausage is made. That's totally fine.

▲

networked 2 days ago | parent [-]

It doesn't sound like this is what redwall_hp meant; it sounds like what they meant was that pixels are the wrong level of abstraction. If so, I agree: the web is about marked-up text. When you break it down to the very basics, what you get is a teletype, not raster.

	▲	osigurdson a day ago \| parent [-]
		I'd say that is more like a terminal than a browser. Regardless, what I really mean is some data is needed for the pixels (or whatever abstraction you want above that). You don't need data for anything other than the current viewport and whatever is likely needed next. No less, no more. No over or under fetching. This would be much better imo.