guide.elm-lang.org | My book introducing you to Elm | Learning library

Let's consider an example:

• name: Apple, price: $3.2, pic: 🍏
• name: Banana, price: $2, pic: 🍌
• name: Orange, price: $2.8, pic: 🍊

Now let's imagine that the user sorts by price:

• name: Banana, price: $2, pic: 🍌
• name: Orange, price: $2.8, pic: 🍊
• name: Apple, price: $3.2, pic: 🍏

without keyed nodes, the diffing is going to look like this:

• name: AppleBanana, price: $3.22, pic: 🍏🍌
• name: BananaOrange, price: $22.8, pic: 🍌🍊
• name: OrangeApple, price: $2.83.2, pic: 🍊🍏

which is going to issue in this example 9 replaceElement operations with 9 createTextElement operations (for example, the exact semantics might work slighly differently, but I think the point stands).

The keyed version will understand that the order changed and will issue a single removeChild and appendChild for the apple node.

Hence all the performance savings are on the DOM side. Now this is not just for performance, if those lists had input elements, keeping them keyed if you had your cursor in the Apple input, it would stay in the apple input, but if they weren't keyed, it would now be in the banana input.

You are correct that without lazy the diffing still happens, but the diffing is generally the cheap part, the more expensive part is actually patching the DOM, which is what keyed helps prevent.

You need a webserver that would serve the index.html on every path that is requested. The easiest way is to install elm-live globally and then start it like elm-live src/Main.elm --pushstate

Without serving index.html on every path (let's say you use live-server), if you navigate to an internal path and reload you will get a 404.

If you've already installed the Elm compiler, you already have the REPL. Try typing elm repl in the shell. Note that there is no hyphen in this command.

The instructions you are following to install a separate REPL are long out of date.

You can fire the second request when you handle the response from the first endpoint. Something like: