5 ms·

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

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.

hybridcivic182 10y ago
mutable APIs are so 2015 - ember and redux for the best of both worlds https://github.com/toranb/ember-redux https://github.com/toranb/ember-redux
- kimshibal 10y ago
  You are still using redux? Everyone is moving to mobx
  - tsxxst 10y ago
    Could you elaborate on why mobx is better than redux other than "new and shiny"?
    - Lazare 10y ago
      I grumpily ignored the comments about mobx for a while, then finally broke and used it on a small side project. The results were... ...disheartening. Because (at least for my team and the specific projects we do), mobx was much much better. (Disclaimer: We use React to incrementally replace/upgrade pages and panels in a very large admin console. So we have a ton of very small apps that share a lot of concepts, but are still distinct apps. Obviously this multiplies the amount of boilerplate we have to deal with compared to if we were using a single "monolithic" SPA.) Key advantages: 1) Way, way, way less boilerplate. With redux you soon grow used to the dance of adding a new sub-reducer, a new batch of constants, a new batch of action creators, then wiring up the new action creators to your container, wiring up the new state sub-trees to your container, and boom, now you've got some props that represent your data, and some functions you can call to change that date. With mobx, you add some new observers and (optionally) some actions to change those observers and...you're done. It feels odd at first; when you're used to redux you're used to setting up a new app (or coming to grips with an old one you haven't touched in a while) as a very elaborate process. With mobx the "skeleton" is done before you even really start. It's almost worrying. 2) Redux has some very specific ways it wants you to structure your project, and some of them are quite good. A junior dev might struggle to grasp what's required to set it up from scratch, but I think for an intermediate dev it can be quite helpful. It strongly forces you to make some good choices about data flow, seperation of concerns, logging, etc. But for a senior dev it can be a little...limiting. I actually know what I'm doing, and sometimes the right answer doesn't 100% fit into the Redux way of doing things, even if the "redux way" is great 95% of the time. Mobx allows a lot more flexibility. I suspect that could be a drawback in some cases too, but for this particular case, it's quite nice. You can actually implement a number of different patterns on top of mobx, including a redux style state tree, or (as we've done) some Backbone/ActiveRecord style models. Which obviously have a lot of limitations and are great for everything, but are really great for our specific use case. 3) On a related note, redux really needs data to be normalized; you end up devoting a remarkable amount of time to normalizing data (using normalizr or whatever) and then de-normalizing it in your components to handel relations properly, and then figuring out how to modify your normalized state tree in your reducers based on actions triggered in your denormalized component tree. Totally doable, but a pain. Mobx makes it easy to use references, avoiding the entire issue. 4) Closely related to the last two points, components written with redux in mind often end up with very extensive lists of props, because they end up needing a little bit of data from six different reducers, plus a dozen action creators. It works. It's fine! But... ...with mobx, at least the way I'm using it, you can generally get away with just passing in the relevant model, You keep ending up with situations where you pass your ProductList model into your ProductList component, which maps over the Product models it contains and passes them into a component called Product. Your actions are just methods on the model class. Components with 1-2 props are easier to reason about and (in my experience) easier to test. All of which is basically just 4 different ways of saying that for me, it lets me type a lot less (which is good), but most of all it lets me think more about the problem I'm trying to solve, and less about the libraries I'm using (which is key).
      - cageface 10y ago
        Thanks for the taking the time to write this up. I'm using redux for the first time and I really hate it. It may be the least DRY state management approach I've ever seen. This will be helpful in convincing my colleagues to give mobx a try on our next project.
        TooterBoo 10y ago
        What do you hate about Redux? I went from Flux to Reflux to Redux and it really makes state management easy from my experience. You should give the idiomatic redux videos at egghead.io a try: https://egghead.io/courses/building-react-applications-with-idiomatic-redux https://egghead.io/courses/building-react-applications-with-...
  - woah 10y ago
    I looked at mobx, but it did not appeal to me at all. Lots of ceremony (observables) to eliminate a small amount of typing. The power of Redux is that it works in an extremely simple way and you can hold the operation of the framework in your head along with your app. Redux is just a big switch statement that ingests plain action objects and outputs a modified state object, along with a connect function to bring parts of the state object into your components. Mobx looks quite baroque in comparison.
  - estefan 10y ago
    I only worked on a react/redux app last year and things have changed again... sniff
spinlock 10y ago
I've worked on 2 production Ember apps. The first was a nightmare because there were 2 way bindings and the team that built it didn't know how to use the router. The second was a dream because we built it after a couple of years dealign with the fallout from a bad ember app (plus "data down - actions up" was now the prescription). Ember can be really nice if you follow the happy path.
phereford 10y ago
I completely echo this sentiment. I like Ember, but have found that the learning curve of a React/Redux app is significantly smaller than that of a similar Ember app. Small sample size for me (2 Ember projects, 6+ React projects), but the entry level engineers to the senior level engineers seem to grasp React/Redux MUCH faster than Ember.
postcarnival 10y ago
> 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 10y ago
  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 10y ago
    yep, this

hybridcivic182 10y ago

mutable APIs are so 2015 - ember and redux for the best of both worlds https://github.com/toranb/ember-redux https://github.com/toranb/ember-redux

kimshibal 10y ago
You are still using redux? Everyone is moving to mobx
- tsxxst 10y ago
  Could you elaborate on why mobx is better than redux other than "new and shiny"?
  - Lazare 10y ago
    I grumpily ignored the comments about mobx for a while, then finally broke and used it on a small side project. The results were... ...disheartening. Because (at least for my team and the specific projects we do), mobx was much much better. (Disclaimer: We use React to incrementally replace/upgrade pages and panels in a very large admin console. So we have a ton of very small apps that share a lot of concepts, but are still distinct apps. Obviously this multiplies the amount of boilerplate we have to deal with compared to if we were using a single "monolithic" SPA.) Key advantages: 1) Way, way, way less boilerplate. With redux you soon grow used to the dance of adding a new sub-reducer, a new batch of constants, a new batch of action creators, then wiring up the new action creators to your container, wiring up the new state sub-trees to your container, and boom, now you've got some props that represent your data, and some functions you can call to change that date. With mobx, you add some new observers and (optionally) some actions to change those observers and...you're done. It feels odd at first; when you're used to redux you're used to setting up a new app (or coming to grips with an old one you haven't touched in a while) as a very elaborate process. With mobx the "skeleton" is done before you even really start. It's almost worrying. 2) Redux has some very specific ways it wants you to structure your project, and some of them are quite good. A junior dev might struggle to grasp what's required to set it up from scratch, but I think for an intermediate dev it can be quite helpful. It strongly forces you to make some good choices about data flow, seperation of concerns, logging, etc. But for a senior dev it can be a little...limiting. I actually know what I'm doing, and sometimes the right answer doesn't 100% fit into the Redux way of doing things, even if the "redux way" is great 95% of the time. Mobx allows a lot more flexibility. I suspect that could be a drawback in some cases too, but for this particular case, it's quite nice. You can actually implement a number of different patterns on top of mobx, including a redux style state tree, or (as we've done) some Backbone/ActiveRecord style models. Which obviously have a lot of limitations and are great for everything, but are really great for our specific use case. 3) On a related note, redux really needs data to be normalized; you end up devoting a remarkable amount of time to normalizing data (using normalizr or whatever) and then de-normalizing it in your components to handel relations properly, and then figuring out how to modify your normalized state tree in your reducers based on actions triggered in your denormalized component tree. Totally doable, but a pain. Mobx makes it easy to use references, avoiding the entire issue. 4) Closely related to the last two points, components written with redux in mind often end up with very extensive lists of props, because they end up needing a little bit of data from six different reducers, plus a dozen action creators. It works. It's fine! But... ...with mobx, at least the way I'm using it, you can generally get away with just passing in the relevant model, You keep ending up with situations where you pass your ProductList model into your ProductList component, which maps over the Product models it contains and passes them into a component called Product. Your actions are just methods on the model class. Components with 1-2 props are easier to reason about and (in my experience) easier to test. All of which is basically just 4 different ways of saying that for me, it lets me type a lot less (which is good), but most of all it lets me think more about the problem I'm trying to solve, and less about the libraries I'm using (which is key).
    - cageface 10y ago
      Thanks for the taking the time to write this up. I'm using redux for the first time and I really hate it. It may be the least DRY state management approach I've ever seen. This will be helpful in convincing my colleagues to give mobx a try on our next project.
      - TooterBoo 10y ago
        What do you hate about Redux? I went from Flux to Reflux to Redux and it really makes state management easy from my experience. You should give the idiomatic redux videos at egghead.io a try: https://egghead.io/courses/building-react-applications-with-idiomatic-redux https://egghead.io/courses/building-react-applications-with-...
- woah 10y ago
  I looked at mobx, but it did not appeal to me at all. Lots of ceremony (observables) to eliminate a small amount of typing. The power of Redux is that it works in an extremely simple way and you can hold the operation of the framework in your head along with your app. Redux is just a big switch statement that ingests plain action objects and outputs a modified state object, along with a connect function to bring parts of the state object into your components. Mobx looks quite baroque in comparison.
- estefan 10y ago
  I only worked on a react/redux app last year and things have changed again... sniff

spinlock 10y ago

I've worked on 2 production Ember apps. The first was a nightmare because there were 2 way bindings and the team that built it didn't know how to use the router. The second was a dream because we built it after a couple of years dealign with the fallout from a bad ember app (plus "data down - actions up" was now the prescription). Ember can be really nice if you follow the happy path.

phereford 10y ago

I completely echo this sentiment. I like Ember, but have found that the learning curve of a React/Redux app is significantly smaller than that of a similar Ember app. Small sample size for me (2 Ember projects, 6+ React projects), but the entry level engineers to the senior level engineers seem to grasp React/Redux MUCH faster than Ember.

postcarnival 10y ago

> 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 10y ago
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 10y ago
  yep, this