Recent submissions

Comment · 5 years ago
I would also love to read this! kevinl at hey dot com
Comment · 5 years ago
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.

Comment · 9 years ago
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.
Comment · 9 years ago
I find this much simpler: ln -s $(which git) [some dir in your $PATH]/git-git

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton