<aside> 🚧 Even though there is a lot of information here, this guide is still incomplete and a work in progress. If you'd like to help out, check out the Contribution Guide to get started!
</aside>
Both React and Ember conceptually can provide the solutions to the same problems. React has historically only been the component layer of applications, but that is changing as React evolves, and gradually adds more features that aim to make developing applications with React more pleasant. Ember offers a bit more out of the box, and aims to have a solution or pattern for most situations – with additional tooling, conventions, architectural patterns. The goal is to abstract away the menial differences between apps and reduce friction when switching projects.
React is only Components
React is mostly components. Interactions with external services such as Redux, GraphQL or Orbit.js happen through components backed by a *Context* which we'll dive into in a bit.
Ember connects to data via Services
Ember has architectural patterns for dealing with specific interactions. Third party services are always interfaced with an Ember Service. Services are used for a lot more than just 3rd party library integrations. A Service is a singleton; it lives for the duration of the application. Ember has object types other than services
Both Ember and React use components as the foundational building block for web apps, and Ember and React components have a lot in common. There are a couple important differences between components in the two frameworks you should know about, though!
<aside> 💡 Before going further, you should familiarize yourself with Ember's Components! Check out the Ember Guides on Components for a deep dive!
</aside>
The first major difference is that React Components can be defined using either JavaScript classes or functions, whereas the equivalents in Ember are class-backed components (which use a JavaScript class) and template-only components (which do not use JavaScript at all). This separation is a reflection of the second major difference between React and Ember components: how the rendered HTML is defined. React components use JSX and Ember uses Templates – sometimes in addition to a backing JavaScript file.
<aside> 💡 Some of the reasons for using a templating language over "just JavaScript"™ are discussed here in this video from ReactiveConf. There are other reasons as well, but they are beyond the scope of this guide.
</aside>
Like React, Ember makes heavy use of ideas from both functional programming and object-oriented programming, though you'll find they show up in different ways!
<aside> 💡 Presentational components only display or format data. They do not have state, do not make requests, and do not cause side-effects within the app without being passed a function to do so.
</aside>
Presentational components are one half of a common design pattern in component-driven interfaces, where behavior is separated from what displays the result of the behavior. These are most commonly referred to as container and presentational components. However, a container component with state does not need to exist in order to use a presentational component. A presentational component could be thought of as a Pure Function in that the output is always the same for any given set of inputs. The presentational component may have logic for controlling what is displayed when, but it does not maintain the state that backs the logic. Icon component libraries, such as those provided by Font Awesome are entirely presentational.
The example below shows a logic-less, presentational component that will be rendered with some static data:
// presentation.jsx
import React from 'react';
​
export function Presentation({ message, response }) {
return (
<>
Obi Wan Kenobi: {message}
General Grievous: {response}
</>
);
}
// invocation.jsx
<Presentation
message={'Hello There!'}
response={'General Kenobi!!'}
/>