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.
Related
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?
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I want to use static in my react-native project. I am not sure about memory uses
so it will take extra memory or any memory leakage will happen in my project.
Not exactly a memory issue but as with all code elements, more lines of code (especially heavy ones) will lead to slightly more RAM usage. This isn't an issue, especially if you're using something like expo or p5.js where the online editor uses resources from the server and not your home computer. More RAM is good to have, especially with multitasking, but it's not exactly a necessity. If you have 8-12GB RAM or more, you should be fine with coding projects like these even when hosting from a laptop.
There's probably little to no memory leak risk, but that's the same with everything right, every project has that risk but it mostly works out fine. You should be good and if not, just try optimising your code. One method that I always use is splitting complex statements into simpler ones which work the same. It increases the lines of code but makes it easier to debug. Then I revert it back to the original having found the bug and fix it.
Good luck!
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 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 8 years ago.
Improve this question
I really hate css. I try to do simple things and it gets really complicated really fast.
On the other hand, ive used canvas to code games which have a lot of functionality and menus..
So I was wondering if there is anything wrong with using a canvas element all over the webpage? Or even one giant canvas?
This article makes it seem like canvas is much better, but harder to use(which i think is the other way around) http://www.kirupa.com/html5/dom_vs_canvas.htm
Yet all the tutorials use css extensively. So is it bad practice? if so, why?
Using pixel drawing for web pages is a very bad idea, because own browser's viewport is almost the same but at the operating system level.
HTML and CSS are just simplifications of composing UIs without the hassle of forcing developers to draw what they want to show on screen by code.
I'm going to give you the best advice that you can find out there: learn CSS if this is the issue, because re-inventing wheels because of not reading the manual and a lack mind openness is just the worst decision we can ever made in software development.
Maybe taking a look at these pseudo-languages which compile into regular CSS might change your mind about HTML+CSS:
LESS CSS.
SASS / Compass
As others have said in comments...
...manual drawing means:
No SEO.
No search indexing (i.e. index your content in Google)
No user text selection
No way to save images (jpg, png...) using the "Save as..." dialog as regular HTML documents.
No viewport scaling depending on user's device.
...and dozens of cons.
OP said...
would this be acceptable in a professional environment? Say if I used
it in a portfolio to apply for a job.
No, because professional Web developers develop on top of Web standards: they're not creating alternate approaches to draw documents which aren't understandable by the mainstream development community!
If some tech recruiter with actual development knowledge discovers your way of developing the Web, he/she would say "impressive, but this candidate won't fit well in our development team".
In addition to the already excellent answer by MatÃas Fidemraizer I would like to add that it would be an interaction nightmare. You would have to manually track the position of all elements, get the position of all interaction events, coordinate them, and having an event loop running. You would, in effect, be replicating a good chunk of the browser in javascript.
Learning css is difficult for any number of reasons. If someone wrote a 'CSS: The Good Parts' it would arguably be even thinner than the Crockford book. There was recently a really great talk at CSSConf.Asia about this. Its css for back-end devs. It might give you insight into a more manageable subset of css.
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.