Ryan Florence's React talk - does not make Ember look very good

Performance
1

Felt a little sad watching this talk and was interested in hearing some performance specialists chime in about Ember’s direction.

I would also love to see what this demo would look like with the latest version of Ember. Are we expecting speeds that are comparable to React?

I think it’s worth a watch, some pretty awesome demo’s going on.

2

Just pulled down the repo and downgraded to ember.prod.js (1.9.1) and the memory leak is mostly fixed. Still feels pretty slow through.

3

Major performance improvements are planned, they just take time.

1 Like
4

@mmun - appreciate all the hard work you guys have done. Also, just saw this on Twitter :blush:

1 Like
5

The performance aspect is not the sad part, looking at those amazing animations made me consider giving React a shot.

2 Likes
6

I knew about the diffing stuff coming, but I wonder if that will enable the React style “magic moves” mentioned in the video.

7

Indeed, you could do the same in Ember but it would not be easy in Ember’s current state.

8

Are the demos in the video a fair comparison to ember? React lets you do cool things but ember’s goal seems different - it’s a framework for building large maintainable apps and tries to be a guard rail to prevent devs from hurting themselves. I figure with goals like that it’s natural to make some big compromises.

More than anything, I was bummed to see Ryan Florence moving on from ember to react. I loved his ember 101 video tutorials and he is great at explaining things.

5 Likes
9

does not make Ember look very good

No it doesn’t, but these are areas of improvement and are being worked on.

10

Did Ryan mentioned which version of Ember he used in the demo?

11

You can look at the repo, it’s 10 beta 4, so it has HTMLBars…

12

Are the demos in the video a fair comparison to ember? React lets you do cool things but ember’s goal seems different

Exactly. React is much smaller in scope, since it focuses on Views. It has a relatively shallow learning curve and is easier to “sell” as a result.

In all fairness: the presentation did point out that frameworks are bound to catch up in terms of performance eventually. Performance is not an advantage that will hold in the long term.

2 Likes
13

And even in the short to medium term :wink:

14

To be honest, having tried to get similar things to happen in Ember, I’m with you. I’m going to give Liquid Fire a fair shake first though.

1 Like
15

Yeah, it’s a shame that Ryan only seems to have vitriol to give out these days, as far as Ember is concerned.

16

First off, I wouldn’t say Ryan’s had vitriol (at least, none that I’ve seen and I’ve followed him on Twitter for some time). Furthermore, a lot of his concerns are very real. If I had to give my own list of complaints on Ember:

  • JS heavy apps do not perform well on Android/Cordova Android (hoping the fix in chrome webview will improve this in a few months)
  • It’s hard to build good nestable components like carousels, off-canvas, or modals without some serious work arounds. (1.10’s refactor mostly addresses this with block params).
  • initial render time is horrendous. Fastboot and HTMLBars will (hopefully) fix this, but I suspect more could be done to address how slow Ember is to get going. Compare the refresh time of Ember to Angular and React in Ryan’s presentation.
  • adding to, removing from, or reordering collections/lists is basically a no can do. (again HTMLBars is likely to fix this, especially once the react style diffing is involved). To be able to do this well, you’ll need to design and implement custom components for managing your lists. You don’t get performant list handling out of the box, and nearly every big data type or digest is a list.
  • Bindings, CPs, Observers encourage a very broken data flow that quickly make things such as validation-inputs much trickier to implement well. I think the new explicit binding and streams are great things.
  • The Ember.run family is passed by very quickly in explanations “it’s here but you’ll probably not need it”. In actuality, Ember.run.schedule will save your app’s mobile performance. In my own case, I implemented two new queues in Addition to Ember’s own for handling background tasks and background data refreshing after afterRender concludes.

In short, Ember as an MVC framework is pretty awesome, but Ember for performance is not. Using Ember.run correctly, I think Ember does a far better job than Angular (I don’t know about React) at managing a JS heavy app without overloading the CPU, but as much ground it gains there it loses far more with it’s poor rendering performance. Rendering performance is definitely something Ember can fix, mostly because it’s been architected in a manner that improving parts doesn’t require a framework overhaul.

I’m not bailing on Ember after seeing React’s render performance put on full display. I think we’ll gain this ground back and then some with HTMLBars + React style diffing, and I think React’s code style disregards separation of concerns to a level that forces designers to be engineers.

6 Likes
17

The performance improvements are a multi-part endeavor not fully encompassed by HTMLBars. HTMLBars brings some improvements but there are more in store.

1 Like
18

I think React’s code style disregards separation of concerns to a level that forces designers to be engineers.

Exactly.

I feel your point needs to be highlighted as a strength of Ember, because it does allow for a separation of work and responsibility between dev and designer.

As someone who works along side a designer that writes Emblem for my project, the pain caused by forcing him to be more-of-a-developer-than-he-would-like-to-be is severe. Putting him through the pain of switching his design-world to React would be ludicrous, just so our app could get more FPS (as it were).

2 Likes
19

I would suggest that the team make this priority to solve as perf has been haunting for a well. Originally the expectation is that HTMLBars would make it go away but it seems like it is still going to take some time.

To me, it is great that we have features like server rendering down the road, but in the near term, this perf issue is affecting our ability to deliver top notch customer experience, and I know that the awesome Ember team can solve this! :smile:

20

I’ve followed him for a long time too.

vit·ri·ol noun

  1. cruel and bitter criticism.

Here’s a couple of his Tweets:

Every Ember app is a rats nest of implicit dependencies, performance nightmares, unclear action handling, and requisite object mutation.


Let's talk about hype: htmlbars fell flat on its face for performance. It's still terrible.

I’m not saying his points aren’t valid, but I stand by my choice of description for his new attitude these days.

1 Like