Perf is somewhat improved in spots, but generally the same otherwise.

Cuts only about 2% of the bundle, but removes a pretty bad pain point in the code. Plus, inserting arbitrary HTML outside a container is usually a recipe for disaster in terms of styling.

It's simpler that way and I don't have to condition it.

It's redundant and has been for ages. A v3 increment gives me the ability to minimize surprise.

…t from the router

People can just use equality and regexps as needed.

Also, rename it `m` to make dev stack traces a little more readable, and remove a useless layer of indirection.

This makes that class fully monomorphic and also a bit safer.

That's not been there for years

The long comment at the top of it explains the motivation.

It's now been made redundant with `m.tracked`.

Dropping a premature abstraction, and I have perf concerns.

This new version should hopefully avoid needing arguments allocation

If you remember v0.2, you'll recognize the API here. Thing is, this tries to be a little more rigorous with it by making it a proper vnode instead of just a magic attribute.

Also, as these are the last remaining magic attributes (and `m.route.link` just returns the needed attributes itself), `m.censor` is gone.

…ix a renderer bug

Part of this meant moving children to an attribute property. I've also added a translation layer of sorts so one can pass them through to DOM vnodes and them "just work", even though the internal structure separates attributes and children.

All in all, this should hopefully result in a lot less memory usage and some faster app load times.

…tory

They weren't actually testing the update flow, only reliably the create flow.

Also, they weren't testing `m.mount`, or `m.redraw` in their totality, which is honestly a very important thing to test.

It shouldn't be testing particular implementation details, just that it works. Also, this one's more likely to exhaustively hit every possibility.

…sed vnodes

Aims to ease discoverability. Plus, it's a bit easier to navigate.

… revise a few more things

Didn't fully think through that experiment of file loading - it doesn't also load Mithril, among other things.

Also, remove some redundant conditionals in `src/core.js`.

- `function foo(...) {...}` to `var foo = (...) => {...}` saved a fair bit of space. I also replaced other ES5 `function` functions with arrow functions where possible.
- I inlined several functions. Turns out Terser wasn't inlining them properly (they were getting nonsensically inlined as IIFEs), and it was causing performance to suffer.
- I dropped the `contenteditable` code, since that was only needed to handle the since-dropped `m.trust`.
- I switched from tag names to type masks. This enabled several optimizations.
    - Size: I switched from a `switch` to function tables for create and update. Now, it just hinges on how well the CPU predicts it, and modern desktop CPUs very much can chase such multi-level indirect branches.
    - Size: I could blend single-key diffs with element and component tag name diffs, for better performance.
    - Performance: By using an expando bit, I've avoided needing to read the current namespace in some pretty hot loops, including in `setAttr`.
    - Performance: In `setAttr` and other places, I've merged as many as 4 tag comparisons to a single bit comparison.
- I truncated the vnode properties to single letters. This resulted in a moderate savings.
- I moved `redraw` to a return value of `m.mount` and also passed it via a context value to components so they can deal with non-global redraws.
- I re-split `m.layout`.

I also swapped out the benchmark library for something I rolled myself, and used that to set up the benchmarks. Benchmark.js isn't maintained anymore, its built-in output wasn't all that great, and it was forcing me to use globals where I otherwise didn't really need to, so I decided to roll some statistics stuff myself and make something simple. And while I was at it, I simplified the benchmark code by a lot.

I also ripped out the select/option Chrome bug workaround - it doesn't seem to replicate anymore. Removing that brought a slight boost to attribute setting performance and enabled me to factor that code out to something a lot simpler.

Try this page for example:

```html
<!doctype html>
<select>
  <option value="foo">Foo</option>
  <option value="bar">Bar</option>
  <option value="baz">Baz</option>
</select>
<script>
var select = document.querySelector("select")

console.log("s", select.selectedIndex, select.value)
select.onchange = select.onclick = select.onblur = () => {
  console.log("c", select.selectedIndex, select.value)
}

var second = select.children[1]
setInterval(() => {
  console.log("i", select.selectedIndex, select.value)
  second.value = "bar"
  console.log("i", select.selectedIndex, select.value)
}, 5000)
</script>
```

…lbacks

