I'm not entirely enthusiastic about either. The parts[parts.length - 1] using manual index lookup and subtraction may well take a moment to recognize, "Oh, this is getting the last element of the array". The second, using .reverse() followed by destructuring of the first item also could take a moment to think about before you understand what exactly it's doing.

As an alternative, consider using .pop() instead, I think it's more intuitive than both:

return someString
  .split('.')
  .pop();

The only (tiny) downside is that the above isn't functional, since it mutates the split array - but that's OK, since the array isn't being used anywhere else.

It's true that performance for something like this isn't really something to worry about if this is used in a larger project - what matters more if it's easier to understand what the code is doing.

Remember that if something isn't immediately intuitive, that's what comments are for, though all of these cases are self-documenting enough that it's not needed.

Another way to make it easier to recognize what's going on would be to put this into a function with a descriptive name, such as getLastProperty (if the input is meant to show a path to a nested property lookup, for example - name it as appropriate for how it's meant to be used).

I'm not entirely enthusiastic about either. The parts[parts.length - 1] using manual index lookup and subtraction may well take a moment to recognize, "Oh, this is getting the last element of the array". The second, using .reverse() followed by destructuring of the first item also could take a moment to think about before you understand what exactly it's doing.

As an alternative, consider using .pop() instead, I think it's more intuitive than both:

return someString
  .split('.')
  .pop();

The only (tiny) downside is that the above isn't functional, since it mutates the split array - but that's OK, since the array isn't being used anywhere else.

It's true that performance for something like this isn't really something to worry about if this is used in a larger project - what matters more is if it's easier to understand what the code is doing.

Remember that if something isn't immediately intuitive, that's what comments are for, though all of these cases are self-documenting enough that it's not needed.

Another way to make it easier to recognize what's going on would be to put this into a function with a descriptive name, such as getLastProperty (if the input is meant to show a path to a nested property lookup, for example - name it as appropriate for how it's meant to be used).