Hacker News Reader

Comment by Touche | Hacker News Reader

It's too bad that you can't separate virtual dom, the innovative part of React, from the rest of React which has its warts. They should receive credit for coming up with the idea, but there are better, more reactive frameworks using virtual doms now. React shouldn't win simply because they were first and have a big company behind them.

View on HN

You can: https://www.npmjs.com/package/virtual-dom

You should also check out Mithril: https://www.npmjs.com/package/mithril

I'm aware of these. But React gets all of the attention despite its warts like local component state or encouraging singletons for Flux.

You can use Om if you like, right? Or Omniscient. Or Morearty.

Not everyone is ready to go into FP-land right now.

React lets you take these decisions yourself.

Whether local state is practical for your team or not.

You must be living in a very different world than mine if you think that compared to its rivals (Angular, Ember, etc), React is somehow “encouraging” local state. Sure you could go more functional than that, but take a look at the mainstream frameworks and you'll see it's such a long way to go, that had React not allowed local state, it would not have gotten adoption at all.

There are going to be lots of different types of frameworks that encourage different patterns all backed by this concept. I'm not saying React is the worst of the bunch but I also don't think it's clearly the best.

All I'm saying is that when people praise React I wish they were really praising what you call "declarative component model".

React is receiving 100% of the attention in this space when imo it should be receiving about 75%.

>All I'm saying is that when people praise React I wish they were really praising what you call "declarative component model".

I long for time when these concepts are boring enough no one thinks of React anymore. Sadly we're not there yet.

Yeah, I'm pretty sure it should at least be about 76%.

Agree that singletons for Flux are bad, but they're totally not necessary (e.g. https://github.com/acdlite/flummox). And if you don't like Flux, don't use it. I don't see how that's can be a demerit against React, since they're completely separate things.

React doesn't have a good pattern for passing information up the tree other than Flux. Prior to Flux they told everyone to pass functions through props which is fine up until a certain point but it doesn't scale to large apps. Flux does solve it, and is a generally good idea, but the singleton pattern breaks when applied to the server.

Ah, I see. I don't really agree, because I think the enforced unidirectional data flow is one of the best parts of React, but that's certainly a valid point of view.

I just want to emphasize again that Flux is entirely possible without singletons, and works just as well on the server if you create new instances for every request. Flummox does it, Fluxible does it (at least for stores). It's just a shame Facebook pushed singletons and then everyone followed their lead.

Honestly I think FB put the flux pattern out before that idea had become fully developed looking for feedback from the community. The flux repo explicitly states that none of the examples are used by facebook or even resemble facebook (client-side) code. The dispatcher, which was released months after they announced flux, is the only component in the flux they admit to using. Immediately after it's release (even before the dispatcher) we began writing client-side javascript code based on arbitrary examples meant to demonstrate a concept.

I also think flux's real-world implementation came from the necessity to build React components within pre-built apps, where they simply didn't have the ability to pass down props because they had to create complete separate components.

passing functions through props scales up to large apps fantastically better than any other not-React based approach I've ever used. I've done it.

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.

Ractive also uses a virtual DOM. http://www.ractivejs.org/ I found the blog pretty useful for comparing to React: http://blog.ractivejs.org/posts/whats-the-difference-between...

Virtual DOM is an implementation detail of React for web.

Its true innovation is its declarative component model.

You are missing the point of React.

https://medium.com/@dan_abramov/youre-missing-the-point-of-r...

I don't know what you mean by "declarative component model", can you explain?

The mental model is much simpler because your `render` method describes UI at any point of time. Not just the DOM, but your own components too. On the inside, any component can have its own state, but from the outside, it's not visible, and components using it don't care or know about it.

Separating `props` and `state`, component boundaries, lack of two-way binding and predictable top-down data flow make it easy to reason about where any data comes from, and how UI will change over time.

Read this:

http://jlongster.com/Removing-User-Interface-Complexity,-or-...

This is true of all virtual dom libraries. There is no point of two-way binding when you have a virtual dom, and I'm not sure it even makes sense since you have to rerender the tree anyways.

So we agree, you're just separating the concept from the implementation and I'm talking about them as one.

There's a difference between “virtual DOM” and components.

In React, components are not just functions that return their own virtual DOM. AFAIK for many vdom-based libraries this statement wouldn't be true.

React components may have local state (as much as some people hate it, some find it useful), they have a lifecycle, can react to receiving new props with side effects, can implement diff bail-out hook. And you can nest such components declaratively.

The other libraries intentionally left out shouldComponentUpdate because they don't think it's something a developer should have to worry about. I don't know of any evidence to suggest that React is faster because of this feature.

And declarative nesting is a feature of all of the frameworks I've come across, I'm not sure why you think that's unique to React. The advantage feature I would credit React for is the size of its community and influential advocates like you.

>declarative nesting is a feature of all of the frameworks I've come across, I'm not sure why you think that's unique to React

Declarative nesting of lifecycle-ful and stateful components without going full FRP.

I'm actually excited to learn about other frameworks that do this! Which do you have in mind?

WPF (even completely ignoring XAML), JavaFX both support declarative nesting with interesting databinding features to support it. They are based on retained scene graphs, however.

If you are interested in academics, I published such a system at ECOOP in 2006:

http://research.microsoft.com/pubs/179366/mcdirmid06superglu...

The "declarative component model" is not an innovation, it's an obvious approach that has been used for ages when prototyping. You can achieve the same conceptual model of your interface by just generating the entire HTML of the page and rerendering it whenever something changes. This obviously doesn't perform and has some edge cases where it breaks things (textboxes, for example), but the idea is the same as react's components.

FRP is based around the idea of declarative components, but a lot of developers have an aversion to it because of the academic aura around it.

React's innovation is using virtual DOM to make declarative components usable without delving into FRP.

>FRP is based around the idea of declarative components, but a lot of developers have an aversion to it because of the academic aura around it.

Not just that. I may be stupid but personally I find it mentally simpler to `setState` than to `flatMapLatest`. To each their own I suppose.

>React's innovation is using virtual DOM to make declarative components usable without delving into FRP.

Precisely.

>The "declarative component model" is not an innovation, it's an obvious approach [..] can achieve the same [..] by [..] obviously doesn't perform and has some edge cases where it breaks things (textboxes, for example), but the idea is the same

React is not an academic paper, it's a tool. It doesn't need to have new ideas, it needs to execute on them in a practical way. Which it does.

I believe Riot.js provides a lightweight alternative: https://muut.com/riotjs/

Riot.js claims to use virtual DOM whereas, if you look into its source, it doesn't[1] and works with DOM directly.

It really has nothing to do with React's approach, at all.

[1]: https://github.com/muut/riotjs/blob/master/lib/view.js#L75

Reply on news.ycombinator.com