Forem: tinyforge

Rust's Iterators Are Lazy — Proven With Logs

tinyforge — Mon, 18 May 2026 01:00:00 +0000

Originally posted on tinyforge.store.

This is part 2 of a series on lazy iterators.
Part 1: Rust's Iterators Are Lazy — Proven With Logs

Update (2026-05-18): Added Section 4 on Iterator Helpers (ES2025). The original framing — that lazy iteration in JS requires generators or a library — is outdated for modern runtimes. [...].values().filter(...).map(...).take(...).toArray() is now lazy natively. Section 5 (formerly Section 4) reframes lazy.js as a pre-2025 fallback. Thanks to juner for flagging this in the Zenn comments.

In the previous post we proved that Rust's iterators are lazy — they process one element at a time through the entire pipeline, and stop the moment they have what they need.

JavaScript arrays work differently. And the difference has a real cost.

1. The Default: Eager Evaluation

In JavaScript, every array method creates a new array and processes all elements immediately.

const data = Array.from({ length: 10 }, (_, i) => i + 1);

const result = data
  .filter(x => {
    console.log(`  filter: ${x}`);
    return x % 2 === 0;
  })
  .map(x => {
    console.log(`  map: ${x}`);
    return x * 10;
  })
  .slice(0, 3);

console.log('\nresult:', result);

Output

  filter: 1
  filter: 2
  filter: 3
  filter: 4
  filter: 5
  filter: 6
  filter: 7
  filter: 8
  filter: 9
  filter: 10
  map: 2
  map: 4
  map: 6
  map: 8
  map: 10

result: [20, 40, 60]

Notice what happened:

filter ran on all 10 elements
map ran on all 5 results from filter
slice(0, 3) then discarded 2 of them

15 operations to produce 3 results. Compare this to the Rust equivalent — 6 operations total, stopping as soon as 3 items were collected.

This is eager evaluation: each method completes in full before the next one starts. The intermediate arrays ([2, 4, 6, 8, 10] after filter) are allocated and then discarded.

For small arrays this doesn't matter. For large datasets — logs, search results, data processing — it does.

2. Can You Do Better With a Plain Loop?

Yes. A hand-written loop is lazy by default because you control when to stop:

const data = Array.from({ length: 10 }, (_, i) => i + 1);
const result: number[] = [];

for (const x of data) {
  console.log(`  checking: ${x}`);
  if (x % 2 === 0) {
    const mapped = x * 10;
    result.push(mapped);
    if (result.length === 3) break;
  }
}

console.log('\nresult:', result);

Output

  checking: 1
  checking: 2
  checking: 3
  checking: 4
  checking: 5
  checking: 6

result: [20, 40, 60]

6 iterations — same as Rust. The loop stops as soon as 3 items are collected, and never touches elements 7–10.

The problem is readability. Chained .filter().map().slice() is expressive and easy to follow. A manual loop with a break condition is imperative and harder to compose. As the logic gets more complex, the loop gets harder to read and maintain.

3. Lazy Evaluation in TypeScript — Generator-Based

JavaScript has a native mechanism for lazy sequences: generators. A generator function produces values one at a time on demand, without allocating intermediate arrays.

function* lazyFilter<T>(
  iter: Iterable<T>,
  predicate: (x: T) => boolean
): Generator<T> {
  for (const x of iter) {
    console.log(`  filter: ${x}`);
    if (predicate(x)) yield x;
  }
}

function* lazyMap<T, U>(
  iter: Iterable<T>,
  fn: (x: T) => U
): Generator<U> {
  for (const x of iter) {
    console.log(`  map: ${x}`);
    yield fn(x);
  }
}

function take<T>(iter: Iterable<T>, n: number): T[] {
  const result: T[] = [];
  for (const x of iter) {
    result.push(x);
    if (result.length === n) break;
  }
  return result;
}

// Usage
const data = Array.from({ length: 10 }, (_, i) => i + 1);

const filtered = lazyFilter(data, x => x % 2 === 0);
const mapped = lazyMap(filtered, x => x * 10);
const result = take(mapped, 3);

console.log('\nresult:', result);

Output

  filter: 1
  filter: 2
  map: 2
  filter: 3
  filter: 4
  map: 4
  filter: 5
  filter: 6
  map: 6

result: [20, 40, 60]

6 operations. Elements 7–10 are never touched. The behavior is identical to Rust — one element flows through the entire pipeline at a time, and the chain stops as soon as take has enough.

The generator functions are composable and readable, but the syntax for chaining them is awkward compared to the fluent .filter().map() style.

4. Modern JS: Iterator Helpers (ES2025)

