Noted 
You’re right. Basically I’ve broken things up into a few requests pretty aggressively and I don’t show a spinner while we wait for all the info. The blank header is my default while we wait for the request. As for the wish list buttton, yeah, need a better default while we wait.
More tech details on my requests
Right now, when you hit a book page there are 4 requests:
- fetch initial app data (no-user info)
- fetch initial app user data
- fetch book page specific data (no-user info)
- fetch book page specific user data
The idea with breaking it up like this is so that the server can cache the non-user specific data and render that immediately for you and search engines.
I could show a spinner until I have all the info, but that’s a little sad… So I’m going to try and have reasonable defaults for the user specific regions, but it’s still a work in progress.
The header you noticed blinking requires the app user data. I don’t show the header until I have received that response. The button also requires the app user data… but I haven’t put in a good default yet, that’s a good call out.
Other things like the your full user review / stats require the book page user data, and I simply don’t show them until that comes in.
When I get more sophisticated at this, I will have ‘skeletons’ show… which are blank placeholders similar to the content about to be revealed, but obviously show they’re loading. Won’t do those until we’re fully migrated though.
Sorry about that! Yeah, showing your personal user review was broken until today… but showing other peoples reviews was not. So, you got that scary bug where it looks like it disappeared after the code figured out that it was your review and not someone elses 
Yeah, this was bucketed in with the ‘non infrastructure bugs’ as it’s a little more complicated. Good to know that it’s browser specific and makes sense Firefox bugs out. Firefox seems to not like having raw html in that markdown widget I have… presumably for security concerns.
