
Choosing Ember over React in 2016 - jeanlucas
https://blog.instant2fa.com/choosing-ember-over-react-in-2016-41a2e7fd341#.7vyetlgrb
======
jurgenwerk
Ember is a really good choice for running a feature-rich web app where you
want to focus on business and features instead of solving issues about tooling
and deciding on which pieces to bring into the bundle to make everything work.
This is especially crucial for small teams on a budget. Also, upgrading to
newer versions is incredibly easy, deprecations paths are very verbose and
clear. I've been working in Ember for three years, and a few times in between
I jumped into React. I adore React's ideas, and grasping its concepts made me
a better Ember developer. It's just React tooling that's horrible, but I hear
there are great improvements in that area.

~~~
wwalser
I've been keeping an eye out for a project on which to use Ember.
Unfortunately, I've been in that exact mode for literally years. I already
trust that it's solid stuff from having learned a load about software
development from Yehuda back in the jQuery days.

Three or four times I've been about to pull the trigger and every time the
things that's stopped me is that when I go to look for a sample project to
have a read of an actual app using it in anger it seems impossible to find one
that meets my criteria: 1. Uses current version of Ember. 2. Uses idiomatic
ember. 3. Big enough to not be a toy, ember-data, being the recommended way of
doing things, I want to see how it's formatted.

Every time a look it seems like everyone is saying something along the lines
of "Here's a good example project except it's N versions old." or "… except it
doesn't use insert-feature-that-docs-heavily-recommend-using because that
wasn't around when this project started" or "… it uses local storage in place
of a database".

I've read the documentation end to end multiple times over the years. I'm not
sure why that's not enough for me. I just assume I'll run into trouble and I'd
like to see an application with routing, component composition, backend calls,
and understand a bit about the recommended backend before diving in.

~~~
mike1o1
Here are a few open source Ember applications that you might be interested in.

