v5 is coming, here what's changing

[WebReflection]

The next version of uhtml goal is to simplify even more the DX around it:

• htmlFor and svgFor are gone ... the key special attribute will work just like in React:
  • there is no need to manually provide a weak key reference, the template / node is the reference per each keyed list
  • multiple lists can have same keys, these will still be unique nodes per key
  • keys work only for outer components ... it's OKish to use a key within a fragment but it's not fully tested
  • keys free themselves when no list hold keys anymore ... again, just pretty-much like in React
• the node export is no-more needed ... if you render, it returns a Hole, if you don't render, it returns a node or fragment out of the box, making code even more portable across different situations
• the render always needs a function to satisfy above DX
• attributes and differ or text differ can be fully customized, it's deadly easy to add your own attribute implementation
• attributes are just data, aria and shortcuts such as ?, @, . but no other special attributes are provided .. bring your own ref or your own whatever, all attributes are handled like regular attributes with no magic attached unless you decide to have magic
• creating your own tags to provide your own things has been core-focus and simplified a lot so that you could compete with uhtml itself by using uhtml tag special export (examples to be written)
• performance are slightly worse than before but still blazing fast ... there's no way I can compete with explicit things (such as htmlFor) but those explicit things are a headache to remember or deal with ... so I chose DX over split-hair-like performance gains
• memory is also still light but higher than before ... not too bad considering uhtml v4 is likely the lightest, in terms of Memory, across the board
• metrics such as first paint are same or reduced, a win for fully runtime based sites
• removal of nodes is slower (not that much) but still the reason uhtml v5 won't be faster ... the removal of nodes is now always correct, as opposite of being optimistic, so that less errors should happen in most convoluted scenario and once again, performance overall are still top-class
• the Fragment has been rewritten and the udomdiff variant should also grant less surprises in case obtrusive 3rd party scripts do weird things with nodes ... moving or removing these nodes won't cause issues anymore. This need more testing and probably it won't land on udomdiff because I am looking forward to have moveBefore proposal implemented by browsers and there I need a parentNode to work with ... so it's going to be epic anyway, but right now the differ is internal (still based on exact same udomdiff logic)
• the overall size is around 2900 bytes (that is less than 3KB) once compressed, so its final size is also smaller than before
• the TS story has been improved but that's not final as I think I did overkill there for no gain

preview

import { render, html, svg } from 'uhtml';

// a one-off node
const div = html`<div />`;

// a rendered list with keyed nodes
render(document.body, () => html`
  <ul>
    ${data.map((value, i)=> html`
      <li key=${i}>${value}</li>
    `)}
  <ul>
`);

In terms of declarative-aproach, the key is a wonder but it's also rarely needed ... if you need a key use it, if you ar enot sure, don't use it.

Last, but not least, v5 provides a better core to eventually finalize hydration, as v4 has never been a good core to do so. I won't promise hydration or a proper SSR story out of the box but it will, eventually, land in here.

This is probably my last iteration over this library as I think I can't make it more readable, maintainable, still performant, or better, in terms of DX, than current v5 is, still topics like Signals, hydration, ref cna be addressed by its consumers, pushing it further than it's ever been, or I could think about.

Dare playing around with it? In such case https://esm.run/@webreflection/x is your import for the time being, until everything cleaned up further lands in here.

[alsoLut]

This is probably my last iteration over this library

Does this imply the project is entering maintenance mode?

[WebReflection]

@alsoLut not quite ... and also since this post a lot "changed" in the landscape and as I've helped PEP750 tdom project I have more things on the plate, it's just lack of time but I think I won't ever declare uhtml in maintenance mode, all variants and side-projects maybe though ... the latest state that is not standard is @webreflection/x but I need to fix/bring in some hydration that makes sense as opposite of being just slower and bloated than a whole runtime takeover then I should be good to land v5 with all its latest/greatest things

[bcomnes]

Can you add an example of stateful components with signals? Preact uses hooks for signals tied to a specific components (useSignal), and I think you mentioned there was a way to do it but I never figured it out without uland hooks. This is something I never saw clarified in v4.

[WebReflection]

@bcomnes basically the rewrite is gonna bind signals to components (yes, components are coming too!) so that once you have rendered something, you change a signal value, its component will update atomically, nothing else ... deal?

[WebReflection]

in short, a render would be an effect, components within that effect will be sub-effects, signals passed down the pipe that change will update only the related DOM part, the render won't trigger again (as a whole) we should be good there ... right?

[bcomnes]

Sounds awesome! yeah, something along those lines. Basically a way to bind a signal to a component instance once rendered, and that doesn't reset signal state if the component function is called again with new inputs from its parent.

[bcomnes]

the TS story has been improved but that's not final as I think I did overkill there for no gain

This is the story of almost every perfectly fine JS library adding types haha.

[n-ce]

Changelog please?
I'm excited by the amount of dependencies removed, I'd like to update all my components to take advantage of v5

Seeing the updated readme it seems the different ways to write a template has been singularized into one (with signals). I wasn't using signals or the keyed before to keep the bundlesize small, but if they are all one now, I might as well use them.

edit:

woops never mind 😂, I'm staying on 4.7.1 for existing projects.

[WebReflection]

@n-ce I am really bad at releases and this was overly rushed as I have dozen other things to do before going on vacation but the gist/summary is in here: #153

The rest is explained in the README ... basically you don't need to render over and over again when you use components, these are all automatically effected in a scoped effect so if you subscribe to signals these will update atomically when the signal changes too.

That's the main thing, that's the "coolest" variant of this library that makes most sense to me, I hope you'll enjoy your rewrite 👋