> Future you that has to decipher the code. Why make it hard on yourself? Software is a living thing eventually a decision will need to be made about it and without understanding what it does it's easier to make suboptimal assumptions.

To the defense of the title, in my experience, whenever label "hacker" was used on programmer or code, it meant "difficult to read, full of hard to maintain shortcuts and tricks" kind of code. Really always, I don't ever remember it to be used in any other sense.

True this

Eh, it's only 150 lines of simple functions without external dependencies. It's simple enough to understand and modify on the spot. As long as these are not expected to grow significantly in the future, I don't see why it'd be making it hard on yourself (and if it does grow, then it can always be refactored).

This 100x times. There is very little code there. Any effort in trying to bring it up to modern webdev standards would likely make the code expand significantly, and that's not even counting the complexity of the deployment pipeline. This here, it's just 150 lines of plain code. It's not hard to work with something like this.

I'm not saying a rewrite is necessary at all, but refactoring this code to use more modern standards would NOT increase the line count at all, my guess it it might cut it by 15%+ in total size if you leveraged the beautiful builtin functions. Compare these:

    function addClass (el, cl) { if (el) { var a = el.className.split(' '); if (!afind(cl, a)) { a.unshift(cl); el.className = a.join(' ')}} }

Could turn into something like this:

  const addClass = (el, cl) => el.classList.add(cl)

Not only is is shorter, but it's more readable too!

> Not only is is shorter, but it's more readable too!

And won't work on IE. Not just because of el.classList, but also because of the arrow notation. So by doing this change, you either have to ditch one of still used browsers, or introduce a stupidly complex transpilation chain into the mix.

I'm aware, but I'm responding to the myth of:

> Any effort in trying to bring it up to modern webdev standards would likely make the code expand significantly

That's just not true, and nowhere did that person say: "Because of legacy IE support requirements", they only mentioned "modern webdev standards".

Are you suggesting arrow functions, and classList aren't modern standards then?

I was that person, and what I meant was that "modern webdev standards" would include modules and features requiring transpilation, which would introduce many dependencies, all of which count into code size (you have to keep track of them mentally).

Why/where would modules be necessary here? Just because there's a feature now that didn't exist years ago doesn't mean it's the right time & place to use it. The code works as-is, a small refactor to leverage built-in functions to do some of the trickier logic parts would make this code a breeze. There's no need for something like Babel to help out with a small refactor.

el.classList isn't supported by IE < 10

And is it accurate to describe IE < 10 as "more modern"?

It isn't, and I don't think I have.

My point was that using a "more modern standard" would break hn for people using legacy browsers.

The code is entirely self-contained. That's what makes it easier for future-you to understand and decipher. Dependencies won't have gone out of date, library versions won't have moved on, APIs won't have disappeared, etc.