I have no idea what your objection to "this" is. Object Oriented code can be bad sometimes but so can procedural code.
I remembered this same conversation from 8 months ago where I pointed out that parsing something like '#foo' is NOT slow, he argued against it, 5 people pointed out the same thing, and he was not receptive to that feedback, etc.
https://news.ycombinator.com/item?id=24054745
Performance is hard; optimizing the wrong thing is also a problem ...
If jsPerf is down try http://jsbench.github.io/
P.s. i also didn't get that level of difference when i tried to run the microbenchmark but i didn't try very hard.
Using `this` in a callback -- where you expect your caller to provide your local binding -- is straight-up bad juju. Pass arguments instead.
Using `this` in an object instance to namespace is just fine. The entire point of having an object is that you get these nice encapsulated namespaces which can send messages to each other.
One suggestion, and a related ask: rather than just saying "Don't do FOO", provide alternatives as well; e.g., "Don't use `addEventListener`, use `superFooBarBazzer`".
Bonus points awarded for runnable examples. :)
Perhaps my biggest gripe about the entire Javascript ecosystem is finding libraries that provide documentation that looks like this:
// See how easy my library is to use!
myLibrary.doTheThing(fooBar, bazBang);
40k loc. I wrote an ESLint rule to error on this in both statements and expressions.
And I think these are all pretty far from the main performance issues with common apps FWIW. These are more low level coding issues, whereas the real slowness (e.g. 10x or 100x issues) comes from architecture, dependencies, network usage, data structures, reflows, etc.
That is tech debt and complexity. If you start from a simplicity first perspective most of what you list evaporates as a matter of habit.
Instead of addEventListener I assign event handlers directly to the event property of the DOM: button.onclick = whatever. This forces simplicity and cleaner code management because only one function can be assigned to any given property.
Instead of querySelectors I use other standard DOM methods.
For a practical example try this: https://github.com/prettydiff/semanticText
For a practical example try this: https://github.com/prettydiff/semanticText
——
A simple checklist to provide superior front end applications:
* Don’t use this. You (general hypothetical you) probably don’t realize how easily you can live without it only because you have never tried. Doing so will dramatically shrink and untangle your spaghetti code.
* Don’t use addEventListener for assigning events. That method was added around the time of ES5 to minimize disruption so that marketers could add a bunch of advertising, spyware, and metric nonsense everywhere more easily without asking permission from developers. That method complicated code management, is potentially point of memory leaks, and performs more slowly.
* Don’t use querySelectors. They are a crutch popularized by the sizzle utility of jQuery. These are super epic slow and limit the creative expression of your developers because there is so much they can’t do compared to other means of accessing the DOM.
I now add ESLint rules to my code to automate enforcement of that tiny checklist.