Comment by austincheney | Hacker News Reader

Comment by austincheney | Hacker News Reader

Parent Full thread

Take away React, Vue, Angular, or similar away from most current front end developers and there is panic. When I say panic I mean full insanity panic like abandoning the profession or completely going postal.

——

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.

This is a silly list. What? You really think document.getElementById is going to be faster than querySelector("#foo")? You really think there is a meaningful difference between other methods of adding event handlers, other than it being way hackier to add more than one with the other methods?

I have no idea what your objection to "this" is. Object Oriented code can be bad sometimes but so can procedural code.

This person has a weird unjustified objection to querySelector.

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 ...

I guess you ignored this from that thread: https://news.ycombinator.com/item?id=24057163

If jsPerf is down try http://jsbench.github.io/

What precisely do you think a microbenchmark taken out of context is going to prove?

That a 250,000x performance difference is a very large gap. It’s the difference between walking 1 foot or 48 miles.

Or the difference between walking 1 femtometer or a quarter of a nanometer in a day where you're planning to hike 10km. And that's assuming the relative difference holds to the same degree in a real app, which seems unlikely.

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.

I think a bit of context about `this` is important.

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);

Without ever showing you what a `fooBar` or `bazBang` are, and perhaps where and/or how an enterprising developer might obtain one.

https://github.com/prettydiff/share-file-systems

40k loc. I wrote an ESLint rule to error on this in both statements and expressions.

Your opening sentence is weirdly derogatory...

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.

> 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.

I know this won't count for much, but as an amatuer programmer who has done a lot of web scraping at my job due to having a restricted corporate environment, its a breath of fresh air to work with the few websites that actually assign IDs to elements, don't autogenerate all graphic elements and feel like whoever wrote them actually cared. Especially if you are trying to parse it with something stupid like Excel VBA. Trying to reverse engineer what happens when you click a button on a site with 20 event listeners tied to "submit" is a freakish nightmare.

What do you use instead of these constructs?

Instead of this I use explicitly named variables and functions.

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.

Other standard DOM methods like what? getElementById and getElementsByClassName?

Try this for a starter guide: https://prettydiff.com/2/guide/unrelated_dom.xhtml

For a practical example try this: https://github.com/prettydiff/semanticText

I also want to know this.

Try this for a starter guide: https://prettydiff.com/2/guide/unrelated_dom.xhtml

For a practical example try this: https://github.com/prettydiff/semanticText

Reply on news.ycombinator.com