The story above — that you need generators or a library for lazy chains in JavaScript — was true until recently. As of ES2025, the Iterator Helpers proposal reached Stage 4 and shipped. Array.prototype.values() returns a native Iterator object, and Iterator.prototype now has lazy .filter(), .map(), .take(), .drop(), .toArray(), .reduce(), and more.

const data = Array.from({ length: 10 }, (_, i) => i + 1);

const result = data
  .values()
  .filter(x => {
    console.log(`  filter: ${x}`);
    return x % 2 === 0;
  })
  .map(x => {
    console.log(`  map: ${x}`);
    return x * 10;
  })
  .take(3)
  .toArray();

console.log('\nresult:', result);

Output

  filter: 1
  filter: 2
  map: 2
  filter: 3
  filter: 4
  map: 4
  filter: 5
  filter: 6
  map: 6

result: [20, 40, 60]

Six operations, no intermediate arrays, behaviour identical to Rust. No library, no generator wrapper, no LazySeq class.

The critical character is .values(). Calling .filter() directly on the Array still hits Array.prototype.filter — eager, the Section 1 behaviour. Hopping to .values() hands you a native Iterator, and from that point everything in the chain is Iterator.prototype and lazy. One method call's worth of difference, opposite semantics.

Runtime support: Chrome 122+ (March 2024), Firefox 131+ (October 2024), Safari 18.4+ (March 2025), Node 22+. Solid on every actively-developed JavaScript engine.

This collapses the headline question of the post. JS still has eager array methods by default, but a single .values() call gets you Rust-like lazy iteration natively. The gap between "lazy by default" (Rust) and "lazy on demand" (JS) is now one method call wide.

5. Pre-ES2025: `lazy.js` as Fallback

lazy.js wraps the generator pattern in a fluent API that looks exactly like native array methods. It was the canonical answer before Iterator Helpers shipped, and it's still the right call if you need to support pre-2024 browsers or Node <22.

import Lazy from 'lazy.js';

const data = Array.from({ length: 10 }, (_, i) => i + 1);

const result = Lazy(data)
  .filter(x => x % 2 === 0)
  .map(x => x * 10)
  .take(3)
  .toArray();

console.log(result); // [20, 40, 60]

That's the whole thing. The chain reads identically to native array methods, but nothing is evaluated until .toArray() is called — and it stops as soon as take(3) is satisfied. Six operations, no intermediate arrays allocated.

How it works under the hood — if you're curious what the library is doing internally, it's essentially this pattern:

class LazySeq<T> {
  constructor(private source: Iterable<T>) {}

  filter(predicate: (x: T) => boolean): LazySeq<T> {
    const source = this.source;
    return new LazySeq(
      (function* () {
        for (const x of source) {
          if (predicate(x)) yield x;
        }
      })()
    );
  }

  map<U>(fn: (x: T) => U): LazySeq<U> {
    const source = this.source;
    return new LazySeq(
      (function* () {
        for (const x of source) {
          yield fn(x);
        }
      })()
    );
  }

  take(n: number): T[] {
    const result: T[] = [];
    for (const x of this.source) {
      result.push(x);
      if (result.length === n) break;
    }
    return result;
  }
}

Each adapter method returns a new LazySeq wrapping a generator — nothing runs yet. Only when take() iterates the chain does each element flow through the pipeline one at a time. You don't need to build this yourself — neither lazy.js nor the native Iterator Helpers — it's here to show what's happening inside both.

6. Summary: Eager vs Lazy in JS/TS

Approach	Syntax	Lazy	No intermediate arrays	Available
Native array methods	✓ fluent	✗	✗	always
Manual `for` loop	verbose	✓	✓	always
Generator functions	awkward chaining	✓	✓	always
`.values()` + Iterator Helpers	✓ fluent	✓	✓	ES2025
`lazy.js`	✓ fluent	✓	✓	always (library)

For small arrays, native eager array methods are fine — the overhead is negligible and the readability is excellent. For large datasets where you're filtering down to a small result set, prepend .values() to your chain and you're on the lazy Iterator path with no library or refactor cost. Reach for lazy.js only if you're stuck supporting pre-ES2025 runtimes.

How This Compares to Rust

In Rust, laziness is the default. Every iterator adapter is lazy out of the box — you don't need a wrapper class, generators, or a .values() hop. The compiler also collapses the entire chain into a single loop at compile time, as we showed with cargo-show-asm in part 1.

In modern JavaScript, eagerness is the default on arrays, but laziness is a single method call away. array.values() returns a native Iterator, and from there the chain runs on Iterator.prototype — lazy, no intermediate arrays, behaviour identical to Rust. The gap that this post was originally written to describe — "JS has no native lazy iterators" — closed when Iterator Helpers shipped in ES2025.

