1.6.1: Fix property setter cache collisions and further reduce bundle size

[Tao-VanJS]

Hi fellow VanJSers,

I'm happy to announce the release of VanJS 1.6.1. 🎉🎉🎉

1.6.1 was a minor release. In this release, we fixed property-setter cache collisions in tag functions.

When setting a property in a tag function, VanJS looks up the property's setter from the DOM element's prototype chain. To avoid repeating this lookup for every element, previous versions cached the result with the tag and property names as the key—for example, "a,href". The key did not include the element's namespace or actual prototype, so different kinds of elements could collide in the cache.

For example:

const {a} = van.tags
a({href: "https://vanjs.org/"})

const {a: svgA} = van.tags("http://www.w3.org/2000/svg")
svgA({href: "#icon"})

The first call cached the href setter from HTMLAnchorElement under "a,href". The second call could then reuse that setter for an SVG <a> element, where the setter is incompatible with the actual element.

The cache could also become stale when a custom element was registered:

const MyElementTag = van.tags["my-element"]

// No customValue setter exists yet, so its absence was cached.
MyElementTag({customValue: "before registration"})

class MyElement extends HTMLElement {
  get customValue() { return this._customValue }
  set customValue(value) { this._customValue = value }
}
customElements.define("my-element", MyElement)

// The cached result could prevent the newly registered setter from being used.
const dom = MyElementTag({customValue: "after registration"})

The same problem could affect customized built-in elements created with the is option.

The fix keeps the cache for ordinary built-in HTML elements, while resolving the setter from the actual prototype for namespaced elements, autonomous custom elements and customized built-in elements. Thus we preserve the fast path for common HTML tags without applying the cache where the element's prototype can differ.

This is also the first VanJS release driven by AI. I prompted Codex to study VanJS deeply and look specifically for an inherent implementation flaw—not a syntax preference or an issue already surfaced by user feedback, and not to invent a flaw just for the sake of finding one. After it identified these cache collisions, I asked it to explore possible fixes, add regression tests for the failure modes, and verify the tests in a browser.

I then specifically prompted Codex to optimize the bundle size, with the gzipped file as the primary metric. I asked it to search thoroughly for further reductions, while rejecting optimizations that would make the source less readable or the runtime less performant. As a result, despite the bug fix, the final gzipped bundle is still slightly smaller than 1.6.0.

I'm particularly excited about this experiment: instead of merely implementing a predefined change, AI helped discover a subtle issue, reason through the trade-offs, verify the fix and optimize the final result. This feels like a promising new way to evolve a small and carefully designed framework without giving up human judgment over its design choices.

There is no API change in this release.

---

With the bug fix and bundle-size optimizations, the gzipped bundle decreases to 1074 bytes (1.0kB) from 1076 bytes (1.0kB) (2 bytes decrease), while the minified bundle increases to 2083 bytes (2.0kB) from 2066 bytes (2.0kB) (17 bytes increase) - still being the smallest reactive UI framework in the world.

❤️ Hope you can enjoy!