HackerTrans
TopNewTrendsCommentsPastAskShowJobs

lamflam

no profile record

Submissions

Xsv: A fast CSV command line toolkit written in Rust

github.com
4 points·by lamflam·5 tahun yang lalu·0 comments

Questions to Ask Before Adopting Usage Based Pricing

adilaijaz.medium.com
93 points·by lamflam·5 tahun yang lalu·38 comments

comments

lamflam
·5 tahun yang lalu·discuss
I would also love to read this! kevinl at hey dot com
lamflam
·5 tahun yang lalu·discuss
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.