Levels of abstraction

[dakom]

I'm hoping to try hyperHTML for my next work project - possibly pairing it with xstate for state management.

From looking at the ecosystem it seems there are various levels of abstraction:

• core
• element
• component
• neverland
• third party wrappers, etc.

I'm not quite sure which level I want, coming from say React and component trees (last state management I did was w/ Context, plain objects, and lenses - so I don't have a direct modern redux or xstate project to compare with - but I'd imagine "per-component + top-level state" is ultimately the same set of problems for hyperHTML's perspective)

My knee-jerk reaction is to say "Neverland" since it's closest to React w/ hooks, and I love a good pun (Ruufiioooo!!!) - but on the other hand I see TodoMVC which was done a while ago just used the core, and it looks powerful enough...

Any advice both for my specific use case and general explanation to supplement the official docs, on the difference between these, is much appreciated.

Thanks!

[k-j-kleist]

David, It would be extremely interresting to hear about your experiences from HyperHTML and xstate later on. We are using HyperHTML as the view layer for https://github.com/final-form/final-form/ (instead of React), and are planning to migrate our home made joke for a state machine to xstate.

[dakom]

Happy to share once I get there! Tbh I only just looked at xstate recently, never used it before, so it may take a little while to get my bearings and have worthwhile experience to talk about.

But I totally hear you - it looks really exciting! Looking forward to giving it a go and hearing from other people too.

Final Form looks really cool at a glance, and a lot of work no doubt. Good stuff :D Also happy to hear your thoughts on the transition... especially for something big like that, lots of things make sense in toy demos and then break down at scale. Curious to see more reports from products that have real-world usage :)

[WebReflection]

even if coming these days from React the Neverland approach seems to be the best/easiest choice, I must say core, element, and component are the only battle-tested/production ready options I would recommend, 'cause I am using these daily, reaching out ~100M users (ABP Web Extension) so you'd also be on the "fast lane" when it comes to bugs, which luckily aren't many these days (actually 0 known issues).

I am also working on my free time on an augmenter which goal is to make anyone able to create a Neverland like approach, without needing to change the bind/wire nature of the library, the two primitives that are kinda here to stay, since already too valuable to be replaced.

That being said, it always depends on what you need, or what you are trying to create, or if you are trying to migrate.

Custom Elements are an obvious choice if you target modern browsers, but a no-go regardless for those needing Shadow DOM, since the polyfill is heavy and unreliable so it's either natively supported or ... you chose a deadly poison, IMO.

If you are that lucky (i.e. in ABP we use Custom Elements though the DRE polyfill and without Shadow DOM), consider HyperHTMLElement your best option!

If you need SSR though, hyperHTML.Component and its viperHTML.Component counter part are your best pick, because these are thin wrappers for a generic wire and work well through events (props down, events up thing in React works very well there indeed via all little utilities such dispatch and setState plus Component.for(data) simplification).

However, if you simply want to produce SSR compatible layout, using just bind or wire in either client or server would be enough to start playing around without needing to lock-into Component or Custom Elements logic.

I am closing this 'cause it's not really a bug, but I'll be happy to answer more, if necessary.

Have fun with hyperHTML 👋

[WebReflection]

BTW, and for your info, Neverland has been updated to 0.4 which is based on the augmentor and it's been rewritten from the scratch.

It has fixed the only known bug and it's faster and easier than ever, it's also now 1:1 compatible with React hooks, where useEffect with an empty array as guard will trigger automatically effects / cleanup either on Dom node connected, or disconnected, similar to React mount/unmount.

Maybe 0.4 is less a toy and more ready for production than I've though, please let me know if you give it a chance.

[dakom]

Cool! I wish I could have gotten to it this week but just not yet... hoping to play with it soon!

[dakom]

Btw - just to also understand ... what is the advice to understand the equivalent of what I might use Context for in React?

i.e. if I have something like a top-level state management, or several top-level things (like theme, user auth session, etc.) and I want to pass that down to child components?

I think overall what I'm looking for is maybe like a "migration guide" from React to Neverland/Hyper...

[pinguxx]

i talk a bit about state in this blog, https://medium.com/easy-apps-with-hyperhtml/easy-apps-with-hyperhtml-3-fdc3610fd9e3, using hyper.Component, hope that works

[dakom]

Excellent, starting at part 1... :D

[dakom]

Ah... not exactly a migration guide but the side-by-side comparison page is really helpful to put the pieces together