Edit: This answer has been written by someone who is unexperienced in JavaScript programming (me). Please note the comments shed a slightly different light on the topic.
One of the reasons there are not many JS chess engines out there is that JavaScript is quite unsuited for heavily parallelisable tasks, especially complex minimax analysis.
Major drawbacks JS has (in my opinion) are:
- JavaScript is a high level language, making writing fast code
difficult. (Of course I have to add that coding in ASM or C isn't
going to be faster if you don't know what you are doing. But chess
programmers know.) Additionally, performance optimisation details depend on the browser you are using.
- No real multithreading support. (That's a damn hard limit on
computation speed.)
- No real memory management. (JS does it for you, but I imagine you as
a programmer can allocate much more efficiently.)
- Apparently, limits on stack size, CPU usage etc. are imposed on
JavScript Code (although Icannot give hard evidence right now).
- I cannot imagine JS being very efficient with hash tables.
- I imagine it being difficult to load opening books or endgame
tablebases during runtime (slow) or preloading it on startup (still
slow and your bandwidth won't like it).
Well, technically, these are reasons why it would be hard to code a good chess engine - but who wants an engine with 1800 Elo? (Well, still enough for one or two standard deviations of players' practical purposes.)
And in the end: it's client side. If you need something client side, don't do it in a browser. If it can be done on the server, use it! E. g., using PHP, pipes and the UCI protocol, you'll get much further and you can let the server compute it for all clients (and I know it has been done before, but can't tell exactly where I've seen it).