That is true, coding style can be differrent per use case.

As an actual user of applications I can tell you that I don't like slow applications and I don't even care about the code behind since it is secure and works.
We, as programmers, tend to see our code as something we give/share with other programmers and we forgot that someone else will use it at the end.
Someone who will lost time of his/her life waiting for something to finish... because we have a beautiful but slow code :)

I think it is more interesting when presenting facts to trigger some thoughts and point out some possible mistakes - we all do mistakes.
Posting just a solution is fun but is more fun and productive if someone read it and do some critics. That's the way to get better.
Making a jsperf comparison is a good way of that - nothing more!

Thank's for your respond and hope I didn't trigger any "weird" feelings to anyone with my posts - after all, in coding and war everthing is fair :D

PS. at the banking sector there was not a single time that I heard "that's slow but anyone can read it, let's keep it" - just the opposite! :)

I see a lot of solutions using "map" etc... bad although it is eye catching they are even 40%+ slower than my "old-school" "for" method.
Should the "best" solution be the "eye catching" one or the fastest one? (given both are working correctly)

(Some solutions are also altering the MORSE_CODE table - bad practice?)

Some tests in Chrome and Firefox:
http://jsperf.com/morse/2

With a very small optimization, the decode2_opt is the fastest one by far.

Agree, though it is still slower in Firefox and IE11.
I am sure it will be someday the fastest solution.