[Proposal] Snabbdom V2

[caridy]

Snabbdom V2

This issue is a placeholder for some discussions about snabbdom v2.

Goals

1. 20% perf improvement on the most common cases.
2. 30% size reduction of the core library.
3. Provide extension point for custom comparison of vnodes.
4. Provide a way to normalize children collection in modules.
5. Clear separation between helpers and core lib.
6. Formalize hooks and modules workflow for the different type of vnodes.
7. Preserve module's API for backward compatibility.
8. Make shadowDOM and Fragments first class citizens to support web components.
9. Eliminate the ambiguious double exports.

Other changes

• No more dist/ folder, users of this low-level library, users of it can bundle it at their will.
• Perf infrastructure to measure incremental changes.
• Improve test infrastructure.
• Improve the overall contributing experience.

Details

1. Perf Improvements

• Reduce string manipulation and string comparison during the critical path.
• Reduce the amount of branches during the critical path.
• Off-load part of the heavy lifting (vnode normalization) to the vnode creation.
• Reduce type cohertion.

2. Size Reduction

• Core lib does not need to know about the DOM or Elements at all.
• Patch API reduced to only deal with normalized vnodes.
• Eliminate unnecessary abstractions.

3. Custom Comparison

Using key and sel as a way to determine whether or not two vnodes are alike can still cover a lot of ground, but in some cases, users might want to apply a more restrictive mechanism to avoid recycling old vnodes. We should provide a way to define such comparison as an extension point.

4. Children collection could be normalized by modules

As today, the children reference is stored before invoking update or create hook, this makes it difficult for modules to do any kind of slotting or normalization of children without mutating the original children array, which is not ideal and goes against the principle of snabbdom of never mutating objects that it doesn't own.

A possible solution is to only extract the children value of the vnode after all modules are done with the update or create process.

5. Core vs Helpers vs Modules

This project contains the "core lib" whos job is to diff and patch, it also contains a default set of modules that covers most common cases for a DOM Element patching, and a set of helpers to pave the way for users to adopt snabbdom for the Web. This separation is not clear today, and should be very explicit in the next version. The proposed separation is:

• Helpers: attachto, h, thunk, tovnode
• Modules: same as today
• Core: snabbdom plus the types defined in hooks and vnode

Additionally, I believe htmldomapi should be a helper too, and should be a required argument of the init method to keep the separation clear, while snabbdom can focused on the critical path only.

6. Formalizing workflow

As today, there are some arbitrary conditions to call certain hooks for certain types of vnodes, or certain type of data, these conditions seems arbitrary to the best of my knowledge, and I will like to formalize them. E.g.: vnodes with only a text will never go thru the create/destroy hooks. In some other cases, vnodes without data are not good for create/update.

[katyo]

I suggest introduce similar DOM APIs for modules too. For example, attributesapi for attributes module, styleapi for style module and so on.

[staltz]

Good ideas, I support this.

[caridy]

@katyo I'm not proposing any changes on the modules, h, toVNode or thunk at the moment, only few more APIs on htmldomapi to support fragments, and few changes in the signature of the initialization. The rest is just moving things around.

We should also discuss how to approach the process of introducing v2, and the branch strategy in case we need/want to patch v1 in the future.

[staltz]

We should also discuss how to approach the process of introducing v2, and the branch strategy in case we need/want to patch v1 in the future.

I'd actually recommend making a new package, either snabbdom2 or another name ("snapdom"? ""quickdom"? ...).

[paldepind]

Definitely lots of good ideas 👍 Related to the point about better test infrastructure I'd like to mention that having CI would be really nice.

I'd actually recommend making a new package, either snabbdom2 or another name ("snapdom"? ""quickdom"? ...).

As in a new npm package? That sounds like something that would be a source of confusing to me. If necessary we could have a branch for the old version and also release patches to that version on npm.

[diervo]

@paldepind We plan to push the v2 with CI and perf runner included :)

[JSteunou]

@caridy can I propose an improvement for the eventListener module? Listening events on body by default and maintain an internal map of listeners in order to do global event delegation like React does.

[caridy]

@JSteunou yes, but I will recommend to be caution because that doesn't work with shadow DOM and some custom events, and probably mislead users. The alternative is always to have a new npm package that provides a replacement/alternative of the module provided by this project, and we can probably start listing 3rd party modules in the README.

[kuraga]

I suggest introduce similar DOM APIs for modules too. For example, attributesapi for attributes module, styleapi for style module and so on.

@katyo , good day. I've thought the same and even liked this with 👍 .

But I have a new thought now: all Snabbdom is strongly DOM-oriented and DOM-specific. See: whole attributes module should be "interfaced" in this case. Even xlinkNS value. Or here.

Now I have a new thought: even remove htmldomapi! :)

[kuraga]

On children normalization, see also: #362 (comment)