Also re-added the `vnode === old` optimization, out of necessity for other utilities (there's a long code comment explaining why).

Before this `m.layout` change, code would've looked like this:

```js
// For libraries that bind state to the element itself
function ThirdParty(attrs, old) {
  return m("div", m.layout((elem, signal) => {
    // Do DOM initialization
    Library.initialize(elem)
    // Schedule DOM cleanup
    signal.onabort = () => Library.dispose(elem)
  }))
}

// For libraries that return an instance
function ThirdParty() {
  return m("div", m.layout((elem, signal) => {
    // Do DOM initialization
    let instance = new Library(elem)
    // Schedule DOM cleanup
    signal.onabort = () => instance.dispose()
  }))
}
```

The problem with this is it makes logic that only needs to care about removal a lot more complicated than it otherwise needs to be. (See `src/std/init.js` for a concrete example of this, and how this change simplifies those use cases a lot.) It also requires not only an extra closure that necessarily has to lay around until removal, but an entire `AbortController`, so this change ultimately saves a little over 200 bytes per layout/remove pair. (If you have a lot of such elements, this could be noticeable.)

After this change, third-party integration code (the other main motivator for `m.layout` in the first place) would look something like this:

```js
// For libraries that bind state to the element itself
function ThirdParty(attrs, old) {
  return m("div", [
    // Do DOM initialization
    !old && m.layout((elem) => Library.initialize(elem)),
    // Schedule DOM cleanup
    m.remove((elem) => Library.dispose(elem)),
  ])
}

// For libraries that return an instance
function ThirdParty() {
  let instance
  return (attrs, old) => m("div", [
    // Do DOM initialization
    !old && m.layout((elem) => instance = new Library(elem)),
    // Schedule DOM cleanup
    m.remove(() => instance.dispose()),
  ])
}
```

It was already possible to initialize an element outside of its scope by saving a reference to it:

```js
function ThirdParty(attrs, old) {
  let label, root
  return [
    label = m("label", "Some text"),
    root = m("div.library"),
    m.layout((elem, signal) => {
      let instance = new Library(root.d, label.d)
      signal.onabort = () => instance.dispose()
    }),
  ]
}
```

This change makes that a little cleaner to wire up:

```js
function ThirdParty() {
  let instance
  return (attrs, old) => {
    let label, root
    return [
      label = m("label", "Some text"),
      root = m("div.library"),
      !old && m.layout(() => instance = new Library(root.d, label.d)),
      m.remove(() => instance.dispose()),
    ]
  }
}
```

It also fits in a JSX world a little more nicely, but this wasn't something I was specifically seeking out:

```jsx
// Old unified
function ThirdParty() {
  return <div>
    {m.layout((elem, signal) => {
      let instance = new Library(elem)
      signal.onabort = () => instance.dispose()
    })}
  </div>
}

// Old split
function ThirdParty(attrs, old) {
  let label, root
  return <>
    {label = <label>Some text</label>}
    {root = <div class="library" />}
    {m.layout((elem, signal) => {
      let instance = new Library(root.d, label.d)
      signal.onabort = () => instance.dispose()
    })}
  </>
}

// New unified
function ThirdParty() {
  let instance
  return (attrs, old) => <div>
    {!old && m.layout((elem) => instance = new Library(elem))}
    {m.remove(() => instance.dispose())}
  </div>
}

// New split
function ThirdParty() {
  let instance
  return (attrs, old) => {
    let label, root
    return <>
      {label = <label>Some text</label>}
      {root = <div class="library" />}
      {!old && m.layout(() => instance = new Library(root.d, label.d))}
      {m.remove(() => instance.dispose())}
    </>
  }
}
```

- Did some baseline optimization to it to reduce overhead and memory requirements. Won't be too much of a deal with smaller apps, but users using a lot of streams will appreciate the reduced overhead.
- Removed the runtime-deprecated `Stream.HALT`.
- Dropped the source list from `Stream.combine` callbacks' operands. It's almost always available in context anyways.

This prepares for future possible render flags, like a "remove on error" flag that might get exposed in the future to enable userland error boundaries.

Proper debouncing and throttling is easy to screw up, and the usual implementations that invoke a provided callback don't compose well. Instead, this provides functions that return promises you can filter on. This is far more composable and far easier to use.

Also, the thing people usually do in a pinch, leading edge throttling, is usually the wrong thing to do. For example, if you're implementing an interactive search, you want the first to go immediately, but still incrementally update while the user is typing.

Also made some small (but needed) changes to the entry points and minified scripts.

No specific tests for the error handling yet aside from the existing error-related tests that needed to change. But here's the going idea: error boundaries can be done in userland. Users would do something like this:

```js
function slurpContext(context) {
    const chain = []
    while (context !== null && context !== Object.prototype) {
        chain.push(context)
        context = Object.getPrototypeOf(context)
    }
    return chain.reduceRight((a, b) => Object.defineProperties(a, Object.getOwnPropertyDescriptors(b)), {})
}

function ErrorBoundary(attrs, _, context) {
    return m("div.boundary", [
        m.layout((dom) => {
            try {
                m.render(dom, m.set(slurpContext(context), attrs.view()), {
                    render: context.render,
                    removeOnThrow: true,
                })
            } catch (e) {
                attrs.onerror(e)
            }
        }),
        m.remove((dom) => m.render(dom, null)),
    ])
}
```

`finally` is apparently really slow. This improved benchmarks by about 3-4x, bringing them back to roughly what they were when I first cut the branch.

This matches HTML more closely, and makes for a much better experience with custom elements.

It's more predictable that way, and I expect this to break approximately nobody. (If anything, it's likely to *unbreak* some users, as they may have been assuming this to have been the case from the beginning.)

…tListener`

Some point along the way, this got erroneously changed and saved.

It's going to unnecessarily complicate the release process, especially now that artifacts aren't saved to the repo anymore.

I clearly didn't check this bit properly

Did some math and some benchmarking and...it's actually a potential perf bottleneck for apps and so I had to optimize it a ton. Also rolled some new benchmarks for it.

Within the hyperscript side, it's a significant (roughly 10%) perf boost.

…FACTORY`

Turns out this was way more perf-sensitive than I initially thought. Also included a long comment to explain everything, as it's not immediately obvious just looking at it that it'd be perf-sensitive.

…ification.

…e `m.use`

`m.use` is specially designed to be used a fair amount, and simulating it is relatively slow, so it's worth making a built-in.

`m.key` -> `m.keyed` provides for a simpler interface, one that you don't have to type `key` out explicitly for anymore. (Most frameworks require you to explicitly add a "key" attribute, while this approaches it more like a glorified `Map`.)

It's very common to want context and not care about attributes. What's *not* common is wanting the old attributes and not the new. So that's what this optimizes for.

… tweak comment

…ion better

It mostly delegates to `fetch`.

Also, kill `m.withProgress` as that only existed because there was no `m.request`.