Home

Chrome 137's Non-Keyed Mode Flips JS Framework Rankings

A featured image for a developer blog article about "Chrome 137's Non Keyed Mode Flips JS Framework

Chrome 137's Non-Keyed Mode Flips JS Framework Rankings

Hey devs, imagine your app's perf rankings flipping overnight because Chrome decided to tweak how it handles lists. That's exactly what's happening with Chrome 137 and krausest's legendary JS Framework Benchmark. If you're building UIs with React, Svelte, or anything in between, this could rewrite your speed leaderboard. Why care? Because non-keyed mode in lists just exposed which frameworks are truly fast—and it's shaking things up big time.

The Hook: Why Non-Keyed Mode Matters for Your Code

Krausest's benchmark (check it at https://krausest.github.io/js-framework-benchmark/current.html) has been pitting top JS frameworks against each other for years. It tests speed, memory, and even Lighthouse scores across real-world ops like creating rows, swapping them, or clearing lists. Post-Chrome 118, they switched to weighted geometric means for fairer scores. Now, Chrome 137 introduces non-keyed lists—no stable key props, just raw appends and removes.

Why this matters: Keys help frameworks like React track DOM nodes efficiently during updates. Without them? It's a wild west of diffing algorithms. Some frameworks crush it (hello, potential new leaders), others stumble. This mirrors real apps where you might render dynamic lists sans keys for simplicity. Suddenly, your "fast" framework might guzzle memory or lag on mobile. Always peek at 'current.html'—it's updating daily with fresh Chrome truths.

TL;DR: Chrome 137's non-keyed mode flips benchmark winners. Svelte or Solid might edge out React now—test your stack!

Keyed vs. Non-Keyed: A Quick Diff

Keyed mode (old default): Frameworks use unique keys to minimize DOM thrashing. React shines here.

Non-keyed mode (Chrome 137 reality): No keys. Browsers guess at changes, favoring frameworks with smart heuristics or minimal DOM touches.

Historical tables show the flip: In keyed tests, Framework A wins; non-keyed? Framework B surges ahead. Weighted means post-Chrome 118 smooth this out, but the shakeup is real.

Code Example 1: Vanilla JS Non-Keyed List (Try This!)

Let's see raw browser perf. Append 1000 items without keys—Chrome 137 handles it snappily.

<!DOCTYPE html>
<html>
<body>
  <div id="list"></div>
  <button onclick="addItems()">Add 1000 Items</button>
  <button onclick="clearList()">Clear</button>
 
  <script>
    const list = document.getElementById('list');
 
    function addItems() {
      const start = performance.now();
      for (let i = 0; i < 1000; i++) {
        const div = document.createElement('div');
        div.textContent = `Item ${i}`;
        list.appendChild(div);  // Non-keyed append
      }
      console.log(`Took ${performance.now() - start}ms`);
    }
 
    function clearList() {
      list.innerHTML = '';
    }
  </script>
</body>
</html>

Pop this in Chrome 137. Feels instant? Now imagine frameworks layering logic on top. Practical use case: Todo lists or search results where items shift dynamically—no need for keys if your framework optimizes well.

Code Example 2: React Keyed vs. Non-Keyed Showdown

React loves keys, but skip 'em and watch perf dip in non-keyed mode.

import React, { useState, useEffect } from 'react';
 
function ItemList({ items }) {
  return (
    <ul>
      {items.map((item, index) => (
        <li key={item.id}>  {/* Keyed: Fast! */}
          {item.text}
        </li>
      ))}
    </ul>
  );
}
 
// Non-keyed version (risky, for demo):
function NonKeyedList({ items }) {
  return (
    <ul>
      {items.map((item, index) => (
        <li>{item.text}</li>  {/* No key: Chrome 137 tests this */}
      ))}
    </ul>
  );
}

Why it matters: In benchmarks, keyed React holds strong, but non-keyed exposes re-render overhead. Use case: Static lists from APIs—add keys if items mutate!

Code Example 3: Svelte's Secret Sauce (Minimal DOM)

Svelte compiles away the framework at build time, acing non-keyed with tiny runtimes.

<script>
  let items = [];
  $: doubled = items.map(i => ({ ...i, text: i.text * 2 }));
</script>
 
<ul>
  {#each doubled as item (item.id)}  <!-- Keyed each -->
    <li>{item.text}</li>
  {/each}
</ul>
 
<button on:click={() => items = Array.from({length: 1000}, (_, i) => ({id: i, text: i}))}>
  Load 1000
</button>

Non-keyed {#each doubled as item}? Svelte still flies in Chrome 137 benchmarks. Use case: Dashboards with real-time data feeds—less JS, more speed.

Real-World Impact: Frameworks in the Hot Seat

From krausest's tables:

  • Speed: Non-keyed favors lightweight champs like Svelte, Solid.js over React/Vue in row swaps.
  • Memory: Keyless clears leak less for some (looking at you, DOM-heavy libs).
  • Lighthouse: Faster paints = better scores for PWAs.

Practical? Optimize e-commerce carts or infinite scrolls. Test in Chrome 137 DevTools (new perf insights rock!).

Chrome 137 isn't just benchmarks—it's got JSPI for WASM/JS speedups and DevTools tricks like ignoring irrelevant scripts.

Try It Yourself: Next Steps

  1. Hit https://krausest.github.io/js-framework-benchmark/current.html—toggle keyed/non-keyed.
  2. Benchmark your app: npm i js-framework-benchmark or use Chrome DevTools perf panel.
  3. Update to Chrome 137, profile lists, and share rankings in comments!

Frameworks evolve fast—who's your new perf king? Dive in and find out. 🚀