Really? Plenty of needlessly abbreviated function names IMO. At a quick glance is it immediately obvious what posf or arem are without looking into the context in which they're being used? Don't get me wrong it's a nice piece of code but super-readable it isn't.

Well, I disagree. It is abbreviated, but since the whole file is self-contained and the definitions are put at the beginning, there is enough information to infer the function's semantics without being excessively specific. I think well defined organization of abstractions is an often overlooked but surprisingly effective way to achieve readability

> there is enough information to infer the function's semantics without being excessively specific

You mean you can just read the function definition to see what it does?

He doesn't like being excessively specific with his writing I guess. Plus it makes you sound more like an engineer when you speak like this.

It's also a piece of code that hasn't been rewritten to fit whatever buzz is the buzz today. I wish more of the world was written with code that need not be rewritten every five years.

I think the main reason this is somewhat readable is because there's hardly any code. Which is fine.

The supreme art of war is to subdue the enemy without fighting.

-sun tzu

It seems some of the one-liners are simply renaming JavaScript built-ins like forEach to aeach and slice to acut. Maybe this is to make it look more like the Lisp backend? But taken on its own it does not really improve readability.

No, it is because some array-like objects like node lists actually aren't Arrays and don't have those functions in their prototype.

this is why I usually go for something like const $ = (el) => [...document.querySelectorAll(el)]

Although NodeList has forEach defined on it now at least.

Really? It has horrendous naming and it isn't even using es6

function byClass (el, cl) { return el ? el.getElementsByClassName(cl) : [] }

const byClass = (el, cl) => el ? el.getElementsByClassName(cl) : []

Your code is not more readable, it is just shorter.

In fact, using the online babel transpiler, it transpiles the es6 version you provided precisely into hn's version:

https://bit.ly/2MPmjK7

To use es6 to achieve what this tiny piece of javascript could already do, you probably need to introduce some tremendous dependency like babel just to be compatible with all kinds of weird browsers out there. What does es6 give here? Not very much in my opinion.

It's 2018. Unless you're using Internet Explorer arrow functions are supported natively.

And I bet there are some people here using IE. And old browsers.

I would REALLY love to see the browser usage statistics for HN :)

Well.. I might be an outlier, I use OmniWeb and Camino as they give the best results with my 2005 Mac. So I'm still living in the Pre-=> Age.

You're still returning a live HTMLCollection or an Array.

It's still bad code. Using newer syntax to do the same thing didn't actually improve anything.

How does es6 improve readability in this case? It barely removes `{}` and replaces very clear word `function` with `const` that in most languages is associated with constant values, not with functions

It removes the brackets and the return keyword, const is in fact a constant but this not ES6 it is just doing a function expression instead a function declaration (you create a const variable and assign an anonymous function to it instead of using the keyword 'function')

This is used for readability and to avoid hoisting that can be confusing.

Given that brackets and the return keyword (and the function keyword!) are core parts of functions (a scope and a value to return to the caller), I would argue that removing these key parts of a function makes it harder for someone not familiar with ES6 to see that it is a function.

This reminds me of Ruby's return-the-last-evaluated-thing-in-a-function semantics (which sadly Rust copied). Having to type one extra word is not such a burden that you should add cognitive overhead each time someone not intimately familiar with the language has to read your code.

If the argument is that only ES6 experts should only ever have to read or write ES6 code, then I would argue that any syntax argument is pointless because only experts can comment on a languages syntax -- and thus COBOL objectively has the best syntax and you cannot disagree unless you are a COBOL expert.

It does seem strange if you think of it as “return the last evaluated thing from the function.” But that’s not the semantic; the semantic is “everything is an expression and expressions evaluate to a value.” Removing this behavior would make these languages less consistent.

(And yes, in both Ruby and Rust not literally everything is an expression, but almost everything is.)

I agree that because of common uses of things like match in Rust it makes it consistent to also do it for functions. I don't agree that the reason why it's consistent is because a function body is an expression (though of course you have more expertise than me on this one -- and Rust does actually treat scopes much more strictly than most other languages so you could argue every scope has the smell of a function call associated with it).

Here's the citation: https://doc.rust-lang.org/reference/items/functions.html

> A function consists of a block, along with a name and a set of parameters.

https://doc.rust-lang.org/reference/expressions/block-expr.h...

> Blocks are always value expressions and evaluate the last expression in value expression context.

> This reminds me of Ruby's return-the-last-evaluated-thing-in-a-function semantics (which sadly Rust copied). Having to type one extra word is not such a burden that you should add cognitive overhead each time someone not intimately familiar with the language has to read your code.

I think the concept of returning by default is fundamental enough that doing so or not is mostly a matter of what you're used to. If I'd started out with Elixir or Ruby I'd probably find it strange that I have to manually return stuff from a function.

Furthermore, at this point ES6 is common enough that knowing at least some of the core additions (among them arrow functions with their implicit return) should be something any front-ender knows.

The es6 syntax is LESS readable. It's less declarative. Just quicker to type if you don't have a nice editor setup.

My issue with this method is the name more than anything. I would also guess if it's even needed - probably bad application logic is requiring that ternary statement but didn't read it yet.

Ideal method name is already given - getEmementsByClassName... Really should just have a utility to default return types.

It was almost certainly written long before ES6 was widely supported.

Probably not worth setting up a babel transpiler for that small amount of JS tbh

Makes supporting older browsers a lot easier