The underscore is used for placeholders, that is variables you need to declare but you're not going to use. In this case, I guess, the author thinks that this looks better than

    () => window.location.href

Fat arrow is used to define a lambda function. The left-hand side of the arrow is argument list (_ is used to indicate lack of used arguments) and the right-hand side is the function body. It is equivalent to:

   var currentUrl = function () { return window.location.href; }

> _ is used to indicate lack of used arguments

Note that this is a convention, not a requirement for the syntax (like in some other languages).

I've spent at least a few mins troubleshooting why `_.map` (from `lodash` npm module) didn't work inside of a fat function while fixing another developer's defect.

If you use `_` as a valid const/variable identifier anywhere in your codebase, I would recommend you ditch `_ => alert(1)` for something more obscure like `ø => alert(1)`

It is not the same as that. the fat arrow doesn't change the value of "this" while the function definition does.

Given that "this" isn't referenced in the function, though, it's practically equivalent.

I think one is more efficient memory wise but I'm not sure which one.

The non-fat-arrow one, as it does not need to carry around the context of `this` with it.

Do you have a reference for this? I always thought arrows were lighter weight because their `this` is static rather than dynamic.

the `=>` de-sugars to:

    var currentUrl = function(_) {
        return window.location.href;
    }

the underscore is used so they don't have to type `() =>` instead

Ahhh. I think I was confused why referring to `window.location.href` would be needed to be put into a function, and then called as `currentUrl()`, rather than having currentUrl be a string value. Is this best practice? I mean, is there some `window.location.href` isn't a global object?

Because the value may change. If 'currentUrl' was a constant (eg. `const currentUrl = window.location.href`) it would capture the href at the start of the application, even though it might change later on (history API, pushstate etc).

Why wouldn't you just reference `window.location.href` when needed, instead of wrapping it up in `currentUrl`?

Yeah that was my question. I was racking my head thinking of when this window.location.href wouldn't refer to what a program would want given how it almost acts like a global function in some ways (e.g. `window.location.href="http://example.com"` can be used to change the page). Maybe currentUrl is supposed to be a wrapper just incase window.location.href changes (which seems highly unlikely but again, I'm out of the loop with modern JS).

Some snippets, like this, read a lot like codegolf functions.

Code Golf is about using the most terse syntax (and frankly, showing off while doing it).

This was a new syntax added to the language spec to reduce the amount of boilerplate required for common tasks.

Also, the "fat arrow function" handles "this" different inside of the function, so it can serve a slightly different function and in many event-handling cases it can be even more terse than traditional JS functions.