When your problem is perpendicular to your project

At work one of our new devs has been working on a problem we originally assigned a day or two worth of points to resolve. The issue itself is not that interesting, we run on top of a commonly used web framework with a shadow DOM and need an event to trigger when the page is done loading. But as the page fills in dynamically and data is pulled asynchronously all solutions for this problem are hit or miss if they work and none work 100% of the time. It is a common issue, one of those where no one has a good Stack Exchange solution in spite of the fact there are many duplicate questions posted.

What I found interesting about this problem is why it exists and why no one has a good solution. Our specific problem is that the framework doesn't really have the concept of a page load being "complete." Components are connected with properties, async calls for data will modify these properties and the page is always in a state of agitation. We can't use timers because of the drastic difference in time to load from a desktop on a 1Gbps connection compared to a super slow 3G cell connection. We can't use event handlers in the page because when component life cycle claim it exist the page may still be changing and the event fires too soon.

But the truly interesting part was when I had to explain it to a non-technical audience. The problem we are trying to solve is perpendicular to the project we are working on. It's as if we are squashing a bug in the 4th dimension when all the code we write exists in only 3. We can see its effects but actually manipulating it just isn't possible. While you and I as humans can look at a page and say it looks to be done loading, from a programmatic stand point the amount of work required to make that assumption is just ridiculously excessive. Every bit of dynamic information needs to be known, evaluated and a determination needs to be made, something our eyes and brains can do in an instant.

I feel bad for the dev that had to work on the problem. The more and more we tried to come up with solutions the more problems we ended up creating. The more we Googled and read through Github bug tickets the more we came to realize this is a problem many, many devs have but no solution quite works. In the end we came up with a solution that works about 80% of the time. It may fail, but the amount of effort put in currently can't justify the return on investment of the feature. It feels weird to mark a ticket Do Not Fix due to conceptual issues with your design. Devs cringe when anyone says "you can do it, it's just software" but often times we think that is true. Sometimes, however, it's not.

$ published: 2023-01-19 16:27 $

-- CC-BY-4.0 jecxjo 2023-01-19

back