Split the repository in two

Brought up in #227, this issue raises the possibility of splitting this repository in two.

In my opinion, Snabbdom is too bloated: my use case requires a custom h function; custom modules; and I have no use for thunks. The core patching algorithm (together with the vnode representation) is the only part of Snabbdom that I try to keep untouched in my own fork (I made some simplifications).

With this, I would like to propose the splitting of this repository in two repositories: something like snabbdom-core, which would mainly contain the core algorithm, possibly with vnode (I’d be okay with removing vnode from it too); and some other repository, say snabbdom-utils or even simply snabbdom, containing the h function, modules, thunks, DOM API, and anything else that might be useful for the “common” users of the library.

What do you guys think?

[TylorS]

I’m not sure of the impacts of splitting diff and patch; it seems to me like it would be a whole different algorithm

I’m pretty sure that splitting the diffing and patching in snabbdom is going to lead to more downsides than upsides. Combining the 2 processes, to my best knowledge, has a lot to do with the performance that snabbdom achieves. A lot of the hook/module behavior is dependent on knowing a lot of information about the process as a whole, and my own investigation to split the 2 usually lead to trade-offs around the types of vNode/module hooks that are achievable. One thing I’ve always loved about snabbdom is its modules and the ability to create very cool things using modules. So personally, I’d be very unexcited to see that behavior change.

[TylorS]

I’d propose using npm scoped packages if this is decided upon. Then the name of this “core” could be @snabbdom/core. It’s a good way to differentiate what are “official” snabbdom packages and which are 3rd party snabbdom-foo.