funkiee, good catch on that issue. I just tried using the current index during iteration, instead of the actual unique ID of the search results item and that sped things up a lot. In fact, now React and Marko perform almost exactly on par for client-side rendering. Server-side rendering of React components is still very slow in comparison. I will update the README with the new results.
On a related note, the React docs were very misleading when they stated the following:
"In practice, finding a key is not really hard. Most of the time, the element you are going to display already has a unique id. When that's not the case, you can add a new ID property to your model or hash some parts of the content to generate a key."
Source: http://facebook.github.io/react/docs/reconciliation.html#key...
I tried following their advice and used the unique ID of the search results record and it turns out that was the wrong thing to do. It was better to use the index of the current iteration and I think that should always be the recommended thing to do given the performance difference.
On a related note, the React docs were very misleading when they stated the following:
"In practice, finding a key is not really hard. Most of the time, the element you are going to display already has a unique id. When that's not the case, you can add a new ID property to your model or hash some parts of the content to generate a key." Source: http://facebook.github.io/react/docs/reconciliation.html#key...
I tried following their advice and used the unique ID of the search results record and it turns out that was the wrong thing to do. It was better to use the index of the current iteration and I think that should always be the recommended thing to do given the performance difference.