An excellent Front-End developer will do pixel-perfect, millisecond-sensitive testing, while a sloppy Front-End developer will do careless quick-and-dirty testing and thus miss crucial bugs and their causes.

There were times where I caught at least four bugs on a single component by performing these detailed tests, resulting in my catching these bugs. I don't think it's a good webdev trait to not care about 'a couple of frames', as these can mean the difference between a good user experience and a bad one. Missing certain pixels will have you think the component is badly written, while it's you yourself who didn't account for basic edge testing.

As far as I know, Front-End developers are and should be precision-driven people - the same goes for any Computer Scientist. We all know that the pressures from outside cause people to be sloppy.

Front end should never be about pixel perfect unless you're testing every plausible different resolution.

I'm not a pussy. I test by deploying to prod.

If somebody starts whining, it means there's a problem.

I'm kidding but honestly I don't see the need in pixel perfection except in some situations like video.

Data-driven dashboards? Nobody cares about minor layout stuff.

@antigermanist In this case the pixel perfection was needed because the React component inherited a custom framework that had a handler that didn't cover the entire click area, so you had to be very precise in your clicking. If you clicked a few pixels next to the area, the component didn't seem to respond.

The other case was where the React components were jumping around in x/y/w/h due to async rendering and varying text content, and this would be detrimental to the user experience. Our customer said they would quickly move onto another provider if we didn't fix the problem. One mitigation was to use skeleton loaders as usual, and another industry-standard solution is to use the component lifecycle methods to do the pre-rendering checks. Something else I can think of is provide fixed-width and height containers and not let UI drawing depend on the data.

@CaptainRant yeah i'm not doing low level UI stuff either, I rely on a lib for that

@CaptainRant but i sortof do tooling for contractors / people we pay, not that much for clients themself, so that changes. We are the clients to them