3 ms·
Seems useful to me in the context of something like a progressively rendered UI. A large block of text appearing a few characters at a time would be fine, but a
by xp84 1y ago
Seems useful to me in the context of something like a progressively rendered UI. A large block of text appearing a few characters at a time would be fine, but a number that represents something like a display metric (say, a position, or font-size) going from 0 to 0.5 or from 1 to 1000, would result in goofy gyrations on-screen that don't make any sense. Or imagine if it was just fields in the app's data.
Name: John Smith. Birth Year: A.D. 1 [Customer is a Senior: 2,024 years old]
Name: John Smith. Birth year: A.D. 19 [Customer is a Senior: 2,006 years old]
Name: John Smith. Birth year: A.D. 199 [Customer is a Senior: 1,826 years old]
Name: John Smith. Birth year: 1997
- tags2k 1y agoIf you're updating the UI every time you receive a single character from this library, you've got bigger problems than font size.
- sysguest 1y agohmm this makes sense for LLM usage (but for other uses - nope)
- spankalee 1y agoIf your UI layer can't efficiently update when you get new characters, you've got bigger problems than JSON parsing. Seriously, you should be able to update the UI with a new character, and much more, at 60fps easily.
- xp84 1y agoIsn't that one of the main points of React and its ilk? The state is just a big JSON object, and sometimes you might be fetching a bunch of data that makes up that state, and streaming it in. If latency is high and volume of data is high, seems perfectly reasonable to get the UI rendering as the state comes in instead of waiting for the last byte to do anything. For instance, imagine you don't fully control the backend to split up a large response into several smaller API calls, but you could render the top part of the UI, which may be the most useful part, from the first couple of keys in the JSON, while a large "transaction history" after that is still downloading.