Standalone vdom from hyperapp

[arturi]

I was wondering if there is a way to just use the vdom of hyperapp, with lifecycle hooks, but without state management and router? Could vdom become a separate file that I can require const vdom = require('hyperapp/vdom') and use like this (roughly)?

It could be a separate package (which you probably don’t want to do), or it could be just a module inside hyperapp that could be used standalone. Basically, I want something as simple, friendly and low-level as yo-yo, but with vdom and useful lifecycle hooks.

[jorgebucaran]

@arturi This is a reasonable suggestion and could be implemented in the future! It might need some refactoring, but I don't see any big issue with this.

Now, the reason this is/was not provided out of the box is because IMO, there are already plenty of standalone vdom engines out there, virtual-dom, morphodom, snabbdom, domvm, etc. The value of hyperapp is in the whole package.

Put a different way, hyperapp is a not a vdom engine. It includes one out of the box, but that's a technical detail. If you look at the git history you'll find how we went from virtual-dom to morphodom and then to snabbdom and finally the current implementation.

See the initial commit.

[arturi]

If you look at the git history you'll find how we went from virtual-dom to morphodom and then to snabbdom and finally the current implementation.

Right, but you did that for a reason? :) I think your vdom solution might be lighter and more robust with time. Can you recommend something as light, with lifecycle hooks? With virtual-dom, for example, I remember having SVG issues when used with hyperx (which I think were resolved later). And it doesn’t offer lifecycle hooks, or I am not seeing them?

[jorgebucaran]

Right, but you did that for a reason?

Yes, I wanted a no-dependency, light and fast vdom engine.

• Virtual-dom development is slow.
• Morphodom's most attractive feature (diffing native DOM elements) is slow and still comes with a bunch of deps that could be spared. Why?
• Snabbdom is the fastest on this list, but it's too big. The API is also non-standard (it uses its own h vnode factory function which is incompatible with hyperscript). For that reason, you need a function that can translate Snabbdom's h to a Hyperx/JSX compatible function. I even published hyperx-to-snabbdom and used it for a while.

Can you recommend something as light, with lifecycle hooks?

@leeoniya's domvm is fast and has a rich lifecycle hook system.

[leeoniya]

@jbucaran thanks for the mention :)

domvm's hyperscript factories are also non-standard, since they support more features than possible with JSX. you could probably create a JSX adapter if you're willing to give up a bunch of niceties. i'm not a fan of JSX or requiring users to set up node/babel, an IDE and other tooling to use domvm. the goal is to be 100% usable with plain js and a <script> include, like good ole jQuery ;)

for posterity, i suppose: https://github.com/leeoniya/domvm

some other worthy mentions:

https://github.com/AFASSoftware/maquette
https://github.com/thysultan/dio.js
https://github.com/pakastin/redom
https://github.com/lhorie/mithril.js

[jorgebucaran]

Going to close here as I don't plan releasing hyperapp's vdom engine as a separate module.

[arturi]

All right, thanks! But what about exposing those methods at some point? :)

[jorgebucaran]

You mean patch? Closing here means this will not be happening soon, but depending on how the project evolves it's a possibility.

There are already a lot of modules out there for DIY framework enthusiasts (that's a thing? :P). At the moment, I'd like to concentrate on making hyperapp useful and create a lot of practical examples!

If you've built anything with hyperapp, please share it too.

[arturi]

You mean patch? Closing here means this will not be happening soon, but depending on how the project evolves it's a possibility.
I'd like to concentrate on making hyperapp useful and create a lot of practical examples

Yes. Ok, fair enough :) I understand, it makes sense.

So far I’ve re-built my static file admin interface with markdown preview, from choo to hyperapp (out of curiosity): https://github.com/arturi/tent/blob/hyperapp/index.js. Will post if I build something else :)

[jorgebucaran]

@arturi Try to update to 0.7.1 reducers/effects -> actions to see if everything's still okay 🙏.

[arturi]

I will, was very excited about that change.

[arturi]

Try to update to 0.7.1 reducers/effects -> actions to see if everything's still okay 🙏

Done: arturi/tent@1594e04

Broke my head a little, was throwing errors like b[a] is not a function when I kept the old way of doing subscriptions, i.e. object vs array. Then nothing showed up in my view, because onupdate is now onUpdate 😆

Changed things around, works now ✨ Changelog with API changes would help, maybe its here somewhere?

[jorgebucaran]

when I kept the old way of doing subscriptions, i.e. object vs array.

Funny you mention that; there has not been any changes in the subscriptions API since like 0.0.2 or something.

Changelog with API changes would help, maybe its here somewhere?

Release notes, but there aren't any for 0.7.0 0.7.1. The only API change was reducers/effects are now actions.

The API docs are up to date, tho.

EDIT:

Then nothing showed up in my view, because onupdate is now onUpdate 😆

Ah, yes, oops. 🙇
/cc @farism's fault 😛

[arturi]

I upgraded from version 6 and I’ve successfully used subscriptions as an object there, don’t know :)

[jorgebucaran]

Hmm, maybe the way in which subscriptions was iterated changed. I think we are using a for loop now, which means they must be an array. Bummer.

Still, it doesn't make sense to use named subs in hyperapp since they are separated from actions and you can't call them by name anyway. 😅

[arturi]

Yeah, not complaining much about that, just noticed :)

Still, it doesn't make sense to use named subs in hyperapp

Mostly did that for structure/code comments to understand what that subscription does, sort of.