Is it bad practice to leave hidden elements in the dom?

Question

I'm looking for perspectives from other web/ui developers.

I'm a UI developer and my company requires that I use components built by another team within the company.

That team has developed some patterns over time that I would consider bad practice, but I thought I'd see what others think before I raise any awareness to the other team.

So, for example, this other team has created a drawer that slides into view when a button is pressed, and goes back out of view when it is closed. The problem I have with this is that the entire component is in the dom, but only set to hidden. So I can't see it visibly, but it is still there, all the time.
Another component they have built is a datepicker, which when you click on the input field, it opens up the calendar with the current month displayed. When you select a day or press the close button in goes out of view. This issue with this is that when it is closed, it again is only hidden. So if you look in the dom, you'll see the elements for the calendar container, the title bar with the day names, all of the days in that month, and nested inside of each day is the span.

These are only 2 examples of components they have made, but they follow this practice of only hiding elements with almost all of their components.
My worry with this is that when an entire page is finished, the dom is full of unnecessary elements and could potentially bog down the performance of the app. I currently write in React and try my hardest not to render anything unless it needs to be seen. But with the other team's components it is usually not possible.

Would anyone else consider this bad practice? Or have any suggestion that I could bring to attention?

Ps. There is no code because I'd be violating my security agreement

Answer 1

You seem to be primarily concerned with the performance difference between hiding a DOM component and removing it. The usual advice about performance applies: don't worry about performance unless you know that there is a problem, you have a clear target of acceptability, and you have profiled your app to find the biggest problems.

My guess would be that if you are going to be regularly adding/removing the parts of the UI, then showing and hiding would be faster than reconstructing them. But that only matters if there is a business case for speeding up those interactions. If you have a business case for speeding up initial load time, it may be worth it to wait to construct those elements until they are needed. But it may be even more worth it to avoid React and use native JS.

Until you have requirements (which must come from a business need), a repeatable test you can run (to show that your changes actually improved performance), and a target (so you know if your changes were sufficient), then you are just speculating.

A little more advice that fits more into The Workplace than Software Engineering, but I would strongly recommend against going to someone's superior to complain about their work. At a minimum, try bringing up your concerns with the other team and listen to what they have to say.

Answer 2

Performance is a tricky thing, that need to be weighed against many factors. Transmission time (server to client) and execution time (server side and client side).

Usually modals are small and store in .js files so they get sent once and saved on the client machine in this case don't worry about it.

Only raise concerns with efficiency of code that runs on the server side as its effect get multiply by the number of requests.

You will notice client side inefficiency when testing but if predeployment stress testing is inadequate or missing, which I offen see in start up, your site will crawl to an halt as traffic increases.