I was working with one of my colleagues at Slate on a challenge to write a highly performant JavaScript code to solve a specific problem. We wanted to build a function that will decode a value and return it in a particular way (more details about it later), and we both ended up using drastically different approaches.

The next day, while I was in the office, I asked two more guys if they want to join the fun... that's how it all started. We discussed how to efficiently solve the problem and started building solutions based on our ideas (worse or better).

We decided to open the challenge to more people in the team. I wrote down all the requirements and posted it on Slack so anybody can have a look over the weekend. I received code from eight people, and almost everybody sent me revised versions while they were working on performance improvements. It was interesting to learn how one problem had so many different solutions. All valid, all working, all fast.

One thing is worth noting. The whole thing wasn't created as a challenge for the team, but it turned into one. I was stunned to see how much engagement it created, and I had a lot of fun doing it, testing and running performance tests.

The challenge

This part is the techy part so you can skip to another point if you are not a coder.

A real-life example is based on filters. I have a filtering functionality where each number (power of 2) is assigned specific filter options, for example, 1=address, 2=photos, 4=reviews, 8=email, 16=chat, 32=somethingElse, etc.

I want to pass to a function a number which will return me an array of all filters applied. We don't want to assign a filter name to any numbers at this stage yet.

  • It has to be fast, doesn't have to be pretty.
  • Doesn't have to support more than 32 bits.
  • Order of a returned array doesn't matter.

A couple of examples:

Javascript challenge

The results

You review everything we did on JSPerf site and follow the evolution of our code. Most of the functions with "1" are slower than next iterations. There is also a massive difference between browsers and a solution that is a winner on Firefox, might be far behind when running on Safari. It gets even weirder when you run the tests on IE or Edge.

Tests are reflecting different scenarios to make sure the code is fast across the board. Why test the input with a small or large number, and cases when the return value might be an array with one item or with multiple (30).

Javascript challenge results

If you would like to review the code, all functions, tests and results, go to https://jsperf.com/all-power-of-2-numbers-in-value and have fun!

And the winner is...

Joe 'Stanz' Stansbury (person E in tests) is our talented senior Javascript Developer at Slate and he is the winner of our first Unexpected JavaScript Challenge. His functions are consistently fast in all browser and always close, or on the top of results with the high output of operation per second. What is important, is the fact that his first version was already ridiculously good (I had to re-work my code, after seeing what he produced) and yet he managed to improve it even more with his second version.

What did I learn from this experience and you should too?

  • Even if you think your code is the best in the world and you can't make it faster, there is always somebody who will prove you wrong.
  • People like to engage in small challenges like that. It builds trust, expertise and team spirit. Team members can be creative in their own way and show it to the world.
  • You can solve problems in ways you couldn't even imagine until you saw them. Work with people around you, and they will help you to become even better at what you do.
  • I love vanilla JavaScript for its faults and imperfections. It is as messed up as the human brain; full of surprises, unexpected behaviours and glitches, yet powerful and amazing.
  • Details matter, even when we consider them insignificant, they might still have a massive impact on the results of your work.
  • Test everything you do, don't think you are so amazing that you don't make mistakes.
  • The efficient and powerful code doesn't have to look "smart" and use "fancy methods".