3 ms·

Lots of talk why you don’t really need to have compound documents anymore, but no real arguments why compound documents are bad. If your server and client archi

Lots of talk why you don’t really need to have compound documents anymore, but no real arguments why compound documents are bad. If your server and client architectures are somewhat sane adding a compound on-load resource is cheap and I don’t see many downsides. Maybe even pack them into your initial HTML.

psturgeon 5y ago
There's loads of problems and I've been talking about them all through a series of blog posts and talks, I just didn't cover it here. The main problem is that tertiary data slows down primary data. Put simply, when you request 3 things, it might take a little while for the server to find process the response, create all the JSON, shove it all over the wire, and be picked up by your client application. The user has been sat there waiting for all three things to come back at once. Real world example: a social network full of posts and images is failing to load because the application wanted to know if there was any space left in a meeting room nearby. If you have 3 different things they probably have different cacheability, so let them declare their own cacheability and let the client only bother fetching them if they need to. Show the things you have when you get them. Progressively enhance the page. Don't just show nothing. There's a lot of solutions to various problems with compound document systems like JSON:API and I've written about those too: https://apisyouwonthate.com/blog/making-the-most-of-jsonapi https://apisyouwonthate.com/blog/making-the-most-of-jsonapi But the core purpose of compound documents was the same thinking as CSS combination and Image Sprites, most of which have gone away now, and I think compound documents should too. They were a handy hack that had downsides and its no longer necessary to mess with them.

3 ms·

Lots of talk why you don’t really need to have compound documents anymore, but no real arguments why compound documents are bad. If your server and client archi

by sfvisser 5y ago

psturgeon 5y ago
There's loads of problems and I've been talking about them all through a series of blog posts and talks, I just didn't cover it here. The main problem is that tertiary data slows down primary data. Put simply, when you request 3 things, it might take a little while for the server to find process the response, create all the JSON, shove it all over the wire, and be picked up by your client application. The user has been sat there waiting for all three things to come back at once. Real world example: a social network full of posts and images is failing to load because the application wanted to know if there was any space left in a meeting room nearby. If you have 3 different things they probably have different cacheability, so let them declare their own cacheability and let the client only bother fetching them if they need to. Show the things you have when you get them. Progressively enhance the page. Don't just show nothing. There's a lot of solutions to various problems with compound document systems like JSON:API and I've written about those too: https://apisyouwonthate.com/blog/making-the-most-of-jsonapi https://apisyouwonthate.com/blog/making-the-most-of-jsonapi But the core purpose of compound documents was the same thinking as CSS combination and Image Sprites, most of which have gone away now, and I think compound documents should too. They were a handy hack that had downsides and its no longer necessary to mess with them.