Proposal: can we transfer snabbdom to Cycle.js org?

Hi @paldepind and contributors,

As many of you know, we (= @TylorS and I) use and depend heavily on snabbdom in http://cycle.js.org. It’s a very handy virtual DOM library that keeps to its promise of being: damn fast, small, with a functional API and decent hook system. Previously, we were using virtual-dom, which was also good, but not as fast, not as small, not so functional API.

However, one of the main reasons why we migrated from virtual-dom to snabbdom is that that library was largely unmaintained. The core authors didn’t have time to merge PRs, manage issues, make new developments. It was rotting, and it was sad. Snabbdom seemed more maintained at that time.

This time, unfortunately, we feel that Snabbdom is rather unmaintained too. Or at least we feel like we could move much faster if Snabbdom as a repository would receive faster issue management and PR merging and authoring, etc. For instance, Tylor forked snabbdom to write https://github.com/TylorS/snabbdom-ts and then again to write https://github.com/TylorS/flow-dom.

So, here’s a proposition: to transfer this snabbdom repo over to the cyclejs org. And to calm the nerves, here are the terms:

• Tylor and I would actively maintain it (meaning: handling issues, PRs, basic janitoring)
• Paldepind would still be the contributor, would still have all the same access rights
• Tylor and I would proceed to make https://github.com/paldepind/snabbdom/issues/150 happen
• Tylor and I would experiment with immutable APIs for snabbdom, like https://github.com/TylorS/flow-dom
• None of the above must drastically affect snabbdom performance or size (unless it’s an improvement)

I can totally understand if you don’t want to do this. In that case, we would fork snabbdom and make a virtual DOM library mostly compatible with snabbdom, but with the changes mentioned above. That would be ok, but it would be, well… a fork. And if the community can avoid a fork, that’s better so there’s less confusion, and less scattering of open source workforce.

What do you think?

[paldepind]

I’ve created the organization and sent out invitations 😄

[paldepind]

I can certainly see where you are coming from. When building a framework such as Cycle it is of course very important that the packages you depend on are reliable so that you’re never stuck because a third party dependency isn’t moving along fast enough. And while I wouldn’t call Snabbdom unmaintaned I am certainly handling the maintenance at a very slow pace. I think that you and @TylorS offering to help maintain Snabbdom is great news for Snabbdom. I hold both of you in high regard and am certain that your contributions would be beneficial to Snabbdom and it’s overall health.

I am happy that Snabbdom is useful to Cycle. I think Cycle is a great framework. When I created Snabbdom my hopes where excactly that people would find it useful for building their own things on top. And several people has done so which is nice. It is important to me that Snabbdom can continue to serve people in this respect. I.e. not only serve Cycle but other users as well. I feel that moving Snabbdom to the Cycle organization might end up implying to some people that Snabbdom is a virtual DOM library just for Cycle. And not an independent virtual DOM library for everyone, whatever you might want to do.

Thus instead of moving Snabbdom to the Cycle org I think it might be a better idea to set up a GitHub organization specifically for Snabbdom. If the respective authors are interested they’d be invited to move their Snabbdom related packages to this organization. For instance @acstll’s snabbdom-to-html, snabbdom-jsx, snabbdom-helpers, babel-snabbdom-jsx, and the other Snabbdom related projects. I, @staltz, @TylorS and the interested related packages owners would be part of this organization and maintain Snabbdom together.

I feel like this would be a great move both for Cycle who can be certain that Snabbdom is timely maintained and for the rest of the Snabbdom users who would still be certain that Snabbdom remains a general purpose virtual DOM library. Additionally it would help me fell less guilty for not dedicating enough time to maintaince 😅

Something completely different: This is the first time I’ve heard about flow-dom. Is there somewhere where I can read more about it?