Answers.Body: <p>WASM defines how an engine is compiled but not how it runs. Browser chess engines always run on a web worker in JavaScript. </p>
  
  <p>Sample code for running a chess engine on web browser:</p>
  
  <pre><code>const x = new Worker('/stockfish.js')
  x.postMessage("uci")
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-09T14:28:01.293Z
Answers.Text: You shouldn't unconditionally run stockfish.js. As the documentation states, you should test whether the browser supports Wasm, and then run either stockfish.wasm.js or stockfish.js, as appropriate. And if you run stockfish.wasm.js, it will use the browser’s native Wasm support to run the file stockfish.wasm.
Answers.UserDisplayName: Stephen
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-09T08:45:51.090Z
Answers.LastActivityDate: 2020-06-09T08:52:54.287Z
Answers.LastEditDate: 2020-06-09T08:52:54.287Z
Answers.UserDisplayName: SmallChess
Answers.Body: <p>Lichess uses <a href="https://en.wikipedia.org/wiki/WebAssembly" rel="noreferrer">WebAssembly</a> (Wasm) - as is stated on the analysis page (“Stockfish 10+ WASM in local browser”). Wasm is the obvious thing to use, as it runs on the client side but is faster than JavaScript.</p>
  
  <p>Running Stockfish in a web browser is usually done using <a href="https://github.com/niklasf/stockfish.js" rel="noreferrer">Niklas Fiekas’ Wasm+JavaScript port of Stockfish</a>, which is what Lichess uses. This consists of a Wasm file <code>stockfish.wasm</code> containing the engine itself, and a smaller JavaScript file <code>stockfish.wasm.js</code> that controls the use of the engine. (There is also a large file <code>stockfish.js</code> that is used as a fallback on browsers that lack native Wasm support.)</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-09T07:30:54.483Z
Answers.Text: Wow nice. I'll look into it. Thanks.
Answers.UserDisplayName: Ram
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-09T07:28:01.773Z
Answers.LastActivityDate: 2020-06-09T14:07:02.177Z
Answers.LastEditDate: 2020-06-09T14:07:02.177Z
Answers.UserDisplayName: Stephen
Body: <p>I recently build a chess engine using javascript (<a href="https://github.com/Ram-the-coder/ai-chess-engine-v2" rel="noreferrer">https://github.com/Ram-the-coder/ai-chess-engine-v2</a>). It runs on the browser - because of this when the chess engine is computing the best move, the webpage gets unresponsive. So I thought if I move the processing to the server, then I can eliminate the unresponsiveness. But if I do that then I've to maintain the game state for each client of the server. The size of the game state I think is in mega bytes as it includes the hash tables.</p>
  
  <p>Another problem I faced in keeping the processing on the client-side is that the processing speed becomes dependent on the client's device.</p>
  
  <p>How are such online chess engines usually built?</p>
  
  <p>I don't think storing the game state in memory is good as the server has to serve many clients. Maybe storing in a database in the same server might work...</p>
  
  <p>If I use a client-server architecture, won't I be restricted to serve one client request per server at a time? If yes, how are online chess engines able to serve unlimited clients at the same time?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-06-09T06:04:40.100Z
Comments.Text: usually UCI chess engines (which can be run online) use a separate thread for the search.
  It totally depends on the hardware it is running on. But if its js, I assume its running on the client computer, right? So you should try to use a separate thread.
Comments.UserDisplayName: Finn Eggers
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-06-09T07:29:01.790Z
Comments.Text: I thought multi-threading in the browser was impossible. Upon some searching, I just found web workers. Maybe I should use that. Thank you.
Comments.UserDisplayName: Ram
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-06-09T20:53:48.463Z
Comments.Text: Even before web workers, you could do a tiny amount of work, then post an event to do the next step, emulating "cooperative multithreading".
Comments.UserDisplayName: Mooing Duck
Tags: <engines><software><online-chess>
Title: How are online chess engines' architecture designed?
ThreadText: # How are online chess engines' architecture designed?
  
  (Asked by: username_0 on 2020-06-09)
  
  I recently build a chess engine using javascript (<https://github.com/username_0-the-coder/ai-chess-engine-v2>). It runs on the browser - because of this when the chess engine is computing the best move, the webpage gets unresponsive. So I thought if I move the processing to the server, then I can eliminate the unresponsiveness. But if I do that then I've to maintain the game state for each client of the server. The size of the game state I think is in mega bytes as it includes the hash tables.
  
  Another problem I faced in keeping the processing on the client-side is that the processing speed becomes dependent on the client's device.
  
  How are such online chess engines usually built?
  
  I don't think storing the game state in memory is good as the server has to serve many clients. Maybe storing in a database in the same server might work...
  
  If I use a client-server architecture, won't I be restricted to serve one client request per server at a time? If yes, how are online chess engines able to serve unlimited clients at the same time?
  
  **Tags:** engines, software, online-chess
  
  > **Comments:**
  > **username_1**: usually UCI chess engines (which can be run online) use a separate thread for the search. It totally depends on the hardware it is running on. But if its js, I assume its running on the client computer, right? So you should try to use a separate thread.  
  > **username_0**: I thought multi-threading in the browser was impossible. Upon some searching, I just found web workers. Maybe I should use that. Thank you.  
  > **username_2**: Even before web workers, you could do a tiny amount of work, then post an event to do the next step, emulating "cooperative multithreading".  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2020-06-09. Score: 3 | Accepted answer
  
  WASM defines how an engine is compiled but not how it runs. Browser chess engines always run on a web worker in JavaScript. 
  Sample code for running a chess engine on web browser:
  const x = new Worker('/stockfish.js')
  x.postMessage("uci")
  
  > **Comments:**
  > **username_4**: You shouldn't unconditionally run stockfish.js. As the documentation states, you should test whether the browser supports Wasm, and then run either stockfish.wasm.js or stockfish.js, as appropriate. And if you run stockfish.wasm.js, it will use the browser’s native Wasm support to run the file stockfish.wasm.  
  
  ---
  
  ### Answer by username_4 on 2020-06-09. Score: 8
  
  Lichess uses [WebAssembly](https://en.wikipedia.org/wiki/WebAssembly) (Wasm) - as is stated on the analysis page (“Stockfish 10+ WASM in local browser”). Wasm is the obvious thing to use, as it runs on the client side but is faster than JavaScript.
  
  Running Stockfish in a web browser is usually done using [Niklas Fiekas’ Wasm+JavaScript port of Stockfish](https://github.com/niklasf/stockfish.js), which is what Lichess uses. This consists of a Wasm file `stockfish.wasm` containing the engine itself, and a smaller JavaScript file `stockfish.wasm.js` that controls the use of the engine. (There is also a large file `stockfish.js` that is used as a fallback on browsers that lack native Wasm support.)
  
  > **Comments:**
  > **username_0**: Wow nice. I'll look into it. Thanks.  
  
  ---
  
  