3 ms·

If Ember is going to borrow so heavily from React, why not just use React and Flux instead?

by sshillo 11y ago

adamnemecek 11y ago
React is a library, Ember is a framework.
- ubercore 11y ago
  I think maybe the parent comment is wondering "Why Glimmer and not React for the rendering library?"
  - wycats 11y ago
    We talk about this a bunch in https://www.youtube.com/watch?v=qwIyenCaSXk https://www.youtube.com/watch?v=qwIyenCaSXk The TLDR is: * We like templates, and were able to implement a more efficient algorithm using them (even more than the recent improvements in Babel). * Compatibility is important to us, so HTMLBars was going to be a much better transition story for Ember 1.x than JSX. * We prefer an HTML-centric templating story (copy/paste valid HTML and it works) over an XML strategy that requires camelCasing, className/htmlFor, etc. * We optimized Glimmer for a hybrid (rerender + subscriptions to the model or service layer) model that can opportunistically avoid work based on knowledge we have from the whole stack.
    - seivan 11y ago
      The Youtube video just says "Please stand by.".
      - wycats 11y ago
        Whoops: https://youtu.be/msS-3zqKKUI?t=51m5s https://youtu.be/msS-3zqKKUI?t=51m5s
    - mrcwinn 11y ago
      Fair enough, but I would argue JSX is just as "HTML-centric" as anything Ember has implemented, so long as we agree "HTML-centric" means, practically speaking, "not HTML."
      - wycats 11y ago
        What I mean specifically is that if you copy and paste some valid HTML from inside a body tag, it will work. That is an explicit non-goal of JSX, and it shows.
k__ 11y ago
I don't know if they implemented it like React. There are a bunch of virtual DOM implementations out there who are faster. Also, for the most part, it's a drop in replacement for the old rendering.
wycats 11y ago
That's a completely fair question since large parts of this blog post are focused on major Ember 2.0 features, many of which were strongly inspired by React. As you know, React describes itself as the V in MVC; in contrast, Ember is a complete front-end stack, including not only a model and service layer, but also a built-in router, integrated command-line tools, and an add-on ecosystem that takes advantage of that common set of assumptions. It's also safe to say that the React community is still exploring the space of the application layer: multiple flavors of the original Flux architecture, Facebook's recent announcement of a successor (Relay), and different routing libraries that work well with React. We believe that there are productivity benefits to having the community coalesce around a single stack, but we also believe that it's important to avoid stagnation. That's why Ember 2.0 is both focused on bringing in some of the great ideas that React has pioneered in the view layer, but maintains many other aspects of the 1.0 stack. We make the changes compatibly on the 1.x branch with a clear transition plan so that we can bring along as many existing users as possible.
bluepnume 11y ago
Well... for a start, there are many existing apps written in Ember. These will get a immediate, backwards compatible boost in performance. Quite often "why not rebuild" isn't exactly going to be a trivial exercise. For new apps, the "why Ember over React" exercise is left to the reader. They're both excellent at what they do.

If Ember is going to borrow so heavily from React, why not just use React and Flux instead?

by sshillo 11y ago

If Ember is going to borrow so heavily from React, why not just use React and Flux instead?

adamnemecek 11y ago

React is a library, Ember is a framework.

ubercore 11y ago
I think maybe the parent comment is wondering "Why Glimmer and not React for the rendering library?"
- wycats 11y ago
  We talk about this a bunch in https://www.youtube.com/watch?v=qwIyenCaSXk https://www.youtube.com/watch?v=qwIyenCaSXk The TLDR is: * We like templates, and were able to implement a more efficient algorithm using them (even more than the recent improvements in Babel). * Compatibility is important to us, so HTMLBars was going to be a much better transition story for Ember 1.x than JSX. * We prefer an HTML-centric templating story (copy/paste valid HTML and it works) over an XML strategy that requires camelCasing, className/htmlFor, etc. * We optimized Glimmer for a hybrid (rerender + subscriptions to the model or service layer) model that can opportunistically avoid work based on knowledge we have from the whole stack.
  - seivan 11y ago
    The Youtube video just says "Please stand by.".
    - wycats 11y ago
      Whoops: https://youtu.be/msS-3zqKKUI?t=51m5s https://youtu.be/msS-3zqKKUI?t=51m5s
  - mrcwinn 11y ago
    Fair enough, but I would argue JSX is just as "HTML-centric" as anything Ember has implemented, so long as we agree "HTML-centric" means, practically speaking, "not HTML."
    - wycats 11y ago
      What I mean specifically is that if you copy and paste some valid HTML from inside a body tag, it will work. That is an explicit non-goal of JSX, and it shows.

k__ 11y ago

I don't know if they implemented it like React. There are a bunch of virtual DOM implementations out there who are faster. Also, for the most part, it's a drop in replacement for the old rendering.

wycats 11y ago

That's a completely fair question since large parts of this blog post are focused on major Ember 2.0 features, many of which were strongly inspired by React. As you know, React describes itself as the V in MVC; in contrast, Ember is a complete front-end stack, including not only a model and service layer, but also a built-in router, integrated command-line tools, and an add-on ecosystem that takes advantage of that common set of assumptions. It's also safe to say that the React community is still exploring the space of the application layer: multiple flavors of the original Flux architecture, Facebook's recent announcement of a successor (Relay), and different routing libraries that work well with React. We believe that there are productivity benefits to having the community coalesce around a single stack, but we also believe that it's important to avoid stagnation. That's why Ember 2.0 is both focused on bringing in some of the great ideas that React has pioneered in the view layer, but maintains many other aspects of the 1.0 stack. We make the changes compatibly on the 1.x branch with a clear transition plan so that we can bring along as many existing users as possible.

bluepnume 11y ago

Well... for a start, there are many existing apps written in Ember. These will get a immediate, backwards compatible boost in performance. Quite often "why not rebuild" isn't exactly going to be a trivial exercise. For new apps, the "why Ember over React" exercise is left to the reader. They're both excellent at what they do.