Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And those singletons will bite you hard the moment you try to do server-side rendering because you will now have state shared across sessions.

The approach that raynos/mercury takes where state is fully decoupled from layout/rendering is the way to go. In mercury, all the render functions are composed together to make one large pure function. You give it the current state and it deterministically will always render the same layout. So much better than the react approach. Furthermore, the complete decoupling from the rendering functions and the reliance on using bijective lenses with shallow copying means you get time travel debugging for free (i.e. undo redo is available right out of the box)

https://github.com/Raynos/mercury



I discovered React after using Om, and I believe that Mercury comes with a lot of good practices enabled by default. But it's technically possible to achieve the exact same 'decoupled-state-pure-shallow-etc' using React. It's just not turned on by default and some additional boilerplate is needed, so it's harder to achieve this in React. The only reason I use React instead of Mercury is that React is battle-tested. No amount of testing can replace the real-world situations.I choose a path of higher resistance because I trust React most (due to it's popularity and usage), even though Mercury is better in theory. Ultimately it's a pattern, and that pattern is associated with a level of abstraction over the DOM as well as the way we write code. Mercury and React are two examples of this. I would like to see more competition and libraries to choose from, modular DOM abstractions, with declarative UI's and alternative API's and jsx-esc transforms. That'd be awesome IMO.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: