3 ms·
I don't want to sound snarky (and please don't see it as such), but did you read the readme? I'm not familiar with Mercury, but looking at the code examples, so
by toxmeister 8y ago
I don't want to sound snarky (and please don't see it as such), but did you read the readme? I'm not familiar with Mercury, but looking at the code examples, some obvious differences are:
- hdom does NOT care about state, where it comes from or how you manage it
- hdom uses vanilla arrays(*) instead of `h()` function wrappers, which not just create more legible (IMHO) style, but also open components up for more options in terms of construction/composition and also transformation.
I think that last aspect is seldom talked about in all those discussions and comparisons w/ React & co. Entire 3rd party frameworks are invented & maintained just to provide augmentation, configuration & injection features for React style components, issues which can be much easier solved if your components are in a less abstract & more native data format already. ES6 provides a ton of nice features to construct and transform arrays without any additional support structures. hdom also supports & fully embraces ES6 iterators and the more modern ways of transforming data they support.
There's a blog post about this forthcoming, so apols for not going into more detail here now...
- ricardobeat 8y agoNeither do most of the other libraries care about how you manage state. There are also other libraries that can take arrays/data as input, we ended up with inline functions mostly due to performance. There is no intrinsic advantage to plain arrays other than being serializable without an intermediate step, everything else is the same (jsx pragma and an array-based tree are fully interchangeable since you can easily generate one from the other). Looking forward to that post as I’m always happy to be proven wrong!