Two real differences remain. First, JS still defaults to eager when you call .filter() directly on an Array; you opt into laziness with .values(). Rust never has that choice — it's iterators all the way down. Second, Rust's compiler can collapse the chain into a single loop with no allocation; JS engines still pay for the Iterator object per chain. The semantic gap is closed. The cost-model gap is narrower than it was, but not zero.

The practical takeaway: if you reach for .filter().map().take() on a large array in modern JS, prepend .values(). You'll thank yourself the first time the array has a million elements.

From the author — Kurippa: a keyboard-first clipboard manager for macOS.

Tauri Cold Launch Was ~1s. Here's How I Got It to Feel Instant.

tinyforge — Tue, 12 May 2026 03:05:02 +0000

Originally posted on tinyforge.store.

When I started building Kurippa — a keyboard-first clipboard manager for macOS — I ran into something that bothered me more than any bug.

The app worked. The UI looked exactly how I wanted. But every time I summoned it with a hotkey, there was a noticeable pause before the window appeared. Not a crash. Not an error. Just... a moment of nothing.

For a clipboard manager, that pause kills the whole point. You're mid-flow, you hit the shortcut, and instead of instant access you're waiting. The friction is small but constant.

This post is about understanding why that happens, what the alternative looks like, and how I solved it without abandoning the web UI stack I'd already built.

1. The Tradeoff: Web UI vs Native UI

Tauri lets you build desktop apps with a web frontend — HTML, CSS, React, whatever you like — rendered inside a native WebKit webview. The upside is enormous: you get the full expressiveness of the web platform. Animations, complex layouts, design systems, component libraries — all of it works.

The cost is that a webview is not a lightweight thing. When your app window opens, Tauri needs to:

Spawn the WebKit XPC helper processes
Load your HTML/JS bundle
Execute your React (or equivalent) code
Paint the first frame

On macOS, a cold Tauri launch takes roughly ~1 second to reach a fully painted window. For a menu-bar or hotkey-triggered utility that should feel instant, this is a real problem.

Native UI frameworks don't have this cost. A SwiftUI window renders directly with system primitives — no webview, no JS runtime, no bundle parsing. The tradeoff is that you're working with a more constrained toolkit.

Let's make that concrete with numbers.

2. Baseline: Tauri vs SwiftUI

To isolate the startup cost, I built the same minimal app in both: a floating window with a search field and a list of 10 static items. Nothing fancy — just enough UI to be representative.

SwiftUI — minimal list window

import SwiftUI

@main
struct NativeListApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

struct ContentView: View {
    @State private var query = ""

    let items = (1...10).map { "Item \($0)" }

    var filtered: [String] {
        query.isEmpty ? items : items.filter { $0.localizedCaseInsensitiveContains(query) }
    }

    var body: some View {
        VStack(spacing: 0) {
            TextField("Search...", text: $query)
                .textFieldStyle(.roundedBorder)
                .padding(10)

            List(filtered, id: \.self) { item in
                Text(item)
            }
        }
        .frame(width: 320, height: 400)
    }
}

Tauri + React — equivalent minimal list window

