lamflam

I would also love to read this! kevinl at hey dot com

For the applications I have worked on, rendering is basically the only reason for unresponsiveness. Loading from the network happens asynchronously and doesn't block the JS thread so any other interactivity or loading state/animation should work just fine. If loading over the network makes the application seem unresponsive, that's generally just bad UX implementation.

I am currently working with low-latency audio and the latency requirements mean I have minimal buffering. While the VDOM render cycle is generally fast enough to be unnoticeable to the user, it stalls the audio buffering just enough to cause some stalling. There's a few heavier parts of the application where the rendering is expensive enough to briefly stall animations as well.

While both of these issues are something we need to fix, it is specifically the rendering/vdom process that we need to work around to address these performance concerns, and we are definitely not at all Facebook.

I've been using https://github.com/Malpaux/apollo-offline for offline support in production for a few months now and it has worked very well. I discovered one issue but the maintainer was very responsive and had my PR merged in and published within 24 hours.

I find this much simpler: ln -s $(which git) [some dir in your $PATH]/git-git