Make virtual-hyperscript optional about cyclejs HOT 6 CLOSED

Probably will not happen because soon virtual-dom will contain virtual-hyperscript, vtree, vdom, see Matt-Esch/virtual-dom#118.

Also, the string templates will return VTree, and also h() returns VTree. So you don't need to use virtual-hyperscript, but you do need to use VTree which is a core requirement in virtual-dom. If we try to generalize VTree to be replaceable, then we need to lose the dependency on virtual-dom, which probably won't happen.

Also, why would someone want another implementation of virtual-dom?

from cyclejs.

I'm not talking about VTree, I'm talking about virtual-hyperscript, which is bundled in Cycle because of just that one line.

virtual-hyperscript is small, but anyway it increases the size of the application. Today, even if someone wanna use VTree directly they still get their app with all the virtual-hyperscript code.

Also, I may be wrong (I didn't actually read the source) but it seems that the virtual-dom repository will contain virtual-hyperscript, but it will not be automatically bundled in the app by something like browserify if the app code don't actually require('virtual-dom/virtual-hyperscript'), because virtual-dom doesn't depend on virtual-hyperscript; so there is no problem.

About other implementations of virtual-dom, I don't know why would someone use that, this was just a secondary question, but I only thought about it because you said, in your article about MVI (in the section "Renderer separated from View.") that one could play with different implementations -- the same principle applies to Cycle.

from cyclejs.

@staltz

The optimization here is to import vtree/vnode.js directly and create one instead of using h()

This means that browserify cycle | wc -l is significantly smaller.

This optimization may or may not be worthwhile

mercury does not make this optimization and just says "I ship with these 12 modules preloaded and I hope to be <50kb"

from cyclejs.

Ok, I see what you are saying @fiatjaf , and yes it makes sense to replace h() with a simple constructor for VNode in that line of code in therenderEvery that you mentioned. Will do.

But now I remember the real reason why virtual-hyperscript is a dependency. We have a shortcut Cycle.h() which is now the most practical way of making Views. The other alternative is using raw VNode, but it becomes easily unreadable. I don't want to force people to put virtual-hyperscript separately if anyway they will need to have it.

Once there is mustache and other templates in place, maybe also JSX, then we can review this issue again.

from cyclejs.

Also, you are right. I'm seeing that virtual-dom actually exports h in all cases, so there is no way to actually reduce the amount of code here.

from cyclejs.

@fiatjaf there is a way to reduce the amount of code.

Just require('virtual-dom/diff') instead of require('virtual-dom').diff

from cyclejs.