Note that there are some explanatory texts on larger screens.

plurals
  1. POPerformance and memory of prototype pollution vs dedicated library object
    primarykey
    data
    text
    <p>Not sure if this is a new question so pls ref to any good source if you have any.</p> <p>My team is working on a big JS chart project we inherited from the previous developers who made intensive use of built-in objects prototypes for adding reusable code. We have a lot of new utility functions added to Date, Object and other intrinsic objects so I guess they went this way 'cause altering prototypes provides a bit more intuitive API.</p> <p>On the other hand our component suffers from performance/memory gotchas and we apply all the possible optimizations and best practices. I can't find one regarding API design. I'm trying to figure out whether it's better to seed <strong>built-in objects' prototypes</strong> with library code instead of combining them in dedicated objects via somewhat namespace pattern.</p> <p>The question is which design is better? And will one of them gain performance and/or memory over another?</p> <pre><code>Date.prototype.my_custom_function = new function (...) {...}; var period = new Date(); period.my_custom_function(); </code></pre> <p>vs</p> <pre><code>DateLib.my_custom_function // defined in a DateLib function var period = new Date(); DateLib.my_custom_function(period); </code></pre> <p>Thanks, guys, any help is appreciated!</p> <p><strong>EDIt</strong>: The main problem is that our component ended up being an awkward JS beast that slows down some mobile devices, especially old ones, such as iPad1 and early Androids... We've done a lot of optimization but I still see several questionable parts. I want to make sure if the built-in prototype pollution is another candidate to look into. Particularly, the <code>Date</code> and <code>Object</code> guys are heavily loaded with typical library code. For example, in fact the <code>my_custom_function</code> is a big big function and it's not the only additional member that sits on the <code>Date</code> prototype at code startup. The <code>Object</code> is loaded even more. Most of the client code doesn't make use of those additional features, it's used on purpose - so we're about to decide whichever way we're better stick with:</p> <ul> <li>Keep using prototype pollution design</li> <li>Refactoring reusable APIs into separate library static objects</li> </ul> <p>to be honest I haven't run perf benchmarks yet, will do once I have time. If someone has outcome/ideas will be very helpful.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload