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

One of React's selling points is that it uses a virtual DOM to minimize the amount of manipulations it does to the real DOM - http://facebook.github.io/react/docs/reconciliation.html.

The virtual DOM is an implementation detail (riot could re-render everything on each change), but it's what makes React fast, and good for handling big apps.

I don't think you can call a lib "react-like" if it doesn't have something like the virtual dom diff. You could say it has react-like syntax, maybe.

That said, I have been following riot for a while and I always liked its minimalistic approach. Maybe I will give it another look now that it is 2.0

EDIT: I somehow missed the big subtitle which says "Virtual DOM" on the website. It clearly states that Riot has something similar to React's. I can't explain know how I managed to not see it. Thanks to everyone who called me out.



I agree that calling it "React-like" seems misleading. When I read about a 'x'-like library I expect something that could actually replace 'x' and provide nearly the same features.

Pete Hunt did a great talk on what actually makes React / virtualdom different from other databinding approaches.[1] Using this definition Riot.js looks a lot more like Angular, Ember et al. to me.

[1] https://www.youtube.com/watch?v=-DX3vJiqxm4


Virtual DOM implementation is indeed different.

The biggest reason for calling it "React-like" is the basic idea of components, where related HTML and JS are combined together.

> "Build components, not templates"

http://www.slideshare.net/floydophone/react-preso-v2

I think this is the "what" of React and virtual DOM is the "how".


I don't think of something as React-like just because it puts HTML and JS in the same file or combines HTML tags with blocks of JS code.

The difference between React and other databinding methods is that you can use all JS language features (i.e. if, for, while, .filter(), .map(), libraries like Rx.js, etc.) when defining what you want your DOM to look like.

Suppose I want to have a list of items based on some array, which I want to filter based on some predicate, and display the items differently based on their content type.

In a React render() function I would just use

  filter( (it) => { //some predicate } ) 
to filter unwanted items, and

  map((it) => { switch (it.contentType) { // cases } }) 
to map the individual items to how I want them to look like.

To me it looks like to implement something like this in Riot would require to build / use something that is more like Angular's computed properties.

But I'd like to be proven wrong.


In Riot you need to do following:

<my-tag>

  <div each={ items }>

  </div>

  // use JS to construct items
  this.items = arr.map(fn) // or how you want it
</my-tag>

And you can also manipulate items on every update. I'm sure that at some point there will be a clear use case where React is a better choice.

So far Riot rendering has worked us perfectly.


> I don't think of something as React-like just because it puts HTML and JS in the same file or combines HTML tags with blocks of JS code.

Totally agree. While I do (most of the time) appreciate JSX, it is IMO the least interesting and relevant feature of React. It mostly just lets our company's designers continue to edit view templates that would otherwise be far beyond their training/experience. So that's nice, but it's not what makes React tick.


Riot virtual DOM is a simple expression -> DOM node map. It's much different than what React has.

Riot cannot make random sub-tree replacements. It's best for situations where the tag HTML structure is fixed (no tag name changes for example).

Riot virtual DOM minimizes the work and makes less DOM manipulations than React on each update cycle.

Loops and conditionals can change the structure.


It’s advertised as having a Virtual DOM.


You are right, I will have to investigate more. I don't know how much of react's virtual dom diff can you cram in 2.5kb though :)


Not much. The point is that such heavy diffing can be avoided if loops and conditionals are enough and if you don't need random HTML changes.


Once you have loops, conditionals and recursion, don't you have "random HTML changes"?


Exactly. Loops and conditionals should give you enough power.

But in React you can arbitrarily change HTML because the render method returns a string to be compared to the earlier situation.

A tag name can change for example (which you rarely need).


> But in React you can arbitrarily change HTML because the render method returns a string to be compared to the earlier situation.

I'm pretty sure the render method returns a vdom node (which the library can then diff and merge into the actual DOM)


As a point of reference, virtual-dom is 17k when minified with the same settings and 5.8k when gzipped.

That's starting from the 42k 1.2.0 distfile.


>I don't think you can call a lib "react-like" if it doesn't have something like the virtual dom diff. You could say it has react-like syntax, maybe.

Sorry, I don't follow. The Riot.js project site DOES tout "Virtual DOM" as one of its features.

You say it doesn't actually have that?


I somehow missed that (quite incredible, being one of the main subsections), and I simply assumed that you can't cram something like that in 2.5kb - I apologize.




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

Search: