About maintaining

[kuraga]

Good day, @Matt-Esch , @Raynos , @neonstalwart !

There are no significant changes in half of year in this repo. I know that you don't have time :smile: but I see there are many issues, pull requests, ideas, etc.!

You've doing an excellent work! People use virtual-dom and we can't stop!!! Which kind of help is appreciated in this situation? We have to do something! :smile:

UPDATE: About maintaining: first of all (I think) we have to label each issue (question/feature request/bug) and pull request (bugfix/feature). And then close duplicates...

[Zolmeister]

@Matt-Esch if you need me I'd be glad to help

[Matt-Esch]

Yep, I'm super busy these days.

So firstly I believe that feature completeness is a thing and I consider virtual-dom feature complete. A lot of open source modules and languages go through continuous feature additions which are mostly unnecessary. If there is a feature request that can't be implemented outside of virtual-dom then it is worth considering an addition if there is enough support for it. Virtual-dom was deliberately designed without browser-specific features so that user land could build on top of it and so that the scope would be bounded. It serves as a reference implementation for would-be performance pushers.

For some reason there is this opinion in opensource that if you're not actively working on new features then the project is no good. I firmly disagree with this and think it's about time open source focussed on module stability over hapless feature pushing.

That said, I'm going to try to block out some time (in a week or two) to clean up what is left in the issues and then consider what to do about long-term development and maintenance. There's a good chance I will move this project under a different account for long term maintenance, but we shall see.

[kuraga]

@Matt-Esch Firstly, great thanks about response!

Secondly I agree with your position.

Thirdly, however, feature completeness doesn't include bug fixes, documentation correction. And I think, it doesn't include dependencies updating and re-thinking if feature is complete, sometimes. Let's say that's mantaining...

[Zolmeister]

@Matt-Esch There is one feature that I think would have a significant impact, partial subtree diffs, see https://github.com/Matt-Esch/virtual-dom/issues/304#issuecomment-164554945

[serapath]

+1 :yum:

[stevenvachon]

inferno is a lot faster than this library.

[kuraga]

(UPDATED) @stevenvachon, yes (see my comment below).

One note only: benchmark inserts or removes nodes every time and then update. So, it moves many nodes. In this case you should use key option of virtual-dom for efficient. Benchmark doesn't use it.

[kuraga]

About maintaining: first of all (I think) we have to label each issue (question/feature request/bug) and pull request (bugfix/feature). And then close duplicates...

[stevenvachon]

@kuraga check out inferno's "perf-spike" branch for the most recent code that they'll soon be releasing.

[kuraga]

@stevenvachon I see. I said it is 2x faster than virtual-dom on real app since you you use default mechanisms.

According to http://vdom-benchmark.github.io/vdom-benchmark/ Vidom is the fastest.

[stevenvachon]

@kuraga yeah no, inferno is faster across the board, and that's with its older version too. "Snabbdom", however, appeared 50/50 or so to me, but went with inferno because its API involves simple objects instead of functions.

[kuraga]

As I investigated, these packages apply changes to DOM during diffing process, while virtual-dom collect vDOM structures during diffing and then re-render the tree applying vDOM.

Inferno, additionally, produces static content parts which are never diffed. Vidom has some other optimizations.

[1], [2]

[ghost]

@Zolmeister @serapath This project doesn't seem to be maintained. If you are interested in vdom, I'm working on a different project. Drop me an email if you want to join forces!