1

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

migrated from stackoverflow.com Feb 13 at 18:31

This question came from our site for professional and enthusiast programmers.

  • 5
    It's a practice that is fairly common - showing and hiding modal components is a lot more performant than destroying and rebuilding them. (Although the question could be raised if they are big or complex enough to be spun off into pages in their own right.) – Abion47 Feb 13 at 18:07
  • 1
    In particular, this is how most of the jQuery UI widgets work. – Barmar Feb 13 at 18:08
  • 2
    No. And honestly, I have zero concern for (and zero knowledge of) how littered my DOM gets unless it's causing measurable problems. I am Infinity times more concerned with delivering features and keeping my code maintainable. – svidgen Feb 14 at 1:21
  • 1
    I have never heard of hiding widget elements being bad practice. If there is some documentation that makes the case for this being bad practice I would be interested in reading it. I just checked several popular websites and the widgets stay in the DOM albeit hidden. Is the problem that they are not contained in an element tag that can be collapsed so the rest of the DOM is readable? – Jeff Zacher Feb 14 at 2:28
  • 1
    @JeffZacher Not necessarily. Some members on my team see it as bad practice to leave things behind after they've been used. And I'm a relatively new developer as far as professional career goes. It seemed logical to me at first but after reading some of the comments here, I'm thinking that elements in the dom aren't really a concern. – Nate Thompson Feb 14 at 3:32
6

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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.