Use Objects or Switch Statements in Javascript?

Cory Bass
I came across this article over the weekend, discussing the pros and cons of using objects over switch statements in Javascript. I’d like to hear some thoughts on the pros and cons of each method, if you can find time for it. 

Arar Duqoum
The argument they put forth on first blush seems to come down to switch not using curly braces and looking a little weird to a JS only developer's eyes. That's a valid point IMO, but the alternative that is put forth is both nonintuitive and kinda strange looking to me. Switch/case statements have always looked all right to me and aren’t in the least cumbersome. 🙌
I think for simple cases where you are not doing significant functionality in the switch/case statements then this approach is cleaner but otherwise I think this is overkill.

Jane 
Switch statements are probably implemented O(n) where n is the number of cases -- similar to doing:
if (x || y || z || etc...) 
Object literals are O(1)

Andrew Coleburn
I like this actually. But I can freely admit that it's because I hate switch/case. I think the argument that switch/case is weird in JS is a valid point against it as well. I've always found them super clunky and annoying/difficult to debug when something goes wrong (which it often does). and I think the approach offered here is pretty straightforward, especially if you're a JS dev who doesn't work in anything else (🙋‍♂️)  That said, I don't agree that the chain of if/else  is bad. A bit verbose maybe, but very clear, readable, and easier to debug, IMO. Interesting thought on the performance aspect as well, @Jane...

Christopher (he/him) 
I use these constructs all the time, but I conceptualize them differently than switches. I use these for things that clearly fit a “lookup” pattern. Whereas switches are generally for a chained if-else type pattern (in which I actually use a chained if-else because it's clearer and easier to understand). If my cases and breaks don’t line up 1-1 and I need more complex behaviors where a switch would be better, I’ll generally make a new function where I have full compel over early returns. TBH, I don’t like or use switches. ¯\_(ツ)_/¯

 Arar Duqoum
I think the performance argument is ok as far as it goes. It's not wrong. But big o runtime analysis for small numbers doesn't really hold sway since at low numbers you can't disregard constants and implementation details. So it's correct but I personally wouldn't accept it as a cornerstone for a decision to use this style over case switch.

Mark Thompson 
I like if/else since everyone knows how they work and they’re much more common than switch/case. Usually if the list gets long, it’s unlikely that I care about how many more lines if/else takes since I end up adding comments to clarify what’s going on on each style anyway.For more complex stuff, I move things into functions. This helps unit tests and makes your code compact~I like to use object literals for when there’s like 10+ cases and moving logic to a separate function doesn’t help.

Either way, switch/case is cool (I just treat them like if/else). And object literals are cool as long they’re commented since they tend reserve them for the messy stuff.

-In the article:
The first getDrink example shouldn’t use shadow reference of “type” wuhahahaha. But makes sense to me to instinctively move to switch/case or an object literal given the example looks like a look up pattern. I’d go as far to say use an enum for everything that’s not the default case, then wrap in a function to provide the default case.

// The drink I chose was Coke
console.log(drink);

I also drink Coke when I’m reaching for a soda

function getDrink (type) {
  return 'The drink I chose was ' + {
    'coke': 'Coke',
    'pepsi': 'Pepsi',
    'lemonade': 'Lemonade'
  }[type];
}

I personally don’t like this type of stuff since it’s not saving many more lines and the code is becoming more complex than it needs to be. An obvious error in this case would be that you’re passing an “invalid” type such as “sprite”, but that’d take a few moments to realize when debugging “Object literal’s function”. Without something like typescript, doing stuff like this will always force people to look up how your code works since it’s not common, I’d avoid this if you don’t have types.

-Overall, all of these styles are valid to me. Some are little too ninja  for my taste, but cool stuff~