// src-tauri/src/main.rs
fn main() {
    tauri::Builder::default()
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

// src/App.tsx
import { useState } from "react";

const ITEMS = Array.from({ length: 10 }, (_, i) => `Item ${i + 1}`);

export default function App() {
  const [query, setQuery] = useState("");

  const filtered = query
    ? ITEMS.filter((item) =>
        item.toLowerCase().includes(query.toLowerCase())
      )
    : ITEMS;

  return (
    <div style={{ width: 320, height: 400, display: "flex", flexDirection: "column" }}>
      <input
        type="text"
        placeholder="Search..."
        value={query}
        onChange={(e) => setQuery(e.target.value)}
        style={{ margin: 10, padding: "6px 10px", borderRadius: 6, border: "1px solid #ccc" }}
      />
      <ul style={{ flex: 1, overflowY: "auto", margin: 0, padding: 0, listStyle: "none" }}>
        {filtered.map((item) => (
          <li key={item} style={{ padding: "8px 16px", borderBottom: "1px solid #eee" }}>
            {item}
          </li>
        ))}
      </ul>
    </div>
  );
}

Results

Metric	SwiftUI (native)	Tauri (Rust + WebKit)
Cold launch (binary → window visible)	~1 s	~1 s
Idle RSS — main process	63 MB	81 MB
Idle RSS — incl. WebKit XPC helpers	63 MB	~159 MB across 4 processes
Binary size	~50 KB Mach-O	8.1 MB
`.app` bundle	n/a (raw binary)	8.2 MB
DMG	n/a	2.9 MB

Cold launch times look similar at this resolution. But memory tells a different story: Tauri spins up 4 separate processes — main + GPU + WebContent + Networking — totalling ~159 MB at idle, versus SwiftUI's single 63 MB process. For a utility that stays resident in the background all day, this gap matters.

More importantly, cold launch isn't the real bottleneck for a hotkey app. The next section is.

3. Why the Warm Show Is Still Slow

For a clipboard manager, the app is always running — you invoke it dozens of times a day with a hotkey. What matters isn't cold launch, it's how fast the window appears on each invocation.

The naive approach is to destroy the window on dismiss and recreate it on each hotkey press. This triggers the full webview spin-up every time: WebKit process init, React mount, first paint. The cold path costs ~225 ms just to reach setup, plus React mount and first paint — roughly ~1 s to fully painted, and 50,000× slower in raw API time than what's possible.

For something that should feel like flipping a switch, this is the problem to solve.

4. The Pre-Warm Technique

The fix is to never destroy the window. Instead of tearing down the webview on dismiss, intercept the close event, cancel it, and call hide(). The webview process stays alive. The React tree stays mounted. The DOM is preserved in memory.

When the hotkey fires, show() + set_focus() is all you need — the window server just makes the existing NSWindow visible again. No rebuild, no React remount, no WebKit spin-up.

// src-tauri/src/lib.rs
use tauri::{Manager, WindowEvent};

fn main() {
    tauri::Builder::default()
        .setup(|app| {
            let window = app.get_webview_window("main").unwrap();

            window.on_window_event(move |event| {
                if let WindowEvent::CloseRequested { api, .. } = event {
                    // Intercept close — hide instead of destroy
                    api.prevent_close();
                    window.hide().unwrap();
                }
            });

            Ok(())
        })
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

This is exactly what Kurippa does. When the user clicks the red traffic-light button, the window disappears — but the webview stays warm in the background, ready to reappear instantly.

5. Pre-Warm Results

Path	API call duration	User-perceived delay
Cold launch (process start → first paint)	n/a	~225 ms to setup, ~1 s fully painted
`window.hide()`	~7 µs	instant
`window.show()` + `set_focus()` (prewarmed)	~15–18 µs	instant

The show() call returns in microseconds — it's just an IPC message to the macOS window server saying "unhide this NSWindow." The WebView, React tree, and DOM never tear down; they're paused in memory and resume immediately.

The remaining user-perceived delay on a prewarmed show is dominated by the macOS window fade animation — a few tens of milliseconds, not Tauri or React at all. For a hotkey popup, this is well under a single frame at 60 Hz.

To put the before/after in perspective: the cold path is roughly 50,000× slower in raw API time than a prewarmed show. In user-perceived terms it's closer to 10–50×, but either way — the difference is the difference between "instant" and "noticeable."

6. Tradeoffs

Pre-warming isn't free. Know what you're accepting:

Memory cost is permanent. The ~159 MB RSS stays resident even when the window is "closed." For a hotkey launcher that runs all day, this is acceptable. For a heavyweight app the user opens occasionally, it would be wasteful.

No automatic state reset. Closing no longer clears form input or scroll position — you'll need to handle that explicitly in your hide logic if your UX requires it.

Background CPU. A hidden WebView with active timers or animations still runs them. If your React tree has any setInterval or requestAnimationFrame loops, gate them on a visibility flag.

For reference, the SwiftUI equivalent is NSWindow.orderOut(nil) / makeKeyAndOrderFront(nil) — same idea, same microsecond-level API cost, but from a ~63 MB memory baseline instead of ~159 MB.

Takeaway

Tauri's cold launch cost is real — ~1 s to a fully painted window, ~159 MB of resident processes. But for long-running hotkey utilities, cold launch is the wrong metric. Pre-warming the webview by intercepting close and calling hide() brings invocation latency down to ~15 µs in API time — effectively instant to the user, with the only cost being memory that stays warm in the background.

Forem: tinyforge

Rust's Iterators Are Lazy — Proven With Logs

1. The Default: Eager Evaluation

Output

2. Can You Do Better With a Plain Loop?

Output

3. Lazy Evaluation in TypeScript — Generator-Based

Output

4. Modern JS: Iterator Helpers (ES2025)

Output

5. Pre-ES2025: lazy.js as Fallback

6. Summary: Eager vs Lazy in JS/TS

How This Compares to Rust

Tauri Cold Launch Was ~1s. Here's How I Got It to Feel Instant.

1. The Tradeoff: Web UI vs Native UI

2. Baseline: Tauri vs SwiftUI

SwiftUI — minimal list window

Tauri + React — equivalent minimal list window

Results

3. Why the Warm Show Is Still Slow

4. The Pre-Warm Technique

5. Pre-Warm Results

6. Tradeoffs

Takeaway

5. Pre-ES2025: `lazy.js` as Fallback