Comment by NathanKP | Hacker News Reader

Comment by NathanKP | Hacker News Reader

Parent Full thread

This comment from another HN poster does a good job of describing the difference between components in React and "components" in Ember and Backbone:

https://news.ycombinator.com/item?id=7738511

Long story short, React has a much more graceful system of making the components generalized instead of the adhoc system that Ember and Backbone use.

Ember and Backbone have features that are similar to components, but components from two different sources will rarely work well, because often one component will break another. Anyone who has tried to put a bunch of different Backbone views from different people together has probably experienced this pain first hand.

React is designed from the ground up to allow components to work well together.

Can you expand more on what you mean by two Ember components will "break each other"? This isn't something I've experienced when putting components together.

Can you also expand on what React design decisions has made vs. Ember that allow components to work well together? We've spent a lot of time thinking about creating a unified interface for Ember components, so I'd like to better understand where it's broken down for you.

so as i understand, the benefit is that React encourages standard I/O. but i also understand that nothing is stopping anyone from using a standard I/O with Backbone or Ember (which i recognize is why you say "from different people").

my point is that it's a people problem as much as a tooling problem. or is it impossible to build incompatible React views?

i'm currently working on a library that makes it easy to share patches (GUI included) for audio applications. i'm using React. one problem i struggle with is that without my own additional standard, nothing is preventing anyone from making a component that can't patch in. which is the same problem i would have if i were using Backbone.

if you're looking for a "standard" way to share components you need to make assumptions about what type of GUI you are building- not just how you are building it.

Ember already has what you describe as "standard I/O."

Reply on news.ycombinator.com