4 ms·

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 aband

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.

pm 6y ago
What do you use instead of these constructs?
- austincheney 6y ago
  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.
  - robertakarobin 6y ago
    Other standard DOM methods like what? getElementById and getElementsByClassName?
    - Valord 6y ago
      I also want to know this.
      - austincheney 6y ago
        Try this for a starter guide: https://prettydiff.com/2/guide/unrelated_dom.xhtml https://prettydiff.com/2/guide/unrelated_dom.xhtml For a practical example try this: https://github.com/prettydiff/semanticText https://github.com/prettydiff/semanticText
    - austincheney 6y ago
      Try this for a starter guide: https://prettydiff.com/2/guide/unrelated_dom.xhtml https://prettydiff.com/2/guide/unrelated_dom.xhtml For a practical example try this: https://github.com/prettydiff/semanticText https://github.com/prettydiff/semanticText
- deleted 6y ago
  [deleted]
donw 6y ago
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.
- austincheney 6y ago
  https://github.com/prettydiff/share-file-systems https://github.com/prettydiff/share-file-systems 40k loc. I wrote an ESLint rule to error on this in both statements and expressions.
bawolff 6y ago
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.
- chubot 6y ago
  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 https://news.ycombinator.com/item?id=24054745 Performance is hard; optimizing the wrong thing is also a problem ...
  - austincheney 6y ago
    I guess you ignored this from that thread: https://news.ycombinator.com/item?id=24057163 https://news.ycombinator.com/item?id=24057163 If jsPerf is down try http://jsbench.github.io/ http://jsbench.github.io/
    - bawolff 6y ago
      What precisely do you think a microbenchmark taken out of context is going to prove?
      - austincheney 6y ago
        That a 250,000x performance difference is a very large gap. It’s the difference between walking 1 foot or 48 miles.
        bawolff 6y ago
        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.
chubot 6y ago
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.
- austincheney 6y ago
  > 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.
thekingofravens 6y ago
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.

pm 6y ago

What do you use instead of these constructs?

austincheney 6y ago
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.
- robertakarobin 6y ago
  Other standard DOM methods like what? getElementById and getElementsByClassName?
  - Valord 6y ago
    I also want to know this.
    - austincheney 6y ago
      Try this for a starter guide: https://prettydiff.com/2/guide/unrelated_dom.xhtml https://prettydiff.com/2/guide/unrelated_dom.xhtml For a practical example try this: https://github.com/prettydiff/semanticText https://github.com/prettydiff/semanticText
  - austincheney 6y ago
    Try this for a starter guide: https://prettydiff.com/2/guide/unrelated_dom.xhtml https://prettydiff.com/2/guide/unrelated_dom.xhtml For a practical example try this: https://github.com/prettydiff/semanticText https://github.com/prettydiff/semanticText
deleted 6y ago
[deleted]

donw 6y ago

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.

austincheney 6y ago
https://github.com/prettydiff/share-file-systems https://github.com/prettydiff/share-file-systems 40k loc. I wrote an ESLint rule to error on this in both statements and expressions.

bawolff 6y ago

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.

chubot 6y ago
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 https://news.ycombinator.com/item?id=24054745 Performance is hard; optimizing the wrong thing is also a problem ...
- austincheney 6y ago
  I guess you ignored this from that thread: https://news.ycombinator.com/item?id=24057163 https://news.ycombinator.com/item?id=24057163 If jsPerf is down try http://jsbench.github.io/ http://jsbench.github.io/
  - bawolff 6y ago
    What precisely do you think a microbenchmark taken out of context is going to prove?
    - austincheney 6y ago
      That a 250,000x performance difference is a very large gap. It’s the difference between walking 1 foot or 48 miles.
      - bawolff 6y ago
        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.

chubot 6y ago

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.

austincheney 6y ago
> 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.

thekingofravens 6y ago

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.