6 ms·

I really like Ember as well and uses it daily. However, if I could remake my decision I would not pick Ember today since it's too opinionated for the current pr

I really like Ember as well and uses it daily. However, if I could remake my decision I would not pick Ember today since it's too opinionated for the current project I am working on. Our stack, as it turns out, is not really ember-friendly. For example, we need several endpoints for the same models which was a pain to get to. Also we don't use jsonapi which also is a pain if you use ember and so on. We didn't know these things before picking the framework, but it's really opinionated which can be a good thing as long as you pick the same opinions and solutions as they do. Developing in Ember for me means basically figuring out how to implement stuff that Ember already have out of the box since we cannot use some of that. But when we can, development is a breeze. If anyone is thinking of using Ember for a new project, be really sure that Ember really is going to work with you and not against you.

vertex-four 10y ago
Note that Ember is not actually strongly tied to Ember Data - the model() function on a route can return any Ember promise, and you can save data however you want. If the rest of Ember is roughly what you want, implementing a custom method of getting Ember objects from API responses and vice versa is probably easier than trying to wrangle Ember Data into doing what you need.
- staticelf 10y ago
  We had a discussion if we should skip Ember Data or not but concluced that it seemed easier to write custom serializers and adapters for most models instead. Maybe it was an incorrect assessment but after a pretty steep learning curve I can at least say I know a lot about how ember works :) Also, if you do not use Ember Data, you don't get to use the data part of the nice Ember plugin for web browsers.
  - Touche 10y ago
    I don't follow your criticism then. Sounds like you have a really bizarre back-end setup and Ember provides you a low-level way to integrate it, so how is that "too opinionated"? Did you expect a high-level API that would work with this multiple endpoint setup?
    - ehsanu1 10y ago
      Clearly the criticism is that it was very muh harder than it had to be, due to the opinionated nature of Ember, even though it's possible. Eg, things you expect to work just not working, because some hidden convention is being violated, and requiring a bunch of hacks to make it work (making this example up btw, I haven't done any Ember). I'm not sure I'd conclude that their backend is bizarre, sometimes things cannot be perfectly resource-oriented in a 1:1 fashion with the backend. I know I've needed to expose two different endpoints and frontend models for the same backend model, for good reasons.
      - mnutt 10y ago
        If your data isn't resource-oriented, you are probably better off without ember-data. We started off using ember-data with an aggregated stats API and eventually found that just using regular ajax was much easier. No hacks needed, just define model() as an ajax call and don't pull in ember-data. If you're using ember without ember-data, you don't have a "store" and ember-inspector's data-store inspector won't do anything. You'll probably end up having to look at network calls. Ember is opinionated in plenty of ways, but I don't think reliance on ember-data is one of them.
      - staticelf 10y ago
        This. I can say that maybe it would have been a better choice to go without Ember Data but since we started there is simply too much work to redo a lot of stuff instead of just continuing in the same path. We didn't know ember had these conventions when we started working with it since it doesn't really advertise it and the problem first arises when you're trying to do something that feels easy but gets complicated due to Embers convention.
      - Touche 10y ago
        > Clearly the criticism is that it was very much harder than it had to be, due to the opinionated nature of Ember, even though it's possible. The opinion is just wrong, then. It wasn't harder because Ember is opinionated. It wouldn't have been any easier with React, which has no model layer at all.

vertex-four 10y ago

Note that Ember is not actually strongly tied to Ember Data - the model() function on a route can return any Ember promise, and you can save data however you want. If the rest of Ember is roughly what you want, implementing a custom method of getting Ember objects from API responses and vice versa is probably easier than trying to wrangle Ember Data into doing what you need.

staticelf 10y ago
We had a discussion if we should skip Ember Data or not but concluced that it seemed easier to write custom serializers and adapters for most models instead. Maybe it was an incorrect assessment but after a pretty steep learning curve I can at least say I know a lot about how ember works :) Also, if you do not use Ember Data, you don't get to use the data part of the nice Ember plugin for web browsers.
- Touche 10y ago
  I don't follow your criticism then. Sounds like you have a really bizarre back-end setup and Ember provides you a low-level way to integrate it, so how is that "too opinionated"? Did you expect a high-level API that would work with this multiple endpoint setup?
  - ehsanu1 10y ago
    Clearly the criticism is that it was very muh harder than it had to be, due to the opinionated nature of Ember, even though it's possible. Eg, things you expect to work just not working, because some hidden convention is being violated, and requiring a bunch of hacks to make it work (making this example up btw, I haven't done any Ember). I'm not sure I'd conclude that their backend is bizarre, sometimes things cannot be perfectly resource-oriented in a 1:1 fashion with the backend. I know I've needed to expose two different endpoints and frontend models for the same backend model, for good reasons.
    - mnutt 10y ago
      If your data isn't resource-oriented, you are probably better off without ember-data. We started off using ember-data with an aggregated stats API and eventually found that just using regular ajax was much easier. No hacks needed, just define model() as an ajax call and don't pull in ember-data. If you're using ember without ember-data, you don't have a "store" and ember-inspector's data-store inspector won't do anything. You'll probably end up having to look at network calls. Ember is opinionated in plenty of ways, but I don't think reliance on ember-data is one of them.
    - staticelf 10y ago
      This. I can say that maybe it would have been a better choice to go without Ember Data but since we started there is simply too much work to redo a lot of stuff instead of just continuing in the same path. We didn't know ember had these conventions when we started working with it since it doesn't really advertise it and the problem first arises when you're trying to do something that feels easy but gets complicated due to Embers convention.
    - Touche 10y ago
      > Clearly the criticism is that it was very much harder than it had to be, due to the opinionated nature of Ember, even though it's possible. The opinion is just wrong, then. It wasn't harder because Ember is opinionated. It wouldn't have been any easier with React, which has no model layer at all.