I disagree :) It's easier for me to look at an object and its contents and see where it is referenced. I think switch statements are ugly. I think if/else blocks are ugly. I prefer boolean statements when possible, although definitely not nested ternaries.

I'm sure I'll get flamed, but I really liked this:

  const getPosition = position =>
      ({
          first: 'first',
          second: 'second',
          third: 'third'
      }[position] || 'infinite');

I think equating ugly with hard-to-read is a common mistake. Many things are "ugly" but easy to read (e.g. in design circles, newbies often do far-too-small fonts with low contrast because it looks pretty, whereas accessibility guidelines tell you to do the opposite; in programming, readability of point-free style has more to do with the reader's ML-vs-Algol experience than how elegant FP may be, and educators often start w/ procedural style precisely because reading the flow of the program matches the students' expectations that things ought to be read top to bottom, rather than peeled through layers of abstractions)

Honestly, I find that rating the readability of the object versions vs the switch statement is bikeshedding. This is perfectly readable and doesn't involve going back and forth with my eyes to figure out the data flow or figure out if I have mismatched brackets or what have you:

    const getPosition = position => {
      switch (position) {
        case 'first':
        case 'second':
        case 'third':
          return position;
        default:
          return 'infinite';        
      }
    }

Another thing that is worth mentioning is that objects consume memory and allocating memory in JS for this is just wasting orders of magnitudes more cycles and sacrificing throughput for no good reason - other than to try to be clever and avoid an idiomatic and optimizable construct.

>I think equating ugly with hard-to-read is a common mistake

This is just a semantics argument. I can replace "ugly" with "hard-to-read" if you want. I think it's both, in this instance.

>Honestly, I find that rating the readability of the object versions vs the switch statement is bikeshedding.

I agree in the context of code review, but since this is what we're talking about I figured I'd share my opinion.

>Another thing that is worth mentioning is that objects consume memory and allocating memory in JS for this is just wasting orders of magnitudes more cycles and sacrificing throughput for no good reason - other than to try to be clever and avoid an idiomatic and optimizable construct.

Premature optimization. If you need to optimize, then do it. Otherwise you should prioritize what you consider understandable and easy-to-write code. I guarantee the vast majority of javascript written would not be ill-affected by this.

I'd ask you to reconsider what an optimization is, and to also consider the concept of "premature cleverification".

A switch statement is a pretty idiomatic choice for the example. Merely knowing more about the low level cost of different options does not make a snippet an optimization.

Examples of actual optimizations (from real world code I've seen) would include using bitmaps, lookup tables, large regexps, tries and binary search. All of these have the property of obscuring the search space in the name of performance, and many come with trade-offs such as increased startup cost or code size. Choosing to use a trie here, for example, without considering its trade offs would be a premature optimization. A switch statement is at worst a refactor that maintains the same algorithm.

What happens when your values are computed? Or expensive to compute, and your map starts to get big? E.g.:

    {'a': foo(), 'b': bar() }[...]

If foo() or bar() ever introduce side-effects or become expensive, you're gonna have a hell of a time figuring out what's going wrong.

If your values are expensive to compute like that, then you'd have the object return a function that would call foo(), bar(), and so on; and you wouldn't call them all to setup the map in the first place.

This is in fact demonstrated in the second example in "Working with functions"...

My personal preference is if-else/switch blocks with enums. Doing conditionals with string parsing just seems gross to me, but I find conditionals easy to read. And the benefits of using an enum is that you can easily find where it is used, which makes reading the code and adding or removing options easier.