This isn't quite right. In invalid UTF8, a continuation byte can also emit a replacement char if it's the start of the byte sequence. Eg, `0b01100001 0b10000000 0b01100001` outputs 3 chars: a�a. Whether you're at the beginning of an output char depends on the last 1-3 bytes.

> outputs 3 chars

You mean codepoints or maybe grapheme clusters?

Anyways yeah it’s a little more complicated but the principle of being able to truncate a string without splitting a codepoint in O(1) is still useful

Yah, I was using char interchangeably with code point. I also used byte instead of code unit.

> truncate a string without splitting a codepoint in O(1) is still useful

Agreed!

This is natively supported in Chrome now: https://www.google.com/search?q=chrome+memory+saver

Any chance it was https://pomb.us/build-your-own-react/? You can't really have hooks without building an entire framework, because the framework has to have the preserve the execution context between renderings.

With the number of VPs sending emails, I think it's much larger than "hundreds".

`0.015.toFixed(2) === "0.01"`, and `0.087.toFixed(2) === "0.09"`

At this level of detail it _is_ super misleading however to say "a 10x improvement" whilst in reality it's more like 6x

The engine here are the creates called "turbo-tasks" and "turbo-tasks-*" extend it with more features. See a bit in https://github.com/vercel/turbo/blob/main/architecture.md#tu...

gotcha, cool – thank you!

Documentation here is one of the areas we need to work on. There's a bit in https://github.com/vercel/turbo/blob/main/architecture.md#tu...

A small example of code that uses this is https://github.com/vercel/turbo/blob/main/crates/turbo-tasks..., which defines how we can load a `.env` file using FS read caching, cached `read` and `read_all` functions, etc.

Ah, very helpful/interesting – thank you! Seems neat.

We plan on supporting both. We're still in the alpha phase, and have not designed the plugin API yet.

It's _currently_ Next specific, but we plan on making it generic and usable in any setup.

that's a crucial detail that I did not read in the article. I've seen Next.js mentioned a lot, but havn't gotten to trying it yet. Reading the article I wasn't sure if this meant I would have to adopt Next.js. I definitely suffer from build tool configuration fatigue, so if it had to be through next.js (a new system for me) it's a lot less interesting, for me, in this moment.

Our initial development cycles were dedicated on getting Next working. But we absolutely plan on expanding the to support generic bundling and will include that in the docs.