Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am trying to understand best practices around accessing and working with DOM objects. I have a script where I get the sibling cells of a table td by calling td.parentElement.cells each time the cell is clicked. Is this considered best practice or do I need to create and initialize an array of the cells of each table row, and search for the corresponding cells of a td that way?
Thanks.
Generally traversing a DOM is an old-fashioned and painful way to program. It works for doing a single modification, but the more your program modifies the DOM, the harder it is for you to mentally model what is, or could be, going on.
It is for that reason that front-end frameworks exist.
You can jump a few tens of centimetres into the air. If you practice very hard, even metres.
But that is not really making a contribution to building an aeroplane to fly long distances: the appearance of progress is illusory.
Have a look here to see how easy it can be when you don't have to traverse a DOM. https://v2.vuejs.org/v2/guide/#Declarative-Rendering
Trade-off
In answer to your question, yes they do add overhead. If minimising to the kilobyte level is crucial for you, then yes you should access the DOM directly, as this will take the smallest amount of code, so it is good practice when working under that constraint.
However, there are few circumstances when reducing code by 20-50k is crucial. Ask yourself, given how your web page will possibly develop over the years, how much time you are willing to spend updating code that traverses the DOM to make edits. Is that extra programmer time (which will not be noticed or appreciated by the end-user) worth it, given the alternative to learn something that extends your capabilities and do more?
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm working on an Ember app and it shows a lot of real time data, it makes the JS thread really busy.
I'd like to add some nice fluid animation with CSS3 but having JS which works under the hood makes the entire app laggy.
Is there a way to give priority to the CSS animations to make them fluid?
After all I don't care if for half second my data is not updated.
I mostly target Chrome and Firefox
You might want to look into webworkers.
If you let all your ajax and dataprocessing be done by the webworker thread, and the displaying only by the DOM thread you can save a lot of overhead/delays caused by computations.
One word of advice. Don't do worker.postMessage(arg,arg) but do worker.postMessage(arg) with a single argument.
The object itself will be posted then instead of it being converted to json and converted back in the other thread. Saves a lot of cpu time.
Keep in mind that the thread that posted the object will have "lost" the object(to prevent concurrency problems)
Also DOM elements cannot be posted to a webworker, so make sure your data is "clean" if you post to the worker.
Maybe trying to get the CSS animations to be rendered by the GPU would be an possibility.
CPU and GPU would run seperate, You should give it a try and see if it gives you an improvement!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
So I'm not totally new to web development or anything...reasonably experienced with it actually, to an extent.
But I had only ever used window and document in the past, amongst what I have now learned are many DOM API interfaces.
This is unnerving to me. In my quest to become a truly capable web developer, the extent of the DOM API has so far been the scariest thing I have encountered. It seems very difficult to me to get a real, strong grasp on it.
So I'm wondering, to developers more experienced with this, how did you learn it? Are there any excellent resources in particular, or an order you went in? Which parts of it are important? Which parts could easily be ignored completely?
I mean, even just in document, there are many methods I am totally unfamiliar with.
The following diagram provides an overview of the DOM core interfaces with the most basic attributes and operations. As suggested by Bergi, the most important interfaces are Node, Document and Element. However, when you have to access/manipulate a specific HTML element (e.g. table) you should also look up the interface of such a specific element (e.g.HTMLTableElement) for the availability of useful attributes and operations (e.g. insertRow).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm sure there are many questions and articles on the subject, I just cant seem to find exactly what I'm looking for...
I have a form where one of the fields excepts a number (1 to 30), I the want to create x elements, where x is the number selected, all elements should have about the same HTML structure, differing only in their id's. the elements are complex, and I think I should format them using HTML/CSS, as I feel that js should only hold the business logic, sort of MVC style.
I suppose my question is two fold:
Is a "philosophical" question: Is it a good idea to try and keep the "view" (format/layout/design) in the HTML/CSS and the "control" (logic) in js? I'm new to web dev, and I'm not sure of web dev architecture philosophy...
Considering I want to keep formatting out of my js, how do I go about dynamically adding/duplicating HTML elements, whilst keeping the HTML in the same file where it belongs. My first thought was to create as many elements as I might need, hidden, and and show the right number of them when needed, but this can't be the best way to do this... My second thought was to use the jquery.clone() function, but this would create duplicate id's.
thanks.
I think you would really benefit from using a client side compositing framework (like KnockoutJs, but there are loads of others like Ember, Angular).
That way you can keep your model (viewmodel in the case of Knockout) in JavaScript and only worry about the implentation of the view in your templated HTML.
Check out the cool knockout tutorials, maybe its what you're looking for
http://learn.knockoutjs.com/
var inputCount = paraeInt$('input').val()),
elementMarkup = $('<div class="dynamic- div"/>');
for(var i; i < inputCount; i++){
$('body').append(elementMarkup);
}
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm adding many class names (6 or 7) to the HTML elements for the requirement of my client javascripts. Some of them are real class names, but some of them are just indicators. Does this impact my page performance?
Well, technically more html means slower. But not that much, not noticable. Each character you write is a byte more to download, so it takes a while before you notice some differences.
The main problem that could occur is your css growing because you denormalize, that will have a much bigger impact.
If you need better performance, optimise images, or stylesheets, or some javascript codes
Short answer: No, this is does not change anything significant.
This is a legitimate question because there can be very valid CSS and HTML that have best nesting and separation in the CSS that result in multiple CSS classes per element, and as you say, if you have marker classes for JavaScript lookups that adds to the volume. I cannot find any good performance analysis, but it shouldn't be hard to test.
This Multiple classes in markup - will it slow down performance? basically says more classes = slower, but I don't know if that's true if each class has smaller content due to neater nesting in the hierarchy and better separation.
This http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/ is somewhat related and shows that complex CSS of well known sites is rendered efficiently.
My answer is that from personal experience I have not noticed performance issues with this design pattern so if your structure is best served by multiple CSS classes and marker classes then that is the most important aspect and performance should not suffer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I come from a computer science background and the languages I'm most familiar with are Java, C# and C++. In these languages your memory footprint is always in the back of your mind and I've been taught to destroy objects that are not in use.
I've recently got an internship as a web dev. I'm getting up to speed with various practices and doing a bit of web design which I haven't done in a while, at least not properly. In one of my sites I have a few images that appear on the screen, then move out of the viewport never to be seen again.
Would it be beneficial to .hide() the elements in question? Would it reduce the memory footprint enough to make it worth it? Would it reduce the footprint at all? A co-worker said it wouldn't be worth it as the hit is taken on page load but he wasn't totally sure.
As mentioned in the comments, hiding the element still leaves it in the DOM (Document Object Model). Personally, If I had something moving off screen and then not needed I would use the jQuery .remove() method to physically remove it from the DOM. It may make a difference to performance depending on the size of the image and the amount of images that this is happening to.
Like I've said, I like my DOM to be clean and tidy without any unnecessary clutter, so I would remove them, but that's just me.
EDIT: Looking into it a bit more, it appears that removing the element from the DOM does not free the memory associated with it (source). It seems that it is dependant on the DOM implementation when the memory is freed (source). Physically reusing the nodes looks like the most efficient way to go.
#Pointy gave the correct answer (as a comment). No - it does very little to hide it because it's still in memory because the element (and all of it's children) are still in the DOM. It MAY make painting a little faster in scrollable/transformable areas (but it may not) but it certainly doesn't decrease the memory consumption of your app simply by hiding it.