Ghost admin: [https://github.com/TryGhost/Ghost-
Admin](https://github.com/TryGhost/Ghost-Admin)

Hospital Run: [https://github.com/HospitalRun/hospitalrun-
frontend](https://github.com/HospitalRun/hospitalrun-frontend)

Hummingbird: [https://github.com/hummingbird-me/hummingbird-
client](https://github.com/hummingbird-me/hummingbird-client)

~~~
jeanlucas
It helped a lot to see it in action. I got lot of help from the Ember Global
Meetup[1] and live coding with buddies at the Ember Community Slack group.

[1]: [https://www.embermeetup.com/videos](https://www.embermeetup.com/videos)

~~~
misterhtmlcss
@jeanlucas what's the link to that slack group?

------
aarpmcgee
I have a pretty fair amount of experience with both Ember and React (along
with Ember Data, Redux, Redux-Saga, React Native, webpack, etc etc).

My opinion, for whatever it is worth, is that Ember might be good for smaller
companies and smaller codebases. The cognitive overhead of using Ember is
massive for me and several people on my team. I find that I have to store the
contents of many files in my head at once to understand how a given component
is being rendered and how it is receiving its data it requires. Your view code
is implicitly coupled to promises all over the place which can really bite you
in the ass. Mutable APIs abound and it is an extremely unpredictable and
volatile way to develop web applications at our scale.

My personal, largely unfounded belief (based both on intuition and anger from
dealing with Ember) is that the supposed gains from Ember's severe convention-
over-configuration ideology don't pay off nearly as much as is advertised.

I never want to work on an Ember project ever again.

~~~
postcarnival
> at our scale.

Care to elaborate what that scale is? We're using ember for a new app that
expects very large traffic volumes on continual basis with realtime components
etc... I've worked with ember for the past few years and opted to use it but
always interested in hearing other viewpoints esp for "high scale"

~~~
akarambir
Parent may not be talking about scale in terms of Traffic but big project
code-base where you and team have a hard time keeping something in head and
how something is being rendered.

~~~
aarpmcgee
yep, this

------
geebee
Great write up.

It sounds like an interesting but probably relatively common situation these -
relatively experienced developers, but inexperienced where it comes to the
front end, who are accustomed to working in a non-javascript language. In this
case, sounds like it's python.

Sounds like their senior developers, who previously worked in Python, will now
be doing at least 50% of their work in javascript.

If you have to do this, it sounds from this article that Ember is a good way
to go. On a related note: I'm so bummed that this is the trend in languages.
Just so bummed. Python and Ruby are really nice languages. To have to switch
from that to Javascript feels like a big step back in developer happiness.

~~~
tejinderss
There's a hope in webassembly

~~~
lightblade
That'll probably never catch on. Front end dev already have 10 frameworks and
5 browsers to worry about. Let's not add 10 more languages for a total of 500
different combinations.

~~~
scottmf
500 combinations of what? Other platforms too have n languages and n
frameworks and so on. We'll be fine.

I'm quite sure it will catch on with Apple, Google, Mozilla and Microsoft
working on it.

I'm intrigued by the server side Swift frameworks coming out right now. If
they could replace JS on the server _and_ browser that could be interesting.

------
tptacek
I don't think I have a strong opinion about Ember, though you can take the
React rendering model away from me when you pry it out of my cold dead hands.
But I think I object a little bit to the way they complexify the React stack:

* ES6

* React

* redux and redux-saga

* react-router

* fetch

* lodash

* webpack

* post-css

* karma/mocha/sinon/chai

Of all of these things, to build a decent React app, you only need React.

It seems chintzy to bill React for the cost of webpack/browserify. I
understand why someone would: it's the worst part about working in modern
Javascript environments. But it's a build tool, not a library.

You Don't Need Redux. Most applications that use redux (or any other Flux
library) probably shouldn't. Even redux's author has been taking pains to
point out how overused redux is.

You _definitely_ don't need react-router, which is an inner-platform disaster.

Billing React for fetch and lodash also feels chintzy (especially when you try
to add a surcharge for switching from underscore to lodash).

I'm also not clear on how ES6 is somehow React's problem. Ember developers use
ES6 too. Because ES6 is better than ES5.

I'm not saying the Clef team is wrong. If they're happy with Ember, God bless
them! I'm just wary of tech advocacy articles that try to make these kinds of
stack complexity comparison arguments; I usually find them to be pretty
dubious.

~~~
jessepollak
I think this is a fair criticism and I agree that I might have used this
comparison in a simplified way to make my point, but I think the primary
thesis still holds: when building a React app, you necessarily need to make a
very large number of choices that you don't need to make when building Ember.

This isn't because React is bad, it's because React is just the view layer! If
we look at it this way, we can re-examine that list as:

* language

* view

* data modeling

* routing

* network connections

* functional utilities

* build

* styling

* testing

And, with React, when you have just a view layer, if you want to build an
advanced application, you likely need to add on a bunch of other layers to get
everything working. I hear you about being able to "just use React", but I
also think that's a an oversimplification the other way: how many applications
on the web today are built with only the view layer and none of the others?

After evaluating all the decisions we made in the past when building a React
app, we decide to trust someone else to make them for us :)

p.s. the original title was "Choosing Ember of the React ecosystem in 2016"
but I ended up shortening it :)

~~~
tptacek
Ok, and fair enough, but a simple question as a response: am I required to buy
into the idea that I need a library to cover all of these cases?

Any attribute of constructing an application you break out, people will build
libraries for. But are they necessary? In some of the cases we're talking
about --- routing and network connections, for instance --- the answer seems
to be a clear "no".

~~~
jessepollak
Ha — I'd never ask you to buy into that idea!

I think this article could easily have been titled "Choosing Ember over
building our web framework"

------
jeanlucas
Seriously, Ember philosophy of slowly aggregating what's good in web dev and
even adopting early some things (like components, and cli) makes me feel very
good using it in projects with teams. For solo projects I like to try what is
new.

------
YCode
I'm a big fan of React, but I agree styling is a mess.

CSS in JS has many limitations and virtually every alternative adds either
another library or some other convention/configuration overhead.

Other frameworks struggle with this as well but it feels like React really
shrugs off styling as the community's problem and subsequently there's a
hodgepodge of solutions that work in this or that scenario but no gold
standard.

~~~
coltonv
I've been doing SPA's in react for a while and have had 0 problems whatsoever
with styling. As long as you stick to good standards and naming conventions
and use SASS or Stylus or something to keep things organized.

What tends to give people so much trouble with styling?

~~~
YCode
It's not a huge issue, but that you have to use some third party library for
styling in a view framework just seems inadequate.

Other comparable libraries include styling into their philosophy, but React is
irritatingly unopinionated about it.

~~~
coltonv
Isn't that part of the React mantra? Everything is completely unopinionated
except for rendering HTML based on data? Like it makes no opinion on how you
should do state or HTTP requests as well as no opinion for styling, which is
something I love since it avoids duplicating code or incompatibilities with
standalone libraries.

------
jessepollak
Hey everyone - OP here! This was a really fun blog post to write and I think I
learned a bunch in the process: if you have any questions, would be happy to
answer!

~~~
duderific
FTA: >When evaluating Ember, We were excited that with ember-data there were
established patterns for how to do things — even if some of those patterns
felt a little outdated.

Could you elaborate a bit on how the ember-data patterns felt outdated?

~~~
jessepollak
Absolutely! I would say that with Ember + ember-data, the framework conforms
to a pattern where data is represented as models on the frontend, which can be
updated and persisted to the server. These updates happen through a CRUD /
REST API (in our case we conform to JSONAPI) and are generally triggered in a
controller (or a route that contains logic and acts similar to a controller in
a traditional MVC framework).

In the React ecosystem, I think there's been a pretty stark departure from
that general pattern with things like redux and GraphQL, so while we love it,
compared to what we'd been using , it felt a little behind.

Does that make sense?

~~~
duderific
Yes it does, thanks!

------
karmajunkie
Thanks for an interesting writeup. Something I'm curious about for devs who've
used ember on projects that had a maintenance period of 1-2 years: how do you
feel about it as your app grows and changes over time?

With most kitchen-sink or CoC frameworks, this is kind of the achilles' heel.
patterns get codified because they're easy and "good enough" but they DO NOT
age well. How does Ember deal with this? Also, what about the ecosystem? Is
Ember work driven almost entirely by the core framework, or is there a plugin
ecosystem that attempts to have an answer for every problem? (yes Rails, I'm
looking at you.)

~~~
evilduck
I started on Ember around the 1.12 timeframe and left that job about a month
ago and we were on 2.6. There were a couple hiccups going to 2.x but nothing
more extreme than I've experienced with any other major version update. The
Ember team also does a stellar job providing useful deprecation notices and
not breaking any minor version update, i.e. if you're on 2.1, you can upgrade
directly to 2.6 and be reasonably confident it'll still work. Your console
might get flooded with deprecation warnings, but they helpfully link to the
release docs for the change.

The only thing I'm not a huge fan of is their JSON-API as a default data
adapter, since there's a _ton_ of immature JSON-API server-side libraries with
varying levels of spec compliance and completeness. If you're backed by Rails,
you're in good shape. If you're backed by Java, you're fairly fucked.

~~~
DrStrngeluv
Some of the engineers in my office developed
[http://elide.io/](http://elide.io/) which Is an actively developed Server
side Java Json-api library.

------
iamleppert
I just took a look at the Instant 2FA app.

What exactly about this thing warrants the use of a behemoth of a framework
like Ember?

The entire app looks like an optimization of a poor experience in another web
service. I'll conserve my cynicism for their actual app, which could have been
implemented without even the need of a framework.

What is exactly complicated about a few different screens? I fail to see the
need for even a web app here.

Also, I'm not sure I understand any of their arguments. Does it really take
days to setup a test harness in anything?

Also, the bit about progressive enhancement -- are we really talking about
this still? When using a single page application framework? For an app that
does two factor auth. I'd also be concerned about the security surface area
for an app like this that pulls in a dependency like Ember, on a third party
site during the login/auth experience. It's bad enough that we have third
parties pulling in react to display some simple forms and buttons.

~~~
neikos
I also find it annoying that it seems people have transitioned from
progressive enhancement meaning 'detect if we can use JS' to 'detect which
features of JS to use' to 'detect how much processing power we can abuse
without the user noticing'.

As someone who really enjoys his <0.3s page loads (that is fully fetched &
rendered, less when from cache) even on mobile it feels annoying to not have a
'middleground'.

For example my current project, which is basically a small website where
people can upload artwork, does not need to be a SPA. However, I'd like to
integrate some interactivity to make browsing easier. Like a 'browser' view
when you click a picture, or in place reloads (so the CSS doesn't need to be
reloaded, nor perhaps the JS. However there doesn't seem to be a library for
that to my knowledge. All I know are either on the jQuery level where you have
small seperated pieces, or the React/Ember/Angular level where you have to
write all or nothing in that language.

I wonder if it is even possible to have an 'augmenter' library that just makes
existing HTML better (Perhaps with some hints in the 'data-' attributes), or
maybe my google-fu is just bad.

~~~
neikos
As a followup I don't seem to be the only one thinking like this [1]. [2]
comes close to what I'd like, but the last update is from 2012 and the author
doesn't seem to have done a lot lately.

[1]: [https://allinthehead.com/retro/367/why-is-progressive-
enhanc...](https://allinthehead.com/retro/367/why-is-progressive-enhancement-
so-unpopular) [2]:
[https://github.com/jamesallardice/Progressive.js](https://github.com/jamesallardice/Progressive.js)

------
joshuahornby
I'm a big fan of Ember, although a word of warning: To get the most out of
Ember you should follow the Ember way of doing things, we found our selfs
wrestling with Ember data, and APIs that don't follow standard responses (this
is to be expected mind)

Still a great framework for large web apps.

~~~
kemenaran
> APIs that don't follow standard responses

Interesting. In my experience the clean separation of layers in Ember-Data
(network, serialization, models) make it quite suited to non-standard APIs. I
found writing a custom (de-)serializer for a non-standard API to be relatively
easy.

Care to elaborate on what were your issues precisely?

~~~
hatsix
Not OP, but it's possible to not write any ember-data code if a server
implements json-api...

Otherwise, you have to write the same code that you have to write in other
places... except that w/ Ember Data there are core patterns and its easy to
add tests.

Writing Ember against an API that speaks json-api is a magical experience :-D

~~~
steveklabnik
So happy to hear JSON API is working that well for you :)

------
babbeloski
I cut my teeth on Ember at a marketing company in 2013, and actually found my
current job through acquaintances made by attending a weeklong Ember training
session in Boston (led by yehuda and tom). It had been a great fit for me at
the marketing company because the apps I was developing were more restful
oriented crud apps. apps with a lot of routes that were more or less their own
thing (not too much shared state).

The company that I joined was using Ember, but their app was more of an
analytic dashboard and it didn't really have more than a handful of routes.
the amount of views and logic and state that lived on each route / controller
was insane. Also, between the few routes you really needed to share state and
things got very messy. I'm still with the company today, and the app's routing
is still controlled by ember, but we have switched entirely to react + redux
and are a lot closer to being off ember completely.

The real boon for us has been the single source of truth and the connect
function from react-redux. Basically any component can just declare the data
it relies on via store query functions e.g. getLabelsForUser(state, userId),
which breaks you free from the uber painful process of passing properties down
the entire view tree to child nodes.

I also got a lot better at developing when I started developing for react,
because I was no longer writing framework code, I was writing and utilizing my
own functions and abstractions.

I'm not saying ember is inferior, but of course there are trade offs to both.
I absolutely love yehuda and tom, they are so prolific, but I would be
interested in seeing how ember apps fair when there are only a couple of
routes but a ton of view logic and state; where does the state live and how is
it coordinated. How do you coordinate data across the app hierarchy? Asking
because I really failed at that 2 years ago and ended up with a mess, it
definitely felt like uncharted territory. Would totally accept developer
error.

~~~
hybridcivic182
agreed - checkout the official redux bindings for ember (a cargo cult of the
connect api from react-redux)

[https://github.com/toranb/ember-redux](https://github.com/toranb/ember-redux)

------
Touche
Note that you should not choose Ember if you are creating an app intended to
be used on mobile, as it doesn't yet have code-splitting. This talk explains
about why this is a hard requirement:
[https://www.youtube.com/watch?v=4bZvq3nodf4](https://www.youtube.com/watch?v=4bZvq3nodf4)

~~~
codinghorror
It isn't just worse on Android it is BRUTAL on Android.

I was deeply unhappy with the 3x-5x widening iOS and Android JavaScript perf
gaps through 2014 and 2015 (TL;DR Qualcomm has completely lost the plot) but
in 2016, it's.. even worse.

The good news is, Ember 2.10 looks like a major speed improvement! The bad
news is, Android is still 10x slower with Ember.

[http://discuss.emberjs.com/t/why-is-ember-3x-5x-slower-on-
an...](http://discuss.emberjs.com/t/why-is-ember-3x-5x-slower-on-
android/6577/59)

It would be a bit more even if Apple wasn't delivering substantial speed
improvements, year after year, consistently.

~~~
Touche
You're talking about rendering performance, but I'm talking about performance
issues caused by bundle size.

------
fooey
Instant2FA sounded like a great thing to pitch internally, then I saw they
want 10 cents for every login, ouch

~~~
traviscj
Assuming 1 login/day and 85k/year annual employee cost (practically a joke,
especially in the Bay Area) and 250 work days/year, it comes out under 3 bps
(0.03%) of the employee cost. Probably not crazy for two factor, vs
distracting yourself from your actual business goals?

------
allendoerfer
I like the author's focus on results and team productivity. Standardized tools
are key for that. This is also my main concern, when it comes to JavaScript
frameworks and libraries. While Ember seems very good at that front, when
talking about a single project or multiple very similar projects, I would like
to add another point:

As soon as you are working with different platforms (the author mentioned
WordPress), you should not necessarily integrate everything all the way up.
Because now you have your Ember based build process and maybe something gulp-
based for WordPress.

I always try to find frameworks, which has all the things only concerning
itself integrated into (say server-side rendering etc.) but then stops there
and makes use of preferably the two or three leading tools (e.g. grunt/gulp
plugin) for all the other concerns.

That way you can choose a standard stack and only consider new frameworks if
they work reasonably well with it.

------
msimpson
"...the thought of Ember making all these decisions for us — enforcing a
convention over configuration — was very alluring"

Alluring, yes. Good? You shall see. When you embark on using an opinionated
framework development can, at first, seem easy. It's when those opinions
change that you can easily get hurt, however.

~~~
Touche
I find that convention over configuration often is trying to solve the wrong
thing. It puts a tremendous burden on the user to know all of these
conventions when being simple and direct usually works just fine.

One example is an Ember RFC I read recently about the required folder
structure of Ember projects. It wasn't clear to me at all _why they were even
doing this_. Like, what were the gains? It turns out the entire point is some
magic auto-discovery of things like Handlebars helpers.

~~~
msimpson
Yeah. Those sort of nuances can often be the hardest to discover and/or debug.

------
mevile
I don't have much experience with Ember, but I have a spent a lot of
professional time with React development, well over a year now. Initially I
quite loved it but that love affair is over.

My problem with React aren't complaints about front-end tooling and build
systems. My problem with React is its emphasis on a tree like relationship
among components. This is an unnatural paradigm for application development.
Certainly user interfaces can be thought of in the form of a tree, but another
way to think about application development is to consider the view a canvas,
with areas to fill in.

React's strong tree type architecture makes some forms of common user
interface development feel unnatural and ungainly, things like modals, toasts,
or things that just don't fit into a neat little area of the screen in a
sibling child parent relationship. Also anything that happens after a render,
like animation, also has the same kind of unnatural cludgy development process
and I often have found myself fighting what to render when with
shouldComponentUpdate.

I'm not saying these things are impossible or even hard, it's that they're
unnecessarily ungainly when those things should be simple. I've also think in
practice that components far down the React tree become second class citizens,
the source of bugs, less well designed and often quite dependent and highly
coupled with parent elements.

Another problem I have is tooling related, it's the wave updates that you have
to deal with whenever React updates. React and many well maintained libraries
do this really well but there's always some bad actor in the ecosystem that
makes it a pain and frankly I never look forward to a new React version. Again
I understand that all these things are problems that can be overcome and I
have, but I'm frankly over it.

I know I'll probably be writing React based applications for an employer for a
very long time, but I would no longer recommend it. I think vue.js is a
promising new library. I think there are things to be said about how React is
very good about enforcing modular component development and I quite like flux
and redux, but React in general. React is just not great.

~~~
shados
"things like modals, toasts, or things that just don't fit into a neat little
area of the screen in a sibling child parent relationship"

That's actually where React is very strong compared to other functional-style
UI frameworks (eg: Elm's). Portals in React are really elegant and makes
dealing with modals and toasts (or anything that doesn't fit in this model)
quite nice.

I was working today with someone who was making a browser extension to inject
stuff in host pages (think something like LastPass or those rulers for
designers).

We made a set of components that create arbitrary elements at arbitrary
locations, or highjack existing ones, and from there you get to manipulate
things like you would any other functional-style UI. It's quite lovely (all
thanks to the lifecycle hooks and React's ability to render subtrees anywhere
on the screen). Very few tools do it as well as React does, otherwise I'd be
writing Elm all day instead of JavaScript.

~~~
mevile
You're achieving that with separate calls to render. In an ideal React
application you only have a single render call. So no, you're not
demonstrating a good use of React and you're certainly not showing this to be
a strength in React. Imagine, you wouldn't call react.render from inside an
existing React component. That's ridiculous.

~~~
shados
React's escape hatches ARE its strength. If you don't need them, you can just
use any ol vanilla virtual dom library.

The entire reason for React's existance is to slap escape hatches on top of a
vdom so you can work functionally in a non-functional environment.

------
mklarmann
As I do understand, conventions manifest often in the setting of defaults for
configurations. These defaults are inherently opinionated, and therefor hinder
the free development of innovation in a open source community. As it will
always favor a specific solution over another.

Conventions over configurations comes to the benefit for small team, beginners
and is in general more fun to code with. But it comes at the cost of being
much slower in adopting new patterns and innovations. As there is currently so
much speed in javascript development happening, I wonder if for now
configuration do outpace conventions, until the battle field has settled.

React has acknowledged the situation and tries to get the best of both world
with its quest for a React CLI. Did they know about it at the time of writing?

------
sriram_iyengar
Ember is an excellent choice. We use it in a real large scale project and
really love the 'addon' way of managing modules. Its simple and comes straight
out of the box. Our teams follow BEM for css and maintain 1:1 for a
component/route and css file.

------
mooreds
Wow, this is great. It's good to hear an considered opinion piece that lays
out good and bad points of the technology, especially from someone versed in a
different space.

As the perlers wisely said: TMTOWTDI

------
delambo
In the React ecosystem, there are several really good tools for managing
build, deploy, and test harnesses. See kyt [1] for example, or the list of
Create React App Alternatives [2].

[1] [https://github.com/NYTimes/kyt](https://github.com/NYTimes/kyt) [2]
[https://github.com/facebookincubator/create-react-
app#altern...](https://github.com/facebookincubator/create-react-
app#alternatives)

------
svschannak
There are a lot of people out there making such decisions every day. Does
anyone know a guide for making the right technology decision?

------
jamesmp98
Ember seems really cool, but I've never had anything big enough I've wanted to
use it on. In fact, I have not used a JavaScript framework for a while (unless
you count an Ionic app a few months back. Ember's learning curve seems a bit
steep too.

------
lightblade
To be honest, I really miss the good old flex + wsdl days.

Component architecture, check. Two way binding, check. Optional type, check.
IDE, check.

My favorite, typed components, check.

------
andrewvijay
The article should have been titled 'ember tooling vs react tooling' I guess.
The explanation is only about the tooling rather than the framework. Good
write up though. Intriguing to try Ember this weekend!

~~~
jeanlucas
If you try, send over the link for us to test.

~~~
andrewvijay
Oh sure.

------
leshow
the lesson here is not to choose a bunch of random libraries you have no
experience with. there was likely no need for you to:

1\. create your own build system when something like create-react-app exists

2\. use something like redux-saga when promises and async/await would suffice

3\. likely you probably didnt even need redux, the application looks fairly
small and doesn't look like it has a lot of internal state.

tl;dr you did it to yourself

~~~
dasil003
How do you get experience with a library if you never choose a library with
which you have no experience?

~~~
leshow
You reach for a library because it solves some particular need that you have,
not just because.

